INTRODUCTION A L AGILITE ET AU SCRUM Petits retours sur ce que sont l AGILITE et le SCRUM et les difficultés que cela implique. Résumé Ayant le vent en poupe, l état d esprit AGILE est aujourd hui de plus en plus mis en avant. C est d autant plus simple qu on retrouve l AGILITE aussi bien du côté de la demande de l acheteur que du côté de la réponse du prestataire de service. Cet ouvrage proposera une présentation de ce qu est l AGILITE et le SCRUM en appuyant particulièrement sur certains éléments de blocage régulièrement rencontrés. CATHERINE Tristan Tristan.catherine@sword-group.com
1. Introduction... 2 2. Le «Cycle en V»... 3 2.1. Description... 3 2.1.1. La conception... 3 2.1.2. La réalisation... 4 2.1.3. La qualification... 4 2.2. Organisation... 4 2.2.1. La maitrise d ouvrage (MOA)... 4 2.2.2. La maitrise d œuvre (MOE)... 5 2.3. Les avantages... 5 2.4. Les inconvénients... 5 3. L AGILITE... 7 3.1. Présentation... 7 3.2. Les gains... 7 3.3. L état d esprit AGILE... 8 4. Le SCRUM... 10 4.1. Description... 10 4.2. Les avantages... 12 4.2.1. Le pilotage... 12 4.2.2. La productivité... 12 4.2.3. La couverture rapide... 12 4.3. Les inconvénients... 13 4.3.1. La maturité du SCRUM Master... 13 4.3.2. La maturité du Product Owner... 13 4.3.3. La motivation de l équipe de développement... 14 5. Conclusion... 15 6. Annexe Table des illustrations... 16 1
1 - Introduction 1. Introduction De plus en plus souvent mentionnée par les directions informatiques, l AGILITE devient un incontournable des métiers du service informatique. Supportée par différentes méthodes de conduite de projet, l AGILITE se construit sur une organisation particulière et différente de celles habituellement rencontrées sur le marché. Lorsque ces organisations n ont pas encore accompli leur transition vers le tout AGILE, il est fréquent que ce qui se cache derrière l AGILITE et les méthodes AGILES soit relativement flou pour elles. Si elles perçoivent facilement les avantages, il leur est en général plus difficile de percevoir les contraintes et prérequis pour une mise en œuvre viable de l AGILITE. L objectif de ce livre blanc est donc double. Il s agit d une part de présenter sommairement ce qu est l AGILITE ainsi que le SCRUM, l une des méthodes de conduite de projet AGILE. Et d autre part nous mettrons particulièrement l accent sur certains risques à se lancer dans un projet AGILE sans y être correctement préparé. Afin de bien appréhender les changements nécessaires et les risques potentiels, nous rappellerons dans un premier temps le déroulement d un projet classique (cycle en V ou Cascade) ainsi que ses forces et faiblesses. Cela permettra aussi de bien mettre en évidence les changements fondamentaux à mettre en place lors d une transition AGILE. Ensuite nous prendrons soin de présenter séparément ce qu est l AGILITE et une méthode AGILE particulière : le SCRUM. Nous présenterons en particulier un certain nombre de raisons pour lesquelles la mise en pratique du SCRUM peut être difficile et échouer. 2
2 - Le «Cycle en V» 2. Le «Cycle en V» 2.1. Description La méthode d organisation projet informatique la plus rencontrée aujourd hui dans les grandes entreprises est le modèle «Cycle en V». Ce modèle est constitué de trois phases majeures s enchainant de façon séquentielle : La conception, ou phase descendante, La réalisation, La qualification, ou phase montante. Figure 1 Cycle en V 2.1.1. La conception Il s agit de définir le livrable final (application, infrastructure, migration de données ) par une succession d étapes servant à rationaliser le besoin et à définir les moyens d y répondre. Chaque étape est accompagnée d un livrable dont la validation est habituellement nécessaire pour le passage à l étape suivante. On retrouve en général les livrables suivants : Expression de besoin, Cahier des charges, Spécifications générales, Dossier d architecture fonctionnelle et technique, Spécifications détaillées, Ces livrables intermédiaires contiennent les tests d acceptation nécessaires pour garantir que le livrable final est conforme aux exigences de l étape. Cette phase est couramment appelée «phase descendante» ou «phase de spécification». 3
2 - Le «Cycle en V» 2.1.2. La réalisation Sur la base du dernier livrable de la phase de conception, le livrable final est produit par l équipe de développement. Cette phase est simplement appelée «réalisation». 2.1.3. La qualification Pour chaque étape de la phase descendante ayant défini des tests d acceptation, et dans l ordre inverse de passage, le livrable final passe par une étape de qualification : Tests unitaires, Recette d intégration, Recette utilisateur, L objectif de ces étapes est de valider les tests d acceptations définis aux différentes étapes de la phase descendante. Chaque étape de qualification est suivie d un procès-verbal confirmant ou non le passage à l étape suivante. On parle de «phase montante» ou «phase de qualification». Figure 2 Cycle en V (modèle en cascade) 2.2. Organisation Durant un projet en cycle en V, l équipe est théoriquement divisée en deux domaines de responsabilité bien définis. 2.2.1. La maitrise d ouvrage (MOA) Elle est responsable du projet et du produit final. En tant que telle, elle porte le besoin, sa définition et sa rationalisation. Elle est aussi responsable des aspects stratégiques du projet que sont le budget et le planning. Elle intervient de façon importante durant la phase descendante sur l ensemble des aspects en rapport avec le besoin. 4
2 - Le «Cycle en V» Lors de la phase montante, elle est en charge de l organisation des tests d acceptations correspondant à ses propres livrables de la phase descendante. Elle assume la responsabilité du projet vis-à-vis du commanditaire. En tant que tel, elle est son interlocuteur privilégié ainsi que celui des utilisateurs finaux.. 2.2.2. La maitrise d œuvre (MOE) La maitrise d œuvre (MOE) est responsable de la réalisation du produit final. Elle assiste la MOA durant la phase descendante en spécifiant les moyens techniques devant être mis en œuvre pour répondre au besoin exprimé. Elle assume seule la phase de réalisation. Au cours de la phase montante, elle fournit à la MOA les moyens techniques nécessaires à la réalisation des tests d acceptation. La MOE est directement au service de la MOA et n est pas censée avoir de contact formel avec les utilisateurs finaux ou le commanditaire. 2.3. Les avantages La méthode de projet «Cycle en V» présente au moins les avantages suivants : Le livrable final est théoriquement conforme à ce qui est spécifié en début de projet. Le cadrage du périmètre est donc connu très rapidement. De même, les étapes successives de conception fonctionnelle et technique permettent de connaitre rapidement le cadre financier et l échéancier du projet. L implication des différents intervenants est spécifique à des étapes données. D une part cela représente un avantage conséquent en matière d organisation des ressources humaines. D autre part cela permet de concentrer ces ressources sur leur domaine d expertise. 2.4. Les inconvénients La méthode présente en particulier des inconvénients directement en rapport avec ses avantages : La rigidité des cadres fonctionnels, financiers et temporels rendent difficile l adaptation en cours de projet. Que cela soit d un point de vue évolution du besoin ou évolution technologique. Afin d anticiper ces difficultés, il est courant de lotir en une succession de projet de type «Cycle en V». Cela permet de réduire le périmètre et donc le délai de livraison de chaque projet. Ce lotissement est généralement réalisé sur la base d une couverture du besoin domaine par domaine. Le livrable final étant construit autour et conformément aux spécifications d origines, la moindre erreur dans celles-ci sera propagée tout au long du projet. Afin d éviter ce type d erreur, des efforts particulièrement intensifs doivent être déployés durant les étapes de la phase descendante. Ces efforts représentent un coût important et n ont qu une efficacité limitée. C est en grande partie du fait de la capacité humaine à interpréter les choses. Afin de répondre à ce risque, il est là aussi courant de lotir le projet mais cette fois avec un principe d affinage de la couverture du besoin. On prendra alors le besoin dans son aspect global dans un premier lot pour s attacher à traiter les aspects spécifiques dans les lots ultérieurs. La mixité des deux principes de lotissement est un casse-tête en soit. Le principe même du «Cycle en V» entraine un manque de visibilité sur ce qui est réalisé entre les étapes de la phase descendante et celles de la phase montante. On parle alors d effet tunnel. Le problème principal de l effet tunnel est que plus une erreur est commise en amont 5
2 - Le «Cycle en V» dans la phase descendante et plus elle sera détectée en aval dans la phase montante. Implicitement, plus elle sera détectée en aval dans la phase montante, plus le retour en arrière nécessaire à sa correction dans la phase descendante sera long et couteux. Les erreurs d interprétation humaine ne pouvant pas être totalement supprimées, on ne parle plus de risque mais de problème. Pour limiter l impact de ce problème, des instances de pilotage sont habituellement mises en place. Elles réunissent l ensemble des intervenants (commanditaire, utilisateurs finaux, MOA, MOE) sur une base régulière et de façon suffisamment rapprochée afin de pouvoir répondre aux problèmes au plus tôt. Ces instances sont en général le seul moment du «Cycle en V» où l on réunit une vision d ensemble du projet. Cette vision se matérialise habituellement sous la forme d un tableau de bord constitué d indicateurs de pilotages (risque, problème, budget, planning, ressources, ). Le livrable étant réalisé en un tout sur la base des livrables intermédiaires de la phase descendante, celui-ci est souvent inexploitable avant complétion totale. Bien que mitigé par les approches de lotissement présentées ci-dessus, ce problème reste le plus impactant. L approche tout ou rien rend difficile la capacité à arrêter le projet avant sa complétion sans en perdre le bénéfice. L ensemble de ces inconvénients entraine un taux d échec important mais aussi un taux de projet insatisfaisant important. On constate par ailleurs que ces tendances sont directement en rapport avec l effet tunnel et la durée de ces projets. Figure 3 Taux de réussite des projets «Cycle en V» (source Chaos Manifesto) 6
3 - L AGILITE 3. L AGILITE 3.1. Présentation L AGILITE est un ensemble de principes et de valeurs mis en avant au début des années 2000 dans le cadre d un manifeste s adressant principalement aux structures de développement de logiciels. Nous avons trouvé une voie améliorant le développement logiciel en réalisant ce travail et en aidant les autres à le faire. De ce fait nous avons déduit des valeurs communes : 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 Nous reconnaissons la valeur des seconds éléments mais privilégions les premiers. Le manifeste AGILE (http://agilemanifesto.org/) Dans la mise en œuvre de ses principes, on retrouve les pratiques suivantes : Prioriser la satisfaction du client, Prioriser les fonctions selon leur valeur ajoutée, Utiliser les livrables opérationnels comme seule unité de mesure de l avancement, Organiser et réaliser les livrables opérationnels par itération de quelques semaines, S ajuster aux besoins au fur et à mesure qu ils émergent, Travailler au maximum au contact les uns les autres (utilisateurs finaux, responsable produit, équipes techniques, ), Appliquer un rythme tenable indéfiniment (même s il n est appliqué que sur une période déterminée), Se remettre constamment en question dans une démarche d amélioration continue, Etre transparent sur tous les évènements pouvant impacter le projet afin d y apporter une réponse au plus tôt. 3.2. Les gains Le consensus actuel sur les gains de l AGILITE est : Des plannings projet plus courts, Plus de projets menés à bout, Une satisfaction des utilisateurs finaux plus importante. 7
3 - L AGILITE Figure 4 Projet mené à complétion : AGILITE versus Cascade/Cycle en V 3.3. L état d esprit AGILE L AGILITE n est pas une méthode mais un état d esprit. On peut tout à fait être AGILE sans y prêter particulièrement attention. Un bon exemple est la réalisation de l Opéra de Sydney. La planification projet présentait des travaux échelonnés sur 4 ans pour un budget de 7 millions de dollars. Figure 5 Chantier de l'opéra de Sydney (source site officiel) En réalité le projet aura duré 14 ans (+250%) pour un coût de réalisation de 102 millions de dollars (+1400%). Les raisons de ces dépassements sont multiples : 8
3 - L AGILITE Changement de gouvernement (correspondant à un changement du commanditaire ou des instances décisionnelles dans un projet informatique), Passage de 2 salles de théâtre à 4 salles de théâtre en court de projet (adaptation aux besoins réels en cours de projet), Evolution des moyens techniques pour la réalisation des toitures (évolution des technologies en cours de projet). L Opéra est repris couramment comme exemple catastrophique d une mauvaise gestion de projet. Il a été réalisé dans la douleur (nombreuses actions juridiques entre les prestataires et l état commanditaire) au point que son architecte a choisi de ne jamais le voir terminé. Il est mort 35 ans après l inauguration. Cependant, il s agit avec le recul d une success story indiscutable : Aujourd hui l Opéra de Sydney accueille plus de 4 millions de visiteurs par an, Il est l un des centres de spectacles les plus actifs du monde. Pourtant sa localisation est peu propice, Il est classé au patrimoine mondial de l UNESCO depuis 2007, C est aussi l un des monuments les plus identifiés visuellement au travers du monde, Son architecte, Jørn Oberg Utzon, a reçu le prix Pritzker (considéré comme le prix Nobel d architecture) en 2003 pour l ensemble de son œuvre dont l Opéra. Figure 6 Opéra de Sydney ((source site officiel) 9
4 - Le SCRUM 4. Le SCRUM 4.1. Description Le SCRUM est l une des méthodes d organisation de projet disponible pour mettre en pratique les principes de l AGILITE. La méthode s articule autour d une équipe dont la composition est : Un Product Owner : propriétaire responsable de l application, c est un expert sur le domaine fonctionnel. Il est capable et habilité à prendre les décisions nécessaires sur la définition du périmètre. L équipe de développement : dédiée au projet et constituée de 3 à 6 experts techniques, elle est capable de s autogérer. Elle est aussi initiée aux concepts métiers abordés sur le périmètre. Serviable 1, elle ne doit en aucune façon être servile 2, l esprit ouvert mais critique étant essentiel à un développeur SCRUM. Le SCRUM Master : garant du respect de la méthode, il doit être à l aise aussi bien avec les concepts métiers du périmètre qu avec les technologies employées. Engagé, impliqué et motivé, il vit le projet et le protège des agressions venant de l extérieur. Facilitateur, il est de sa responsabilité de fournir à l équipe les moyens d atteindre ses objectifs. L équipe SCRUM est une cellule autogérée et engagée dans un processus d amélioration continue. La communication au sein de l équipe doit être transparente et abondante. Celle vers l extérieur doit être uniforme et de préférence portée par le Product Owner. L objectif du SCRUM est la réalisation d un projet maximisant la satisfaction des utilisateurs finaux. Pour ce faire, il s organise en un certain nombre d itérations (sprint) toutes éligibles pour une mise en production. Le tout en respectant les engagements de qualité et de souplesse que l on se doit de retrouver dans un projet se disant AGILE. Pour ce faire : La définition du livrable attendu est organisée sous la forme d une liste de cas d utilisation (User Stories) appelée Product Backlog, La complexité de réalisation des éléments de cette liste est alors évaluée par l ensemble de l équipe lors d une réunion (ou plusieurs selon la taille du projet) appelée Planning Poker, Un ensemble cohérent de ces cas d utilisation est regroupé sous la forme d une itération appelée sprint. La complexité globale de ces cas d utilisation doit être traitable durant la durée d exécution fixée pour le sprint, Ces cas d utilisation sont alors définis dans le détail et découpés en taches techniques lors d une réunion de préparation appelée le sprint planning, Chaque jour, lors d une courte réunion appelée Daily Scrum ou Stand Up Meeting, l équipe fait le point sur ce qui a été fait la veille, les difficultés rencontrées et ce qui doit être fait aujourd hui et par qui. A la fin du sprint, les cas d utilisation ayant été entièrement traités sont validés lors d une réunion formelle appelée Sprint Review. Ils sont alors marqués comme traités dans le Product Backlog. Les cas d utilisation non terminés sont considérés comme non commencés. On parle de Demo or Die. 1 Serviable Qui rend volontiers service. (Larousse) 2 Servile Qui ne s écarte pas d un modèle, le suit aveuglément / Qui fait preuve d une soumission excessive. (Larousse) 10
4 - Le SCRUM Une réunion finale appelée Retrospective permet de faire le point sur ce qui marche et ne marche pas dans l organisation projet et de mettre en place un plan d amélioration continue. Le Product Backlog est mis à jour avec les nouveaux besoins ou l abandon d anciens si nécessaire. Un nouvel ensemble cohérent est déterminé pour le sprint suivant et celui-ci commence. Figure 7 Déroulement du SCRUM (la Grande Messe) Le SCRUM permet de vérifier la capacité de production d une équipe tout au long du projet. Il suffit pour cela de faire la somme des complexités des cas d utilisation que l on réussit à traiter au cours de chaque sprint. On parle alors de vélocité. Cette connaissance de la vélocité est particulièrement utile après le premier sprint pour concevoir des ensembles de cas d utilisation à la fois cohérents et réalisables dans le délai fixé. 11
4 - Le SCRUM 4.2. Les avantages Figure 8 Burn Down Chart 4.2.1. Le pilotage SCRUM est une approche AGILE où sont parfaitement définies les clés de voute permettant la planification : Le périmètre projet sous la forme du Product Backlog même s il est amené à évoluer au cours du projet ; Les jalons temporels sous la forme de sprints et des différentes instances de ceux-ci (planning, review, retrospective), Les ressources impliquées sous la forme d un Product Owner, d un SCRUM Master et d une équipe de développement. Il est donc simple en SCRUM de produire l ensemble des indicateurs de suivi de projet permettant au management stratégique de prendre les décisions nécessaires. 4.2.2. La productivité Grace à la priorisation et à la capacité qu il offre de redéfinir le besoin tout au long du projet, SCRUM permet d obtenir un ratio ressources dépensées / production exploitée reconnu comme bien supérieur à celui de l application d un cycle en V. C est une conséquence directe et prévisible de la suppression de l effet tunnel. 4.2.3. La couverture rapide Le rythme et la façon de construire les sprints en SCRUM permettent de livrer rapidement en production la couverture de besoins prioritaires. D une part cela permet d accroitre le retour sur investissement en obtenant plus rapidement les gains apportés par le livrable du projet et d autre part, cela réduit grandement le risque que la couverture d un besoin soit fournie une fois que le besoin n existe plus. 12
4 - Le SCRUM 4.3. Les inconvénients Les principaux facteurs de risque de l application du SCRUM viennent avant tout de la formation et de la maturité des différents acteurs du SCRUM. On notera en particulier : 4.3.1. La maturité du SCRUM Master SCRUM est usuellement décrit comme étant «une méthode de projet AGILE» alors qu il devrait en fait être décrit comme étant «une méthode de projet pour les structures AGILE». Si la différence peut sembler minime, elle devient en fait fondamentale aux vues du peu de structure AGILE présente sur le marché européen. L implémentation d un projet en SCRUM dans une structure non AGILE est à la fois une demande récurrente et un exercice périlleux. La complexité réside dans le fait que s ils sont pris l un après l autre et associer bout à bout, les éléments du SCRUM donne une vision du projet qui semble cohérente ( Déroulement du SCRUM (la Grande Messe)). Cet ensemble est même si cohérent qu on peut chercher à l appliquer tel quel. La position de SCRUM Master est alors réduite au pilotage de cet enchainement que représente la grande messe. On parlera alors de SCRUM dénaturé (la coquille vide). Le résultat peut alors être à l opposé des gains attendus. L exemple le plus flagrant concerne l effet tunnel. Lors d un cycle en V, cet effet entraine un livrable finalisé mais régulièrement assez éloigné du besoin réel au moment de la livraison. Au moins, il y a un livrable finalisé pouvant répondre partiellement au besoin. Lors d un SCRUM dénaturé, il n est pas rare de ne rien avoir à la fin où d avoir un ensemble d essai s appliquant à un besoin unique mais non exploitables en production. C est pourquoi il est essentiel qu un SCRUM Master soit avant tout un leader AGILE. Son métier consiste à mener des projets AGILE et le SCRUM n est que l un de ses outils. Ce n est pas la nature de son travail. Le test est simple. Si vous demandez à un SCRUM Master la nature de son travail, il peut répondre qu il pilote des projets AGILE. S il répond qu il fait du SCRUM ou qu il est SCRUM Master, il y a une probabilité non négligeable qu il apporte plus d importance à la méthode qu aux principes et donc plus d importance à l outil qu au livrable. Nous sommes face à un problème de maturité. Dans une structure non AGILE, la tentation est forte de former au SCRUM les chefs de projet présents alors que ceux-ci n ont pas assimilés les principes fondateurs de l AGILITE. Ils peuvent alors devenir de fervents défenseurs de la méthode ce qui est à l opposé même de l AGILITE. Un SCRUM Master se sert du SCRUM pour faire de l AGILITE. Il est AGILE avec la méthode aussi. 4.3.2. La maturité du Product Owner Le Product Owner est l élément le plus important d un projet SCRUM. Il est le capitaine à bord du navire. Avec l autonomie et la responsabilisation que l on impose à l équipe de développement en SCRUM, il est indispensable qu en contrepartie celle-ci puissent avoir rapidement les réponses à ses questions. En cas d absence de réponse, les développeurs devront faire au mieux avec les éléments à leur disposition et le Product Owner devra assumer la responsabilité de devoir reprendre le besoin si nécessaire. Le contexte est cependant le même que celui évoqué au niveau du SCRUM Master. Les structures AGILE sont encore peu nombreuses sur le marché européen et pourtant la demande de projet SCRUM est bien présente. Les Product Owner sont donc en général issus soit des services métiers, soit des services MOA. Dans le cas où il est nommé dans un service métier, en général la tache de Product Owner est sous-estimée et celui-ci conserve des taches opérationnelles incompatibles avec les 13
4 - Le SCRUM exigences de disponibilité demandées par SCRUM. Dans le cas où il est nommé à partir des services de MOA classique, la situation est en générale pire. Le Product Owner est alors en général incapable de trancher sur les questions fonctionnelles et devient un intermédiaire entre l équipe de développement et le service métier. Dans les deux cas, l équipe de développement perd sa vélocité, se démoralise et finie démotivée. Le SCRUM Master peut aider le Product Owner à gagner en maturité tout au long du projet. Mais il ne peut pas assumer les responsabilités de celui-ci à sa place. 4.3.3. La motivation de l équipe de développement En SCRUM, il est demandé à l équipe de développement de s autogérer au quotidien, de conserver un œil critique, d être force de proposition et de s engager sur ses capacités à couvrir le besoin. C est pourquoi, afin de rester motivé et focalisé, l équipe de développement doit être dédiée au projet. D autre part, afin de conserver cette motivation et cette focalisation, l équipe doit travailler sur un rythme humainement tenable et stable : charge normale et constante. Ces composantes doivent être garanties par le duo SCRUM Master et Product Owner. La maturité du SCRUM Master et du Product Owner rejailli donc directement sur la motivation et l efficacité de l équipe de développement. 14
5 - Conclusion 5. Conclusion SCRUM n est qu une méthode parmi beaucoup d autres. Il existe bien sur un nombre important d autres méthodes, plus ou moins adaptées en fonction du contexte d utilisation. Parmi les autres méthodes AGILE on nommera : Extreme Programming Crystal Clear Kanban Lean Et c est justement là la vraie nature de l AGILITE, ce qui en fait une philosophie, un état d esprit. Il faut être capable de prendre le meilleur de chaque méthode en fonction du contexte d application, en mélanger les éléments pertinents afin de constituer une méthode spécifique au contexte. La seule nécessité est d apporter une réponse aux différentes bonnes pratiques mises en avant par le manifeste AGILE. Ces réponses peuvent même être créées de toute pièce si le contexte l exige, tout en n oubliant pas que réinventer la roue n a rien d AGILE. 15
6 - Annexe Table des illustrations 6. Annexe Table des illustrations Figure 1 Cycle en V... 3 Figure 2 Cycle en V (modèle en cascade)... 4 Figure 3 Taux de réussite des projets «Cycle en V» (source Chaos Manifesto)... 6 Figure 4 Projet mené à complétion : AGILITE versus Cascade/Cycle en V... 8 Figure 5 Chantier de l'opéra de Sydney (source site officiel)... 8 Figure 6 Opéra de Sydney ((source site officiel)... 9 Figure 7 Déroulement du SCRUM (la Grande Messe)... 11 Figure 8 Burn Down Chart... 12 16