L’acceptation du changement

Embrace change, dit Kent Beck, l’un des « pères » du mouvement agile… « Accueillez le changement à bras ouverts » plutôt que de le craindre et de le combattre.
On sait que nombre de paramètres sont imprévisibles lors d’un projet ; il s’agit alors de mieux contrôler cette imprévisibilité sans la nier en voulant être systématiquement conforme aux plans initiaux rapidement obsolètes.
On échappera, de fait, aux gaspillages de temps et d’énergie et aux frustrations qui en résultent, constatés sur les projets qui ne peuvent admettre le changement : temps (souvent conséquent) consacré à l’élaboration du planning, temps dédié à l’analyse des écarts, efforts fournis pour rattraper le retard, temps accordé à la négociation et au refus des changements, temps affecté à remobiliser l’équipe…
Une équipe agile se dote de pratiques et d’outils lui facilitant l’accueil du changement.
Méthodes traditionnelles ou méthodes agiles ?

Origine et valeurs des méthodes agiles

Le mouvement des méthodes agiles est né en 2001 aux États-Unis. Devant l’observation faite du taux important d’échec des projets, notamment dans les années 1990, dix-sept experts en développement logiciel, qui avaient chacun déjà mis au point et expérimenté de nouvelles méthodes, se sont réunis afin d’échanger et de trouver un socle commun de valeurs et de bonnes pratiques.
Le résultat de cette réflexion a abouti au Manifeste pour le développement logiciel agile1 et la création de l’Agile Alliance2, chargée de promouvoir l’agilité dans les organisations et d’apporter du soutien aux équipes qui veulent démarrer un projet agile.
Le Manifeste décline quatre valeurs en treize principes applicables dans toute démarche agile. Chaque méthode adopte ensuite sa propre terminologie et préconise un certain nombre de pratiques.
Quelles sont les quatre valeurs du Manifeste ?
– Les individus et leurs interactions avant les processus et les outils.
– Des fonctionnalités opérationnelles avant la documentation.
– Collaboration avec le client plutôt que contractualisation des relations.
– Acceptation du changement plutôt que conformité aux plans.
Cela ne signifie évidemment pas qu’aucun processus n’est défini, qu’on ne se dote d’aucun outil ; bien entendu, des plans et une documentation, certes plus réduits, sont produits.
Les valeurs mises en avant à gauche n’excluent pas les valeurs à droite.
Plus récemment, en 2005, a été publiée la « Déclaration d’interdépendance »3 avec, parmi ses signataires, des acteurs majeurs de l’Agile Alliance. Cette communauté a formalisé les valeurs mises en pratique qui les amenaient à rencontrer tant de succès et de bons résultats dans leurs projets.
Elles se résument en six concepts, qui doivent être considérés de façon interdépendante : valeur, incertitude, client, individus, équipe et contexte ; vous ne pouvez créer de la valeur si vous ne collaborez pas avec un client qui, précisément, définit ce qu’est sa valeur ; vous ne pouvez attendre d’une équipe qu’elle soit performante si vous ne reconnaissez pas la contribution des individus qui la composent ; vous ne pouvez maîtriser l’incertitude si vous ne prenez pas en considération la spécificité du contexte.
Les treize principes décrits dans le Manifeste sont déclinés des quatre valeurs citées précédemment ; ils sont présentés dans le tableau 2-2.

Principales méthodes agiles

Les principales méthodes agiles se nourrissent toutes des valeurs et principes du Mani-feste ; cependant, si elles ont un tronc commun de pratiques, elles se différencient par leur degré de formalisme – le poids de la méthodologie dans la documentation produite, les étapes formelles, les revues, le rythme du projet ou le nombre et la longueur des itérations.

Quelles sont leurs spécificités ?

Les principales méthodes agiles sont présentées ci-après par ordre alphabétique.
ASD (Adaptative Software Development)
En 2000, Jim Highsmith (signataire du Manifeste) publie un ouvrage sur la méthode ASD, Adaptative Software Development, a collaborative approach to managing complex systems.
Le cycle de vie d’un projet ASD se déroule autour d’une série de cycles en trois volets :
• Spéculation
– initier le projet (mission, contraintes, collaborateurs, expression des exigences, identification des risques…) ;
– déterminer la durée du projet, le nombre d’itérations et les dates associées (4 à 8 semaines par itération) ;
Gestion de projet – Vers les méthodes agiles
– affecter un objectif (mission) à chaque itération ;
– dresser une liste de tâches à réaliser.
• Collaboration
– livraison des composants ;
– communication forte et assez informelle.
• Apprentissage
– contrôle qualité ;
– suivi et bilan d’avancement ;
– communication forte et assez informelle.
Ses caractéristiques principales sont :
• focaliser sur l’objectif (mission focused) ;
• se baser sur des composants (component-based) ;
• itérer ;
• découper le temps et fixer des deadlines (timeboxing) ;
• piloter le projet par les risques (risk-driven development ) ;
• accepter le changement.

Le cycle de vie ASD

Crystal, ou plus exactement la famille de méthodologies Crystal (figure 2-4), a été mise au point par Alistair Cockburn (signataire du Manifeste).
Le principe est de sélectionner la méthode applicable en fonction de la criticité du projet et du nombre de personnes à coordonner. En effet, on ne gère pas de la même façon un projet de dix personnes et un projet de cent personnes, ou un projet de développement d’un intranet documentaire ou d’un système de sécurité.
Crystal Clear désigne la famille de méthodologies dédiées aux équipes inférieures à 8 personnes.
Quelles sont les propriétés de Crystal ?
– Des livraisons fréquentes.
– Des aménagements permanents.
– Une communication osmotique.
– Confiance, liberté d’expression et sécurité personnelle.
– Focus sur l’objectif et disponibilité.
– Un contact permanent avec les utilisateurs.
– Un environnement de travail approprié pour l’automatisation des tests, la gestion de configu-ration et les intégrations fréquentes.
– Une collaboration étroite entre toutes les parties prenantes, y compris en dehors de l’équipe.
– Une réflexion constante sur ces propriétés.
DSDM (Dynamic Software Development Method)
DSDM est le fruit du travail d’un consortium de sociétés désirant utiliser RAD (voir ci-après), de façon structurée et indépendante, en Grande-Bretagne.
DSDM adhère aux valeurs et principes du Manifeste, puisque l’un de ses représentants, Arie Van Bennekum, est l’un de ses signataires. DSDM a cependant mis neuf autres principes complémentaires en avant.
Quels sont les neuf principes de DSDM ?
– Implication active des utilisateurs.
– Autonomie et pouvoir de décision des équipes.
– Livraisons fréquentes.
– Adéquation aux besoins des clients comme seul critère d’acceptation du produit.
– Développement itératif et incrémental.
– Modifications réversibles.
– Définition globale macroscopique des besoins.
– Intégration des tests dans tout le cycle de vie.
– Collaboration et coopération entre toutes les parties prenantes.
• L’étude de faisabilité : comme son nom l’indique, cette phase permet de bien définir le problème à résoudre et d’en étudier la faisabilité, sur les plans technique, métho-dologique et budgétaire.5
• L’étude du « business » : cette phase vise à déterminer et à analyser les processus métier qui doivent être automatisés et les besoins en informations ; grâce à des ateliers facilités, les utilisateurs hiérarchisent leurs besoins. Une définition de l’architecture globale ainsi qu’un plan global de prototypage sont produits pour préparer les phases suivantes.
• Le modèle fonctionnel itératif : ce modèle produit décrit les besoins en détail et permet de définir quand et comment ils seront satisfaits. Le résultat est une série de modules logiciels constituant un prototype fonctionnel.
• La conception et les développements itératifs : il s’agit, dans cette phase, de fournir un système intégrant toutes les fonctionnalités, conforme aux besoins définis.
• La mise en œuvre : cette dernière phase est la phase de livraison et de prise en main de l’application par les utilisateurs qui doivent la tester (après avoir été formés, le cas échéant) et contrôler la qualité de la documentation avant la mise en production. Enfin, un bilan est dressé afin de capitaliser sur les bonnes pratiques mises en œuvre.
DSDM se caractérise également par une spécialisation des acteurs du projet, dont le rôle est précisément décrit.

Quels sont les différents rôles décrits par DSDM ?

Côté utilisateur
– Le sponsor exécutif : sa position hiérarchique, son engagement et sa disponibilité dans le projet garantissent que les ressources humaines et matérielles seront mises à disposition pour le bon déroulement du projet.
– Le visionnaire : il est « l’expert métier » ; il porte la « vision » et s’assure de la cohérence des besoins exprimés ; c’est lui qui participe activement aux ateliers facilités et à la conception du système.
– L’ambassadeur : il assure l’interface entre l’organisation et l’équipe de développement ; il est le représentant des autres utilisateurs et doit fournir les informations nécessaires au dévelop-pement ; il organise les tests utilisateurs et la formation de ces derniers.
– Le chef de projet : ce rôle peut être confié à un représentant des utilisateurs ou à un membre de l’équipe informatique. Il est responsable de l’organisation et de l’avancement du projet et doit assurer un reporting régulier.
Côté informatique
– Le coordinateur technique : il est le responsable technique du projet.
– Le chef d’équipe : il est en charge de la gestion opérationnelle de l’équipe informatique.
– Indépendant de l’équipe de projet, le facilitateur est chargé d’organiser les ateliers.
– Le rapporteur : il est responsable de la rédaction des comptes rendus de toutes les réunions (ateliers, sessions de prototypage…) et de l’enregistrement des décisions prises.
Il faut souligner que cette méthode est particulièrement bien documentée, depuis 1995, en plusieurs langues, avec des mises à jour régulières.

RAD (Rapid Application Development)

Si RAD n’est pas à proprement parler une méthode agile, il n’en demeure pas moins qu’elle en est à l’origine, puisque dès la fin des années 1980, James Martin présentait la première approche (semi)itérative incrémentale préconisant un usage intensif des techniques de communication facilitée. Jean-Pierre Vickoff a adapté le RAD au contexte français (voir http://www.rad.fr).
Cinq phases structurent le développement rapide d’applications :
• L’initialisation : cette phase définit le périmètre du projet, organise le travail par thème et détermine les ressources nécessaires.
• Le cadrage : il s’agit de la phase d’expression des besoins, au cours de sessions, réunions qui favorisent la productivité des groupes de travail grâce à des techniques d’animation spécifiques.
• Le design : c’est la phase de conception au cours de laquelle le système est modélisé. Les utilisateurs y sont associés pour valider les modèles, l’ergonomie et la cinématique générale de l’application.
• La construction : l’équipe ou swat (unité d’élite) construit l’application de façon itérative, par module ou par thème, que valident les utilisateurs toujours impliqués dans le projet.
• La finalisation : cette dernière phase officialise la livraison globale de l’application, déjà partiellement validée par les utilisateurs dans les phases précédentes.
Scrum
Les racines de Scrum se trouvent dans la publication de « The New Product Development Game » de Takeuchi et Nonaka ; cet article, paru en 1986 dans Harvard Business Review, démontre la fin des approches classiques dans le développement de nouveaux produits et met en avant les vertus des petites équipes pluridisciplinaires intégrées et soudées dans une stratégie plus flexible.
Inspirés par cette nouvelle approche et par le lean management, Ken Schwaber et Jeff Sutherland (signataires du Manifeste) ont développé Scrum, en 1993.

Qu’est-ce que le lean management ?

Le lean management est un mouvement de pensée né au Japon, en particulier dans l’industrie automobile chez Toyota. Celui-ci veille à la réduction des pertes générées à l’intérieur d’une organisation (industrie, services…), pour une production dite « au plus juste » (just in time). Les objectifs sont la réduction des cycles de production, la réduction des stocks, l’amélioration de la productivité et l’optimisation de la qualité.
Mary et Tom Poppendieck ont appliqué ces idées dans le monde du développement logiciel. Quels sont les principes du lean, applicables au développement logiciel ?
– Réduire les stocks : la quantité de tâches non réalisées ou en cours de réalisation constitue les stocks.
– Éliminer les sources de gaspillage : toutes les activités qui n’apportent pas de valeur ajoutée au client sont pure perte ; les anomalies du produit, les blocages ou situations d’attente d’une déci-sion, des fonctionnalités développées mais non utilisées par le client… sont autant de gaspillages.
– Favoriser l’apprentissage : adopter une démarche d’amélioration continue (kaizen en japo-nais) faite de petites corrections constantes au quotidien.
– Retarder l’engagement : il ne s’agit pas de procrastination, mais de reporter la prise de décision au moment où l’on disposera de davantage d’informations ; une décision prise dans l’urgence ou sans les informations ou la connaissance nécessaires est une mauvaise décision, sur laquelle il faudra revenir. Il faut planifier la prise de décision en considérant toutes les options possibles, sans spéculation, en disposant d’une meilleure clairvoyance et s’y tenir.
– Livrer vite mais à un niveau de qualité élevé : livrer rapidement permet d’obtenir un feedback. Plus le cycle de développement est court, plus l’apprentissage est rapide et la prise de décision aisée.
– Impliquer l’intelligence des individus : les personnes impliquées sont les mieux à même de savoir comment elles vont procéder ; on ne peut prétendre que le management détient l’unique vérité. La combinaison des intelligences et des expériences – l’intelligence collective – améliore le processus de prise de décision et la qualité de ces décisions.
– Optimiser l’ensemble du système et non une partie seulement. Chaque expert a tendance à considérer son domaine comme le plus important (IHM, base de données…). C’est la perfor-mance de l’ensemble du système qui doit être privilégiée.
Le cycle de vie Scrum (figure 2-6) est rythmé par des itérations de quatre semaines, les sprints ; la liste des exigences initiales, dressée et hiérarchisée avec le client constitue le référentiel, le product backlog.