AGILE

12 principes

1 – La priorité est d’obtenir la satisfaction client au plus tôt par la livraison rapide et régulière de fonctionnalités attendues.

2 – Accepter les demandes de changement en cours de projet . Ce sont des opportunités pour donner plus de valeur au projet et coller aux vrais besoins des clients.

3 – Mettre en œuvre des livraisons rapides reposant sur des cycles courts (quelques semaines). Ces livrables doivent être opérationnels pour permettre des tests de validation des fonctionnalités attendues.

4 – Coopération forte et continue entre les utilisateurs et le développement. A l’inverse des méthodes classiques où les rencontres entre les utilisateurs et la maîtrise d’oeuvre interviennent surtout en début et en fin de projet.

5 – Donner de l’autonomie à des personnes impliquées et leur faire confiance.

6 – Privilégier le face à face comme canal de communication entre les parties. Les interactions sont plus efficaces et plus riches. Tout va plus vite.

7 – L’important est d’avoir une application opérationnelle.

8 – Avancer avec un rythme constant compatible avec ce que peuvent produire l’ensemble des acteurs.

9 – Focus sur la qualité technique et la qualité de conception pour construire une base solide renforçant l’agilité.

10 – Rester simple dans les méthodes de travail : ne faire que ce qui est nécessaire.

11 – Une équipe qui s’organise elle-même produit de meilleurs résultats.

12 – En revoyant régulièrement ses pratiques, l’équipe adapte son comportement et ses outils pour être plus efficace.

La méthode Scrum

Initiée par Hirotaka Takeuchi and Ikujiro Nonaka puis formalisée par Ken Schwaber et Jeff Sutherland, cette méthode propose un cadre très structuré pour appliquer les principes de l’agilité.

Le Sprint :

Il s’agit des sous-parties d’un projet comme le définit le principe Agile. Chaque Sprint a pour objectif de livrer au client une version potentiellement utilisable du produit.

Les Sprints successifs ajoutent des fonctionnalités au produit ou améliorent celles déjà développées. On parle d’incrément de produit.

Un Sprint démarre lorsque le précédent est terminé. Il s’agit d’un processus incrémental.

Ce cadre repose sur 3 piliers que sont :

– la transparence : élaboration d’un standard commun pour permettre une compréhension partagée.

– l’inspection : des vérifications sont effectuées régulièrement.

– l’adaptation : en cas de dérive constatée lors de l’inspection, des ajustements sont décidés.

Les Sprints se structurent autour de plusieurs outils organisationnels :

• Sprint planning ( Planification du sprint) : réunion pour sélectionner et planifier les priorités de chaque Sprint en terme de liste des fonctionnalités produit (Sprint Backlog).
• Scrum  (Mêlée quotidienne ) : réunion journalière de coordination entre les membres de l’équipe projet. Elle prend fréquemment la forme de « Stand-up meeting » (réunion de courte durée, 10-15mn, tenue debout).
• Sprint Review  (Revue de Sprint ) : réunion de synthèse à la fin de chaque Sprint afin de valider les fonctionnalités développées.
• Sprint Retrospective  (Rétrospective de Sprint) : venant immédiatement après la revue de Sprint, il s’agit d’un bilan dont l’objectif est l’amélioration continue des pratiques. L’équipe échange sur les réussites, les difficultés, relève ce qui a fonctionné ou non. Avec toujours des leçons à tirer pour les prochains Sprints.

Les « artéfacts »

• Product Backlog : liste des fonctionnalités du produit.
• Sprint Backlog : planification   des éléments du Product Backlog à mettre en oeuvre lors du Sprint pour livrer l’incrément de produit doté des fonctionnalités requises pour cette étape. Le Sprint Backlog n’est pas figé, mais est amené à évoluer durant le Sprint.
•  L’incrément de produit : déjà évoqué plus haut.

Avec des rôles définis pour chacun :

• Product Owner – PO  (propriétaire du produit) :  l’expert métier, le maître d’ouvrage , représente le client et intervient sur le coté fonctionnel.
• Scrum Master  (maître de mêlée) :  le coordinateur du projet et le garant du respect de la méthode Scrum.
• Team (équipe) :  les autres intervenants sur le projet (notamment les développeurs).

Les avantages

Cette approche permet d’obtenir :

• Plus de flexibilité en travaillant sur des sous-parties autonomes. Elles peuvent être conçues, testée, modifiées de nouveau sans que l’ensemble du projet ne soit impacté.
• Plus de fiabilité et de qualité : en simplifiant, en testant en continu, en favorisant les feedbacks, les échanges avec les clients.
• Des risques réduits : détection rapide des problèmes grâce à des cycles courts.
• Une meilleure maîtrise des coûts : pas de coûteux retours en arrière (si nécessaire) & le projet peut être stoppé rapidement.

Les limites

La flexibilité poussée à l’extrême peut conduire à un enlisement du projet .

De nombreuses itérations sans que des directions ou décisions ne soient figées représentent un réel danger.

L’une des causes fréquentes de l’enlisement de projets est liée aux des revirements incessants des clients quant à leurs spécifications.

Il convient donc parfois d’arbitrer pour le bien du projet, mais également celui du client.