Refactoring dans le développement Agile
Dans un projet de développement d'application, la portée complète du projet n'a pas été prise en compte dans la conception de l'application. Ainsi, la refactorisation fréquente des codes pour s'adapter aux changements a un impact négatif sur le calendrier de livraison du projet, qui est devenu nécessaire pendant un sprint. Comment contrôler au mieux cela pour minimiser le risque de dépassement de la date convenue de livraison du projet, puisque les parties prenantes ne sont pas disposées à faire des compromis?
Réponses
TL; DR
La nécessité de gérer en permanence les attentes des parties prenantes fait partie de tout cadre de gestion de projet, mais en particulier des cadres agiles comme Scrum . Les gens veulent ce qu'ils veulent quand ils le veulent, mais une grande partie de la gestion de projet consiste à expliquer aux gens ce qu'ils peuvent réellement avoir dans les diverses contraintes qui ont un impact sur le projet. Au fur et à mesure que le projet évolue, il en va de même pour la compréhension de ce qui est actuellement faisable dans les contraintes actuelles, en particulier lorsque ce qui est faisable diverge de ce qui était initialement prévu.
Une retouche est attendue
Le refactoring modifie l'implémentation sans modifier le comportement externe. Selon toute vraisemblance, vous n'êtes pas vraiment en train de refactoriser; vous remboursez une dette technique ou effectuez des retouches et une intégration, qui ne sont pas intrinsèquement les mêmes.
Les cadres comme Scrum traitent divers types de travail (y compris la refactorisation et la retouche) comme un compromis acceptable pour le contrôle empirique et la conception. Ceci est géré dans le processus d'estimation et apparaît (correctement) comme un frein à la vitesse à mesure que la dette technologique, la complexité ou le rythme du changement augmentent. Ceci est à la fois attendu et souhaitable dans un cadre itératif, car chaque boucle d'inspection et d'adaptation offre la possibilité de modifier la portée, la hiérarchisation ou l'approche.
La reprise est le coût du contrôle empirique. Vous ne pouvez pas vraiment l'éviter dans des projets complexes tels que le développement de logiciels. Scrum rend simplement la retouche visible à l'équipe et aux parties prenantes comme le coût des changements nécessaires ou souhaitables.
Fixe-tout n'est pas possible
Le «triangle de fer» postule que vous pouvez ajuster un projet en contrôlant le budget, la portée ou le calendrier, la qualité étant une quatrième dimension implicite affectée par les trois autres curseurs. Le graphique suivant illustre cela.
Les frameworks agiles comme Scrum traitent généralement la portée, et en particulier la portée du projet , comme le curseur principal en demandant:
Quelle portée pouvons-nous intégrer dans la boîte temporelle d'un seul Sprint ou dans notre plan de publication agile ?
Actuellement, votre projet tente de corriger la portée et le calendrier. Cela ne laisse que le budget comme curseur disponible. Si vous essayez de verrouiller cela également, votre projet échouera, la qualité en souffrira, ou les deux. Vous ne pouvez tout simplement pas faire de manière fiable un prix fixe, une portée fixe et un calendrier fixe dans n'importe quel cadre de projet tout en maintenant la qualité; Scrum le rend simplement plus évident et rend les compromis plus visibles.
Le but de Scrum n'est pas de faire disparaître magiquement le triangle de fer. Au lieu de cela, cela oblige le projet (ainsi que les parties prenantes et les sponsors) à accepter les compromis inhérents. Scrum permet aux parties prenantes de déterminer si quelque chose est "assez bon" pour être expédié à la fin de chaque Sprint, et le Product Owner a la possibilité d'ajuster la portée et la hiérarchisation pendant le raffinement du backlog et la planification du sprint. Les parties prenantes doivent tirer parti de ces événements pour s'assurer qu'ils obtiennent le plus de valeur possible dans le plan de sortie; ce n'est jamais une garantie de remboursement que le projet sera soit achevé à 100%, soit adapté à son objectif à la fin d'une série fixe de Sprints.
Diminuer les coûts irrécupérables
Un autre aspect du développement agile est la possibilité «d'échouer tôt». Lorsqu'un projet est susceptible d'échouer pour une raison quelconque, les cadres agiles comme Scrum donnent au Product Owner la possibilité d'économiser de l'argent en annulant un Sprint et en planifiant un nouveau en fonction des attentes modifiées, ou en permettant aux parties prenantes d'annuler le reste du projet si cela ne serviront pas leurs objectifs. Ce dernier ne fera pas réussir le projet, mais réduira les coûts irrécupérables associés au projet.
Rien de ce que n'importe qui fait ne peut garantir la réussite d'un projet. Le mieux que vous puissiez faire est de le contrôler et de tuer un projet condamné le plus tôt possible lorsque le succès n'est plus une option.
Ce que vous pouvez faire maintenant
Tout d'abord, reconnaissez que vous êtes sur la voie d'une marche vers la mort. Si vous ne faites pas face à cette vérité, rien de ce que vous ferez n'aura d'importance.
Ensuite, déterminez si le problème est la conception, la dette technologique, les attentes déraisonnables ou autre chose. Peu importe la ou les causes profondes; il suffit de les rendre visibles pour que l'équipe et les parties prenantes puissent les aborder en collaboration .
Enfin, communiquez clairement l'état actuel. Si vous êtes sur la bonne voie pour une version complète quelques cycles après la date de livraison initialement prévue, discutez de la possibilité pour le projet d'ajuster le sommet «temps». Si vous ne pouvez pas ou ne voulez pas ajuster le calendrier, vous pouvez toujours respecter le délai fixé en augmentant les coûts ou en réduisant la portée. Les parties prenantes échangeraient-elles une livraison à temps pour réduire certaines fonctionnalités chronophages? Vous ne le saurez que si vous le demandez.
Si le projet ne peut ou ne veut pas faire l'une des choses ci-dessus, préparez-vous à l'échec. Rafraîchissez votre CV et espérez que vous avez appris de précieuses leçons que vous pourrez utiliser pour votre prochain projet ou votre prochain emploi. Surtout, espérons que vous avez appris à communiquer tôt et souvent sur les hypothèses, les défis, les exigences du cadre et les compromis, et que vous avez intériorisé l'importance de la gestion continue des attentes des parties prenantes.
Produisez-vous un incrément de produit déployable à chaque sprint? Si tel est le cas, les dates de livraison convenues sont déjà respectées et c'est la meilleure façon de minimiser les risques et de donner au client confiance dans ce que vous faites. Les parties prenantes (via le propriétaire du produit) doivent décider quelles choses elles veulent et quand, donc le plus important est qu'elles continuent à vous voir apporter de la valeur et que vous obteniez leurs commentaires sur les améliorations, les changements et les correctifs nécessaires au produit. Obtenir leurs commentaires est la clé ici. Les clients pourraient naturellement s'inquiéter si la chronologie se prolonge sans nouvelle portée fonctionnelle, mais dès que vous commencerez à inclure les dernières améliorations qu'ils considèrent comme prioritaires, ils seront plus susceptibles d'apprécier le besoin de flexibilité.