Temps de lecture estimé : 15 à 25 minutes
Vous avez surement entendu parlé des méthodes agiles ou de la méthode agile. D'ailleurs doit-on dire LA méthode agile ou LES méthodes agiles ?
Certains la perçoivent comme une énième méthodologie à la mode, difficilement compatible avec leur contexte. Surtout dans le cadre d'un contrat au forfait. Qu'est ce que l'approche agile au juste ? D'où vient-elle ? Comment s'applique-t-elle concrètement ? Voilà ce dont traite cette introduction aux méthodes agiles et à Scrum en particulier.
Approche Agile plutôt que méthode Agile
Si l'approche agile est nouvelle pour vous, il me semble important de partir sur de bonnes bases. Laissez moi vous dire au passage, que je suis honoré d'être votre guide vers ce nouvel horizon.
Le terme "méthode" est trop réducteur pour parler de cette façon d'aborder la gestion de projet. Il s'agit de bien plus qu'une méthode. On parle plutôt de paradigme agile, d'état d'esprit agile, de philosophie agile, de culture Agile ou encore d'approche agile, de mouvement agile, de courant agile, etc. En poursuivant votre lecture et en concentrant notamment votre attention sur le paragraphe "Le Manifeste Agile, un changement culturel", vous comprendrez mieux cette dimension cruciale.
On parle cependant de "méthodes agiles" pour définir les méthodes qui relèvent de ce courant.
Découvrir les méthodes agiles et leur implémentation projet avec la formation “Initiation aux Méthodes Agiles” éligible au CPF, France Travail et aux aides destinées aux petites entreprises.
Une autre approche de gestion de projet
Le terme "agile" définit une approche de gestion de projet qui prend le contre-pied des approches traditionnelles prédictives et séquentielles de type cycle en V ou waterfall (en cascade). La notion même de "gestion de projet" est remise en question au profit de "gestion de produit". De façon à raisonner davantage "produit" que "projet". Après tout, l'objectif d'un projet consiste bien à donner naissance à un produit.
Une approche dite "traditionnelle" attend généralement du client une expression détaillée et validée du besoin en entrée de réalisation, laissant peu de place au changement. La réalisation dure le temps qu'il faut et le rendez vous est repris avec le client pour la recette. Cet effet tunnel peut être très néfaste et conflictuel, on constate souvent un déphasage entre le besoin initial et l'application réalisée. On se rapporte alors aux spécifications validées et au contrat. Certains projets se terminent dans la douleur (surtout dans le cadre d'un contrat au forfait classique) au risque de compromettre la relation client. De plus, il n'est pas rare que certaines fonctionnalités demandées se révèlent finalement inutiles à l'usage alors que d'autres, découvertes en cours de route, auraient pu donner plus de valeur au produit.
Une enquête de 1994 du « Standish Group » (certes controversée, comme toutes les enquêtes qui traitent d'un sujet sensible) fait le constat suivant : « 31 % des projets informatiques sont arrêtés en cours de route, 52 % n'aboutissent qu'au prix d'un important dépassement des délais et du budget tout en offrant moins de fonctionnalités qu'il n'en était demandé ; seuls 16 % des projets peuvent être considérés comme des succès. ».
Cette même enquête renouvelée en 2008 indique un taux de réussite de 35%, ce qui est plutôt positif mais demeure très faible. Le problème reste entier. Parmi les motifs d'échecs, arrivent en tête :
- Manque d'implication des utilisateurs finaux : 12,8 %.
- Changements de spécifications en cours de projet : 11,8 %.
L'approche Agile propose au contraire de réduire considérablement voire complètement cet effet tunnel en donnant davantage de visibilité, en impliquant le client du début à la fin du projet et en adoptant un processus itératif et incrémental. Elle considère que le besoin ne peut être figé et propose au contraire de s'adapter aux changements de ce dernier. Mais pas sans un minimum de règles.
Anthony Bleton de Novius; dans la vidéo ci dessous intitulée Oubliez le cahier des charges, soyez agiles !; explique très bien en quoi l'approche agile se distingue de l'approche traditionnelle. Le tout en moins de 4 minutes, belle performance !
Fonctionnement des méthodes agiles
Les méthodes agiles partent du principe que spécifier et planifier dans les détails l'intégralité d'un produit avant de le développer (approche prédictive) est contre productif. Cela revient à planifier dans les détails un trajet "Paris - Narbonne" en voiture par les petites routes. Spécifiant chaque villes et villages traversés, l'heure de passage associée, chaque rue empruntée dans les agglomérations, litres d'essence consommés, kilomètres parcourus, etc. Les imprévus ne manqueront pas d'arriver : embouteillages, déviations, travaux, sens de circulation inversés, voire la panne, etc. Rendant votre planification et vos spécifications très vite obsolètes. Combien de temps aurez vous passé à planifier cet itinéraire, comment réagirez vous face à vos frustrations de ne pas pouvoir appliquer votre plan à la lettre ?
L'idée consiste à se fixer un premier objectif à courts termes (une grande ville par exemple) et se lancer sur la route sans tarder. Une fois ce premier objectif atteint, on marque une courte pause et on adapte son itinéraire en fonction de la situation du moment. Et ainsi de suite jusqu'à atteindre la destination finale. On parle donc d'une approche empirique. Dans le cadre d'un projet de développement logiciel, le client élabore sa vision du produit à réaliser et liste les fonctionnalités ou exigences de ce dernier. Il soumet cette liste à l'équipe de développement, communique directement avec elle (plutôt que par papier) qui estime le coût de chaque élément de la liste. On peut ainsi se faire une idée approximative du budget global.
L'équipe sélectionne ensuite une portion des exigences à réaliser dans une portion de temps courte appelée itération. Chaque itération inclut des travaux de conception, de spécification fonctionnelle et technique quand c'est nécessaire, de développement et de test. A la fin de chacune de ces itérations, le produit partiel mais utilisable est montré au client. Ce dernier peut alors se rendre compte par lui même très tôt du travail réalisé, de l'alignement sur le besoin. L'utilisateur final quant à lui peut se projeter dans l'usage du produit et émettre des feedbacks précieux pour les futures itérations. La visibilité ainsi offerte est clef. Cette transparence peut également apporter davantage de confiance et de collaboration dans la relation client/fournisseur. Les risques quant à eux sont levés très tôt.
Si le client a priorisé avec soin son besoin, il peut saisir l'opportunité d'accélérer le "time to market" si il estime que le produit en l'état (partiel) peut aller en production. Économisant ainsi son budget et récoltant un premier retour sur investissement. Il a aussi la possibilité de changer en cours de route la priorité des fonctionnalités qui n'ont pas encore été développées (prévues pour les itérations futures). Afin de retarder une fonctionnalité dont le besoin n'est pas mûr, ajouter une nouvelle fonctionnalité cruciale en échange du retrait d'une autre (respectant ainsi budget et délais), etc.
Cette souplesse ainsi offerte est donc un véritable atout pour le client.
Pour apprendre à mener à bien un projet agile, découvrez la formation Scrum Master et la formation Product Owner. Éligibles au CPF, France Travail et aux aides destinées aux petites entreprises.
Témoignage client
Thierry Roche, alors DSI de l’APEC
Quels ont été les avantages de ces méthodes pour votre projet ?
Déjà, on voit concrètement l’évolution du projet car après chaque itération, les utilisateurs peuvent visualiser un « bout » de projet qui fonctionne, ça brise l’effet tunnel des méthodes classiques. Cette évolution nous permet de prioriser nos réels besoins, l’application s’enrichit selon nos demandes. Le surplus n’existe pas, on ne développe pas des fonctionnalités qui ne nous serviront jamais comme c’est régulièrement le cas en adoptant des méthodes classiques. On atteint un bénéfice utilisateur plus rapidement mais aussi un gain financier non négligeable. Nous n’imaginons même pas un retour avec des méthodes classiques.
Source : Le Monde Informatique | Dossier méthodes agiles : Le renouveau des relations client/fournisseurs.
Historique des méthodes agiles
Sans rentrer dans les détails, la première chose à savoir est que l'approche Agile n'est pas un effet de mode né de la dernière pluie. En effet la première approche de gestion de projet de développement itératif date de 1986. La première mise en œuvre de la méthode Scrum (la méthode Agile la plus utilisée, documentée et éprouvée aujourd'hui) date de 1993.
La seconde concerne un événement majeur rassemblant, en 2001, dix sept figures éminentes du développement logiciel pour débattre du thème unificateur de leurs méthodes respectives. De cet événement est né le Manifeste Agile rassemblant à la lueur des expériences de chacun les critères pour définir une nouvelle façon de développer des logiciels. Le terme "Agile" pour qualifier ce type de méthode est également né à cette occasion.
Aujourd'hui ces méthodes ont fait leurs preuves. Tout le monde (dans le monde de l'informatique) ou presque a au moins entendu parler d'une méthode Agile (Scrum, eXtreme Programming, RAD, Chrystal Clear,...). L'outillage associé est maintenant disponible sur le marché y compris dans le secteur Open Source. Les formations, certifications, conférences, livres, blogs se sont multipliés. Nous pouvons également noter la prise de position en faveur de l'approche Agile de la part des organismes faisant "autorité" en matière de gestion de projet informatique :
- Le SEI à l'origine de CMMI en 2008. Voir le rapport "CMMI or Agile: Why Not Embrace Both!".
- Le PMI quant à lui créé en 2011 ses propres certifications Agile.
- En 2012, le Gartner invite à abandonner le Cycle en V.
Le Manifeste Agile, un changement culturel
Le manifeste Agile contient l'essence et la philosophie de l'approche en question. Il illustre à lui seul le changement culturel profond qui est en jeu.
Manifeste Agile
Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser :
Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.
Attention aux idées reçues
Agile = Anarchique > FAUX
La dernière phrase a son importance car si on néglige sa lecture, on peut tomber dans les idées reçues très répandues du style : "Sur un projet agile, il n'y a pas de spécifications, de plan, de processus, d'outil et même pas de contrat".
C'est réservé aux projets de développement de logiciels > FAUX
Même si ce manifeste illustre son secteur d'origine, le développement de logiciels, ces valeurs et principes demeurent transposables dans les autres. On peut simplement reformuler la seconde valeur ainsi :
"Des produits opérationnels plus qu’une documentation exhaustive", le mot "produit" pouvant qualifier un produit physique ou virtuel, un service ou même quelque chose de plus abstrait.
Principes sous-jacents au Manifeste Agile
Nous suivons ces principes :
- 1Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
- 2Accueillir positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.
- 3Livrer fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
- 4Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
- 5Réaliser les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
- 6La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
- 7Un logiciel opérationnel est la principale mesure d’avancement.
- 8Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
- 9Une attention continue à l'excellence technique et à une bonne conception renforce l’agilité.
- 10La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
- 11Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.
- 12À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.
Le cadre méthodologique Scrum
Je vous propose maintenant de zoomer sur l'une des méthodes Agile existantes afin de vous montrer plus concrètement le fonctionnement. Pourquoi traiter de Scrum en particulier ? Tout simplement parce que Scrum est de très loin la méthodologie la plus utilisée parmi les méthodes agiles existantes. Elle est donc la plus éprouvée, documentée et supportée. Livres, blogs, formations, vidéos, associations, conférences traitant de Scrum ne manquent pas et bon nombre de ces ressources sont accessibles gratuitement. On pourrait pratiquement parler d'un standard Agile. Un autre atout important : Scrum est simple à comprendre. Sa maîtrise est en revanche difficile.
Le "package" Scrum
Scrum est considéré comme un cadre ou « framework » de gestion de projet. Ce cadre est constitué d'une définition des rôles, de réunions et d'artefacts.
Scrum définit 3 rôles :
- Le « Product Owner » qui porte la vision du produit à réaliser (représentant généralement le client). Devenir Product Owner certifié.
- Le « Scrum Master » garant de l'application de la méthodologie Scrum. Devenir Scrum Master certifié.
- L'équipe de développement qui réalise le produit. Devenir Membre d'Équipe Agile.
La vie d'un projet Scrum est rythmée par un ensemble de réunions clairement définies et strictement limitées dans le temps (timeboxing):
- Planification du Sprint (Sprint = itération) : au cours de cette réunion, l'équipe de développement sélectionne les éléments prioritaires du « Product Backlog » (liste ordonnancée des exigences fonctionnelles et non fonctionnelles du projet) qu'elle pense pouvoir réaliser au cours du sprint (en accord avec le « Product Owner »).
- Revue de Sprint : au cours de cette réunion qui a lieu à la fin du sprint, l'équipe de développement présente les fonctionnalités terminées au cours du sprint et recueille les feedbacks du Product Owner et des utilisateurs finaux. C'est également le moment d'anticiper le périmètre des prochains sprints et d'ajuster au besoin la planification de release (nombre de sprints restants).
- Rétrospective de Sprint : la rétrospective qui a généralement lieu après la revue de sprint est l'occasion de s'améliorer (productivité, qualité, efficacité, conditions de travail, etc) à la lueur du "vécu" sur le sprint écoulé (principe d'amélioration continue).
- Mêlée quotidienne : il s'agit d'une réunion de synchronisation de l'équipe de développement qui se fait debout (elle est aussi appelée "stand up meeting") en 15 minutes maximum au cours de laquelle chacun répond principalement à 3 questions : « Qu'est ce que j'ai terminé depuis la dernière mêlée ? Qu'est ce que j'aurai terminé d'ici la prochaine mêlée ? Quels obstacles me retardent ? »
processus scrum
L'organisation générale
Travaux préparatoires
L'approche Scrum propose de commencer par lister les exigences du client afin de produire le « Product Backlog ». Voir l'exemple ci dessous pour la réalisation d'un site d'e-commerce :
Elément du backlog | Estimation |
|---|---|
Un internaute peut rechercher un article selon différents critères | 5 |
Un gestionnaire du catalogue de produits peut ajouter des articles | 2 |
L'internaute peut acheter en ligne un ou plusieurs articles | 3 |
... | ... |
L'unité de coût (ou complexité) de la colonne "Estimation" est arbitraire, on procède généralement par relativité en définissant un étalon de base. Par exemple, "voir le détail d'un article" étant une exigence simple, elle servira d'étalon et son estimation convenue sera par exemple de "1 point", "modifier les caractéristiques d'un article" étant 2 fois plus compliquée, son estimation sera de "2 points", etc. Le recours à une telle unité (plutôt que des jh ou €) permet de faciliter l'ordonnancement du Product Backlog, la planification des sprints et des releases. D'autre part il souligne le fait qu'il ne s'agit que d'une estimation (par définition fausse) et non pas un chiffrage en tant que tel.
Le Product Owner ordonnance ensuite la liste en fonction de la valeur ajoutée métier, du coût estimé de chaque exigence et des risques identifiés. Les exigences seront réalisées dans l'ordre ainsi défini selon les contraintes de l'équipe de développement et les éventuelles dépendances (exigence D à faire avant l'exigence X). On fixe ensuite la durée des sprints durant laquelle un certain nombre d'éléments du « Product Backlog» seront réalisés. L'objectif de Scrum consiste à produire le plus tôt possible la plus grande valeur possible, afin de créer des opportunités d'accélération du "Time to market".
Enchaînement des sprints
Une fois que le Product Backlog est prêt et que la durée du sprint est fixée en accord avec le client, il n'y a plus qu'à remplir le sprint avec des éléments du Product Backlog (planification de sprint). C'est également à ce moment que le Product Owner exprime plus précisément son besoin (qu'il aura affiné au préalable) pour permettre à l'équipe de développement d'estimer plus précisément la charge de travail du sprint. Inutile pour autant de réaliser la conception détaillée en séance, des ateliers dédiés pourront avoir lieu en cours de sprint. Le Product Owner peut à tout moment revoir la priorité des exigences qui n'ont pas encore été planifiées dans le sprint en cours. En revanche, les exigences engagées dans le sprint en cours sont "sanctuarisées", seule l'équipe de développement à le pouvoir de modifier le périmètre du sprint en cas d'avance ou de retard.
Chaque sprint se termine par la revue de sprint suivie de la rétrospective. Le sprint suivant s’enchaîne à la suite selon le même cycle et ainsi de suite jusqu'au dernier sprint de la release.
Formations Scrum & Méthodes Agiles
Développez vos compétences professionnelles avec L'Agiliste et obtenez une certification officielle.
Formations Agiles à distance, certifiantes et financées.
Mesure de l'avancement
Grâce aux estimations individuelles des exigences du « Product Backlog » ainsi qu'à la segmentation en sprints, on peut aisément produire un graphique de suivi d'avancement représentant l'évolution du travail accompli en fonction du temps (voir illustration ci contre : total de "points" d'estimation des exigences terminées en bleu et charge totale de "points" de la release en rouge).
La contractualisation agile
La contractualisation d'un projet agile n'est pas la partie la plus facile étant donné que le périmètre est par définition variable. La régie ferait bien l'affaire mais difficile de rassurer le client avec un tel contrat. En France et ailleurs, le contrat au forfait domine; surtout sur les gros projets. Malheureusement pour le fournisseur - dans le cadre d'un forfait classique - tous les risques sont pour lui (aussi bien sur un projet agile que sur un projet traditionnel). On peut limiter ces risques en prenant quelques précautions, mais on limite également la souplesse offerte par une approche Agile.
Cela ne veut pas dire qu'il n'existe pas de solutions. La forfaitisation de chaque itération avec la possibilité pour le client d'arrêter le contrat à la fin de chaque itération est assez intéressante. Ainsi que le principe de troc d'exigence : réalisation d'une exigence imprévue en échange du retrait d'une autre moins importante, de priorité faible et de même coût.
Voici quelques liens qui traitent du sujet :
Et quand tout le monde travaille à distance ?
Vous vous demandez si un tel modèle d'organisation peut fonctionner pour une équipe dispersée (dont les équipiers sont souvent en télétravail par exemple) ? La réponse est oui tout en améliorant la performance, la cohésion et l'engagement de l'équipe. Voici le lien vers l'article "Télétravail et Méthodes Agiles : Comment Scrum Facilite le Travail à Distance".
Vous souhaitez aller plus loin ?
Vous pouvez poursuivre votre apprentissage en consultant la page des ressources clés. Vous y trouverez par exemple, le guide de démarrage Scrum ainsi que des vidéos d'introduction.
Bonjour,
Il manque un point important qui n’a pas été abordé et sous zappé. Que va ton faire dans 5 ans quand on souhaitera changer de logiciel ou effectuer une migration et qu’il n’y aura plus les développeurs et pas de documentation ou pas maintenue à cause des itérations ?
Je ne crois pas que voir à court terme soit forcément une bonne chose et la méthode agile ne est que du court terme.
Bonjour Yannick,
Merci pour ton message.
Qu’est ce qui te fait penser qu’il n’y a pas de documentation ni de vision à long terme sur un projet agile ?
Amicalement
Florent
Bonjour Florent,
Je rejoins Yannick dans son commentaire. Et j’ajoute que ce qui me le fait penser c’est qu’en générale, une itération dure environ 2 ou 3 semaines et que ce laps de temps est généralement trop court pour l’équipe pour exécuter correctement l’ensemble des livrables tels que la documentation fonctionnelle, technique, batterie de tests etc… J’ai pu voir beaucoup de projet en mode agile, et tous avait ces problématiques ce qui n’empêchait pas le projet d’avancer correctement. Un développeur cherche à développer, et non pas faire de la documentation. Sans les contraintes des autres méthodologies (waterfall) ces livrables sont souvent omis car considéré comme non nécessaire à la livraison. Si dire que ces dites documentations font nécessairement parties de la méthodologie ou de la philosophie Agile, je ne vois malheureusement aucune différence avec une méthodologie classique si ce n’est la multiplcation de petite release. On passe de 4 mois à 3 semaines mais on garde les mêmes livrables.
Bonjour Georges,
Merci pour ta contribution à ce débat 🙂
Je partage avec toi le constat que de nombreux projets agiles tombent dans le piège classique « Je suis en agile donc je me simplifie la vie et ne fait que ce qui m’intéresse. Je ne fais pas de doc, je ne planifie pas à l’avance et on terminera quand on terminera… ». Evidemment, tu l’as compris, ce n’est pas du tout ma vision de l’agilité. Certaines équipes agiles intègrent dans leur « définition de terminé » d’un élément du sprint les critères suivants : tests passants, documentation fonctionnelle et technique mise à jour, code revu par un pair, etc. Sans parler du recours à l’intégration continue pour régulièrement vérifier la non régression sur la base de tests automatisés.
Concernant ta dernière remarque. Je répondrai qu’en agile, l’activité de documentation est lissée dans le temps et limitée au strict nécessaire et suffisant pour assurer efficacement l’évolution et maintenance future du produit.
Là où en approche classique, on a tendance à tout faire reposer sur la documentation avant de développer la moindre fonctionnalité susceptible d’apporter de la valeur. Résultat, après avoir passé des journées de boulot sur le cahier des charges, on passe encore plus de temps à spécifier dans le détail l’intégralité des fonctionnalités attendues (la liste au père noël). Puis on développe enfin les fonctionnalités dans la phase dédiée. Et arrivé en recette, on se rend compte que pour bon nombre de fonctionnalités, ça ne correspond pas vraiment au besoin (cf. effet tunnel et interprétation des spécifications écrites). Certaines fonctionnalités seront peu ou pas utilisées. On a une doc pléthorique que plus personne ne veut maintenir. Sans parler du code à maintenir des fonctionnalités finalement pas ou peu utilisée avec probablement des bugs à corriger. Voilà le principal gaspillage que cherche à éviter l’agilité.
A+
Florent
« Des logiciels opérationnels plus qu’une documentation exhaustive ».
Si la question de la documentation reste aussi problématique que dans le cadre d’un produit réalisé avec une approche traditionnelle, votre billet (à moins que ce ne soit la méthode) n’insiste probablement pas assez sur l’intérêt de sa production pour maintenir le produit sur la durée.
La qualité du MCO et sont coût sont en effet fortement dépendants d’une documentation de qualité car elle accroît la maintenabilité tout en réduisant coûts et délais des évolutions et corrections.
Les heures de « rétro ingéniering » nécessaires sont, sans elle, une héritage très lourd du projet, je vous l’accorde, quelle que fût l’approche utiliseée pendant le projet.
Dans ce cas, quelle est, selon vous, la méthode pour verrouiller cet aspect lors de la contractualisation, et en cours de projet (sprint et revue, mise en production) ?
Existe-t-il des typologies d’applications pour lesquelles l’approche n’est pas pertinente ? En fonction de la complexité, de la durée d’amortissement, …).
Merci pour votre article très instructif.
Bien cordialement,
Sylvain
Bonjour Sylvain,
Et bonne année 2015 au passage 😉
Conscient de cette interprétation possible – et malheureusement trop fréquente – du manifeste agile, je précise juste après ce dernier : « La dernière phrase a son importance car si on néglige sa lecture, on peut tomber dans les idées reçues très répandues du style : « Sur un projet Agile, il n’y a pas de spécifications, de plan, de processus, d’outil et même pas de contrat ». ». Je vais mettre cette phrase en rouge et en gras du coup :=).
Oui la documentation a de l’importance dans la plupart des contextes. En particulier pour la maintenance à long terme d’un produit logiciel. L’agilité ne dit absolument pas le contraire. Elle nous invite simplement à éviter de rendre la documentation « contractuelle » et obèse comme j’ai pu le vivre sur des projets menés en approche « classique », ou pire encore : à communiquer via des spécifications (c’est la meilleure façon de ne pas se comprendre). Dans ce type d’approche « classique », le fait qu’on doivent concevoir l’intégralité du produit à l’avance favorise cette situation, surtout si on ajoute à ça un bon vieux contrat au forfait qui verrouille tout et rend tout le monde perdant. J’ajoute au passage qu’une fiche pratique est consacrée aux spécifications agiles.
Comment verrouiller l’aspect documentaire lors de la contractualisation ? Par exemple, en stipulant un livrable documentaire dans le contrat, comme on le fait avec un contrat « classique ». Par contre, vous l’aurez compris, il ne sera pas livré à l’issue d’une grande phase de conception car une telle phase n’existe pas dans le cadre d’une approche agile. En revanche, on peut demander à ce que ce livrable soit communiqué de façon incrémentale. A la fin de chaque itération ou release par exemple ? On peut ainsi voir très tôt – avant que l’intégralité du produit soit documenté – si cette documentation convient ou non. Comme pour le produit en soi.
Y’a t’il des contextes dans lesquels l’agilité n’est pas pertinente ? Je dirai surtout dans les organisations dont la culture est trop en conflit avec les valeurs et principes de l’agilité. L’agilité est tout et n’offre ses bénéfices qu’en mettant ce tout en musique.
J’espère avoir répondu à vos interrogations Sylvain. Merci d’avoir posé ces questions directement sur le site car vous ne devez pas être le seul à vous les poser.
Amicalement,
Florent
Bonjour Florent,
On parle de méthode agile et de projets web, ce qui parait logique..
Mais cette méthode est elle transposable à d’autres SI, environnement ? Quid des progiciels ?
Ps: je débute une formation de scrum master semaine prochaine !!
Hugo
Bonjour Hugo,
Je suis navré d’avoir tant tardé à te répondre. Ta formation est sans doute déjà terminée. On peut considérer l’agilité comme une approche plus qu’une méthode à part entière. Scrum par exemple, est un cadre méthodologique adaptable à des tas de contextes projet différents du moment qu’on travaille en équipe. Y compris des contextes qui n’ont rien à voir avec l’informatique. Même s’il est vrai que les méthodes agiles sont historiquement issues du monde du développement logiciel. Je n’ai pas d’expérience personnelle en projet d’ERP mais je serai vraiment extrêmement étonné qu’une approche agile ne soit pas applicable dans ce type de projet.
J’espère avoir répondu à ta question
Amicalement,
Florent
Bonsoir Florent,
D’abord merci pour tous ces détails sur « l’approche Agile ». C’est très nouveau pour moi et je découvre cela à mon travail depuis quelques jours. Je suis en formation cette semaine sur la méthode SCRUM. Néanmoins, j’ai quelques interrogations quant à son efficacité dans notre domaine par rapport à une approche traditionnelle, qui n’est certes pas la plus efficace.
Notre métier est de développer des logiciels de simulation numérique (divers domaines d’applications). Les développeurs sont amenés à travailler sur plusieurs « projets » (=produits logiciels) à la fois. Et les testeurs, eux testent les développements mais font également d’autres activités. Dans ce contexte, pensez-vous que la méthode SCRUM est la plus pertinente pour réussir à délivrer des produits en temps et en heure et aussi en adéquation avec le besoin client ?
L’idée de découper un projet en « sprint » est bonne. Mais beaucoup d’imprévus surviennent lors d’un projet, un sprint de 2 à 4 semaines me parait bien court !
En espérant avoir quelques éclaircissements 🙂
Salutations.
Laura
Bonjour Laura,
Je comprends tes questionnements. Dans le contexte que tu décris, il peut être intéressant de commencer par expérimenter la méthode Kanban plutôt que Scrum. Surtout si les imprévus sont nombreux.
Cependant, et selon la quantité de développeurs et de projets concernés par le contexte actuel, on peut se poser les questions suivantes : Est ce vraiment efficace de faire travailler une même équipe de développement sur plusieurs projets en même temps ? Est ce normal d’avoir tant d’imprévus ? Pour les demandes d’évolution ou études par exemple, ne peuvent elles pas être centralisées, canalisées, priorisées par un seul acteur et planifiées toutes les 2 semaines par exemple ? etc.
Amicalement,
Florent
Bonjour, je débute par mes propres moyens en « agilité », votre site est la première documentation que je lis. Dans de récents entretiens d’embauche, on m’a parlé de développement Scrum, quand je lis votre documentation, je vois, ici, plus une façon de gérer le projet, d’où ma question ; la méthode Scrum est-ce simplement une façon d’approcher la gestion d’un projet, donc quelque chose qui se situe principalement entre le client et le chef de projet, ou est-ce que cela comporte un certain nombre d’outils fournis aux « simples codeurs » visant à les faire coder autrement, et si oui quels sont ses outils ? Parce que là en tant que simple développeur, je ne vois pas en quoi ça change de ce que je faisais quand j’étais en poste, c’est à dire développer des fonctionnalités (visiblement appelées sprint), les tester et les livrer et attendre le retour du demandeur pour soit valider soit demander des améliorations.
Bonjour,
En effet, Scrum en soi ne comporte aucune pratique ni outil de développement. Généralement, on complète Scrum par les pratiques de développement issues de la méthode eXtreme Programming telles que la programmation en binôme, le développement piloté par les test (TDD), la description des besoins/fonctionnalités en User Stories, etc. On va aussi ajouter un outillage tel que l’intégration continue.
Cependant être développeur agile ne consiste pas simplement à coder. Il doit non seulement savoir coder mais savoir jouer son rôle au sein d’une méthodologie « projet » telle que Scrum. Au sein de Scrum, l’équipe de développement joue un rôle essentiel. Surtout en l’absence de « chef de projet » classique qui dit quoi faire, quand le faire et comment le faire. Elle a du pouvoir de décision, elle estime les fonctionnalités à réaliser, participe à la planification, améliore régulièrement le processus de développement, interagit directement avec le « client » appelé Product Owner, etc. Bref, le développeur n’est pas considéré comme un simple exécutant mais comme un acteur à part entière, essentiel à la conduite du projet.
J’espère avoir répondu à tes interrogations.
Amicalement,
Florent
PS : Le sprint est une itération ou boite de temps de 2 à 4 semaines au sein de laquelle l’équipe de développement va concevoir, développer et tester un ensemble de fonctionnalités du produit à réaliser.
Merci pour ces précisions
[…] approfondir la méthode agile version en ligne pour le lycée, version en ligne pour les pros […]
[…] approfondir la méthode agile version en ligne pour le lycée, version en ligne pour les pros […]