Document Développement itératif, évolutif et agile Auteur Nicoleta SERGI Version 1.0 Date de sortie 23/11/2007 1. Processus Unifié Développement itératif, évolutif et agile Contrairement au cycle de vie séquentiel «en cascade», le développement itératif et évolutif implique de programmer et de tester précocement un système partie selon des cycles répétitifs. Normalement, il suppose aussi que le développement commence avant que tous les besoins n aient été définis en détail : c est le feed-back qui permettra de clarifier, d améliorer et de faire évoluer les spécifications. L approche en cascade favorisait une réflexion exhaustive sur les besoins et la conception, préliminaire à tout codage. Des études répétées on montré que cette approche était fortement associé aux taux d échecs les plus élevés en matière de développement logiciel. Dans un processus en cascade, on essaie de définir (en détail) la plus grande partie des spécifications, voir toutes, avant de programmer. Souvent, on entreprend également de créer une conception complète et des modèles UML complets avant que le codage débute. L idée qu on peut écrire tous les cas d utilisation ou réaliser tous les modèles orientés objet détaillés avant de commencer à programmer est un exemple de raisonnement incorrect. Un processus de développement décrit une méthode qui permet de construire, déployer et éventuellement maintenir un logiciel. Le Processus Unifié s est imposé comme processus de développement itératif pour la construction des systèmes orientés objet. Ce processus est très souple et très ouvert, il incite à inclure des pratiques judicieuses issues d autres méthodes itératives, telles qu Extreme Programming, Scrum. Une pratique essentielle du Processus Unifié et de la plupart des autres méthodes agiles est le développement itératif. Le développement s organise en une série des projets très courts, de durée fixe, nommées itérations. Le résultat de chaque itération est un système partiel exécutable, testé et intégré. Chaque itération comprend ses propres activités : analyse des besoins ; conception ; implémentation et tests. Chaque itération produit un système exécutable mais incomplet, qui n est pas encore prêt à être livré. Il faudra généralement de nombreuses itérations (dix ou quinze) par exemple, avant de pouvoir le déployer dans un environnement de production. Pour chaque itération il faut choisir un petit sous-ensemble de besoins puis concevoir, implémenter et tester rapidement. Lors des premières itérations, le choix
des spécifications et la conception ne correspondent pas forcément au résultat final souhaité, mais le fait de commencer une petite réalisation permet d obtenir rapidement un feed-back des utilisateurs, des développeurs et des tests (en particulier des tests de charge et d ergonomie). Des activités comme les tests de charge, outre qu elles permettent de clarifier les besoins, apporteront la preuve que la conception et l implémentation partielles sont sur la bonne voie ou indiqueront s il y a lieu, lors de l itération suivante d apporter une modification à l architecture de base. Mieux vaut résoudre et prouver au plus tôt les décisions critiques et sujettes à risque ; le développement itératif en fournit les moyens. En conséquence, le processus se développe suivant une série de cycles construction feed-back adaptation. 2. Avantages du développement itératif 1. Diminution des échecs, amélioration de la productivité et de la qualité. 2. Gestion précoce des risques élevés (risques techniques) grâce aux cas d utilisation. 3. Feed-back, implication des utilisateurs et adaptation précoces. Ces points permettent d obtenir un système élaboré qui répond plus étroitement aux besoins réels des parties prenantes. 4. Complexité gérée. L équipe n est plus épuisée par l analyse ou la complexité des tâches. 5. Possibilité d exploiter méthodiquement les leçons tirées d une itération. Cela permet d améliorer le processus de développement lui-même, une itération après l autre. Le changement est une constante à ne pas oublier des projets logiciels, les méthodes itératives reconnaissent les changements et s adaptent grâce au feed-back reçu : - Feed-back issu du début du développement, de la lecture des spécifications par les programmeurs et des démonstrations faites aux clients pour préciser les besoins ; - Feed-back issu des tests et des développeurs pour affiner la conception ou les modèles ; - Feed-back issu de la progression de l équipe abordant les premières fonctionnalités pour ajuster le calendrier et les estimations ; - Feed-back issu du client et du marché pour revoir les priorités des fonctionnalités à traiter dans l itération suivante. La durée des itérations doit être courte avec un feed-back rapide et une adaptation continue. Des itérations longues dénaturent la motivation principale et augmentent les risques du projet. Toutefois, les glissements de dates ne sont pas permis. Si le respect des délais semble compromis, mieux vaut supprimer des tâches ou les inclure dans la prochaine itération que de dépasser la date d achèvement. EXEMPLE DE DEVELOPPEMENT
Avant l itération 1, tenir le premier atelier d expression des besoins, en fixant une limite des temps. 1. Le matin du premier jour : - Analyser les besoins de haut niveau ; - Identifier les noms des cas d utilisation et des fonctionnalités et les principaux besoins non fonctionnels. - Demander à l équipe de choisir parmi les cas d utilisation énoncés une partie présentant ces 3 qualités : o Significatifs du point de vue de l architecture ; o De grande valeur pour le client (ce qui compte vraiment pour lui) ; o Fonctionnalités à haut risque. - Analyser en détail les besoins fonctionnels et non fonctionnels des cas d utilisations choisis d après les 3 critères énoncés plus haut. 2. Tenir une réunion de planification dans laquelle on choisit un sous-ensemble de cas d utilisation qui sera conçu, planifié et testé dans un temps donné. Réaliser l itération 1 (choisir une durée et la respecter) 1. Modélisation des diagrammes UML et des cas d utilisation choisis pour cette itération. Les modèles peuvent et même doivent être vagues pour inciter le programmeur à trouver des solutions adaptés. 2. Coder, tester, intégrer le travail des programmeurs en continu pendant le temps restant avant la fin de l itération. 3. L itération comprend beaucoup des tests : unitaires, de recette, de charge, d ergonomie. 4. Quelques jours avant la fin, demander à l équipe si les objectifs d origine peuvent être atteints. Si c est n est pas le cas il faut modifier la liste de tâches de l itération en plaçant les objectifs secondaires dans la catégorie des «choses à faire». 5. Faire l intégration et les tests pour constituer le référentiel de l itération. 6. Présenter une démonstration du système partiel aux parties prenantes externes afin de leur montrer la progression réalisée. Demander du feed-back. Organiser le deuxième atelier d expression de besoins avant de commencer la prochaine itération. Re-voyer et affiner tout le matériel issu du dernier atelier. Choisir une autre partie des cas d utilisation significatifs du point de vue architectural et d un intérêt certain pour le client. Tenir une réunion de planification de l itération suivante. Réaliser l itération suivante. Les étapes sont similaires. De cette manière, après quelques itérations consacrées au développement exploratoire, arrive le moment où l équipe peut répondre de façon plus fiable à la question «quoi, combien et quand». Le Processus Unifié encourage une planification itérative pilotée à la fois par les risques et par le client. Cela signifie que les objectifs des premières itérations sont choisis afin de : Identifier et atténuer les risques le plus importants ; Construire les fonctionnalités visibles qui comptent le plus pour le client.
Le développement itératif piloté par les risques fait plus spécifiquement appel à la pratique de développement centré sur l architecture. Autrement dit, les premières itérations sont dédiées à construire, tester et stabiliser l architecture du noyau. 3. Méthodes Agiles Les méthodes agiles s appuient elles aussi sur des méthodes de développement itératif et sur une capacité de réponse rapide et souple au changement. Les signataires du manifeste agile privilégient : - Les logiciels fonctionnels d avantage que l exhaustivité de la documentation ; - La collaboration avec le client ; - La réponse au changement d avantage que l application d un plan. Les principes du manifeste agile sont : 1. La première priorité doit être la satisfaction du client. Il faut livrer rapidement et de façon continue un logiciel de qualité. 2. Accepter les changements des besoins, même en cours de développement, en exploitant ces changements pour augmenter les avantages du client. 3. Livrer fréquemment du code fonctionnel (préférence pour les délais courts). 4. Toute l équipe doit travailler ensemble (experts métier et développeurs). 5. Bâtir des projets autour des individus motivés. Leur fournit l environnement et le soutien dont ils ont besoin et leur faire confiance. 6. La méthode la plus efficace pour transmettre l information au sein de l équipe est le face-à-face. 7. Un logiciel fonctionnel est la meilleure mesure de la progression. 8. Commanditaires, développeurs et utilisateurs doivent pouvoir conserver indéfiniment un rythme constant. 9. La réduction du travail inutile au minimum est nécessaire (un logiciel doit être simple et fonctionnel). 10. A intervalles réguliers l équipe réfléchit à une manière d être plus efficace et s adapte et ajuste son comportement en cours de route. Pour arriver à modéliser correctement en respectant le processus itératif il faut : - Construire des modèles (UML) simples à l aide d un logiciel ; - Travailler en binôme ou en trio pour fabriquer les modèles ; - Faire des diagrammes en parallèle ; - Utiliser une notation correcte du point de vue de la conception. Le but de la modélisation n est pas de fournir une solution exacte mais de comprendre mieux le problème posé et communiquer des idées. 4. Bonnes pratiques du processus unifié Il n y a pas de plan détaillé du projet entier. Il existe toutefois un plan à haut niveau nommé plan des phases qui permet d estimer la date de fin du projet et
d autres jalons majeurs, sans que les étapes permettant d aboutir à ces jalons soient finement fixées. Un deuxième plan, nommé plan d itération, n organise précisément qu une itération à la fois. La planification détaillée est effectuée de façon adaptative d une itération à l autre. Meilleures pratiques : 1. Traitement des questions très importantes dans les premières itérations. 2. Implication permanente des utilisateurs et/ou clients dans l évaluation, le feedback et la définition des besoins. 3. Construction du noyau architectural cohérent dès les premières itérations. 4. Application des cas d utilisation de manière appropriée. 5. Modélisation graphique du logiciel (UML). 6. Gestion rigoureuse des spécifications. 7. Pratique des demandes de changement et de la gestion de configuration. 5. Phases du Processus Unifié INTERCEPTION = vision approximative de la finalité du projet, définition du périmètre et des estimations globales. ELABORATION = implémentation itérative de l architecture du noyau, résolution des risques élevées, identification de la plupart des besoins et des cas d utilisation. CONSTRUCTION = implémentation itérative des éléments qui présentent des risques moindres et préparation du déploiement. TRANSITION = moment des bêta tests et du déploiement.