L’histoire d’Agile remonte à la publication de “Le Manifeste pour le Développement Agile de Logiciels” comprenant 12 fondamentaux en 2001. Sans aucun doute, certains agencements de l’approche Agile étaient apparus avant cela, mais seulement ce document les a systématisés et exposés à un degré suffisant pour être utilisés. Au fil des ans, de nouvelles entreprises, des spécialistes de l’informatique et des chefs de projet adhèrent au Manifeste. De nouvelles méthodes et versions du système de développement agile émergent.
Qu’est-ce que la méthodologie Agile ?
Agile est un modèle de développement interactif dans lequel le logiciel est créé progressivement dès le début d’un projet, contrairement aux modèles en cascade où le code est livré à la fin du cycle de travail.
La méthodologie flexible repose sur la décomposition des projets en petites unités opérationnelles appelées histoires utilisateurs. Selon les priorités, les tâches sont résolues dans de courts cycles de deux semaines (itérations).
Les 12 principes qui constituent la méthodologie Agile peuvent être résumés en 4 idées principales :
- Priorité aux personnes et à la communication plutôt qu’aux outils et aux processus ;
- Priorité à un produit fonctionnel plutôt qu’à une documentation abondante ;
- Priorité à la collaboration avec les clients plutôt qu’à la confirmation contractuelle ;
- Priorité à la disposition au changement plutôt qu’à la conformité au plan initial.
Méthodes inhérentes à Agile :
Scrum
Le terme Scrum a été emprunté au rugby, où ce mot désigne la méthode de jeu d’équipe sous la forme de trois lignes formées par chaque adversaire tentant de saisir le ballon. Pour réussir à reprendre, non seulement une bonne condition physique est essentielle — chaque joueur de scrum doit agir en concert avec les autres, avec une compréhension claire de l’objectif.
Cette méthode est utilisée avec succès par des entreprises telles que Microsoft, Yahoo, Siemens Healthcare. Un chef de projet d’Amazon a même décrit un cas d’introduction de Scrum basé sur l’expérience acquise.
Puisque Scrum est un cadre pour le développement, chaque exemple qui suit peut différer du précédent.
Jeff Sutherland, l’auteur du livre “Scrum. L’art de faire deux fois plus de travail en moitié moins de temps”, a distingué 8 étapes pour utiliser la méthodologie :
- Sélectionner le propriétaire du produit qui est conscient de l’objectif du projet et du résultat attendu.
- Organiser une équipe — jusqu’à 10 personnes avec les compétences nécessaires pour créer un produit opérationnel.
- Désigner le Scrum master qui supervisera le workflow du projet et assistera l’équipe projet à relever les défis.
- Établir le dossier produit — pour chaque exigence produit, définir des priorités sur le tableau Agile. Dans ce processus, le rôle du propriétaire du produit est essentiel, car il recueille les demandes pour que l’équipe du dossier puisse les évaluer.
- Planifier des sprints (itérations) — fragments de temps pour compléter des chaînes spécifiques de tâches.
- Organiser des réunions quotidiennes de quinze minutes — poser à chaque membre de l’équipe 3 questions : ce qu’il a fait hier, ce qu’il va faire aujourd’hui, ce qui empêche l’accomplissement de la tâche.
- Faire des revues des parties opérationnelles du produit — en impliquant les parties prenantes dans ces revues.
- Tenir des rétrospectives — discussion des problèmes avec recherché de solutions après chaque sprint. Mettre en œuvre le plan de modification résultant dans le sprint suivant.
Rétrospective dans Agile
Scrum possède 4 éléments clés :
- Dossier Produit — liste des exigences du projet
- Dossier Sprint — liste des exigences devant être remplies dans le sprint à venir
- Objectif de Sprint — but du sprint
- Graphique de Burndown de Sprint — le diagramme qui est mis à jour à mesure que les tâches avancent étant complétées. Cela facilite la compréhension de la dynamique et du niveau d’avancement de l’équipe dans le projet.
Programmation Extrême (XP)
Kent Beck, le développeur de cette méthodologie, a créé une méthode de programmation extrême ciblée sur l’adressage des exigences de produits logiciels volatils et l’amélioration de la qualité du développement.
Elle n’est applicable que dans le domaine du développement logiciel, et elle repose sur 4 processus :
- codage — selon les normes communes de mise en page de l’équipe ;
- tests — les tests sont essentiellement créés par les programmeurs avant d’écrire un code qui sera testé ;
- planification — tant pour la construction finale que pour les itérations séparées. Ces dernières ont lieu en moyenne tous les deux semaines.
- audition — tant des développeurs que d’un client, afin d’éliminer les points flous et de définir les exigences et les valeurs.
Méthodologies Crystal
Cette famille de méthodologies développée par Alistair Cockburn, l’un des auteurs du “Manifeste pour le Développement Agile de Logiciels”, est peu connue dans certains domaines locaux de gestion de projet. Cockburn propose de faire une classification par couleurs, basée sur le critère du nombre de personnes dans une équipe : de 2 (Crystal Clear) à 100 (Crystal Red). Les couleurs Maroon, Bleu et Violet sont attribuées à des projets plus vastes.
Les projets Crystal doivent se conformer à 3 caractéristiques de base :
- livraison rapide du code opérationnel — une idée éprouvée pour le modèle itératif dans le développement Agile.
- amélioration par réflexion — une nouvelle version logicielle est améliorée sur la base des informations sur la version précédente.
- interaction “osmétique” — innovation d’Alistair, une métaphore pour la communication et l’échange d’informations entre les développeurs de logiciels dans une même pièce.
Cette famille de méthodologies est décrite en détail dans le livre “Crystal Clear: A Human-Powered Methodology for Small Teams” par Alistair.
Méthode de Développement Logiciel Dynamique (DSDM)
Non pas une seule personne, mais même pas une équipe, mais un consortium de 17 entreprises britanniques a travaillé sur le développement de DSDM. Comme la programmation extrême, DSDM est principalement utilisé pour créer des logiciels.
Le consommateur final (utilisateur) joue un rôle spécial dans le processus de développement. Ce principe fondamental est complété par les suivants :
- lancements fréquents des versions opérationnelles du produit
- autonomie des développeurs dans la prise de décisions
- tests tout au long du cycle de travail.
DSDM est subdivisé en versions qui sont mises à jour à mesure que les technologies se développent et que de nouvelles exigences de développement logiciel apparaissent. Actuellement, la dernière version est DSDM Atern, sortie en 2007, bien que la précédente (de 2003) soit encore en service.
Au début, l’équipe considère la faisabilité du développement d’une application et son champ d’utilisation. Ensuite, le travail est divisé en trois cycles interconnectés :
- cycle de modèle fonctionnel — création de documents analytiques et de prototypes.
- cycle de conception et d’ingénierie — mise en opération d’un système.
- cycle de mise en œuvre — déploiement du système.
Développement dirigé par les fonctionnalités (FDD)
Cette méthodologie est apparue même avant “Le Manifeste pour le Développement Agile de Logiciels”.
Bien que FDD utilise également le modèle d’itération de développement, il diffère d’Agile par les caractéristiques suivantes :
- plus d’attention au modèle préliminaire
- importance accrue (par rapport à Agile) dans la création de rapports et de graphiques
- la méthodologie est conçue pour le développement en entreprise.
Le développement dirigé par les fonctionnalités se compose des phases cycliques suivantes :
- Créer un modèle général — vision du projet basée sur des données préliminaires.
- Développer une liste de propriétés — similaire à un dossier produit dans la méthodologie Scrum.
- Planifier par propriétés — la complexité des propriétés est évaluée par chaque membre de l’équipe.
- Pour chaque propriété — conception technique et mise en œuvre – la phase finale à l’issue de laquelle la propriété fusionne dans le produit, et le cycle se répète.
Développement Logiciel Lean
Le développement logiciel Lean est un ensemble de principes de gestion lean (plutôt qu’une méthodologie) qui visent à accroître l’efficacité du processus de développement et à minimiser les coûts.
Ce ensemble comprend les 7 fondamentaux suivants :
- élimination des pertes — tout ce qui n’ajoute pas de valeur au produit pour le consommateur final.
- formation continue — le développement en cours d’une équipe renforce les possibilités d’accomplissement efficace des tâches.
- prendre des décisions le plus tard possible — la priorité est donnée à des solutions réfléchies, bien développées et basées sur des connaissances acquises, plutôt qu’à des solutions spontanées.
- livraison rapide — c’est essentiellement le principe fondamental du modèle itératif.
- renforcement de l’équipe — un des fondamentaux du “Manifeste…” affirme que les personnes et leurs interactions sont plus importantes que les processus et les outils. Une équipe projet est la meilleure garantie de réalisation réussie des tâches.
- intégrité et qualité — il est nécessaire de produire un produit qualitatif dès le départ pour né pas perdre du temps et des ressources dans des tests ultérieurs et l’élimination de bugs.
- vision d’un tableau d’ensemble — un projet né peut pas être décomposé en parties séparées sans comprendre l’état actuel du développement, ainsi que les objectifs, le concept et les stratégies relatives au logiciel développé.
Versions des méthodologies de développement Agile
Modélisation Agile (AM)
La modélisation Agile est un ensemble de valeurs, de fondamentaux et de pratiques pour la modélisation des logiciels.
AM est utilisé comme un élément dans des méthodologies de développement logiciel à part entière — par exemple, dans la programmation extrême ou le développement d’applications rapides.
La modélisation Agile a les caractéristiques fondamentales suivantes :
- interaction efficace entre les parties prenantes du projet ;
- inclination à développer une solution finalement simple parmi toutes celles possibles, qui répondra à toutes les exigences ;
- réception continue de retours d’expérience ;
- courage de prendre des décisions et d’en assumer la responsabilité ;
- réaliser que vous savez absolument tout.
Processus Unifié Agile (AUP)
L’AUP est une version simplifiée d’une autre méthodologie de développement logiciel — le Processus Unifié Rational (RUP). Depuis 2012, il a été remplacé par la Livraison Agile Disciplinaire (DAD), mais l’AUP est encore présent ici et là.
Scott Ambler, l’auteur de la méthodologie, a souligné les points clés suivants dans le Processus Unifié Agile :
- Votre équipe sait ce qu’elle fait ;
- La simplicité prime.
- Conformité aux fondamentaux de la méthodologie de développement flexible.
- Concentration sur les activités précieuses pour le projet.
- Indépendance dans le choix des outils.
- Configuration personnalisée de l’AUP pour les exigences d’un projet spécifique.
Méthode des Données Agile (ADM)
ADM est un ensemble de méthodologies de développement logiciel itératives qui mettent l’accent sur la formation des exigences et des solutions dans un projet grâce à la collaboration de différentes équipes. Comme l’AUP, cette méthodologie n’est pas autonome non plus.
Le principe de la Méthode des Données Agile est défini par six fondamentaux :
- Données — la base pour la création de toute application.
- Problèmes dans un projet — ils né peuvent être détectés que si l’objectif et le concept du projet sont clairement compris.
- Groupes de travail — en plus de l’équipe de développeurs de base, il existe des groupes d’entreprise qui soutiennent d’autres groupes de travail.
- Originalité — il n’existe pas de méthodologie parfaite, chaque projet nécessite donc des outils issus de différentes méthodologies pour être combinés.
- Travail d’équipe — le travail commun est beaucoup plus efficace que l’activité individuelle.
- “Point idéal” — recherché d’une solution optimale à un problème (“point idéal”) en évitant les extrêmes.
Processus Unifié Essential (EssUP)
Il a été développé par Ivar Jacobson, un scientifique suédois, pour améliorer le Processus Unifié Rational.
EssUP utilise le concept de pratique qui inclut :
- scénario d’utilisation — description du comportement du système.
- dév éloppement par itérations — création de pièces opérationnelles du code lors de cycles courts de quelques semaines.
- pratiques d’équipe — visant à rassembler l’équipe et à accroître son efficacité.
- pratiques procédurales — par exemple, “Pensez globalement, commencez petit” ou “Impliquer les parties prenantes dans les processus d’affaires”.
Sous une forme ou une autre, toutes les pratiques sont présentes dans le RUP et les méthodologies CMMI, ainsi que dans la méthodologie de développement flexible.
Réalisme (GR)
C’est une méthodologie efficace pour les startups et les équipes débutantes, qui suggère le maximum d’utilisation des caractéristiques spécifiques propres aux petits projets et aux entreprises, telles que la mobilité, la flexibilité, la recherché de nouvelles solutions, l’absence d’une hiérarchie stricte et confuse, etc.
Jason Fried et David Hansson, fondateurs de l’entreprise 37signals (aujourd’hui Basecamp), ont défini Getting Real comme un système de résolution de tâches réalisables, qui est finalement simple, compréhensible et fonctionnel.
GR est un mélange d’une douzaine d’outils de développement agile qui sont utilisés pour minimiser ce qui suit :
- alternatives
- options et réglages
- structure de l’entreprise
- réunions
- promesses.
Un concept aussi extraordinaire n’est pas devenu mainstream, bien que certains de ses éléments aient fusionné dans d’autres méthodologies.
OpenUP (OUP)
C’est une méthodologie de développement logiciel indépendante des outils et exempte de structure stricte, qui fournit des pratiques telles que :
- mesurer la vitesse de fonctionnement de l’équipe ;
- tenue de réunions quotidiennes et de rétrospectives à l’issue des itérations ;
- concept de micro-étapes et de tests précoces en utilisant des listes de contrôle ;
- méthodologie de Développement Modélisé Agile (AMDD).
Ces pratiques sont réalisées selon quatre principes :
- réconciliation des intérêts et atteinte de la vision commune dans le travail commun ;
- amélioration continue par un retour d’information en cours ;
- concentration sur l’architecture de l’application à un stade précoce pour minimiser les risques ;
- maximisation de la valeur pour le consommateur final.
Indicateurs Agile
Étant donné la diversité des outils Agile, pratiques, méthodes et méthodologies, nous devons choisir un instrument qui nous aidera à déterminer l’efficacité de chacun d’eux.
Les métriques sont utilisées comme tel instrument.
Pour la plupart des projets, ces 4 catégories de métriques seront suffisantes :
- Productivité — elle s’associe aux métriques de Vélocité et de WIP. La première né convenant pas à tous les projets, puisque le nombre de tâches accomplies par itération est mesuré, mais les itérations né sont pas égales. La métrique de Travail en Cours définit la limite des tâches à différentes phases : plus elle est élevée, plus cela pose problème ;
- Prévision — la métrique de Capacité, qui consiste à déterminer le nombre d’heures parfaites disponibles dans le sprint suivant. Ainsi, il est possible de comprendre la quantité de temps disponible pour le travail, le degré d’efficacité dans l’accomplissement des tâches, ainsi que de planifier le nombre de tâches pour un sprint ;
- Qualité — par exemple, l’indice de stabilité des exigences qui est calculé selon la formule = (Nombre total d’exigences d’affaires initiales + Nombre d’exigences modifiées par le temps donné + Nombre d’exigences ajoutées + Nombre d’exigences supprimées) / (nombre total d’exigences initiales). Cette métrique est utilisée pour déterminer le temps passé à retravailler les tâches ;
- Valeurs — cette métrique est calculée individuellement dans chaque cas, selon le format du projet. Par exemple, dans la startup AirBnb, le nombre de photos de haute qualité téléchargées a été choisi comme métrique déterminant la valeur finale du produit pour les utilisateurs. À mesure que ce nombre augmente, le nombre d’utilisateurs croît proportionnellement.
Les règles applicables aux métriques sont les mêmes que celles pour les autres outils Agile.
Il n’existe pas de métrique unique qui serait à la fois correcte et pertinente pour votre projet.
Les métriques doivent être révisées de manière continue, celles obsolètes doivent être supprimées et de nouvelles ajoutées si nécessaire. Elles doivent être complètes et accessibles à toute l’équipe sans devenir un objectif en soi. Les métriques pour le simple plaisir des métriques sont une mauvaise solution.
Briseurs de mythes : Agile
La popularité de la méthodologie de développement flexible a joué un tour bas à celle-ci, et des mythes sur certains aspects d’Agile peuvent être observés même sur des portails spécialisés. Débattons les uns après les autres !
Mythe n°1 : Agile conviendra à tous les projets.
C’est la misconception la plus affirmée. Une seule méthode Agile né vaudra rien par elle-même, ni n’encouragera l’équipe.
Mythe n°2 : Agile défavorise la documentation.
La méthodologie de développement agile né défavorise pas la documentation, elle rejette la documentation comme un but en soi. En matière de sélection de la documentation comme moyen de communication, Agile privilégie réellement la communication personnelle.
Mythe n°3 : Agile et planification sont incompatibles.
Ce mythe est contesté par les événements quotidiens de planification avec des réunions debout de 10 minutes, ainsi que par la planification d’itération ayant lieu toutes les deux semaines, les réunions de sprint, etc.
Mythe n°4 : Agile nécessite beaucoup de retravail.
La méthodologie de développement logiciel agile prévoit le retravail sous deux formes : retravailler les exigences (les utilisateurs comprennent ce dont ils ont vraiment besoin) et retravailler le logiciel (les équipes de développeurs trouvent de meilleures façons de rédiger et de concevoir des applications). Mais cela se rencontre également dans d’autres méthodologies ! De plus, une nouveauté Agile telle que le modèle itératif sert à réduire l’influence négative du retravail.
Avantages et inconvénients d’Agile en usage
Avantages :
- impliquer les parties prenantes — l’équipe devient plus capable de comprendre les exigences du client. De plus, la livraison précoce et fréquente de logiciels renforce la confiance des parties prenantes envers l’équipe projet et rend l’engagement dans le projet plus profond.
- livraison précoce et prévisible — le modèle de développement basé sur l’itération (dans des périodes courtes de 1 à 6 semaines) offre de la flexibilité et incite à la sortie du produit.
- concentration sur la valeur commerciale — la collaboration avec le client garantit que l’équipe comprend comment rendre le produit véritablement précieux pour le consommateur.
- amélioration continue de la qualité — les tests pendant chaque itération avec une division de la construction finale en pièces séparées du code opérationnel facilitent l’amélioration et l’élimination des erreurs logicielles avant la sortie du produit final.
Inconvénients :
- exigences strictes pour l’équipe et les clients — sans interaction étroite entre l’équipe projet et les utilisateurs, il est impossible de garantir la livraison d’un produit de haute qualité avec une haute valeur. De plus, les nombreux outils et méthodes Agile prédisent que l’équipe doit être expérimentée pour leur introduction appropriée.
- non adapté à l’externalisation et aux projets où les participants n’interagissent qu’en mode en ligne.
- le risqué que la version logicielle finale né soit jamais livrée — surprenant, cet inconvénient découle d’avantages Agile tels que le développement itératif et l’amélioration continue du produit.
- il échoue sans une vision claire des objectifs commerciaux du projet — puisque l’équipe Agile est guidée par les parties prenantes, il est impossible de développer un produit sans un objectif et un concept clairement définis.
Applications
Tous les services ou programmes de gestion de projet né conviennent pas à la gestion de projet basée sur Agile, car chacun d’eux a ses caractéristiques spécifiques.
Si votre entreprise est une agence de marketing & publicité, de design, de SEO ou numérique, vous pouvez utiliser le service SaaS de Worksection pour que toute l’équipe puisse y travailler. À ce jour, nous sommes recommandés par COXO Digital, Royal ® Advertising et Prozorro.
Voici quelques astuces pour configurer Agile dans Worksection :
- configurer les étiquettes et les statuts nécessaires au travail dans votre entreprise. Les statuts peuvent être : en cours, vérification, terminé, retravail nécessaire, critique, fonctionnalités, paiement dû. Les étiquettes se lisent souvent comme ceci : mise en page, test, production, concept, code.
- créer le dossier de projet et le printemps de projet.
- créer des tâches et des listes de contrôle préliminaires, des croquis, etc. dans le dossier.
- lors des réunions, déterminer les tâches de sprint et les transférer du dossier au sprint.
- utiliser l’accès invité des clients aux tâches afin d’avoir toujours des retours coordonnés et pertinents sur le projet.
- étiqueter les personnes responsables dans les tâches pour que chaque collègue sache son domaine de responsabilité et se sente impliqué dans le résultat du sprint.
Verdict
Grâce à la méthodologie de développement logiciel Agile, les petites équipes projet gagnent en efficacité maximale. Agile se réalise à travers d’autres méthodes flexibles telles que Scrum, XP, Lean, etc.
Il né peut pas être déployé à la hâte, par une équipe inexpérimentée, dans un court laps de temps,
mais, une fois introduit, Agile améliorera l’interaction entre l’informatique et les entreprises, il incitera à la mise sur le marché des produits et il ajoutera de la valeur au produit pour le consommateur final.