Archives de Tag: scrum

Mon premier Randori en java

Par défaut

Non, je n’ai pas mangé un bol de riz en Indonésie, j’ai participé à un Dojo à Montbonnot  pour développer un jeu de morpion en TDD avec des développeurs Java. Ce Dojo était mené sous forme de Randori c’est à dire dans un Dojo d’informaticiens une séance de pratique de dev et tests par pair-programming ou chacun à son tour passe en co-pilote puis en pilote face au clavier.

J’ai donc participé hier à mon premier Dojo Java… je vais pouvoir mettre sur mon CV Eclipse, Java, Junit… 6 minutes aux commandes et 6 minutes en co-pilote 😉 To be continued… Et puis va falloir que je lise java pour les nuls 😉

En tant que Directeur de projets, voici les enseignements que j’en ai tiré :

  • en 1h, j’ai vu le caractère de chacun face à la fabrication d’une application dans une approche TDD
  • le réflexe TDD n’est pas acquis, il faut donc s’entrainer, les Dojo sont là pour ça
  • l’un est calme, et bien que ne disposant que de 6 minutes, fait un apport (test et programme) posé et maîtrisé
  • un autre fait très vite le code, lance les tests, ça plante, il remodifie très vite le code, ça replante, réitère ainsi de suite jusqu’à la fin des 6 minutes avec au final des TU en échec. Sa méthode ? Il donne l’impression de faire des modifs au petit bonheur la chance et de tester son test par le code… le monde à l’envers…
  • un autre réfléchit, écrit son test puis le code… lance les tests, erreur, puis réfléchit… jusqu’à ce qu’on lui dise de sauver son code et de relancer les tests… Et là, c’est OK. Il aurait pu passer 30 minutes à relire encore et encore son cas et son code … à ne pas comprendre ce qui ne marche pas… à réécrire son cas de test

C’est amusant mais le caractère des gens ressort très vite qd on est en temps compté dans un exercice de Randori…

Dans mon équipe Scrum, à part en cas de pépin où un équipier demande de l’aide et travaille temporairement en pair, le mode normal est chacun en solo face à son ordi.

Cela ne permet pas de débloquer l’autre, ni de voir ses forces (sur lesquelles je pourrai le solliciter si je bute sur un problème de tel type) ni ses faiblesse (afin de l’aider pro-activement à gagner sur ce volet).

D’où l’idée suivante que je propose de tester :

–          pour le prochain recrutement d’équipier sur un de mes projets, dès son arrivée, organiser un randori afin qu’il rencontre par pair chaque membre de l’équipe et que chacun le voit aussi à l’ouvrage. L’équipe étant collectivement engagée sur le sprint, chacun doit être conscient des possibilités des autres et notamment du nouvel arrivant pour l’aider à donner le plus vite possible le meilleur

–          pour le prochain projet que je démarre, organiser un randori au démarrage avec l’équipe pour les mêmes raisons qu’évoquées ci-dessus.

Pratiquez-vous cela chez vous ?

A+

Jean

Publicités