Niko niko !
J'avais indiqué dans mon billet d'anniversaire que je j'allais abordé de nouveaux thèmes dans ce blog, et notamment le développement agile.
Ce billet est donc le premier d'une série que j'espère longue sur ce sujet qui me tient particulièrement à cœur, car je suis persuadé que l'avenir du développement logiciel et surtout la qualité logicielle passe par l'utilisation de l'agilité.
De plus, chez PMSIpilot, mon nouvel employeur, les équipes de développement sont en train de passer en mode agile, et j'ai donc de la matière brute de première main et un retour direct d'expérience à vous faire partager.
Les sprints ont en effet débuté il y a quelques mois, et un certain nombre de pratiques, pour la plupart issues de SCRUM, sont en place.
Il y a donc entre autre pour chaque projet un backlog
, une réunion de planification, une estimation de la complexité, des sprints de trois semaine, une mêlée matinale, un mur, des tickets, un burn down chart, des rétrospectives, etc.
Tout cela est évidemment épaulé par de l'intégration continue ainsi que par des tests unitaires et fonctionnels, même si le développement piloté par les tests et la programmation en duo ne sont pas encore au goût du jour et sera complété prochainement par du développement piloté par les tests et de la programmation en duo.
C'est donc naturellement que mon équipe a suivi le mouvement lorsque nous avons commencé à travailler sur notre projet, et comme j'en suis le seul membre à avoir une expérience agile, je me suis permis de proposer certains ajouts, tel que le calendrier Niko-Niko.
Je vous propose donc ici un bilan de cette pratique, suite à la conclusion de notre premier sprint.
Concrètement, le calendrier Niko-Niko se présente sous la forme d'une feuille divisée en colonne, chaque colonne correspondant à un membre de l'équipe.
Chaque jour, à l'issue de sa journée de travail, chacun membre met dans sa colonne un smiley représentant son ressentie de la journée.
Un smiley qui fait la gueule représente donc une mauvaise journée, tandis qu'un smiley souriant représente une bonne journée et un smiley neutre une journée mi-figue, mi-raisin.
Ce smiley a de plus une valeur globale sur la journée, dans le sens ou il englobe aussi bien l'aspect humain que technique, et il est strictement personnel.
J'ai également proposé de noter sur un Post-it les raisons du mécontentement représenté par un smiley aigri.
En effet, personnellement, au bout d'une ou deux semaines, j'ai beaucoup de mal à me souvenir de l'origine des problèmes que j'ai rencontré et qui m'ont amené à remplir ma colonne de la sorte.
L'ajout de ce Post-it permet donc de pallier à ce genre de déficiences, et ainsi de gagner du temps lors de la rétrospective de fin de sprint.
La mise en place de la pratique a donc été très rapide, puisque la création du calendrier n'a pas du prendre plus de deux minutes, et fournir les explications à l'équipe lors de la mêlée matinale n'a pas du prendre plus de temps.
Le coût financier est quand à lui proche du zéro absolu, puisqu'elle ne nécessite qu'une à deux feuilles de papier, en fonction de la taille de l'équipe de développement.
Au niveau de l'équipe, justement, ma proposition a été très bien accueillie, à tel point qu'au fil du temps, remplir le Niko-Niko est presque devenu un jeu et permettait de dédramatisé les mauvaises journées.
Nous avons eu ainsi des smileys enjolivés de noms d'oiseaux ou et autres massues lors des mauvaises journées, et les membres de l'équipe n'hésitaient pas à rappeler à ceux qui omettaient de le remplir leur obligation.
L'équipe s'est donc appropriée la pratique en y ajoutant sa touche personnelle et en s'auto-disciplinant ce qui est un signe certain qu'elle était acceptée et intégrée.
Au jour le jour, le calendrier Niko-Niko a été un outil appréciable lors de la mêlée quotidienne, car il a permis d'avoir un retour immédiat sur les problèmes rencontrés lors du développement, alors que traditionnellement, ce retour est donné lors de la rétrospective de fin de sprint.
Il a donc permis à notre ScrumMaster
d'avoir un ressentie immédiat du moral de l'équipe et de comprendre qu'il y avait eu des problèmes sans avoir besoin de poser la question, ce qui lui a permis de se concentrer immédiatement sur les éventuelles solutions à apporter.
Évidemment, pour les membres de l'équipe, il a été un support très utile pour expliquer de manière plus efficace les problèmes rencontrés, ce qui a également facilité le travail du ScrumMaster.
le calendrier Niko-Niko a donc permis d'avoir des mêlées plus efficaces lorsque le développement se passait mal, qui se sont alors transformées partiellement en mini-rétrospectives informelles.
Le Niko-Niko a également été un support efficace lors de la rétrospective, car il a permis de faire ressortir en un temps record que l'ensemble des problèmes qui avait influé sur l'humeur de l'équipe avait été posé par l'apprentissage de nouveaux outils tel que PHPUnit, à lui seul responsable d'au moins 80% des smileys coléreux.
En outre, le calendrier a fait ressortir le fait que l'ensemble de l'équipe avait été impacté, et plus ou moins aux mêmes moments.
Nous avons également pu constater une relation très forte entre les décalages du burn down chart et la répartition des smileys.
Très logiquement, lorsque l'équipe est heureuse, les pentes théoriques et réelles du burn down chart sont en corrélation, alors qu'elles divergent lorsque l'équipe rencontre des problèmes.
Le Niko-Niko est donc un outil simple mais très efficace pour optimiser le déroulement des mêlées quotidiennes ainsi que les rétrospectives, puisqu'il permet d'avoir, même s'il s'agit d'un indicateur très subjectif, une vision immédiate et précise du moral et de l'état d'esprit de l'équipe, indépendamment d'indicateurs plus objectifs, et cela même s'il existe une relation entre les deux types d'indicateurs.
Je pense par ailleurs que nous n'avons pas encore découvert toutes les possibilités offertes par cet outil, et que les prochains sprints seront riches en enseignement à ce niveau, d'autant que son utilisation a été généralisée à l'ensemble des équipes de développement de PMSIpilot.

Commentaires
c'est aussi très pratique lors de la réunion de debrief pour retrouver ce qui a été et ce qui n'a pas été. D'autant plus si le sprint est long (ce qui est le cas chez PMSIpilot).
@Olivier Mansour : Réunion de debrief = rétrospective.
ha j'ai lu trop vite
Je passe par hasard sur ce blog, et je me dois d'en saluer la qualité !
Et un abonné de plus, un !
Bonjour, concernant l'intégration continue, pourriez-vous nous en dire plus ? Quel(s) outil(s)/plateforme(s) pour le dev PHP ?
Merci et keep up the good work!
@R4f : En ce qui concerne l'intégration continue chez PMSIpilot, il y a des informations ici.