CRAFT et obsession de la mesure : auto-évaluez vous !

Chez OCTO, nous sommes organisés en tribu. La tribu CRAFT a pour but d’accompagner à l’adoption des pratiques du software craftsmanship pour nos clients mais aussi pour nous-mêmes.

Or, il y a un peu plus d’un an, des “anciens” octos ont constaté des projets de delivery en souffrance. Nous avons été plusieurs à constater que les pratiques crafts n’étaient pas toutes adoptées sur ces projets, notamment le TDD et les revues de code. De là sont parties plusieurs discussions, hypothèses et autres conjonctures. Mais la vraie question était : nos recrues sont-elles formées à ces pratiques ?

Le meilleur moyen qu’on ait trouvé pour avoir la réponse, c’est de leur demander : on ne pilote que ce qu’on mesure.

Sondage et initiatives

Nous avons donc lancé un sondage le plus factuel possible à destination des octos. Nous avons obtenu une centaine de réponses qui étaient en plus représentatives de la répartition de séniorité et d’expérience chez OCTO. Nous avons publié ces résultats en interne dans un souci de transparence et pour susciter des initiatives.

Les premières initiatives étaient l’accompagnement de craft·wo·men au sein d’équipe OCTO sur des projets de delivery, la tenue de BOF, REX et autre BBL pour sensibiliser aux pratiques de TDD et de code review.

Le timing correspondait aussi au lancement de notre livre blanc sur les pratiques craft : Culture Code. Initialement prévu pour sensibiliser nos clients, Culture Code a eu comme bénéfice de sensibiliser également en interne.

Autre timing parfait, la mise en place d’OCTO Skool, dont l’objectif sera détaillé dans un prochain article, est de former nos recrues juniors aux pratiques agile et craft en proposant un cursus de formation intense lors de leurs premiers mois parmi nous.

Un an après

Un an après, nous avons proposé exactement le même sondage. Nous avons également obtenu une centaine de réponses qui étaient tout aussi représentatives de la répartition de séniorité et d’expérience chez OCTO. Nous vous partageons les résultats plus bas.

Nous avons la faiblesse de croire que la mise en place de nos initiatives ont eu comme conséquence l’amélioration des résultats. Autre constat : les projets sur lesquels ont été mis en place les pratiques de TDD et code review ne souffrent pas de problèmes de qualité.

Moralité

Si, comme nous, vous êtes convaincu·e·s que les pratiques craft vont vous permettre de faire du développement durable, inspirez-vous du questionnaire en bas de l’article pour détecter vos prochains chantiers (formations / accompagnements / coaching).

Pour constater les bénéfices de vos initiatives, rejouez régulièrement vos sondages pour trouver d’éventuelles corrélations et enclencher les prochains chantiers de votre amélioration continue.

Les résultats de 2017

C’est mieux sur la revue de code :

– comparé à l’année dernière, les revues sont plus variées, plus fréquentes et plus collectives.

– seul 4,1% ne fait aucune revue de code (12,6% l’année dernière)

Fréquence des types de revues de code

Taux de ceux qui ne pratique aucune revue de code

 

C’est mieux sur les tests unitaires :

– La grande majorité teste unitairement (stable par rapport à 2016)

– Il y a nettement plus de personnes qui testent avant : 78,2% (60,7% en 2016)

– Il y a plus de personnes qui refactor après que les tests soient au vert => TDD rules !

La pyramide des tests est mieux connue des octos : 91,8% (76,8% en 2016)…  

– … et est nettement plus respectée sur leurs projets : 61,8% (34,2% en 2016)

Testes-tu ton code unitairement ?
Testes-tu unitairement avant ou après l'implémentation ?

Pratiques-tu un refactoring une fois les tests passés au vert ?

Connais tu la pyramide des tests ? Est-elle respectée sur tes projets actuels ?

C’est mieux sur la partie clean code :

– 77,3% ont des standards de code sur leur projet (62,1% en 2016)

– les pratiques sont assez connues => un éclaircissement sur certaines pratiques est nécessaire

Ton équipe a-t-elle défini des standards de code ?Pratiques Clean Code

 

Le questionnaire complet

Quel est ton poste ?

Quel est ton ancienneté ?

Testes-tu ton code unitairement ?

  • Oui
  • Non

Testes-tu unitairement avant ou après l’implémentation ?

  • Oui
  • Non

Trouves-tu ça … ?

  • Facile
  • Difficile

Pratiques-tu un refactoring une fois les tests passés au vert ?

  • Oui
  • Non

Trouves-tu ça … ?

  • Facile
  • Difficile

Connais-tu la pyramide des tests ?

  • Oui
  • Non

Est-elle respectée sur tes projets actuels ?

  • Oui
  • Non

Sur tes projets actuels , pratiques-tu la revue de code ?

  • Pair Programming
  • Peer Review Synchrone (côte à côte en face de l’écran)
  • Peer Review Asynchrone (en faisant des commentaires dans un outil github, gitlab, sonar, gerrit, …)
  • Collective (à 3 ou plus devant un écran)]

Trouves-tu ça … ?

  • Facile
  • Difficile

Ton équipe a-t-elle défini des standards de code ?

  • Oui
  • Non

Pratiques-tu ces principes ? (si tu ne connais pas, réponds non)

  • Don’t Repeat Yourself (DRY) [Oui / Non]
  • Keep It Simple, Stupid (KISS) [Oui / Non]
  • You aren’t gonna need it (YAGNI) [Oui / Non]
  • Boy Scout Rule [Oui / Non]
  • Single Responsibility Principle (SRP) [Oui / Non]
  • Dependency inversion principle (DIP) [Oui / Non]

    Laisser un commentaire

    Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


    Ce formulaire est protégé par Google Recaptcha