(5 votes, moyenne: 3,80 sur 5)
Loading...C’est un sujet complexe, pour lequel je n’ai pas de recette magique (y’a qu’à faut qu’on…).
En revanche, pour tenter de produire de la valeur et en mesurer la concrétude, les règles que je vais vous partager sont incontournables. Ne pas les respecter entraîne systématiquement des retards, des frustrations, des dérapages budgétaires qui obèrent assurément la valeur perçue des résultats produits. C’est en tous les cas mon expérience.
1. Fixez les règles ! (Et appliquez-les)
En premier lieu, définissez très concrètement vos attentes en termes de résultat et mettez en place les indicateurs de suivi de ces objectifs.
Les incontournables (tout ou une partie sont omis trop souvent lorsqu’on confond vitesse et précipitation) :
- Automatiser les tests de non-régression des X scénarios critiques de l’application
- Fixer le volume et surtout la qualité attendue des tests unitaires UTILES (la présence d’un test unitaire qui en fait ne fait RIEN ne suffit pas) ;
- Fixer le volume et la récence acceptable d’incidents non traités ;
- Le planning des sprints et des « respirations » (NON on n’enchaîne pas des sprints de 2 ou 3 semaines sans regarder le calendrier des congés scolaires, sans laisser du temps pour l’analyse, etc.) ;
- Les Definition of Ready et Definition of Done ne sont pas du folklore agile ;
- Ne pas laisser la relation avec l’éditeur (progiciel, outil, etc.) entre les seules mains de l’intégrateur. Si vous avez fait un tel choix, la connaissance de la philosophie de ce logiciel est primordiale. Investissez-vous, impliquez l’éditeur à VOS côtés, pas à travers l’intégrateur.
2. Mettez en place une matrice de compétences
Pour des prestations majoritairement intellectuelles la valeur des équipes est clé et il faut, en particulier, mettre en place une matrice de compétences avec vos partenaires.
Comment la constituer ? Pas de recette unique, en revanche elle doit :
- Mixer expérience et compétences tant sur le sujet métier adressé que sur les technologies embarquées ;
- Valoriser le temps passé sur le projet pour les ressources (normalement le TJM devrait augmenter et non baisser avec le temps…) ;
- Valoriser les périodes de montées en compétences (i.e la charge doit être supportée par le partenaire, pas par le Client) ;
- Fixer des limites acceptables pour considérer qu’une équipe est opérationnelle pour le projet (20 % de « débutants » est un seuil à ne pas franchir, à ne pas accepter. NON, 2 ressources à 500 € ne valent pas une ressource à 1 000 €, elles coûtent la même somme, c’est tout).
Encore récemment, la mise en œuvre d’une matrice de compétences objective sur des équipes présentes depuis plus de 2 ans sur un projet en difficulté a mis en exergue que pour 38 développeurs que comptait ce projet 21 cochaient la case « DEBUTANT ». Comment vouliez-vous que ce projet produise de la valeur pour le Client ? Fort de ce constat, nous avons pu engager un plan de redressement avec le prestataire qui a porté ses fruits en moins de 6 mois.
Ne démarrez pas le projet si :
- Les règles ne sont pas fixées et acceptées par l’ENSEMBLE des parties prenantes (métier compris) ;
- Les équipes de tests ne sont pas constituées (NON les testeurs embarqués dans les équipes agiles ne suffisent pas !) ;
- Les équipes de développement ne sont pas suffisamment formées à votre métier et/ou à la technologie (outil du marché en particulier) et NON les certifications sans expérience de mise en œuvre ne suffisent pas (cf. matrice de compétences).
Il parait évident que les tests font partie intégrante d’un projet agile, pour autant les équipes de test métier sont bien souvent sollicitées, pour des raisons évidentes de charge opérationnelle, à la fin des cycles de développement (Program Increment ou sprint) faisant automatiquement sortir le projet de son « agilité ». Idem pour les tests « de bout en bout ». L’intégration continue prônée par les frameworks agiles est bien souvent un leurre et n’intègre pas de tests dignes des enjeux.L’organisation n’ayant alors plus d’agile que le nom.
SAFe, par exemple, n’est pas une « mode », c’est un modèle complet d’organisation qui ne s’applique ni à tous les projets ni à toutes les organisations (maturité).
« Faire SAFe » peut devenir dramatique pour des projets ou des organisations non éligibles.
3. Ayez le courage de faire évoluer l’organisation et le rythme des équipes au fur et à mesure de l’avancement du projet
En effet la part build/run va mécaniquement se modifier :
- Le run (incidents de production, anomalies, petites évolutions) va prendre de plus en plus de place et obérer la capacité à embarquer de nouvelles fonctionnalités ;
- La gestion du backlog et des priorités se complexifie ;
- Durant l’été une approche Kanban est souvent plus efficiente ;
- L’usure du temps sur les équipes est une réalité, faire évoluer l’organisation et les rythmes permet de « remettre l’église au milieu du village ».
La maîtrise du temps est primordiale :
- NON, on n’enchaîne pas les sprints sans « pause » ;
- NON toutes les semaines (donc tous les sprints) ne se valent pas (congés, jours fériés, etc.) ;
- OUI une entreprise possède son propre rythme (saisonnalité, organisation du travail, etc.), ce n’est pas à elle d’adapter son calendrier mais au projet d’en tenir compte.
Donc établissez un planning annuel (au moins) en tenant compte de toutes les périodes de congés, des jours fériés (qui varient en fonction des cultures, des pays), du rythme de l’Entreprise, etc. Vous verrez qu’on ne peut pas faire plus de 10 sprints par an (1 sprint = 3 semaines + 1 de « respiration »), pour tenir les instances, prendre du recul, des décisions, préparer le sprint suivant, etc.
ANTICIPEZ !
Partagez ce planning (incluant les périodes de mise en production et de gel de celles-ci) avec TOUTES LES PARTIES PRENANTES.
Vous aurez contre vous tous les intégristes du « faire agile », RESISTEZ !
Si vous voulez en savoir plus, je vous invite à lire cet article expliquant concrètement la démarche de mise en œuvre d’un modèle de maturité.
A bientôt.
Didier
