Soyez agile Dans l industrie du logiciel, la gestion de projet est confrontée à de nombreux défis. Le principal est de pouvoir assurer l adéquation d un produit et de ses fonctionnalités avec les besoins réels des utilisateurs lors de la mise sur le marché. C est également l un des plus complexes. Pourquoi? Parce que l environnement est changeant, l horizon des projets lointain et les capacités de prévision de l humain limitées : les besoins sont donc difficiles à exprimer correctement en amont. De plus chaque projet informatique est par nature différent. On ne peut donc pas industrialiser les processus en se basant sur les projets passés et mettre ainsi sous contrôle les projets futurs. Il n existe malheureusement pas de «recette» qu on appliquerait pour garantir la réussite du projet. L industrie du logiciel a donc besoin de trouver des alternatives, de nouvelles façons de concevoir ses produits. Deux approches différentes s opposent. D un côté des méthodes lourdes axées sur l analyse exhaustive des risques pour tenter de supprimer le changement. De l autre, des méthodes innovantes dites légères, tirant parti du postulat qu un projet est vivant et évolue inéluctablement
Origines et principes de l agilité est essentielle Les méthodes classiques (c est-à-dire séquentielles) comme Waterfall, ou le modèle en V ont montré certaines limites sur des projets à forte valeur ajoutée fonctionnelle et technologique. L équation respect des délais, du budget et de la qualité parait ainsi souvent insoluble. L équipe et le client sont confrontés à un effet «tunnel», source de frustration : le résultat n est visible qu à la fin et l avancement difficile à estimer. L avis des utilisateurs n est pris en compte qu au début du projet sur la base d éléments conceptuels et très peu concrets. Or l adéquation entre les besoins du client et l état de la demande des utilisateurs Les méthodologies séquentielles proposent un processus de spécifications amont rigide : les parties prenantes ont alors tendance à sur-spécifier les besoins initiaux, à les considérer d un point de vue technique uniquement, et en prenant peu en compte des réalités business qui elles évoluent très rapidement. De plus ces spécifications ne sont souvent adaptables qu à la marge, alors que les modifications d autant plus probables et importantes que le projet est complexe. Enfin, l approche séquentielle est optimale pour des processus définis (comme la production industrielle d un bien physique), or la création d un logiciel est un processus empirique Autant de facteurs augmentant le risque d échec. Dans les années 90, plusieurs acteurs du développement logiciel ont donc pris le contre-pied des approches existantes et ont développé indépendamment diverses méthodes amenant un changement majeur dans la façon de gérer les projets. En 2001, ils se sont réunis et ont rédigé un manifeste formalisant la philosophie commune au cœur de leurs méthodes, et valorisant : - Les individus et leurs interactions plus que les processus et les outils - Des logiciels opérationnels plus qu une documentation exhaustive - La collaboration avec les clients plus que la négociation contractuelle - L adaptation au changement plus que le suivi d un plan Ces quatre postulats de départ ont été déclinés en douze principes appliqués à la gestion de projet. Pour résumer, une méthode agile est une approche itérative et incrémentale menée dans un esprit collaboratif, où le formalisme est réduit à l essentiel. Elle génère un produit de haute qualité tout en prenant en compte l évolution des besoins des clients. Il est intéressant de noter qu itératif n est pas synonyme d agile, mais qu agile implique, entre autres, un fonctionnement itératif. La vision d ensemble du projet est macroscopique- l équipe et le client connaissent l objectif global et ont une idée du délai total. Le projet est ensuite découpé en fonctionnalités et tâches, qui
peuvent évoluer, et qui seront planifiées au fur et à mesure des itérations courtes : les projections précises sont donc effectuées sur le court-terme, là où l équipe a effectivement de la visibilité. En fonction de l avancée, des résultats et des feedbacks recueillis, la gestion du projet peut être rectifiée rapidement quand cela est nécessaire, afin de garantir le meilleur résultat possible. La simplicité c est-à-dire l art de minimiser la quantité de travail inutile est essentielle en agilité. Ce concept implique par exemple une documentation réduite à l essentiel, de créer uniquement les indicateurs nécessaires, le développement des fonctionnalités à valeur ajoutée réelle, mais également des solutions et codes les plus simple possibles. La priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. À chaque livraison de fin de cycle, qui peut durer de quelques semaines à quelques mois - avec une préférence pour des cycles courts sans quoi on perd les avantages de l agilité - le produit doit être opérationnel ; c est le principal critère d avancement du projet. La proximité et la collaboration entre client, équipes métiers et équipes techniques permet de garder la finalité d usage du projet devant les considérations techniques. Les produits développés agilement sont généralement de haute qualité puisqu ils prennent au fur et à mesure en compte l évolution des besoins des clients, et que chaque itération est testée et validée. L agilité favorise également l innovation intelligente : par l acceptation du changement, l équipe est prête à rechercher des solutions innovantes pour contourner un obstacle, si les solutions connues ne résolvent pas de façon satisfaisante le problème rencontré. Pour vous aider à mieux visualiser les différentes solutions utilisables à l heure actuelle, voici un tableau synthétique des principaux aspects à prendre en compte pour développer des applications mobiles dans des environnements spécifiques.
Scrum une méthode dans l univers agile Il n y a pas une méthode Agile, mais des méthodes agiles : différentes méthodes respectent ainsi les quatre postulats du manifeste, même si les avis peuvent diverger sur la classification de certaines. Citons par exemple Scrum, XP (extreme Programming), Crystal Clear, DSDM (Dynamic Software Development Management) ou FDD (Feature Driven Development), entre autres. Les plus utilisées et connues à ce jour sont Scrum et XP. Chacune d entre elles a ses particularités dans la mise en œuvre et les outils proposés. XP propose ainsi aux équipes de nombreux outils et pratiques de développement (TDD, intégration continue), mais la majorité de ces outils peuvent aussi être utilisés dans le cadre d autres méthodes agiles. Crystal offre quant à lui différentes versions, en fonction de la taille et de la criticité des projets, en partant du principe qu on ne gère pas de la même manière un projet avec 5 ou 50 personnes. Scrum, qui est la méthode agile que nous avons adoptée chez af83, est intéressant de par sa façon de gérer la succession des itérations et son focus sur la valeur ajoutée pour le client. Avant de s intéresser plus précisément à Scrum, il est important de souligner que la méthode dispose d un vocabulaire spécifique, très efficace pour éliminer les soucis de compréhension et de différences de référentiel d une organisation, équipe, ou personne à une autre. Une équipe projet, dans la méthode Scrum, est composée de 4 à 7 personnes aux compétences multidisciplinaires, du Scrum Master (chargé d animer l équipe et de veiller à ce qu elle soit toujours dans de bonnes conditions pour le projet) ainsi que du Product Owner, qui est la personne de l entreprise cliente en charge de déterminer les besoins et de valider la production livrée. Le client fait ainsi partie intégrante de l équipe. Il est en charge du Backlog, une liste de fonctionnalités correspondant aux besoins estimés ; c est lui qui les priorise en fonction de leur valeur métier. L intérêt principal du Backlog est qu il peut, et va, évoluer au fur et à mesure de l avancée, en fonction des besoins et des retours divers. Le projet global est découpé en «releases» (des versions du produit) de 1 à 3 mois, elles mêmes découpées en «sprints» durant de 1 à 6 semaines, décomposés en journées de travail. Pendant un sprint l objectif est de produire un ensemble de fonctionnalités, déterminées en début d itération avec le Product Owner. Le projet est donc découpé en tranches fines de fonctionnalités opérationnelles qui se suffisent à elles-mêmes. Les sprints débutent et se terminent par des réunions permettant de fixer les objectifs, puis de les valider et de faire un retour sur le déroulement de l itération. A chaque niveau de cycle divers processus (les cérémoniaux) et outils (artefacts) sont utilisés.
Enfin, Scrum prône la transparence, l inspection et l adaptation : Les indicateurs mis en place doivent être visibles par tous (équipe, client, dirigeants) en permanence, ils sont analysés régulièrement et permettent de prendre les mesures correctrices adaptées. Le Scrum Master en particulier est continuellement à l écoute des inefficacités.
Repenser l organisation de l entreprise et les relations une attention particulière à l humain. Les méthodes agiles peuvent réellement améliorer la conduite des projets et leur résultat. Mais pour cela, il est nécessaire d intégrer une culture du changement. Le changement n est plus négatif ou préoccupant ; si des changements doivent survenir, ils sont «normaux» et l équipe se doit de les intégrer dans son organisation et ses processus. Ce changement d optique n est pas évident à mettre en place : mal expliqué et compris, il peut générer du blocage il ne convient d ailleurs pas forcément à tout le monde Passer en mode agile demande donc de porter L agilité, ce ne sont pas uniquement des règles, mais avant tout un état d esprit, une culture (d organisation et personnelle) qui demande un certain type de comportement. Par conséquent, être agile ne se décrète pas, et une telle approche doit être comprise et portée par tous. Par ailleurs, la méthode ne peut pas fonctionner sans une véritable relation de confiance entre le client et l équipe de réalisation. La règle du jeu doit être parfaitement connue et les informations circuler en toute transparence. Ce sont deux principes incontournables pour la réussite du projet. Le client qui travaille avec un fournisseur agile doit avoir une forte disponibilité et implication à toutes les phases du projet, car c est lui qui décide et valide. Il est donc également important pour lui d accorder et arbitrer les différents objectifs et attentes des parties prenantes internes, afin de parler d une seule voix via le Product Owner pour Scrum (ou rôle équivalent dans les autres méthodes). Pour les organisations qui font le choix d être agiles, plusieurs éléments sont importants. Elles doivent procurer l environnement et le soutien nécessaire à l équipe, lui faire confiance pour l atteinte des objectifs (c est l équipe qui est responsable de la réussite du projet). Enfin responsabilisation et collaboration sont les maîtres mots des organisations agiles : ainsi le pairprogramming (ou programmation en binôme), les réunions quotidiennes, l entretien d un climat de contradiction positive et l engagement collectif sur les résultats constituent autant de pratiques collaboratives qui concourent à l agilité de l équipe. L agilité est également caractérisée par une grande autonomie et une responsabilisation collective, les décisions se prenant de manière consensuelle au sein de l équipe. Dans ce cadre, le chef de projet classique doit revoir son rôle et son comportement, puisqu il n est désormais plus le décideur ni le leader du groupe. Par contre les équipes agiles auto-organisées ont besoin de conseils et de
support actif et bienveillant pour atteindre leurs buts. Il pourra par conséquent se concentrer sur la facilitation des missions et la mise en place d un environnement permettant la collaboration. Les méthodologies agiles font donc surgir de nouveaux rôles dans les équipes et les organisations, comme les personnes en charge de l animation de l équipe (et non plus de son contrôle), le porte parole du client/utilisateurs. Elles tendent également à remettre en cause les organisations hiérarchiques fortes, ce qui peut être un problème dans les grosses structures en particulier ; Cependant de plus en plus d entreprises sont conscientes qu elles ont besoin d agilité à tous les niveaux. Il est d ailleurs intéressant de constater que si les méthodes agiles sont, de par leur conception et domaine d application initial, orientées vers le développement logiciel et les projets informatiques, les dimensions stratégiques, organisationnelles et humaines de l agilité sont au cœur de l évolution des entreprises : prise de conscience que la valeur ajoutée est créée par l homme plus que par la technologie, et de la dépendance mutuelle des parties prenantes, recherche de réciprocité de progrès avec l environnement et de la satisfaction durable des clients dans une relation éthique et transparente
Nos recommandations 1. Choisir la méthodologie la plus adaptée Selon votre type de projets, de clients, d organisation, certaines méthodologies seront plus ou moins adaptées : l efficacité d une méthode dépend de l adéquation de votre projet avec son «sweet spot» (ou zone de confort). Choisissez donc avec soin la méthode qui vous conviendra le mieux, après le temps nécessaire à une étude approfondie. Enfin, se tenir à la méthode choisie : ne pas jongler entre dix méthodes différentes, en appliquer une mais le faire bien, en en maîtrisant les subtilités et avantages. 2. Être dans sa zone de confort Même en ayant choisi la méthodologie la plus adaptée à votre contexte, il faut tenir compte de chaque élément s écartant de cette zone de confort, et faisant perdre en efficacité. Il faudra donc mettre en place des mécanismes et outils pour réduire cet écart, ou le compenser tout en étant conscient qu un trop grand écart ne sera pas rattrapé, et peut être signe du choix d une méthode inadaptée. 3. Respecter les règles du jeu Les règles énoncées dans les différentes méthodes agiles peuvent avoir l air basiques voire simplistes, mais elles ne sont pas là par hasard. Elles font appel à des mécanismes sous-jacents forts, liés par exemple aux problématiques de développement, de gestion d équipe, etc. et permettent de limiter les risques. Il faut donc les modifier le moins possible, et uniquement lorsqu on sait ce qui est en jeu, et pour quoi on les change. 4. Maîtriser son code Les méthodes agiles impliquent une reprise continuelle du code. Pour assurer une qualité optimale, il faut donc pouvoir supprimer et ajouter du code facilement sans dégrader la qualité d ensemble de ce qui a été produit, mais aussi pouvoir déployer les modifications rapidement pour voir si elles sont fonctionnelles, et pouvoir les tester pour vérifier qu elles ne provoquent pas d anomalies. Pour cela il est nécessaire de maîtriser les principes d intégration continue et de TDD (Test Driven Development). La présence d une majorité de développeurs expérimentés est également essentielle à ce point.
Pour en savoir plus Une sélection de ressources sur l agilité - Le manifeste agile, le site de l organisation éponyme pour la diffusion de Scrum - Scrum alliance Développement d applications mobiles - Les blogs de Ken Schwaber et Jeff Sutherland - Le livre de référence pour s initier à Scrum : Agile Software Development with Scrum, écrit par Ken Schwaber et Mike Beedle. - Un article sur les limites de l agilité et de Scrum Utiliser Scrum pour de gros projets Scrum est idéalement destiné à des projets mobilisant des équipes de 5 à 9 personnes. Que faire donc si un projet nécessite des équipes de taille supérieure? Il est découpé en sous-projets, chacun avec son équipe dédiée. Le Scrum of Scrum est alors la réunion qui permet de réunir les représentants des différents Scrum (le Scrum Master, ou un membre de l équipe à tour de rôle) pour faire le point sur les avancements et les points de recouvrement et d intégration du travail des différentes équipes, et les coordonner. Le but est de faire circuler l information, pour voir ce qui peut servir à plusieurs équipes, ne pas réinventer la roue, partager les retours d expérience,. Pour plus de détails, voir Mener un Scrum of Scrum. C est dans cette configuration de projets qu il peut également exister plusieurs Product Owner (le plus fréquemment un par Scrum). Cela permet de garder une disponibilité optimale du Product Owner dans l équipe, mais peut mener à des divergences de point de vue et priorisation Dans ce cas il est intéressant de désigner un Product Owner «en chef» reconnu par tous, qui aura pour rôle d amener au consensus et en cas d échec, de prendre les décisions finales. Cependant cette configuration est à éviter au maximum. Lean Lean est une école de gestion de la production, issue du Toyota Production System, au départ principalement utilisée en production, et plus spécifiquement par le secteur de l automobile. Cependant les principes du Lean ont depuis essaimé en dehors de ces domaines. Le système de pensée Lean se décline sur quatre aspects, pour certains proches de la philosophie agile : - redéfinition de la valeur produite, la valeur ajoutée d une tâche contribuant à un processus doit être considérée du point de vue du client. - développement d un schéma productif caractéristique, avec par exemple l établissement de relations partenariales riches avec ses fournisseurs incités à adopter les mêmes pratiques, ou la recherche permanente de l excellence. - développement d attitudes managériales originales, comme l incitation à proposer des améliorations, ou trouver et éliminer les causes profondes des problèmes dès qu ils surviennent. - stratégie à long terme, en privilégiant les enjeux de long terme, en explicitant son objectif global et en l inscrivant de façon soutenable dans l avenir.
Contractualisation La contractualisation d un projet Scrum peut poser problème, puisqu il n y a pas de date ni de périmètre précis fixes et définitifs. Dans l idéal, un contrat de type «régie» reconduit à la fin de chaque sprint permet de répondre aux spécificités de cette méthode. Un sprint d essai permet alors de donner un ordre de grandeur de vélocité. Lorsqu il s agit de répondre à un Appel d Offre où prix et délai sont fixes, il faudra insister sur l explication de la démarche et son intérêt : visibilité sur l avancement du projet et possibilité de l arrêter à chaque fin de sprint, livraison d un produit fonctionnel, et encore possibilité de modifications sans impact majeur Sachant qu un projet suit aussi la règle des 20/80 (80% de la valeur ajoutée provient de 20% des fonctionnalités seulement) le client peut choisir de s arrêter une fois ces 80% atteints. Dans cette optique là, le backlog hiérarchisé et le planning de release seront la base de la discussion client-fournisseur.