Article original : Project budgeting: an anti-pattern
Par Bertil Muth
Les avantages souhaités du développement agile sont nombreux. Les clients sont plus heureux et plus enclins à acheter. Le temps de traitement, de l'idée à la livraison, est plus court. Les employés sont plus motivés et plus productifs.
Ça a l'air bien, n'est-ce pas ? En pratique, certains comportements font obstacle à ces avantages. En tant que scrum master et coach agile, je vois les mêmes anti-patterns se répéter dans de nombreuses entreprises. L'anti-pattern d'aujourd'hui concerne la budgetisation des projets et les contrats.
Fixer le périmètre - pas une bonne idée
Dans de nombreuses entreprises, le périmètre de livraison doit être décidé en premier. Ensuite, quelqu'un estime l'effort et calcule le budget nécessaire. Enfin, une décision de go ou no-go est prise pour le projet.
C'est similaire pour de nombreuses relations client-fournisseur. D'abord, un contrat doit être établi qui décrit exactement ce qui sera livré. Sinon, il n'y a pas de commande.
Comment pourrait-il en être autrement ? Comment pouvez-vous, en tant que client, être sûr de ce qui sortira à la fin ?
En tant qu'agiliste, voici ma réponse. Les clients ne peuvent pas connaître le résultat final exact à l'avance. Le développement de logiciels est plein de surprises. Les exigences d'aujourd'hui sont de l'histoire demain.
Il est important de reconnaître la tension entre la prévisibilité et la capacité de changement. Vous ne pouvez pas avoir les deux : une prévisibilité parfaite du résultat final au début et une considération maximale des demandes de changement plus tard.
Ce que vous pouvez faire à la place
Au début du développement agile, il suffit que les parties prenantes s'accordent sur une vision produit, et peut-être sur une feuille de route approximative. Le financement peut être fait de manière incrémentielle, sprint par sprint.
Mais que faire si cela n'est pas possible dans votre entreprise ? Que faire si les parties prenantes ne veulent pas renoncer à l'illusion de sécurité qui vient de la clarification précoce des exigences ?
Eh bien, c'est une perte de temps de spécifier des détails d'exigences qui changeront plus tard. Alors, que faire ?
Vous pouvez vous accorder sur des user stories à l'avance. Cela a du sens. Mais ne définissez pas les critères d'acceptation ! La clarification des détails est reportée au développement, peu avant l'implémentation.
L'avantage : vous pouvez réagir aux leçons tirées du développement et aux nouveaux besoins des clients.
Gestion du changement bien faite
Soit au début d'un projet, soit lors de la négociation du contrat, les parties prenantes doivent s'accorder sur le mode de coopération et la gestion des changements ultérieurs.
Il est important de suivre quelques principes importants.
S'il y a des changements, un processus de gestion du changement qui évalue chaque changement individuellement n'est PAS suffisant. Au lieu de cela, un changement doit être lié à d'autres changements.
Pour chaque changement qui est implémenté, soit
- retirez une autre exigence du périmètre, soit
- augmentez la durée du projet.
Lors du développement, des éléments individuels peuvent donc être remplacés par des éléments équivalents en termes d'effort de développement. Scrum supporte cela avec le Product Backlog – en remontant un élément du backlog, les autres éléments ont automatiquement moins d'urgence.
Si vous voulez en savoir plus sur la conception de contrats agiles, je vous recommande de jeter un œil à Money for Nothing and Your Change for Free.
Pour maîtriser les bases du développement agile de logiciels, visitez mon cours en ligne. Si vous voulez rester informé de ce que je fais ou me laisser un mot, suivez-moi sur dev.to, LinkedIn ou Twitter. Ou visitez mon projet GitHub.