Collection Mémoires et thèses électroniques
AccueilÀ proposNous joindre
Chapitre 3 : Description de méthodes agiles
Précédent   Suivant

Chapitre 3 : Description de méthodes agiles

Table des matières

La plupart des méthodes agiles ont été élaborées et proposées par des praticiens œuvrant en consultation. Ces méthodes étant relativement jeunes, les références sont assez limitées. Ce chapitre offre un tour d’horizon de différentes méthodes agiles existantes.

Trois d’entre elles sont détaillées : Extreme Programming (XP) pour sa popularité et ses pratiques de programmation ; SCRUM pour sa popularité grandissante et ses pratiques de gestion de projets ; Crystal Clear pour ses valeurs et sa versatilité. Chaque description comporte un bref historique, expliquant les motivations de base des inventeurs et la description de la méthode. Les annexes A, B et C comportent les observations apportant des éléments d’analyse et des critiques. On complète avec un survol de quelques autres méthodes de l’alliance agile.

3.1 Extreme Programming

Extreme Programming (XP) est une méthode agile qui priorise l’excellence technique. Elle comporte un ensemble de pratiques interdépendantes qui demandent beaucoup de rigueur, afin de puiser le maximum d’efficacité des équipes de développement.

Extreme Programming (XP) a été développé par Kent Beck, Ward Cunningham (inventeur du Wiki) et Ron Jefferies au cours des années 1990. Beck est le principal instigateur de XP. Tout en s’intéressant à plusieurs sujets avant-gardistes et au fil des ans, il collabora avec Erich Gamma (1991) et Grady Booch (1993) [Beck 2005]. Le plus important dans la vision de Beck est l’interaction sociale, afin de changer la manière dont les gens se traitent les uns les autres et comment ils sont traités par l’organisation. XP prône les valeurs de communication, la simplicité, le feedback et le courage. Elle est la plus intéressante des approches agiles [Highsmith 2002a]. Elle se concentre sur le client, le gestionnaire et le programmeur. Elle accorde aussi des droits et des responsabilités à ceux qui jouent ces rôles [Beck 2000].

Beck n’a pas inventé les pratiques de XP et il ne s’en cache pas. Ce qu’il a inventé, c’est la synergie qui les relie. Il s’est inspiré de diverses sources qui ont servi à bâtir cette méthode [Beck 1999].

Cette méthode est vouée aux environnements, dont les spécifications changent fréquemment, entraînant une évolution rapide de la planification du projet. On part d’un petit système qui évoluera et se précisera au cours de son développement, ce qui rappelle le modèle en spirale. Elle marque une scission entre les décisions d’affaires et techniques. On construit les spécifications et la planification selon une perspective des caractéristiques. L’utilisation des métaphores aide à synthétiser les concepts.

Cette méthode précise aussi l’attitude des participants et l’aménagement des espaces de bureaux issues d’études sur le sujet. L’annexe F (Les racines de XP) présente la section de l’article de Beck qui répertorie ses sources.

Cette méthode a été créée pour répondre aux changements émergeants de l’apprentissage des clients en cours de projet. Elle s’adresse principalement aux petites équipes composées de 2 à 12 personnes, travaillant dans un espace commun. Elle demande une grande implication du client et exige de pouvoir automatiser les tests. Elle augmente la productivité et offre de meilleurs résultats. Son objectif consiste à livrer le logiciel requis au temps requis [Wells 1999]. Elle se distingue avec ses pratiques particulières et ses valeurs. Elle est exigeante, car chaque pratique en renforce une autre, ce qui forme un tout cohérent. Si vous n’appliquez pas les toutes les pratiques, vous ne suivez pas XP [Beck 2000].

XP repose sur 4 valeurs fondamentales [Beck 2000] :

Ses valeurs se déclinent en 13 pratiques. Ces pratiques se regroupent en quatre grandes catégories qui touchent la planification, la conception, la réalisation et les tests [Beck 2000; Wells 1999]. Il est possible de décomposer ces pratiques en couches, pour faciliter leur implantation. Consulter l’annexe A (Observations sur XP) pour avoir un exemple de regroupement des pratiques. Ces pratiques ne sont pas nouvelles, ce qui est nouveau c’est la manière dont elles sont appliquées [Highsmith 2002a].

Afin de visualiser le processus, nous pouvons schématiser les pratiques dans leur contexte. Nous pourrons voir les détails sur différentes échelles : au niveau du projet, des itérations, du développement et de la propriété commune.

Figure 3-4 : Processus XP au niveau du projet

Figure 3-4 : Processus XP au niveau du projet

Au niveau du projet, les scénarios utilisateurs sont les principaux éléments qui mènent le projet. Ils sont composés par le client qui exprime ses besoins. Ils fournissent la liste des caractéristiques à réaliser et serviront de référence lors des tests d’acceptation.

Les transitions architecturales (architectural spike) forment les grandes parties du système qui construiront les métaphores du projet. L’utilisation de métaphores aide à la communication et permet de regrouper les scénarios ensemble.

La planification de la livraison liste les scénarios qui seront réalisées au cours des itérations. Cette planification se construit en fonction des priorités du client, des estimations et de la vélocité de l’équipe qui prévoit être en mesure de produire ces scénarios pour cette itération.

Si une incertitude survient sur une estimation, une transition (spike) amène un peu plus de rigueur à cette estimation. Elle sert de preuve de concept, afin de mieux évaluer la charge de travail, ce qui élimine les solutions infructueuses. Si quelque chose ne fonctionne pas, il est préférable de le savoir rapidement.

Lorsque la liste des scénarios à réaliser est complétée, les cycles des itérations pour cette livraison commencent. La durée des itérations doit être constante. Une durée de deux à quatre semaines est conseillée. Cette constance aide lors de la planification, puisqu’elle sert au calcul de la vélocité de l’équipe. La vélocité est une mesure estimant la charge de travail qu’une équipe peut réaliser en un laps de temps. Les fonctionnalités étant estimées selon une charge de travail, l’équipe peut déterminer combien de fonctionnalités elle peut livrer lors de cette itération. Cette notion, similaire aux estimations en jour/personne, se raffine à chaque itération qui permet aux équipes de toujours améliorer leur exactitude.

Les tests d’acceptation suivent les itérations. Ces tests d’ordre fonctionnel, comparent les fonctionnalités réalisées aux scénarios décrits préalablement pour en vérifier la conformité. Les problèmes soulevés sont alors complétés dans une version suivante. Ces conformités sont vérifiées par le client.

Lorsque satisfaisante, elle sera une nouvelle petite version. Suite à la livraison de toutes ces petites versions, le projet est terminé.

Figure 3-5 : Processus XP au niveau de l'itération

Figure 3-5 : Processus XP au niveau de l'itération

L’itération est un mini projet en soit. Les intrants de cette phase sont la liste des scénarios utilisateurs à réaliser lors de cette itération et les « bugs » rencontrés aux itérations précédentes. En fonction de sa vélocité, l’équipe estime ce qu’elle pourra livrer.

Ces différents éléments sont consolidés, afin de composer le plan d’itération. Les scénarios non-inclus seront réalisés ultérieurement dans les prochaines itérations de la version.

Lorsque la liste est complétée, l’équipe entre dans la phase de développement. Même au cours de cette activité, l’équipe peut débusquer de nouveaux scénarios. Cette phase est riche en interaction avec le client. Le cycle d’apprentissage s’opère naturellement.

Chacune des corrections et des fonctionnalités complétées, sont intégrées tous les jours à la dernière version. De cette manière, le produit progresse vers son objectif. Le client peut constater concrètement les efforts de l’équipe et voir son système opérer.

Figure 3-6 : Processus XP au niveau du développement

Figure 3-6 : Processus XP au niveau du développement

L’activité principale d’XP reste le développement. Le quotidien des développeurs commence par la rencontre matinale (Stand Up Meeting) qui passe en revue les tâches à réaliser suivant le plan d’itération, ainsi que les tâches précédentes incomplètes. C’est aussi lors de cette rencontre que les demandes trop exigeantes sont mises de côté dans la liste des choses à compléter.

La propriété commune du code fait appel à toutes les compétences de l’équipe même. C’est la pierre d’assise d’XP, elle est expliquée plus en détail à la page suivante. Chaque développeur apporte ses connaissances au projet, afin de partager les éléments qui peuvent aider à la réalisation des fonctionnalités.

Il en ressort de nouvelles fonctionnalités qui réussissent entièrement leur suite de tests unitaires. La correction des erreurs est aussi validée au cours de cette pratique.

Figure 3-7 : Processus XP sur la propriété du code commun

Figure 3-7 : Processus XP sur la propriété du code commun

La pratique de la propriété du code commun, est en fait la réalisation informatique des scénarios utilisateurs décrits sur les cartes CRC (Classe, Responsabilité et Collaboration donc, en anglais : CRC Cards). Le design et la réalisation sont faits conjointement.

Les développeurs prennent connaissance de la tâche à réaliser. Cette tâche peut être nouvelle ou provenir d’une précédente ayant échoué son test d’acceptation que le client ne jugeait pas adéquat. Les développeurs commencent par préparer les tests unitaires qui leur permettront de vérifier le résultat de la fonction qu’ils produiront.

La programmation s’effectue en pairs (pair Programming). Les gens créent, corrigent et simplifient le code source. Le code doit suivre les standards (nomenclature, commentaire etc.) et il doit être conçu de la manière la plus simple et compréhensible possible. Le code doit se limiter à être capable de réaliser les cas de tests que l’on attend de lui. De nouveaux cas de tests unitaires peuvent aussi s’ajouter, afin de colmater les autres erreurs possibles nouvellement décelées.

C’est autour de cette activité que les gens peuvent consulter et perfectionner le code existant, code qu’ils n’ont pas nécessairement fait eux-mêmes. Les tests unitaires automatisés viendront confirmer que tout fonctionne encore correctement après ces modifications.

Si une équipe requiert de l’aide, la paire peut être changée. Cette « circulation » (move people around) renforce les expertises de chaque développeur. L’apprentissage est constant et diversifié. C’est par cette pratique que la connaissance du système se propage, ce qui remplace la lecture des spécifications écrites.

Tout le code et les tests unitaires liés sont intégrés continuellement sur un poste dédié à cette fin. Ce poste est la référence qui garanti l’intégrité du produit. Il assure que les tests unitaires passent dans le contexte du système. Si une régression est observée, elle sera corrigée. Si la correction ne peut être fournie immédiatement, l’ajout est retiré et le système est remis dans son état précédent. C’est une forme de contrôle de configuration du produit garanti en tout temps, une version fonctionnelle de tout le système.

À chaque jour, tous les tests unitaires qui fonctionnent sont soumis au test d’acceptation (acceptance test passed) par le client qui est disponible sur les lieux. Les tests d’acceptation sont validés avec les cartes CRC, qui sont les aide-mémoire du projet. Si une fonctionnalité du système ne correspond pas aux attentes du client, il peut la clarifier directement auprès des développeurs qui arriveront à mieux comprendre ce qu’ils doivent réaliser. La progression du nombre de tests acceptés par itérations, est illustrée par la figure suivante [Tiré de Jefferies 1999].

Figure 3-8 : Progression des tests acceptés par itérations

Figure 3-8 : Progression des tests acceptés par itérations

XP remet en question la séquence des tâches préconisées par les méthodes en cascade : Analyse – Design – Implémentation – Test. Cette méthode diffère aussi des méthodes itératives qui séparent le projet en plus petites phases, mais qui obéit à la même séquence d’opérations. Dans XP, après une première phase couvrant l’ensemble des fonctionnalités du système, toutes les autres tâches sont réalisées de manière parallèle, couvrant ainsi toutes les fonctionnalités et permettant rapidement d’altérer le design.

Figure 3-9 : Séquence des activités selon différentes méthodologies.

Figure 3-9 : Séquence des activités selon différentes méthodologies.

[Tiré de Beck 1999]

Cette manière de procéder met en relief deux choses. Premièrement, l’équipe est autorisée à prendre des décisions sur le design en même temps qu’elle teste et programme le logiciel. Deuxièmement, le développement ne cloisonne pas les gens dans une spécialité comme l’architecture, l’analyse fonctionnelle, la programmation et l’assurance qualité. L’équipe aborde le projet en silo. Elle fragmente le travail et pousse une petite partie jusqu’au bout, avant d’entreprendre une autre section. Cette manière de procéder développe la compétence de l’équipe sur tous les niveaux. Cette pratique réalise plus rapidement des éléments que le client pourra utiliser, avant que le système ne soit réellement complet. Ainsi, le client pourra bénéficier plus rapidement d’un retour sur l’investissement.

La dynamique créée par ce cycle d’interdépendance, amène les clients et les développeurs à mieux se connaître et à mieux communiquer. Chaque participant au projet travaille pour ajouter plus de valeur au produit. Les développeurs et les clients améliorent ainsi leur expertise dans leurs estimations, ce qui crée un cycle d’apprentissage.

Figure 3-10 : Apprentissage de l’estimation de la valeur et des coûts.

Figure 3-10 : Apprentissage de l’estimation de la valeur et des coûts.

[Traduit et tiré de Beck 2000]

Pour en connaître davantage, l’annexe A (Observations sur XP) présente les différentes analyses et critiques sur cette méthode.

Elle est la plus connue des méthodes agiles donnant ainsi l’illusion qu’elle est la seule. Son côté « extrême » dérange. Bien définie par ses pratiques, elle s’accroche surtout aux quatre valeurs fondamentales qui valorisent la communication et les relations humaines. Elle insiste sur la confiance et la qualité, deux éléments importants pour plusieurs développeurs.

La méthode XP est exigeante et ne convient pas à toutes les organisations, elle a une niche particulière, dont les limites ne sont pas encore toutes tracées. Elle s’adresse à de petites équipes autonomes et expérimentées, travaillant dans un contexte où ils ont à découvrir progressivement, avec l’aide du client, le système à construire. C’est une approche qui mérite d’être connue, afin de proposer une vision différente.

3.2 SCRUM

SCRUM est un processus de contrôle empirique de développement logiciel. Il permet aux équipes de produire des logiciels de manière itérative incrémentale, favorisant ce qui a le plus de valeur pour l’entreprise [Norton 2005].

Ken Schwaber est un développeur d’expérience, président de la firme de consultant Advanced Development Methods, Inc (ADM). Cette firme, dédiée à l’amélioration de méthodologies, développa un outil de support nommé MATE (Methods And Tools Expert). Elle a été parmi les pionnières en matière d’outils de gestion des processus. Cet outil était implanté dans plusieurs grandes entreprises. Son cheminement dans ce domaine l’amena à être un partisan évident des procédés adaptatifs, légers et empiriques pour le développement logiciel. Il travailla à l’élaboration de la méthode SCRUM avec Jeff Sutherland et Mike Beedle [Highsmith 2002a; ADM 1996a].

SCRUM est intimement liée à la firme ADM. Leur outil MATE, s’appuyait sur une grande connaissance des méthodologies. L’outil évolua de 1987 à 1993, pour devenir un outil de gestion de processus de travail collaboratif, orienté objet [ADM 1996b].

En 1994, AMD révisa son approche. Elle conclut que les processus utilisés contraignaient le développement et que ces mécanismes de gestion surchargeaient les gestionnaires et les développeurs. Un changement était nécessaire. L’entreprise a pris alors deux grandes orientations de recherche :

Le modèle de processus qui pourrait rencontrer leurs objectifs, devait tolérer le chaos, être mesuré constamment et maximiser la communication. Le produit ne doit jamais être considéré complété, mais doit être le meilleur possible compte tenu des efforts qui auront été investis [Norton 2005].

C’est Jeff Sutherland qui a entendu parler de SCRUM à partir du livre de DeGrace and HuLet Stahl de 1990 « Wicked Problems, Righteous Solutions», principalement suite à un article de Takeuchi et Nonaka dans leur publication du Harvard Business Review de 1986 «  New New Product Development Game ». Sutherland les définit les auteurs comme les parrains du processus SCRUM, ils ont introduit cette notion à partir d’un simple paragraphe : “The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.” [Takeuchi 1986] Cet article présente une liste de caractéristiques pour travailler à la limite du chaos, tout en conservant le contrôle du projet. Le nom SCRUM fait référence à la mêlée que forment les joueurs de rugby lorsque le ballon est mis en jeu. Cette métaphore nomme les rencontres journalières que tient l’équipe au cours du développement. Dans un environnement instable, les équipes sont appelées à être autonomes pour s’organiser. Le chevauchement des phases de développement favorise l’apprentissage multiple, le développeur améliore ses compétences d’architecte, de concepteur, de programmeur et de testeur. La fréquence des rencontres augmente le transfert des connaissances organisationnelles, le tout suivi par des contrôles subtils.

Chez DuPont, Schwaber rencontra Babatunde Ogannaike qui rédigeait un document sur les contrôles des procédés industriels pour l’industrie chimique. Il dénota deux types de processus, ceux étant définis assez précisément pour être automatisés et les autres, moins définis, classés empiriques. Ces derniers ne pouvant être planifiés, des contrôles rapprochés s’imposaient [Highsmith 2002a]. En s’appuyant sur trois théories, Schwaber conclut que le processus de développement était empirique, plutôt que défini [Norton 2005].

Le principe d’incertitude en génie logiciel de Ziv, qui statue que l’incertitude est inhérente et inévitable en développement logiciel.
Le principe d’incertitude des spécifications de Humphrey, qui statue que pour les nouveaux logiciels, les spécifications ne seront pas complétées tant que l’utilisateur n’aura pas utilisé le logiciel.
Wegner's Lemma statue qu’il est impossible de fournir toutes les spécifications pour un système interactif.

La figure suivante illustre les résultats d’analyse de chez ADM et le pourcentage de chance de réussite d’un projet de développement, en fonction de la complexité de son environnement. Les résultats démontrent qu’il y a moins de chance de terminer avec succès un projet complexe en suivant un processus défini plutôt qu’empirique.

Figure 3-11 : Probabilité de succès en fonction de la complexité du projet

Figure 3-11 : Probabilité de succès en fonction de la complexité du projet

[Tiré de ADM 2003].

Un processus défini permet de prévoir les résultats en fonctions d’un contexte. Un tel processus peut produire un modèle théorique qui est automatisable. À l’opposé, si on ne connaît pas complètement un processus et que le seul moyen d’obtenir le résultat voulu est de le contrôler, ce processus est qualifié d’empirique. Les modèles des processus empiriques sont dérivés des variables observées et des contrôles implantés pour produire un résultat dans des limites prescrites. Nous devons le traiter comme une boîte noire [ADM 1996b; Rosenhead 1998]. Le travail d’un programmeur étant considéré de la sorte, il peut tout de même être contrôlé par des mécanismes de suivi à brève échéance. Moins un système est prévisible, plus le suivi doit être court. Les rencontres journalières contrôlent ainsi le processus.

SCRUM s’inspire de sources diversifiées. Elle est une amélioration du processus itératif et de l’approche incrémentale pour le logiciel orienté objet, initialement documenté par Pittman, puis par Booch [Pittman 1993;Booch 1995]. Ce processus peut servir au personnel de gestion, mais d’une manière différente, tel que décrit par Graham [Graham 1994].

Plusieurs processus sont traités comme définis, alors que ce n’est pas le cas. Des résultats imprévisibles et incontrôlés en découlent. La première observation de petites équipes hautement performantes a été réalisée en 1986 par Takeuchi and Nonaka dans plusieurs firmes de haute technologie [Takeuchi 1986]. Une approche similaire appliquée au développement logiciel a été observée chez Borland par Coplien [Coplien 1994].

Après avoir été adaptée pour le développement en Smaltalk par Sutherlandet pour Delphi par Schwaber, [Schwaber 1996] les analystes conclurent que SCRUM peut aussi être appropriée pour d’autres entreprises de développement [Aberdeen 1995].

Plusieurs éléments de SCRUM sont des métaphores référant au rugby. Le développement est perçu comme un jeu d’équipe. Au dire de Ken Schwaber « Les deux s’adaptent, sont rapides, s’organisent de manière autonome et ont peu de repos.» [Traduit et tiré de Highsmith 2002a]

Backlog produit : Liste des éléments techniques et fonctionnels à produire dans un avenir prévisible pour le produit complet. Inclue ce qui est défini et ce qui reste à préciser.
Sprint backlog :Liste des éléments techniques et fonctionnels à produire au cours d’un sprint. C’est un sous-ensemble du backlog produit. Elle comporte des éléments suffisamment définis pour qu’ils soient réalisés au cours de la période du sprint.
Sprint : Une période de 30 jours où un ensemble de travaux sont effectués pour créer un livrable.
SCRUM : Rencontre journalière de l’équipe où l’avancement et les empêchements sont révisés. Il s’agit du plus fréquent et plus bas niveau de contrôle.
Règlement des rencontres SCRUM : Protocole des réunions quotidiennes pour être efficaces. Afin de minimiser la logistique, une série de règles uniformise la dynamique des rencontres.
Équipe SCRUM : Équipe multidisciplinaire qui travaille sur les éléments du sprint. Toutes les personnes (vente, service clientèle, etc.) impliquées dans le projet sont invitées à se joindre à l’équipe.

Cette méthode se décline principalement en trois phases [Schwaber 1996].

La Phase initiale est consacrée à préparer le travail à faire. Cette démarche est linéaire et connue. Cette phase doit construire la liste des éléments que comportera cette version du produit. Elle comporte les objectifs suivants :

Planning -Architecture
Mise en place d’un backlog produit (liste des éléments à effectuer)
Définition de l’équipe
Analyse des risques – Budget

Les phases de sprints sont les phases itérativesqui réalisent concrètement les éléments qui composent le produit. Ce travail étant plus chaotique, il est aussi qualifié de « boîte noire ». Elles comportent les objectifs suivants :

Un sprint backlog est sélectionné, cette liste sera suivie et réalisée.
Période d’environ 30 jours, au cours de laquelle l’équipe est isolée des influences extérieures. C’est-à-dire que la liste des éléments reste inchangée.
Réunion quotidienne SCRUM.
Comporte au dernier jour, une réunion post-sprint de présentation des résultats.

La Phase de clôture, elle aussi est linéaire et connue. Elle prépare la documentation, finalise les tests et rend la version fonctionnelle et présentable.

Documentation finale
Préparatif et livraison.

Figure 3-12 : Processus global de SCRUM

Figure 3-12 : Processus global de SCRUM

[Tiré de Cohn 2005a].

SCRUM utilise une liste de caractéristiques envisageables qui composent le backlog du produit. Toutes personnes pouvant apporter quelque chose au projet sont invitées à participer, ce qui inclue les ventes, le marketing, le service à la clientèle, etc. Comme l’équipe technique participe avec le client à dresser cette liste, les caractéristiques incluent à la fois les fonctionnalités et les éléments techniques. Cette liste, d’ordre macroscopique, permet de dresser une architecture globale du produit.

La rencontre précédent un sprint, assure de choisir les éléments pour composer le backlog du sprint. Les caractéristiques sont choisies en fonction de leur valeur pour le client. En un premier temps, on identifie les caractéristiques. Ensuite on détermine les tâches pour réaliser ces caractéristiques. Une estimation plus précise peut alors être réalisée, afin de coordonner les efforts nécessaires et les ressources disponibles au cours du sprint. Cette liste sera réalisée au cours des 30 jours que durera le sprint.

Finalement, un but au sprint doit être déterminé selon une vision d’affaire. Cet objectif peut être atteint avec un sous-ensemble des caractéristiques ou de tâches demandées, afin de laisser un peu de latitude à l’équipe au cours du sprint. L’objectif étant la cible à atteindre afin que l’équipe arrive à concevoir ce qui doit être fait. Ceci conserve la vision de l’objectif et rappelle pourquoi quelque chose doit être fait. C’est ce qui permet une certaine latitude, afin d’adapter certains éléments pour atteindre l’objectif [Highsmith 2002a].

Le sprint est la phase de réalisation itérative du produit, c’est le cœur de SCRUM. Il peut y avoir plusieurs sprints afin de créer une version livrable. La section suivante reprend en détail ces éléments.

À la fin d’un des sprints de la version, le client peut décider que le produit est suffisamment complet en fonction de son échéancier, ses finances ou toute autre raison. Cette décision commande de préparer une version livrable. C’est à ce moment que le polissage du produit, l’implantation et la formation sont réalisés pour cette livraison.

Pour initier un sprint, il doit y avoir une liste d’éléments sélectionnés composant ainsi le backlog du sprint. Au cours de cette période d’environs 30 jours, l’équipe se concentre sur cette liste. Toutes les altérations (ajouts, retraits) seront relayées au backlog produit. L’équipe est isolée de l’influence extérieure pour cette période [BI 2001]. C’est au cours de cette période que l’équipe doit s’adapter à son environnement, qui est constitué des exigences, du temps, des ressources, des connaissances et de la technologie [VTT 2002].

Cette rencontre se divise en deux parties. La première vise à établir l’objectif des fonctionnalités du prochain sprint. La seconde, plus technique, vise à établir les moyens mis en places pour la réalisation de cet objectif.

En fonction des éléments du backlog produit, les éléments prioritaires et pertinents avec l’objectif du prochain sprint sont sélectionnés. Lorsque la liste est établie, le sprint peut commencer. Cette liste reste stable jusqu’à la fin du sprint.

Chaque jour, l’équipe se rencontre pour une période d’environs 30 minutes. Cette courte rencontre est appelée SCRUM et a pour but de mesurer la progression du sprint. C’est un des contrôles empiriques de SCRUM. Le chef de projet, appelé « SCRUM Master », demande à chaque participant de répondre à trois questions :

Le chef de projet a pour responsabilité de prendre les décisions que l’équipe n’est pas en mesure de prendre et d’éliminer les embûches rencontrées. L’objectif est à la fois d’avoir l’avancement du projet et de partager les connaissances entre les membres de l’équipe.

Au dernier jour du sprint, se tient une rencontre informelle avec tous les intervenants afin de démontrer la progression. C’est à ce moment que la décision est prise pour poursuivre le projet vers un autre sprint ou conclure avec une livraison. Au terme de cette rencontre, il peut en découler de nouveaux éléments au backlog produit ou une nouvelle orientation.

Les variables d’un projet de développement de système sont les risques, les fonctionnalités, les coûts, le temps et la qualité. Ces variables sont grossièrement estimées au début du projet. Chacune d’elle changera en cours de projet. Il existe une interrelation entre les variables. Par exemple, nous pouvons améliorer les fonctionnalités en investissant plus de temps et d’argent. Afin de permettre un suivi, différents contrôles existent dans SCRUM. Chaque élément peut être quantifié, afin de permettre l’extraction de métriques qui permettent le suivi [ADM 1996a]. On y retrouve notamment :

Le backlog projet liste toutes les fonctionnalités et caractéristiques qui seront complétées dans l’ensemble du projet.
Les problèmes sont des élémentsqui doivent être solutionnés par un membre de l’équipe, afin de permettre la réalisation des objets liés au backlog produit.
Un changement est l’activité réalisée pour résoudre un problème ou implanter une solution.
Un risque peut être associé à un problème, un enjeu ou un élément du backlog.

Ces contrôles sont mesurés, corrélés, et suivis. Les principaux contrôles sont le backlog et les risques. Le backlog doit être de haut niveau pour commencer et raffiné en cours de projet. La liste des risques se rédige lorsque le backlog, les enjeux et les problèmes sont plus détaillés. Lorsque le logiciel est complété, les risques sont rendus à un niveau acceptable

L’annexe B (Observations sur SCRUM) discute des différentes possibilités et présente quelques extensions et solutions possibles concernant les problématiques fréquemment discutées. À la fin de cette annexe, vous trouverez une synthèse d’une seule page.

Conclusion sur SCRUM

Certains prétendent que SCRUM pourrait se voir étendre à divers secteurs de l’entreprise. C’est un retour aux sources, car à son origine, SCRUM ne s’adressait pas au développement logiciel [Sutherland 2005].

Puisant ses racines au milieu des années 1980, SCRUM amène une dynamique différente de la gestion de projets des développements logiciels. Elle propose un équilibre entre la portion définie et la portion chaotique du développement de produit. Cette méthode ne précise pas de technique de réalisation précise. Elle laisse cet aspect à la discrétion de l’équipe. Cette ouverture permet l’inclusion de pratiques provenant de d’autres méthodes.

En priorisant sur la valeur ajoutée par chaque composante du produit, SCRUM assure que ce dernier est toujours la meilleure valeur d’affaire possible pour l’investissement du client.

En détachant l’aspect logiciel et en portant cette approche à d’autre domaine d’ingénierie, SCRUM se permet de porter l’agilité aux autres secteurs de développement de produits.

3.3 Famille Crystal

Alistair Cockburn se présente comme un ethno-méthodologiste, il étudie la culture et les méthodologies de développement. Ayant beaucoup voyagé, il constate que la plupart des cultures fonctionnent. Bien que parfois étrange, ne pas comprendre l’aspect culturel peut mener à l’échec. Chaque pays, entreprise ou projet possède sa propre culture.

À travers ses expériences, il réalisa que la théorie ne s’appliquait pas partout et qu’une culture locale existe à chaque endroit. Il n’y a pas qu’une seule réponse à la question des méthodes. Il chercha à discerner les meilleures techniques. Il mit à l’essaie une première méthode et constata que les gens ne suivaient pas ce qui était prescrit. Il comprit qu’il y avait quelque chose de plus complexe : la nature humaine.

Pour lui, une méthodologie se définie par un ensemble d’éléments de communication et de politique, afin de coordonner les efforts d’une équipe. Cet ensemble de conventions défini la méthode. Ce que fait un groupe de personnes pour se coordonner est une méthodologie [6] . Cockburn est aussi motivé par l’introspection créatrice nécessaire à la conception logiciel.

Il est un des rares méthodologiste à creuser le passé, afin d’analyser ce qui fonctionne efficacement. Il découvrit plusieurs choses intéressantes. Premièrement, pratiquement personne n’applique ce que l’on retrouve dans les livres d’experts. Peu de gens disent qu’ils ont essayé et ceux qu’ils le disent, ne le recommande pas. Deuxièmement, quels que soient les outils ou les technologies utilisés, aucun ne prédit la performance. Le seul point déterminant, est que l’équipe collabore bien [Highsmith 2002a].

Crystal est une plate-forme méthodologique. La famille de méthode Crystal comporte présentement quatre membres, qui ne sont pas encore tous documentés. Présentement, seul Crystal Orange et Clear ont été décrit dans différents ouvrages [Cockburn 1997; Cockburn 2004]. L’analogie avec les couleurs de Crystal, réfère à son opacité, plus la méthode est complexe plus sa couleur est foncée. Pour qu’une équipe puisse choisir la méthode qui lui convient, on présente souvent cette famille sous forme de matrice.

L’axe des X représente la grosseur de l’équipe. Le nombre de personne impliquée sur un projet, détermine les éléments de communication qui devront être utilisé. La qualité de la communication est fondamentale pour Crystal. Plus il y a de personnes impliquées, plus les moyens de communications sont formalisés.

L’axe des Y représente les dommages potentiels pouvant avoir un impact sur la qualité du produit. Le niveau critique du système s’étend de la perte de confort, la perte d’argent discrétionnaire, la perte d’argent essentielle ou la perte de vie. Plus le produit comporte un impact lourd, plus il y aura de pratiques d’assurance qualité du produit.

Figure 3-13 : Matrice de la famille Crystal

Figure 3-13 : Matrice de la famille Crystal

[Tiré de Cohn 2004]

Crystal Clear est une méthode ouverte qui permet d’intégrer des pratiques provenant de d’autres méthodes. Ce qui constitue le noyau de cette méthode, c’est les propriétés appliquées à travers différentes stratégies et techniques [Cockburn 2004].

Livrer fréquemment comporte plusieurs avantages. Cela démontre le progrès et permet aux utilisateurs de valider la conformité du produit. Ce retour d’expérience guide l’équipe de développement et l’encourage à continuer. Cette propriété permet aussi de raffiner la méthode de déploiement. Une livraison mensuelle est conseillée. Une équipe adoptant cette propriété peut se demander: “Au cours des six derniers mois, avez-vous livré au moins deux fois le code testé et utile à vos utilisateurs?”

En cours de développement, l’équipe est appelée à s’analyser pour faire ressortir les pratiques efficaces et celles qui doivent être améliorées ou abandonnées. L’équipe adapte sa méthode. Elle ajuste ses conventions, afin de trouver son point d’équilibre. Une équipe adoptant cette propriété peut se demander: « Au cours des deux derniers mois, votre équipe s’est-elle réunie pour discuter de la manière dont elle travaille? Savez-vous ce qui vous aide, vous ralenti et ce qui peut être amélioré? »

La communication est le point fort de Crystal Clear. Cette méthode demande que l’équipe soit très proche et dans une aire ouverte. Il faut que les gens soit « à porter d’oreille » afin que les conversations d’arrière plan puissent être comprises. C’est une manière très rapide et efficace pour obtenir les commentaires des autres membres de l’équipe. Lorsque quelqu’un pose une question, tout le monde peut y répondre ou corriger la réponse de celui qui l’a fourni. Une équipe qui adopte cette propriété peut se demander: « Est-ce que cela prend moins de trente secondes afin de poser une question, face à face, à la personne qui connaît la réponse? Percevons-nous régulièrement des éléments pertinents à travers les conversations des autres? »

Les membres de l’équipe doivent pouvoir discuter librement des choses qui les dérangent, sans avoir peur des représailles. C’est une preuve de confiance et cela signifie que la qualité des échanges est de nature transparente. Il faut que les membres de l’équipe puissent admettre leur ignorance, leurs erreurs ou leur incapacité à accomplir une tâche. Lorsqu’il n’y a pas de crainte à cet égard, les gens échangent les informations plus librement. Cette propriété s’appuie sur des études qui prouvent une corrélation entre la confiance et la performance d’une équipe. Une équipe adoptant cette propriété peut se demander: « Puis-je dire à mon supérieur que j’ai sous-estimé le projet de 50%? Pouvons-nous débattre sur la conception des autres et manifester un désaccord amical? »

Chaque personne doit savoir ce qu’il a à faire et avoir le temps requis pour s’y consacrer. Connaître l’objectif aide à motiver le développeur qui comprend mieux l’importance de sa tâche. Pour se motiver, une personne doit pouvoir investir suffisamment de temps pour démontrer une progression. Il est possible que des plages de temps sans dérangement soient requises, afin d’atteindre cet objectif. Par exemple, certaines équipes prohibent les réunions en matinée. Une équipe adoptant cette propriété peut se demander: « Est-ce que tout le monde connaît les deux éléments prioritaires sur lesquels ils doivent travailler? Est-ce-je peux travailler sur mes priorités, au moins deux jours de suite par semaine ou deux heures de suite par jour? »

Contacter facilement l’utilisateur comporte plusieurs avantages. Cela permet de déployer et tester les livraisons. L’accès facile permet de fournir du feedback rapide sur la qualité du travail et sur les décisions de conception à prendre, tout en fournissant des spécifications à jours. Il existe différentes méthodes pour faciliter cet accès. La première, est de rencontrer périodiquement l’utilisateur. La seconde, consiste à intégrer l’utilisateur à l’équipe de développement. Finalement, un développeur peut être formé auprès des utilisateurs, afin de connaître les différentes tâches supportées par le système à produire. Une équipe adoptant cette propriété peut se demander: « Pouvons-nous obtenir les réponses des utilisateurs en moins de trois jours? Le pouvons-nous en quelques heures? »

Certains éléments techniques favorisent l’agilité. Les outils utilisés permettent une souplesse dans la manipulation du code. Les meilleures équipes utilisent conjointement les trois éléments :

Une équipe adoptant cette propriété peut se demander: « Pouvons-nous lancer les tests sans que personne ne soit présent? Est-ce que tous les développeurs vérifient leur code dans l’outil de gestion de configuration? Est-ce que le système est intégré au moins deux fois par semaine? »

Crystal Clear n’impose pas de stratégie ou de technique précise. Elle en propose certaines, afin d’aider le démarrage. L’équipe déterminera en cours de projet ce qui est le plus avantageux pour elle. Crystal comporte une révision périodique sur la manière de travailler, ce qui permet à l’équipe de s’ajuster [Cockburn 2004].

Au début du projet, l’équipe est invitée à faire un tour d’horizon du projet. Cette stratégie permet au départ de fixer quelle est la valeur d’affaire et ses spécifications. Cette étape de haut niveau permet de planifier le projet, les technologies, de composer l’équipe, de définir la méthode et les conventions de travail utilisés. Cette étape de planification peut prendre quelques jours à une semaine. À la fin de cette étape, les décideurs sont en mesure de choisir si le projet est une bonne opportunité ou s’il est préférable de ne pas procéder.

Gagner est une force qui aide les équipes à avoir confiance en elle-même. Les petites victoires renforcent le groupe et favorisent l’esprit d’équipe. Si cette force surgit en début de projet, elle peut permettre d’accélérer la cohésion de l’équipe dès le départ. Certaines méthodes proposent de commencer par le plus complexe en premier, afin de valider que les difficultés latentes soient surmontées. Paradoxalement, l’équipe doit s’adapter et se faire confiance, ils ont donc deux difficultés importantes à confronter simultanément. La stratégie que propose Crystal est de prendre un élément facilement réalisable, afin de valider la manière de travailler avant d’attaquer les problèmes les plus complexes. De cette manière, un projet techniquement réalisable ne sera pas abandonné pour des raisons d’organisation du travail.

Cette stratégie complète aisément celle de la victoire rapide. Son objectif est de concevoir une architecture minimale pour que le produit soit fonctionnel. Il s’agit parfois d’une fonction primaire du système tel que de permettre une inscription dans une base de données. Ceci permet de baliser la démarche technique qui sera suivie. Elle valide le fonctionnement des couches nécessaire au système. Le code réalisé à ce niveau est permanent. Il ne s’agit pas d’un prototype ou une preuve de faisabilité technique. C’est l’ossature sur laquelle est incrémentée les autres fonctions. Cette stratégie est aussi utilisée dans d’autres méthodes [Poppendieck 2003a].

L’architecture doit évoluer à partir de son origine pour répondre aux contraintes d’affaires et technologiques. Révisée, l’architecture est une des propriétés fondamentales de l’agilité logiciel. Il est possible que certains architectes très expérimentés puissent concevoir une architecture ayant une longue portée. Par contre, elle ne devrait pas excéder la vision de l’architecte et les contraintes établies. Une architecture minimaliste et simple s’avère facilement évolutive. Les fonctionnalités sont disponibles plus rapidement, ce qui accélère la réception des commentaires des utilisateurs.

Les radiateurs d’informations sont des outils d’affichage, illustrant la progression du projet. Souvent sous forme d’affiches, ils doivent être installés à la vue et comporter des informations facilement compréhensibles. Ces outils permettent d’informer tous les passants, ce qui réduit les dérangements causés par les questions d’avancement. L’information couramment affichée, couvre les fonctionnalités en cours de développement, les assignations ainsi que différentes métriques, tel que le nombre de cas de tests développés ou le constat des réunions.

Cette technique se décompose en deux étapes. Elle débute par une série d’entrevue, afin d’élaborer les forces et les faiblesses de l’équipe. Il en résulte une liste d’expertises, des bonnes et des mauvaises pratiques expérimentées. La seconde étape reprend cette liste, afin de composer une méthode. L’équipe est appelée à choisir les éléments qui composeront la méthode employée en cours de projet. Cette série de conventions sert de point de départ au projet.

Les ateliers de réflexion sont complémentaires au façonnement de la méthode. Après chaque livraison, il est conseillé à l’équipe de se consulter pour analyser leur méthode de travail. Elle discute de ce qui fonctionne bien et de ce qui devrait être corrigé ou abandonné. Afin d’aider la réflexion, il est suggéré de dresser un tableau séparé en trois sections dans lesquels sont listés les différents éléments de la méthode. Une section est consacrée à ce qui doit être conservé. Une autre section est consacrée à ce qui ne fonctionne pas bien et ce qui cause des problèmes. Finalement une section est consacrée à lister ce qui devrait être essayé.

C’est l’occasion pour les décideurs et les utilisateurs experts de contribuer au projet avec l’équipe de développement, afin de produire le plan et l’échéancier du projet. Un peut comme XP [Beck 2000], les participants indiquent sur des cartes les différentes tâches à réaliser en cours de projet. On indique sur la carte une brève description de la tâche, la personne en charge et une estimation sommaire. Ces tâches sont ensuite groupées, formant ainsi les itérations. L’ordre des itérations représente la priorité, l’effort total et individuel qui sera demandé au cours de sa réalisation.

Cette technique d’estimation a pour objectif de prévoir l’effort global du projet. Elle s’inspire de la technique « Wideband Delphi Technique » développé par la défense américaine [Wikipedia 2006h].Son objectif est d’estimer les coûts, la durée, les ressources et de planifier les itérations. Cette technique requiert de réunir une équipe d’experts qui doit estimer différents aspects qui composeront le logiciel. Lors de la première phase, chaque expert doit faire sa propre estimation, qui sera discutée en groupe par la suite. La seconde étape consiste à planifier qui sera affecté aux différents éléments prévus. Cette seconde phase est importante, afin de s’assurer d’avoir les personnes requises au bon moment. La somme des efforts formera l’estimation initiale. La planification des itérations met ensemble les cas d’utilisation similaire, pour composer les différents livrables.

De courtes rencontres journalières, d’environs 15 minutes sont suggérées. Cette technique ne ce cache pas de provenir de SCRUM (Voir SCRUM journalier). Le suivi journalier demeure la meilleure manière de suivre les travaux et de partager l’information.

La conception centrée sur l’utilisation proposée dans Crystal Clear, provient de Jeff Patton [Patton 2002]. Elle demande la participation du client, afin de modéliser le processus de travail que devra supporter le système. Cette approche est centrée sur l’utilisation et permet de concevoir les interactions et les interfaces utilisateurs. De cette manière, le décideur, les utilisateurs et les développeurs partagent une compréhension commune du système. Une fois la conception complétée, il est simple de classifier les fonctionnalités par importance pour l’organisation. Cette technique préconise l’utilisation de papier « post-it » et de crayons, afin que tous les participants soient à l’aise d’intervenir dans la conception.

Comme tout nouveau processus dans l’organisation, il est bon de le mettre à l’épreuve à petite échelle, afin de valider son fonctionnement. Ce que l’on appelle le processus miniature, consiste à prendre quelques heures afin de simuler son fonctionnement. Les oublis et les erreurs sont alors découverts rapidement. De cette manière, tous les gens impliqués ont une meilleure compréhension de leur rôle et de la place qu’ils occupent dans ce processus. Suite à cette expérimentation, les gens adhèreront plus facilement au processus.

La programmation en pairs de XP, consiste à coupler deux développeurs assignés à la même tâche, sur un seul poste de travail. La programmation « côte à côte » de Crystal, n’impose pas de travailler à deux sur une même assignation. Il suggère de mettre les deux développeurs assez proche l’un de l’autre, pour leur permettre de voir l’écran de l’autre sans effort. Cette technique est une amplification de la communication osmotique. Il a été prouvé que les revues de conceptions et de codes sont économiques et comportent moins de défauts.

Le tableau de progression est un outil de communication qui illustre la planification et la progression du projet. Il se construit à travers le temps pour afficher la progression du projet. Il peut être présenté de manière traditionnelle, marquant une progression cumulant les efforts réalisés à travers le temps. Moins connu, le tableau régressif considère que 100% du travail reste à faire et que l’objectif à atteindre est 0. Il comporte un effet positif sur le moral de l’équipe qui voit le travail à faire, diminuer. Ce tableau est d’autant plus efficace si les repères sont assez rapprochés et fixes. Les itérations pouvant servir de repères, les dépassements sont constatés rapidement et peuvent être mieux contrôlés.

Comme les autres approches agiles, le modèle itératif incrémentale est repris. Crystal Clear est composé de cycles imbriqués. La méthode proposée nous permet de schématiser les cycles et leurs répétitions comme une série d'imbrications.

Figure 3-14 : Imbrication des différents cycles de Crystal.

Figure 3-14 : Imbrication des différents cycles de Crystal.

[Inspiré de Cockburn 2004]

Le projet est l’unité de base et peut être de durée variable. Il comporte une étape de planification initiale, au moins deux cycles de livraisons et une étape de fermeture.

La planification initiale vise à recruter l’équipe principale en charge du projet. C’est à ce moment que l’équipe fait l’exploration 360°, qui peut résulter par l’abandon du projet. On y détermine les conventions de la méthodologie qui seront suivi. Finalement, on y construit une planification initiale du projet. Cette planification de haut niveau comporte un aperçu des différents livrables à venir. Ensuite, commence les cycles de livraisons.

Lorsque tous les cycles de livraisons sont complétés, l’équipe procède à la clôture du projet, par une dernière réflexion sur son déroulement afin d’en dresser le bilan formateur.

Le cycle de livraison peut durer d’une semaine à trois mois. Il se termine par la mise en place d’une version du produit fonctionnel pour l’utilisateur. Un cycle de livraison comporte une révision de la planification, une ou plusieurs itérations, une étape de livraison et une séance de réflexion.

La révision de la planification est utile à partir de la seconde livraison. L’équipe est en mesure de mieux évaluer le travail et peut réviser ce qui est prévu pour la livraison qui débute. Cette opération se fait conjointement avec le client, afin de tirer le maximum de valeur de la livraison. Il peut en résulter de remplacer l’équipe, changer la portée ou l’échéancier du projet ou trouver une solution plus créatrice pour arriver dans les délais avec l’équipe en place.

Suite aux itérations, arrive l’étape de livraison à l’utilisateur. C’est-à-dire, un produit fonctionnel et utile pour une véritable production. Étant donné les efforts de formation et de documentation que peuvent représenter une livraison, une durée de trois ou quatre mois est suggérée. Complémentairement, il est possible de déployer des versions intermédiaires à des petits groupes d’utilisateurs, afin d’obtenir le feedback nécessaire à la progression du projet.

À la fin de ce cycle, une séance de réflexion demande que l’on révise deux aspects du projet. D’une part, une réflexion sur le produit en cours de réalisation et d’autre part une réflexion sur les conventions mises en place qui composent la méthode.

Une itération peut durer d’une semaine à trois mois. Ce cycle prend en charge une portion des travaux d’une livraison. Elle comporte une étape de planification et un nombre variable de jours de travail. Elle se termine par une séance de réflexion et une célébration.

Pour une itération, la planification affecte les tâches aux membres de l’équipe. Les développeurs sélectionnent les tâches qu’ils estiment pouvoir réaliser au cours de l’itération. Lorsque chacun sait ce qu’il a à faire, le travail journalier débute.

À la fin de l’itération, les membres de l’équipe participent à une courte séance de réflexion et de célébration. L’objectif de cette activité est surtout de marquer un temps d’arrêt, afin de prévenir l’épuisement. Cette pause réconfortante évite d’épuiser les gens.

Chaque journée comprise dans une itération comporte une rencontre de l’équipe de développement et aucune ou plusieurs intégrations. Les rencontres journalières effectuent le contrôle et le suivi des réalisations. Consulter la section sur les techniques pour plus de détails.

Une intégration comporte plusieurs épisodes, se termine par une compilation et des tests. Dépendamment du projet, une intégration peut se produire à toutes les demi-heures ou aux quelques jours. Un environnement technique bien adapté, permet d’accélérer sa réalisation. Une série de tests sont réalisés à chaque intégration, afin de valider immédiatement le bon fonctionnement du produit avec les nouveaux ajouts.

Un épisode est la portion qui inclut le design, le codage et la vérification. Dans un contexte agile, il est bon de spécifier que le design et le codage sont des activités conjointes. Le développeur est libre de choisir le design qu’il juge adéquat, afin de réaliser sa tâche. Il doit aussi tester son code avec des tests unitaires automatisés de préférence.

L’annexe C (Observations sur Crystal Clear) présente une analyse, comporte quelques comparatifs et compléments d’information sur cette méthode. À la fin de cette annexe, une grille de métriques agiles permet de vérifier le niveau d’agilité d’une équipe.

Cockburn attache une attention particulière à la culture. Ayant travaillé dans divers pays, il conclut que toutes les équipes peuvent atteindre leurs objectifs. Le développement logiciel est un jeu de coopération et de communication.

Crystal fait ressortir les principes communs qui régissent les équipes gagnantes. Une méthode n’est qu’une série de conventions, qu’un groupe d’individu suivent. L’équipe est invitée à construire sa propre méthode sur la plate-forme que propose Crystal. La méthode qui en résulte recherche l’efficience, doit être viable pour les membres de l’équipe et amène le projet dans une zone sécuritaire améliorant ainsi ses chances de succès.

3.4 Autres méthodes agiles

Pour qu’une méthode soit considérée agile, elle doit satisfaire aux critères du manifeste [AA 2005a]. Dans ce cadre, une série de méthodes documentées peuvent être élaborée. Dans cette section, nous présentons les principales méthodes de l’alliance agile, qui se qualifient face au manifeste et qui se retrouvent régulièrement dans les ouvrages de synthèse [Highsmith 2002a; BI 2001; VTT 2002].L’objectif de ce mémoire n’est pas d’être exhaustif et de décrire chacune d’elle, cette section propose plutôt une brève description de celle-ci. L’annexe D (Autres approches complémentaires) survole aussi d’autres approches liées aux valeurs agiles.

Introduit par Robert N Charrette, Lean Development (LD) est la plus stratégique des approches agiles. Elle s’inspire du « Lean Manufacturing » de Deming [Deming 1982] qui révolutionna l’industrie automobile dans les années 1980, aussi connu sous le nom de « l’approche Toyota ». Elle propose de réaliser un produit équivalent à une approche traditionnelle CMM niveau 3, en un tiers du temps, pour un tiers des coûts et comportant un tiers des défauts [Highsmith 2002a].

« Lean development se définit comme une approche systématique qui élimine le gaspillage à travers l’amélioration continue et le perfectionnement du produit impliquant la participation du client. » [Traduit et tiré de Kilpatrick 2003]

Bien qu’à l’origine de cette approche, Charrette ait peu écrit sur LD [Norton 2005], c’est en 2003 que Tom et Mary Poppendieck présentèrent leur adaptation intitulée : Lean Software Development (LSD) [Poppendieck 2003a]. Ce livre comporte une série d’outils pour supporter cette approche.

«  Lean Software Development, réduit les défectuosités et les délais d e livraison qui se régularisent et qui augmentent la valeur d’affaire »[Tiré et traduit de Windholtz 2006].

Les domaines de gaspillage peuvent se transférer au logiciel. Ce qui nous donne le tableau suivant.

Tableau 3-8 : Domaines de gaspillage appliqués au logiciel

[Traduit et tiré de Kumar 2005]

Lean software n’est pas une méthodologie. C’est une manière de penser, basée sur sept principes [AA 2005c; Poppendieck 2003b] :

Bien que cette approche ne préconise aucune pratique précise. L’ensemble de ces principes rejoint les valeurs du manifeste agile, ce qui lui permet de se qualifier comme approche agile.

Dynamic System Development Method (DSDM) ou Méthode Dynamique de Développement de Système, s’inscrit comme une formalisation du RAD des années 1980. Elle a été développée en Grande Bretagne par un consortium de sociétés en 1994 [Fowler 2005]. Il s’agit en fait d’un canevas plutôt que d’une méthode. Son évolution a même porté un ajustement sur l’acronyme de DSDM par Dynamic Solution Delivery Model ou Modèle Dynamique de Livraison de Solutions [Highsmith 2002a]. Elle priorise de donner à l’entreprise ce qu’elle a besoin, quand elle en a besoin. Elle assume fondamentalement que rien n’est parfait du premier coup, mais que 80% des fonctions utiles peuvent se réaliser en 20% du temps [DSDM 2005].

Cette approche inverse la pyramide de planification. L’approche traditionnelle fixe l’ampleur du projet et amène une variation sur le temps et les ressources. Inversement, DSDM fixe le temps et les ressources en laissant l’ampleur variable. [VTT 2002].

Figure 3-15 : Pyramide inversée de DSDM

Figure 3-15 : Pyramide inversée de DSDM

[Tiré de DSDM 2005]

Neuf principes définissent le DSDM. Tous ces principes s’accordent avec le manifeste agile, c’est pourquoi elle se qualifie de méthode agile [DSDM 2005].

Le cycle de développement de DSDM propose cinq étapes, les deux premières sont séquentielles et les autres font partie des cycles itératifs. Le modèle proposé s’applique à tous les domaines qui touchent le projet. Cette méthode s’appuie beaucoup sur la construction de prototypes, à cause de ses origines. Par contre, cette notion doit être clarifiée, car les prototypes ne sont pas jetables. Le code qui les compose est complété dans la suite du développement [Highsmith 2002a].

Figure 3-16: Cycle de DSDM

Figure 3-16: Cycle de DSDM

[Tiré de Cohn 2004].

L’étude de faisabilité a pour objectif de proposer une solution au problème posé. Elle estime les coûts et la faisabilité technique, elle peut même présenter un prototype. Cette étape décrit brièvement la solution proposée et indique si l’utilisation de DSDM est favorable pour mener le projet à terme.

L’étude du fonctionnement d’affaire couvre l’aspect du processus d’affaire à automatiser et requiert la participation des utilisateurs. L’étude permet de prioriser les besoins et de dresser l’architecture de haut niveau du système.

Le modèle fonctionnel itératif a pour objectif de préciser le besoin sur l’aspect fonctionnel des traitements et données. Cette étape produit des modèles d’analyse et aussi des prototypes qui intègrent une grande partie des spécifications qui ne sont pas décrits textuellement. Comme plusieurs méthodes agiles, DSDM comporte peu de documentation, mais ses différents prototypes compensent cet aspect.

La conception et réalisation itérative sont conditionnelles à l’accord d’un prototype. Elles raffinent le prototype et réalisent le module conformément au standard. Il en résulte un produit utilisable et testé. Le cycle fonctionnel et celui de la conception sont généralement abordés, subséquemment par domaine d’affaire.

La mise en œuvre comporte la migration et l’implantation en production du système. Cette phase couvre la formation des utilisateurs et la rédaction de la documentation.

Un aspect intéressant de DSDM, est la classification des besoins. Comme le projet laisse l’ampleur variable, une classification des besoins est utile. Cette classification suit la règle de MoSCoW. Cette règle fait référence à l’acronyme anglais : Must, Should, Could, Won’t et qui peut se traduire par un ordre d’importance :

Le consortium améliore, promeut, forme et certifie les entreprises sur DSDM. Présentement à sa version 4.2, son utilisation se fait sous licence. Cette méthode est conforme avec ISO 9001. Il est sous-entendu que se faire certifier par DSDM, facilite la certification ISO.

Feature Driven Development (FDD), ou en français : Développement Dirigé par les Fonctionnalités, a été développé par Peter Coad, Jeff de Luca et Stephen Palmer. Cette méthode priorise la gestion des risques, en s’appuyant sur de courtes itérations pour donner des fonctionnalités tangibles à l’utilisateur. Celui-ci est rapidement informé de l’avancement, ce qui diminue les risques. Selon ses créateurs, celle-ci peut-être utilisée dans le développement de systèmes critiques [VTT 2002].

Elle ne prescrit pas de pratique de programmation précise, mais certains rôles sont définis [BI 2001]. FDD est plus un guide qu’un processus prescrit. Selon ses inventeurs, FDD est capable de s’adapter à de gros projets [Highsmith 2002a].

Cette méthode comporte 5 grandes étapes, dont les deux dernières se trouvent dans le cycle itératif [Fowler 2005].

Les étapes de départ sont révisées en cours de projet avec beaucoup moins d’ampleur. Le graphique suivant illustre les différentes étapes et le pourcentage approximatif d’effort requis au départ et par la suite dans le projet.

Figure 3-17: Cycle de développement de FDD

Figure 3-17: Cycle de développement de FDD

[Tiré de BI 2002].

La première étape est de concevoir le modèle général du système. Cette étape permet de délimiter le système et son contexte. Les cas d’utilisations de haut niveau sont aussi conçus à cette étape.

La seconde étape consiste à établir la liste complète des fonctionnalités. Avec la participation du client, cette étape met en évidence les fonctionnalités valables pour lui. Les caractéristiques définies sont complètement orthogonales avec le modèle objet. Il faut que le client conserve une compréhension du système [Highsmith 2002a]. Une notion intéressante de cette approche, est que les fonctionnalités sont décrites selon une syntaxe précise, qui standardise leurs énoncés.

Ces fonctionnalités sont ensuite regroupées pour former un ensemble plus général. En suivant cette approche, le client peut facilement développer sa compréhension du système.

La troisième étape planifie les fonctionnalités qui seront réalisées ensemble. Elle priorise et regroupe les fonctionnalités communes. Ces regroupements doivent être réalisables en moins de deux semaines d’efforts. On détermine réellement les dates buttoirs et les affectations aux développeurs. C’est à la fois une forme de délégation qui permet aux développeurs de planifier les travaux. Pour sa part, le responsable du projet peut se concentrer sur le projet global.

La quatrième étape conçoit chaque caractéristique. Cette étape prend en charge la conception d’un groupe de fonctionnalités. C’est à cette étape que les caractéristiques se transforment en classe. L’équipe peut participer à cette activité, afin d’harmoniser la conception.

La cinquième étape réalise chaque classe incluse dans une fonctionnalité. Elle se fait subséquemment à la conception. C’est à cette étape que le code est construit, inspecté, testé et intégré. Le propriétaire de la classe se charge de ses travaux.

FDD définit plusieurs rôles. En particulier au niveau des développeurs, il y a les chefs programmeurs et les propriétaires de classe. Les chefs programmeurs se voient confier le développement d’une fonctionnalité, ce qui peut demander l’implication de plusieurs classes. Il rassemble les propriétaires des classes impliquées pour former une équipe fonctionnelle. Ce sont eux qui implanteront les différentes classes pour les besoins de la fonctionnalité.

Mis à part l’objectif de réaliser une fonctionnalité en moins de deux semaines, il n’y a pas de notion de temps fixe (time-boxing), d’itération ou de version. L’équipe de développement est en perpétuel mouvement. Ce sont les groupes de fonctionnalités qui forment l’ampleur et la durée d’une livraison.

La gestion du changement se fait par l’ajout de nouvelles fonctionnalités. Dépendamment de l’ampleur (+10%) de ces ajouts et modifications, la planification du projet peut demander d’être révisée [Highsmith 2002a].

Cette méthode accorde beaucoup d’importance à la modélisation. Elle préfère démarrer plus lentement que d’autre méthode, afin de construire un meilleur modèle général. Elle s’oppose à l’approche de XP sur ce point. Cette méthode a fait ses preuves sur de gros projets. Il est intéressant de noter que TogetherSoft, entreprise de Peter Coad, a été acheté par Borland en 2002. Cet outil de modélisation UML, permet une intégration du design et de la génération de codes, favorisant ainsi l’agilité tout en conservant une documentation système à jour.

Cette méthode a été développée par Jim Highsmith, elle s’inspire de la théorie de la complexité et que tout est un apprentissage. Comme il n’y a pas de pratique formellement décrite, ASD est un gabarit. Cette méthode est une évolution des approches par prototypage (RAD) des années 1980, que son concepteur a largement utilisé [Highsmith 2001].

Avec une approche traditionnelle, il est mal vu de déroger de sa planification. On considère ce comportement comme une incompétence à planifier. Cette culture ne favorise pas l’intégration des nouvelles connaissances, qui changent les perceptions d’origine. Nous sommes aveuglés par la précision de la planification et oublions que les produits évoluent à partir de peu de planification et de beaucoup d’apprentissage. Même s’il est difficile de prévoir les choses, cela n’implique pas qu’il est difficile de progresser [Highsmith 2000].

ASD accepte que les gens ne soient pas infaillible et que le plan ne doit être vu que de manière spéculative. La théorie de la complexité aide à comprendre l’imprévisibilité des projets de développements, qui sont des processus empiriques. ASD cherche l’équilibre entre le chaos et l’ordre, qui a été défini par Dee Hock comme « Chaordic» [Highsmith 2002b].

ASD intègre une culture de changement basé sur trois thèmes : spéculer, collaborer et apprendre. Spéculer laisse le temps d’explorer et permet de dévier du plan sans inquiétude. Cette facette reconnaît la complexité des problèmes et encourage l’exploration et l’expérimentation. La collaboration est nécessaire pour l’évolution de solutions complexes, qui exigent beaucoup de connaissances diversifiées et qui ont besoin d’être mises en commun.

L’apprentissage résulte de l’expérimentation des connaissances. C’est aussi une forme d’humilité qui nous rappelle que nous ne sommes pas infaillibles. Les utilisateurs fournissent les retours d’expérience pour alimenter le cours du développement.

Il n’y pas de pratiques concrète, mais un cadre général qui comporte quelques valeurs qui constituent les fondements de ASD [BI 2001] :

Différentes étapes du cycle de développement se retrouvent dans les trois grands thèmes : Spéculer, collaborer et apprendre.

Figure 3-18 : Les grands thèmes et les étapes de ASD

Figure 3-18 : Les grands thèmes et les étapes de ASD

[Tiré de Highsmith 2000]

Initiation – Cette étape détermine l’objectif du projet, les intervenants et les limites du projet. Elle s’appuie sur un atelier de développement commun avec le client (« joint application development » nommé JAD) pour faire ce premier exercice. Cette étape n’est réalisée qu’au départ du projet.

Planification – Cette étape demande de découper le projet en blocs de temps (Time-box), afin de planifier les cycles de livraison. Elle prévoit les ressources nécessaires et les composants inclus dans chaque cycle. Un cycle peut durer de deux à quatre semaines. Chaque cycle possède une mission et doit présenter des fonctionnalités utiles au client.

L’ingénierie simultanée – Cette étape réalise concrètement le produit. Elle nécessite la collaboration des différents intervenants.

Collaboration – Cette étape encourage les intervenants à collaborer. ASD est ancré sur les relations qui sont à la base des organisations. L’équipe de développement est invitée à adopter des pratiques favorisant cette collaboration, tel que la programmation en pairs et le partage du code.

Revue de qualité – Cette étape est le moment pour tirer des leçons et de conserver l’attention sur la mission du cycle. Elle révise la qualité suivant plusieurs aspects. L’appréciation du client se fait comme une approche marketing avec un groupe pilote. La révision technique vérifie le design et le code. Les pratiques de l’équipe sont analysées : ce qui fonctionne bien et ce qui doit être corrigée. Finalement, on y fait le statut du projet pour juger de son avancement et réviser le plan.

Rencontre finale et livraison – Cette étape termine le projet et finalise le livrable. La revue finale de projet aidera à améliorer les prochains développements.

La culture d’optimisation, tel que le CMM, catégorise souvent les choses en noir ou blanc tandis que la culture adaptative reconnaît les zones grises. Cette culture reconnaît que le succès émerge des différents essais, qu’ils soient bons ou pas. Les projets de développement logiciel sont non-linéaires et imprévisibles. Passer à une culture adaptative, outille l’organisation pour le future, plutôt que de l’optimiser sur son passé [Highsmith 2000].


[6] La méthodologie, est une méta méthode, méthode des méthodes ou classe de méthodes, une sorte de boîte à outils, dont chaque outil est une méthode singulière appropriée à résoudre une énigme en particulier. [Wikipedia 2005] Méthode : http://fr.wikipedia.org/wiki/M%C3%A9thodologie

© Richard Tremblay, 2007

Précédent   Suivant
Chapitre 2 : Caractéristiques des méthodes agiles Sommaire Chapitre 4 : Implantation d’une approche agile