Loin de vouloir faire du manichéisme, voici une petite réflexion informelle et personnelle de ce qui me semble être de l’ordre du pattern et de l’anti-pattern dans la démarche de projet logiciel agile en général et avec Scrum en particulier.
On peut considérer deux types d’entreprise et de processus agiles :
– l’entreprise semi-agile : la demande et le produit ne sont pas gérés de manière agiles, ce n’est seulement qu’à la frontière avec la technique que l’agilité démarre.
– l’entreprise agile : tout les processus de création de valeur par l’entreprise sont agiles, de la réflexion à la réalisation
A ces deux types d’entreprises correspondent deux types d’exigence en terme de pratiques et processus.
L’ignorance des pattern agiles importants, ou l’emploi trop appuyé d’anti-pattern agiles, doit plutôt être vu comme une incitation à :
– envisager la nécessité d’un travail autour de l’application de la méthodologie (travail dans le sens de…)
– à contrario envisager l’emploi d’une autre méthodologie agile (XP, concepts lean etc) si la résistance au changement est trop importante
Dans tout les cas, ne pas oublier que :
– les méthodes agiles ne font qu’agréger des pratiques ‘du bon sens’ issues de l’expérience
– c’est bien la méthode qui est au service de l’homme et pas l’inverse ; donc de facto, constituez votre trousse à outil agile et votre ensemble de règles basées sur les méthodes agiles
| Priorité selon le manifeste agile | Patterns (processus ou procédés consolidateurs) | Anti-pattern typique (processus ou procédés contrariants) |
Pattern nécessaire à l’entreprise agile |
Pattern nécessaire à l’entreprise semi-agile |
| … aux personnes et aux interactions (plutôt qu’à des processus ou des outils) | Echanges oraux mais consolidés par une trace écrite | Echanges uniquement par email |
X |
|
| réunions quotidiennes (daily) | TTM imposée, milestones rigides |
X |
X (daily scrum pour la partie agile) |
|
| cycle court avec estimation | réunion d’avancement – point d’étapes réguliers |
X |
X (calage réunions vis vis des sprint) |
|
| planning poker – demo – retrospective | kick-off + tunnnel + relase finale |
X |
X |
|
| Tableau public – scrum board | Feuille excel gérée par un CDP |
X |
X (les artefacts non agiles sont consolidés vis à vis du product backlog et du sprint backlog) |
|
| … à la collaboration avec le client (plutôt qu’à la négociation contractuelle) | Epic User story (résumé) | Roadmap |
X |
|
| Découpage des travaux en tâches (User Story) | Spécifications fonctionnelles, use-case |
X |
X |
|
| Cycle agile : itératif, incrémental et adaptatif | Lotissements fonctionnels fermés, spécifications fonctionnelles, use-case |
X |
||
| Retrospective, feedback | Recette finale, pv de livraison, audit |
X |
X (réunions agiles pour la partie agile) |
|
| Transition vers l’agilité, pioche de pratiques agiles au cas par cas (dans XP, SCRUM and co) | Process figé |
X |
||
| … à la production de fonction (pas à la documentation par exemple) | Acceptance test, demo, iteration | Recette fonctionnelle |
X |
X (pour la partie agile) |
| Délivrable potentiel à l’issu d’une itération timeboxée (sprint scrum par exemple) | Définition/Négociation de Milestone |
X |
X |
|
| Engagement sur les tâches sur un délai court (timebox) | Engagement sur les dates et pas les tâches |
X |
X (si impossible envisager waterfall avec XP et pas SCRUM) |
|
| … à l’adaptabilité et aux changements (plutôt qu’à la poursuite des plans originaux) | pair review, demo (product – dev) | retours au spec |
X |
X (démo occasionnelle) |
| backlog | liste des specifications priorisées |
X |
X |
|
| integration continue | recette d’integration |
X |
X (avec recette d’intégration si nécessaire) |
|
| x+1e sprint (intervalle de confiance) | vsr (vérif. service régulier) |
X |
X |
|
| epic (user story allant être détaillée) | lot fonctionnel/technique |
X |
||
| test (acceptance, sanity) durant l’itération, tests unitaires | recette d’intégration, sanity check à chaque milestone |
X |
Biblio :
http://www.entreprise-agile.com/HistoAgile.pdf
http://www.mountaingoatsoftware.com/system/presentation/file/123/Cohn-Agile-and-Deadly-Sins-of-Project-Management.pdf
http://www.agileopencalifornia.com/wiki/index.php?title=Semi_Agile_Projects
http://productmanagementjournal.blogspot.com/2009/08/agile-thinking.html
http://www.agilemodeling.com/essays/enterpriseModelingAntiPatterns.htm
Transition vers l’agilité – Livre blanc – 2e édition 2011 – Valtech
Agile, cloud and data blog ! 