Développer en Agile
Introduction
Itératif, incrémental et adaptatif
L'évolution des cycles en matière de développement informatique a débuté avec une vision incrémentale dite « cascade » ou « cycle en V » de la succession des livrables à produire et à valider, puis s'est complexifiée en acceptant les recouvrements de phases de l'ingénierie concourante.
Critères Itératif - Incrémental - Adaptatif
=== Paramètres d'ajustement de planification ===
Une méthode agile est avant tout itérative sur la base d’un affinement du besoin mis en œuvre dans des fonctionnalités en cours de réalisation et même déjà réalisées. Cet affinement, indispensable à la mise en œuvre du concept adaptatif, se réalise en matière de génie logiciel sous deux aspects :
* fonctionnellement, par adaptation systématique du produit aux changements du besoin détecté par l’utilisateur lors de la conception-réalisation du produit (notion de validation permanente de l’utilisateur avec RAD et notion de conception émergente avec XP) ;
* techniquement, par remaniement régulier du code déjà produit (refactoring).
Une méthode agile est ensuite, éventuellement, incrémentale. Lorsque le projet, quel que soit le nombre de participants, dépasse en durée une dizaine de journées en moyenne, la production de ses fonctionnalités s’effectue en plusieurs incréments.
La notion d'adaptatif, quant à elle, nécessite au-delà d'un simple principe, la mise en œuvre de techniques de contrôle de l'évolution du livrable et d'une métrique formelle des modifications, avant, après et en cours de la production. Il en découle une planification opérationnelle élémentaire, directement visible par le biais de l'affichage mural (figure : Affichage mural élémentaire).
Valeurs
Les méthodes agiles prônent 4 valeurs fondamentales (entre parenthèses, les citations du manifeste)4 :
L'équipe (« Les individus et leurs interactions, plus que les processus et les outils ») : dans l'optique agile, l'équipe est bien plus importante que les outils (structurants ou de contrôle) ou les procédures de fonctionnement. Il est préférable d'avoir une équipe soudée et qui communique, composée de développeurs (éventuellement à niveaux variables), plutôt qu'une équipe composée d'experts fonctionnant chacun de manière isolée. La communication est une notion fondamentale.
L'application (« Des logiciels opérationnels, plus qu'une documentation exhaustive ») : il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est une aide précieuse mais non un but en soi. Une documentation précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l'équipe (on en revient à l'importance de la communication).
La collaboration (« La collaboration avec les clients, plus que la négociation contractuelle ») : le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir un feed-back continu sur l'adaptation du logiciel à ses attentes.
L'acceptation du changement (« L'adaptation au changement, plus que le suivi d'un plan ») : la planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet. Les premières livraisons du logiciel vont souvent provoquer des demandes d'évolution.
Principes
Ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes agiles :
- La plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à forte valeur ajoutée.
- Le changement est accepté, même tardivement dans le développement, car les processus agiles exploitent le changement comme avantage compétitif pour le client.
- La livraison s’applique à une application fonctionnelle, toutes les deux semaines à deux mois, avec une préférence pour la période la plus courte.
- Le métier et les développeurs doivent collaborer régulièrement et de préférence quotidiennement au projet.
- Le projet doit impliquer des personnes motivées. Donnez-leur l'environnement et le soutien dont elles ont besoin et faites leur confiance quant au respect des objectifs.
- La méthode la plus efficace de transmettre l'information est une conversation en face à face.
- L’unité de mesure de la progression du projet est un logiciel fonctionnel (ce qui exclut de comptabiliser les fonctions non formellement achevées).
- Les processus agiles promeuvent un rythme de développement soutenable (afin d’éviter la non qualité découlant de la fatigue).
- Les processus agiles recommandent une attention continue à l'excellence technique et à la qualité de la conception.
- La simplicité et l'art de minimiser les tâches parasites, sont appliqués comme principes essentiels.
- Les équipes s'auto-organisent afin de faire émerger les meilleures architectures, spécifications et conceptions.
- À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son processus de travail en conséquence.
Une méthode qualifiée d'agile doit donc se composer d'un ensemble de pratiques instrumentant le cadre décrit par les 12 principes généraux agiles et en conséquence s'inscrire dans le respect des 4 valeurs fondamentales ayant inspiré le Manifeste agile.
Mode Opératoire
Toutes les méthodes agiles utilisent un mode opératoire similaire, voire identique :- Un responsable fonctionnel définit et ordonne la production des composants de l'application.
- Le projet est structuré en incréments de 1 à 6 semaines suivant les nécessités (taille, réactivité, visibilité...).
- Une réunion initiale organise chaque incrément en définissant les tâches à réaliser.
- L’équipe pilote la qualité et la performance du projet de manière consensuelle.
- Chaque jour, une courte réunion d'avancement donne à l'équipe une vision globale du projet, met en évidence les éventuels problèmes et permet de factoriser les solutions.
- Un reporting mural (Kanban, graphes de progression, etc.) est mis à jour en temps réel par les membres de l'équipe.
- Un incrément achevé contient une livraison complète, développée, approuvée et testée.
- Une réunion finale présente l'application et est suivie d'une rétrospective technique du processus de développement.
- Le responsable fonctionnel valide le travail de l'équipe et ajuste les besoins entre chaque incrément.
Pratiques communes à l'ensemble des méthodes agiles
- Les pratiques communes liées aux ressources humaines
- Participation de l’utilisateur final aux groupes de travail.
- Groupes de travail disposant du pouvoir de décision.
- Autonomie et organisation centralisée de l’équipe (motivation).
- Spécification et validation permanente des Exigences.
- Les pratiques communes liées au pilotage du projet
- Niveau méthodologique variable en fonction des enjeux du projet.
- Pilotage par les enjeux et les risques.
- Planification stratégique globale basée sur des itérations rapides.
- Réalisation en jalons par prototypage actif itératif et incrémental.
- Recherche continue d’amélioration des pratiques.
- Les pratiques communes liées à la qualité de la production
- Recherche d’excellence technique de la conception.
- Vision graphique d’une modélisation nécessaire et suffisante.
- Vision de la documentation nécessaire et suffisante.
- Normes et techniques raisonnables de qualité du code (métrique).
- Architecture à base de composants.
- Gestion des changements automatisée.
Critères d'éligibilité
De multiples facteurs contextuels peuvent être pris en considération pour valider ou invalider la possibilité d'application d'une méthode agile. Les principaux critères d'éligibilité pourraient être les suivants :
Favorisant :- - Besoin rapide de mise à disposition du produit
- - Imprévisibilité des besoins du client
- - Nécessité de changements fréquents
- - Besoin de visibilité du client sur l'avancement des développements
- - Présence de l'utilisateur assurant un feedback immédiat
Défavorisant :
- - Indisponibilité du client ou de l'utilisateur
- - Dispersion géographique des ressources humaines
- - Inertie des acteurs du projet ou refus des changements
- - Gouvernance complexe de la DSI
Dans les cas où les critères d'éligibilité de l'utilisation d'une approche agile n'ont pas été respectés, un risque de dérive lié à un formalisme léger peut apparaître.
Roles
Product Owner
The responsibilities of the Product Owner role are:
- ‣Working on a shared vision
- ‣Gathering requirements
- ‣Managing and prioritising the Product Backlog
- ‣Accepting the software at the end of each iteration
- ‣Managing the release plan
- ‣The profitability of the project (ROI)
Metaphor: The Product Owner is a CEO.
Scrum Master
The ScrumMaster helps the product group learn and apply Scrum to achieve business value.
The responsibilities of the ScrumMaster role are:
- ‣Empowering and shepherding the team
- ‣Removing impediments
- ‣Keeping the process moving
- ‣Socialising Scrum to the greater organisation
Metaphor: The ScrumMaster is a facilitator, coach, mentor and bulldozer!
Team
The responsibilities of the Team or Team Member role are:
- ‣Estimating size of backlog items
- ‣Committing to increments of deliverable software
- ‣—and delivering it
- ‣Tracking own progress
- ‣Is self-organising—but accountable to the Product Owner for delivering as
- promised
Do Better Scrum · 7Team members can be developers, testers, analysts, architects, writers,
designers and even users. The team is cross-functional, which means that between all its members they possess sufficient skills to do the work. There is no dictated leadership hierarchy within the team members.
The Scrum Team comprises all three roles: one Product Owner, one ScrumMaster and five to nine Team Members.
Artefacts
Product Backlog
Une liste priorisée de tout ce qui peut être nécessaire dans le produit
Sprint Backlog
Une liste de tâches nécessaire pour transformer le Backlog de produit dans un incrément de produit potentiellement finale
Burndown chart
Mesure le Backlog de produits restant dans le temps
Mesure le Sprint Backlog restant durant le Sprint
Impediment Backlog
Ceremonies
Sprint Planning 1/2
Daily Scrum
Sprint Review
Sprint Retro
Estimation
Ressources
* [[http://referentiel.institut-agile.fr/|Référentiel Agile (Institut Agile)]]
{{tag>SCRUM Agile RAD Agilité XP_Programming}}
Commentaires
Enregistrer un commentaire