Ecrit en décembre 2009 Un grand merci à tous ceux qui ont contribué à la réalisation et à la diffusion de cette vidéo. Mais revenons à nos moutons. Ce retour d'expérience concerne un des plus grands projets de Mobilité en Europe qui consiste à équiper 16 000 conducteurs de train d'une application mobile d'aide à la conduite (une sorte de TomTom ferroviaire). Les délais accordés à la phase de réalisation étaient extrêmement ambitieux en plus des enjeux techniques et fonctionnels. A l'heure actuelle (décembre 2009) l'application réalisée est en cours de déploiement, une petite population d'utilisateurs l'utilise déjà sur le terrain. Contexte du projetObjectifs client
Enjeux projet
Outils utilisés
Résultats obtenus
Degré d'application de Scrum : Nokia TestPartie 1 : avons nous une approche itérative ?
Partie 2 : appliquons nous Scrum ?
Retour d'expérience détailléChoix de l'approche AgileLa décision d'adopter une approche Agile, s'est faite assez timidement de peur de bouleverser trop d'habitudes parmi les acteurs du projet (d'autant plus qu'il s'agissait d'un premier essai à la fois pour le client et pour notre équipe). C'est pour cette raison notamment qu'aucun Product Owner n'a été désigné clairement au début. Le choix s'est porté sur une telle approche en raison des délais hors normes du projet et de la complexité du métier. Il fallait commencer à développer tôt avec rigueur, et donner un maximum de visibilité au client dès que possible avec une souplesse d'ajustement du besoin. L'approche Agile répondait et a répondu parfaitement à ces besoins. Base contractuelleNous avons établi le Product Backlog (PB) en amont du projet en fonction de notre connaissance du besoin. Nous avions au préalable participé à la phase expérimentale du projet, cet exercice n'a donc pas été trop compliqué (2 jours environ). Dans d'autres circonstances, nous serions sans doute parti du cahier des charges ou d'interviews client. Par précaution, nous avons rempli une colonne "hypothèses/couverture" du tableau du PB pour chaque exigence (User Story) de façon à se protéger un minimum compte tenu du caractère forfaitaire du contrat. Exemple : "en tant que conducteur je peux consulter mon planning afin de..." donne "hypothèse/couverture : 2 écrans simples, 1 complexe, alimentation des informations de planning par le SI amont". A partir de cette base, le contenu du PB a bien entendu changé en cours de route, nous avons donc procédé au principe de troc : le client ajoute une exigence en échange du retrait d'une exigence de même coût moins importante qui n'a pas encore été réalisée. Cette approche a permis de gérer les changements sans douleur et sans modifier le budget du projet. ConceptionLa conception fonctionnelle a été lissée sur toute la phase de réalisation du projet. Moyennant tout de même un sprint 0 (un peu plus long que les autres) consacré à la mise en place de l'environnement de développement et d'intégration, des outils, des socles de développement et des bases de l'architecture. La conception fonctionnelle, bien que lissée a toutefois fait l'objet d'un mini "cycle en V" au sein de chaque itération. La première semaine était globalement ainsi découpée : 2 premiers jours d'ateliers de conception avec les utilisateurs finaux et AMOA, 2 jours de rédaction des spécifications/maquettage, 1 jour de relecture/validation des spécifications. Pendant cette première semaine, les développeurs non impliqués dans le travail de conception fonctionnelle et de rédaction réalisaient des développements (anticipés donc) sur des User Stories relativement mûres en termes de besoin. Evidemment, je suis conscient que cette approche n'est pas idéale, nous avons là un axe d'amélioration clairement identifié. Nous avons cependant réussi à atteindre l'objectif du lissage de la conception et donc d'un démarrage des développements très tôt. Ce qui a - à mon sens - fortement contribué à affiner le besoin tout en tenant des délais particulièrement ambitieux. L'effet démoChaque itération s'est terminée par une démonstration faite au client sur un simple PDA de développeur pour la partie mobile et sur un PC pointant sur l'URL de notre serveur d'intégration pour la partie web de l'application. Nous n'avions pas grand chose à montrer sur les premières démonstrations mais ce fut une belle expérience. C'est fou comme un simple écran d'accueil peut avoir de la valeur en démonstration, il structure la suite. Les feedbacks ont donc été précieux. Le client a pu se rassurer en voyant que les choses avançaient dans le bon sens et nous aussi. Parfois il faut courrir après les pré-requis, les décisions, les choix du client,... la démonstration a un effet très positif là dessus, en voyant que les choses avance, le client s'implique, il se projette dans l'usage de l'application, il affine son besoin... Rares ont été les feedbacks coûteux en termes de prise en charge, c'est l'avantage quand on découpe le temps en itération courtes, on a peu de chance de mal interpréter un besoin creusé 2 à 3 semaines avant. A mon sens, cette visibilité offerte au client à travers ces démonstrations a permis d'établir très tôt une relation de confiance précieuse mettant ainsi de l'huile dans les engrenages du projet. EquipeEn termes de management, j'ai fait le choix d'appliquer à la lettre les principes Agile. Fini le "chef de projet" qui décide, dirige et contrôle. Nous avons donc supprimé toute hiérarchie au sein de l'équipe et appelés "coach" les profils expérimentés. Autant que je m'en souvienne je pense avoir donné très peu d'ordres, j'ai aidé l'équipe à atteindre ses objectifs en la protégeant des évènements extérieurs perturbants et en levant de mon mieux les obstacles. Chacun a peu a peu trouvé sa place, s'est responsabilisé, participé aux décisions du projet pour finalement aboutir à une équipe autonome et auto managée. J'ai plusieurs fois été agréablement surpris par les choix pertinents faits par l'équipe, par les actions d'amélioration proposées en rétrospectives (dont certaines ne me seraient jamais venu à l'esprit). Il est clair que l'équipe est souvent la mieux placée pour faire certain choix tant fonctionnels que techniques de part sa connaissance et maitrise des contraintes. L'autre surprise a été de voir naître si vite un esprit d'équipe à toutes épreuves que je n'avais jamais connu sur mes projets précédents, il est indéniable que les mêlées quotidiennes, le travail en binôme, les rétrospectives, favorisent et cultivent cet esprit si précieux (y compris et surtout en termes de productivité). L'équipe était constituée de 70% de membres novices en .NET et développement mobile avant leur arrivée sur le projet. 40% des membres de l'équipe étaient des développeurs juniors. La mêlée (Scrum)Le Scrum est vraiment capital, c'est un moment de communication intense, d'écoute, de décisions, de révélation des obstacles, de coordination, de renforcement de l'esprit d'équipe,... Ce sujet mérite un paragraphe à part entière à mon sens voir plus. Les 2 premiers mois, nous étions aux alentours de 7 personnes, les conditions étaient idéales. L'équipe a cependant mis du temps à vraiment tirer parti du Scrum, à se l'approprier. Les débuts étaient très scolaires, chacun répondant mécaniquement aux 3 questions à tour de rôle en s'adressant à moi plutôt qu'à l'équipe. Peu à peu les choses ont commencé à se fluidifier, à se personnaliser. Jusqu'à l'heure du Scrum qui après plusieurs changements a fini par être fixée à midi (même si je reste persuadé que le meilleur moment pour le Scrum est le matin entre 9h30 et 10h30, je me suis incliné face au choix de l'équipe). Lorsque l'équipe a atteint sa taille maximale (15 personnes) nous avons poursuivi de la même façon sans trop déborder niveau timing. Etant donné que le tour prenait pas mal de temps tout de même, j'ai tenté de faire 2 équipes (donc 2 mêlées) mais on ne peut pas dire que ce fut concluant. Pour 2 raisons à mon sens. D'une part parce que l'équipe était plutôt sur dimensionnée par rapport au périmètre à couvrir (difficulté que nous aurions pu surmonter cf. "axes d'améliorations"), du coup il était difficile de faire 2 équipes suffisamment indépendantes. D'autre part, parce que j'ai séparé l'équipe juste avant de partir 3 semaines en congés (soit une itération) en me disant que c'était l'occasion de tester l'autonomie de l'équipe mais je pense que ça faisait trop d'un coup. Nous sommes donc revenu au mono scrum, puis l'équipe s'est réduite. Travail en binômeSans appliquer les principes XP de Pair Programming à la lettre (Programmeur + co pilote et échange du clavier,...) nous avons eu recours au travail en binôme. Dans 2 cas de figure principaux : la montée en compétence des nouveaux entrants (d'autant plus que beaucoup d'entre eux n'avaient jamais développé en .NET) et pour les développements pointus. Concernant les revues de code, nous avons préféré utiliser l'outil Crucible de la suite Atlassian qui permet de faire des revues de code à distance sans déranger le travail de l'autre (que l'on soit relecteur ou relu). Le travail en binôme a clairement contribuer à faire rapidement monter en compétences des profils novices en .NET. Maintenant que j'ai découvert le fonctionnement du dojo de développement, je pense que j'ajouterai la pratique du dojo en plus de celles que je viens d'évoquer. C'est un excellent moyen créer un esprit d'équipe, de capitaliser les astuces de développeurs (raccourcis de l'éditeur par exemple), d'uniformiser le code, de faire monter en compétence les juniors... Difficultés rencontréesL'essentiel des difficultés dont j'ai envie de parler dans ce paragraphe, concerne celles liées à l'adoption d'une approche Agile par un client, une équipe, un management non initiés. Etant le seul en début de projet formé et convaincu par la pertinence de cette approche dans le contexte du projet, j'ai du faire face à mes propres peurs et celles des autres. J'ai rapidement compris pour quelle raison, l'une des valeurs Agile est le "courage" :-). L'équipe par exemple a du pas mal bouleverser sa façon de travailler en développant par exemple verticalement plutôt que par couche, en se réunissant tous les jours pour parler de ses activités, en déplaçant les post-it au quotidien, en se confrontant au graphique d'avancement (burndown chart) et aux réactions du client en démonstration, en adoptant des nouveaux outils (comme l'intégration continue), etc. J'ai observé le phénomène connu d'une période d'enthousiasme ou de doute (selon les individus) suivie d'une période de perte de repères plutôt chaotique (un mal nécessaire) suivie de la période de stabilisation (les nouveaux repères sont en place). Aujourd'hui je pense pouvoir dire que plus personne ne souhaite retravailler à l'ancienne. Mon management (au sens "mes responsables") a lui aussi du s'adapter à cette nouvelle façon de travailler. Plutôt sceptique au début, puis peu à peu convaincu. Le plus dur a été de faire un peu oublier les aspects contractuels et les excès de planification/anticipation à trop long termes. J'ai du également servir de bouclier pour préserver l'équipe des pressions du management en réponse aux retards parfois constatés en cours de route (cf. burndown chart de chaque itération). L'ambiance a souvent été électrique mais la fin est globalement heureuse. De mon point de vue de ScrumMaster ayant poussé cette approche, je dois dire que ça n'a pas été facile tous les jours au début et que les sentiments de solitude et de peur ont dominé (au même titre que l'excitation heureusement). Le projet était important (pas seulement financièrement), j'ai entrainé avec moi une équipe, le management, le client dans une aventure dont on ne connait pas le chemin exact à l'avance. C'est donc une lourde responsabilité. J'avais beau avoir potassé et expérimenté les méthodes Agile auparavant, la pratique au quotidien avec de gros enjeux est une autre histoire. Mais je ne regrette rien (ni même mes quelques nuits d'insomnie), le jeu en vaut clairement la chandelle. Quoi de plus gratifiant qu'une équipe qui prend plaisir à travailler, qui donne le meilleur d'elle même, qu'un client satisfait qui veut continuer à travailler avec vous ? Quoi de plus gratifiant que de contribuer à rendre le monde de l'informatique un peu meilleur sur le plan humain ? ;-) Certains projet "pilotes Agile" échouent en raisons des difficultés que j'ai évoqué plus haut (et d'autres). On recommande donc souvent de faire appel à un vieux routard Agile qui a déjà fait ses armes. Je suis assez d'accord avec ce point de vue, même si je trouve qu'apprendre de ses propres erreurs est plus formateur. Lorsque les enjeux sont importants, il faut sans doute faire preuve d'humilité et s'en remettre à des personnes expérimentées (sans perdre la main pour autant bien sûr, il s'agit juste d'être à l'écoute des conseils donnés et de les appliquer soi même). Surtout si on rechigne à lire les nombreux ouvrages ou blogs sur le sujet bourrés de cas d'utilisation "vraie vie" des méthodes Agile. Sur un plan technique, l'une de nos difficultés a également été de monter une Intégration Continue (IC) pour les développements Mobile. En effet nous ne sommes pas parvenu à aller au delà de la simple compilation du code. L'exécution des TU ne peut pas se faire ailleurs que sur un PDA, or les outils d'IC du marché ne couvrent actuellement pas ce besoin. Nous avons bien sûr essayé de développer une IC maison mais le résultat ne fut pas probant. C'est vraiment regrettable car la majorité du périmètre du projet se situe sur le PDA. Pour conclure ce paragraphe, je dirais qu'il est primordial d'y aller doucement (petit à petit) dans l'adoption des pratiques Agile afin d'éviter l'indigestion voir le rejet. Tant vis à vis de l'équipe que du management ou du client. De la même façon, mieux vaut expérimenter une approche Agile sur une équipe avant de s'attaquer à l'ensemble des troupes. Outils utilisésEn fonction de notre budget, nous avons opté pour la suite "Atlassian" en termes d'outillage logiciel :
Axes d'améliorationSi le projet était à refaire que changerions nous dans notre approche ?
|
|
|
|
Accueil >
Méthodes Agile en action |
Il est temps de donner des nouvelles et la bonne, c'est qu'on passe le Nokia test ;-)
Depuis 6 mois environ nous avons un vrai Product Owner désigné côté MOA avec des consultants fonctionnels en assistance (AMOA). Ces derniers collaborent au quotidien avec l'équipe de développement. Le Product Owner décide avec elle du contenu de chaque sprint aussi bien pour le choix des User Stories que des défauts à corriger. Nous avons très peu de défauts en stock et la plupart sont mineurs. Nous livrons le produit à la fin de chaque sprint. Etant donné qu'il s'agit d'une application critique (on conduit des trains avec), elle est testée à la fois pendant le sprint mais aussi après livraison. Lorsque le Product Owner dispose de suffisamment de nouvelles fonctionnalités, il décide de mettre en production (moyennant un sprint de clôture au besoin).
Tout le monde (MOA, AMOA, MOE, AMOE) prends du plaisir à travailler sur ce projet et est fier du produit.
Côté pratiques de développement XP, c'est difficile de convaincre l'équipe d'appliquer TDD. Nous avons commencé petit avec la programmation en binôme qui permet de faire progresser très rapidement les nouveaux développeurs de l'équipe, en particulier les juniors. Cette pratique permet aussi d'améliorer significativement la propriété collective du code source et l'uniformité de ce dernier. Nous utilisons depuis quelques temps des cartons bristol pour les User Stories rédigées par l'AMOA. Cette pratique apporte plusieurs points positifs : pilotage des développements par les tests (meilleure qualité), planification des sprints plus facile, interactions développeur/AMOA plus fluide. Par ailleurs, nous essayons d'améliorer la lisibilité et maintenabilité des spécifications fonctionnelles détaillées en se reposant au maximum sur une rédaction en cas d'utilisation (choix qui n'avait pas été fait au début malheureusement). Les rétrospectives quant à elles apportent toujours autant d'amélioration et la vélocité quant à elle semble augmenter.
Le déploiement de l'application aux 16 000 conducteurs de train est compliquée en raison du climat social.
Les syndicaux sont en conflit avec leur direction et résistent fortement au changement.