Voici quelques situations qui doivent vous amener à penser méthodes agiles
(XP, Scrum, ...) :
Votre client/MOA sait exprimer ses besoins mais ne se sent pas
capable de spécifier complètement sa nouvelle application ?
C'est normal. Personne ne sait figer ses
exigences dans les moindres détails avant que les développements ne
commencent.
Les clients qui vous le promettent ne sont pas de mauvaise foi, par contre
leurs utilisateurs en voudront pour leur argent et changeront forcément de
point du vue en cours de projet. Sans parler des changements d'environnement
tout au long du projet (fusion, changement de stratégie, nouvelle législation,
infaisabilité technique, mauvaise compréhension du besoin, ...)
Votre client/MOA ne croit plus aux développements forfaitisés à prix
fixe. Ce soit disant prix fixe explose dès le premier comité de pilotage
!
C'est normal. Aucun développeur, chef de projet ou
directeur de projet ne peut chiffrer un développement à
l'avance. S'il dit le contraire, il n'est pas de mauvaise foi, il se voile
juste la face en se rassurant avec des feuilles de calcul Excel, des points de
fonction et des abaques. Un développement est une fonction avec trop
d'inconnues.
La pire des situations est l'appel d'offre
ouvert qui incite les prestataires à évaluer à la baisse sans jamais
voir le client en face pour lui poser des questions sur son projet.
Au mieux, on doit pouvoir donner une estimation du type : Votre projet
a 70% de chances de prendre 1000hj, plus ou moins 200hj. Ceux qui ont un peu
étudié les statistiques, savent que les résultats de sondages doivent être
donnés sous cette forme, même si les médias pensent que communiquer un
pourcentage est suffisant.
Votre client/MOE souhaite contrôler la qualité de vos livrables sans
savoir trop comment s'y prendre.
C'est normal. Dans le cas de forfaits, l'application livrée
a rarement la qualité attendue, faute de temps pour mieux faire. Pour se
protéger, les clients fixent donc des normes de développement, des outils de
vérification (type cast), des jalons de livraisons, des processus complexes,
... En fait, nos clients cherchent à nous faire porter les risques en
fonctionnant en forfait. Mais comme nous n'arrivons pas à livrer la qualité
attendue dans le temps imparti, ils doivent passer en mode
flicage.
Le pire c'est que ce mode flicage nous rapporte (nous
SSII), puisque l'on aide d'autres clients à mettre au point des normes, des
processus, des audits,...
Le seul indicateur de qualité devrait être le produit livré, confronté aux
utilisateurs finaux. Pour tester la satisfaction de ses clients, Sun ne pose
plus qu'une question : Seriez-vous prêt à recommander nos
produits ?
Alors que faire ?
Il faut aider nos clients à utiliser les méthodes "agiles". Les bénéfices
sont multiples :
Plus de big upfront design, donc des coûts réduits :
Le projet classique (architecture technique, POC, socle technique personnalisé,
développement) est remplacé par une architecture émergeante au fil de l'eau
plus légère et plus flexible. Cela ne veut pas dire que l'on ignore les règles
d'architecture ou d'urbanisation du client. Cela reste des exigences en entrée
du système.
Plus de dépassement de budget incontrôlé : Si le
budget maximal est atteint, on peut choisir :
D'arrêter les développements et d'utiliser le produit tel
quel. Avec les méthodes agiles, on a un produit fini à chaque itération. Avec
les méthodes classiques (même itératives), le projet est rarement utilisable en
l'état.
De contrôler l'augmentation de budget car le produit est
affiné à chaque itération sans risque de régression (grâce au test driven
development). Pourquoi pas ne pas mettre le logiciel en production tout en
repoussant l'ajout de fonctionnalités à l'année prochaine ? C'est
d'ailleurs un peu ce que l'on fait en achetant un progiciel.
Les meilleurs développeurs travaillent pour vous : Les
méthodes agiles attirent en effet les développeurs expérimentés ou en quête de
nouvelles compétences. Grâce au pair programming ou au rythme des itérations,
ils seront plus motivés, plus efficaces et le turn-over est réduit.
Voila pour un court article sur les bénéfices des méthodes agiles. Un
dernier point en passant : L'itératif n'est pas forcément
agile. Ne vous trompez pas, il manque beaucoup à UP pour devenir
agile. Pour moi, les deux points importants sont le pilotage par les tests et
le fait que l'on doit aider le client à décider le contenu des
itérations lui-même. C'est donc bien le client qui tient les
commandes ! (Pas juste le porte monnaie)