5 ans de développement en méthode Agile, retour d’expérience

Pourquoi cet article ?

Tout ce que j’ai lu et appris sur le sujet concerne des équipes qui sont sur un seul projet, ce qui n’est pas notre cas. Il m’a semblait intéressant de partager cette expérience très différente du mono-projet.

En plus de lire sur le sujet, nous sommes allés à plusieurs reprises aux conférences proposées dans le cadre de l’Agile tour : http://at2013.agiletour.org/fr/at2013_bordeaux.html

Cela fait environ 5 ans que l’on travaille en méthode agile, mélange d’EXtrême Programming (XP), scrum et sauce maison.

Voici le contexte :

• Service informatique dans une société qui n’est pas une SSII, l’équipe est composé de 15 développeurs
• il y a en parallèle une dizaine de projets, avec des équipes de 3 développeurs, jusqu’à 1/4 de développeur
• Les développements concernent en grande partie les besoins internes à l’entreprise
• Développement en C#, l’équipe de développement à une moyenne d’age de 27 ans (je ne me compte pas dedans .. heureusement pour la moyenne…)

Nous avons au fil du temps testé différents aspects :

• Le management visuel
• les planning poker
• les post-it
• le travail en binôme
• les tests unitaires
• les tests fonctionnels
• les points quotidiens avec le client
• Le refactoring de code
• etc..

Les points positifs qui dans le temps tiennent :

• le travail en binôme, qui apporte un plus réel au niveau polyvalence, formation, arrivé de nouveaux développeurs
• le planning poker, qui en comparant l’estimation et le réel donne d’excellent résultat. Des alertes naturelles sont faites, afin d’éviter de refaire un code déjà réalisé sur un autre projet
• les test fonctionnels, mais qui restent difficiles à automatiser, au regard de nos applications (clients lourds et clients légers, contexte parfois difficile à reproduire etc…)
• La notion de fiche scénario courte, qui donne un sentiment, pour le développeur d’une bonne journée. On essai de faire des fiches d’une 1/2 journée et pas de 5 jours.
• l’effet tunnel qui n’existe plus

Les points négatifs :

• l’utilisation des post-it, qui n’a pas de sens en multi-projet, qui tombent, qui sont trop petits pour tout écrire dedans etc..
• le travail en binôme, si décalage important de niveaux ou dans un contexte de développement simple
• la notion d’itération qui ne peut être unique si multiples projets
• l’ambiance de l’équipe par des pastilles de couleurs, n’a pas marché, même si cela donnait une bonne vision par jour et dans le mois du ressenti de l’équipe.
• Les points quotidiens avec le client, sont difficiles à faire, en raison notamment de la charge de nos clients internes. Ceux qui peuvent jouer le jeu ont de meilleurs développements, c’est indéniable.

Même si on peut voir que tout n’est pas utilisé les grands concepts sont compris et appliqués, par exemple :

• En parallèle nous faisons les tests, les développements et le manuel de référence. Il y a donc 3 lectures différentes de ce qui doit être réalisé.
• la part de test a explosé et à permis d’avoir des développements plus fiables
• On ne développe plus que ce qui est demandé par le client
• On ne pose plus de questions au client du type « est que cela pourrait vous intéresser ? »
• Le client est plus en avant qu’avant.. ce qui est l’essentiel, pas de surprise pour lui ..

En espérant que cet article aidera des équipes de développement comme la notre…