Vous fatiguez-vous jamais qu’on vous demande «quand sera-t-il prêt?» Vous êtes toujours réticent à vous engager à respecter un délai afin d’éviter d’être accusé d’être «en retard» lorsque vous ne le respectez pas? Car avouons-le, lorsque vous commencez à créer un logiciel ou une grande fonctionnalité que vous ne pouvez pas facilement décomposer, vous ne pouvez jamais vraiment dire avec certitude combien de temps cela prendra. Vous pourriez passer beaucoup de temps à essayer d’anticiper toutes les éventualités à l’avance – mais y a-t-il quelque chose qui sonne plus cascade que ça? Au moment où vous en avez fait assez pour en être certain, vous pourriez aussi bien avoir passé votre temps à créer le logiciel.
Agile vs Waterfall
La planification à long terme dans un environnement agile peut sembler un paradoxe, mais que se passerait-il s’il y avait un moyen de faire une planification à long terme tout en conservant l’agilité? Scrum préconise de ne pas planifier plus loin dans le futur que le prochain sprint (1-4 semaines), mais ce n’est tout simplement pas ainsi que la plupart des entreprises fonctionnent; surtout s’ils n’ont pas de culture basée sur la livraison de produits numériques.
Scrum est un excellent moyen d’organiser des équipes de développement logiciel, mais il ne répond pas au genre de questions que les types de directeurs financiers aiment à poser, comme «combien cela coûtera-t-il et quand le recevrai-je?» Cela est doublement vrai dans les organisations qui n’ont pas toujours construit de logiciels et qui sont maintenant sous pression pour avoir une présence numérique – des organisations qui ont besoin de créer des produits numériques et qui le font si elles ne veulent pas être dépassées par la foule de startups. Si votre entreprise construit des ponts ou des navettes spatiales, la planification au fur et à mesure ne se lave tout simplement pas.
Gérer les parties prenantes
Parler du favori du chef de projet; Le triangle portée-qualité-temps / coût est un moyen de gérer ces besoins apparemment contradictoires entre l’ingénierie et l’entreprise, mais il peut être assez difficile de transmettre un concept si vos parties prenantes n’ont pas travaillé avec des équipes de développement logiciel.
Le triangle du chef de projet
Source: smarterwebsiteowner.com
Le triangle dépeint un monde où vos seuls choix sont entre un produit sous-spécifié ou de mauvaise qualité par rapport à un produit qui répond à tous ses objectifs en dehors du coût et du temps. Dans ce monde, les plans d’affaires reposent sur la clairvoyance: mais que se passe-t-il si quelqu’un vous dit qu’il existe un outil que vous pouvez utiliser pour supprimer une partie de ce travail de supposition? Entrez le burn-up de la version.
La solution Release Burn-up
J’ai trouvé que c’est une solution qui explique comment vous vous engagez à dépenser les ressources nécessaires à la réalisation de votre plan d’affaires sans prétendre savoir exactement ce que vous obtiendrez pour cet investissement. Cela évite également de vous lier à une portée et à un délai impossibles et inflexibles que vous ne pouvez espérer respecter qu’en compromettant la qualité. Ou simplement exagérer vos estimations initiales pour éventualités, au point où il est peu probable que vous obteniez l’approbation de procéder en premier lieu.
Comment faire
La gravure de version illustrée ci-dessus peut facilement être créée. Ses composants sont les suivants:
- Carnet de commandes – il s’agit de la ligne bleue continue qui indique votre meilleure vue de tout le travail que vous devez effectuer pour expédier un produit. Vous l’obtenez en ajoutant des points d’histoire des histoires que vous avez déjà terminées et votre meilleure compréhension de ce qui reste dans le backlog. Il monte et descend et change à chaque sprint lorsque vous réestimez les histoires et ajoutez ou supprimez des histoires / épopées de votre backlog
- Projection – il s’agit de la ligne grise continue indiquant la vitesse idéale pour atteindre votre date de livraison préférée
- Vitesse réelle – il s’agit de la ligne verte continue qui comprend vos progrès réels jusqu’à présent et une projection dans le futur (basée sur la moyenne des trois ou quatre derniers sprints). La projection vous aide à voir si vous suivez votre date de livraison idéale
- Les lignes pointillées montrent ce qui se passerait si vous deviez travailler à un rythme plus rapide ou plus lent que votre vitesse moyenne actuelle. Là où ils coupent la ligne bleue, c’est quand vous pouvez vous attendre à livrer votre produit
Autres ingrédients clés
La version intégrale ne résoudra pas à elle seule tous vos problèmes de gestion des parties prenantes. En fait, il repose sur quelques ingrédients clés pour être efficace, à savoir:
- Une bonne feuille de route qui décrit où vous allez, sinon nécessairement les fonctionnalités que vous allez aborder à des moments précis. La feuille de route produit de Roman Pichler est un bon modèle pour communiquer vos objectifs de haut niveau de manière transparente et flexible
- Un backlog en couches – qui comprend des histoires granulaires prêtes à être travaillées par les développeurs. Mais il comprend également une carte de haut niveau de toutes les épopées que vous devrez peut-être compléter pour un produit complet. Cette carte n’a pas besoin de vivre dans les outils de gestion des tâches et en fait, elle est probablement plus facile à comprendre sous la forme de post-its sur un mur comme l’arborescence des produits de Manna Janna Bastow
- Estimation imprécise – toutes ces épopées de haut niveau dans votre carnet de commandes peuvent recevoir des estimations grossières, étant entendu qu’il y a beaucoup d’incertitudes et ces estimations seront révisées à l’avenir à mesure que vous comprendrez mieux ce que vous essayez de faire.
- Une équipe fixe et stable travaillant à une cadence régulière afin que vous puissiez dire avec un haut degré de certitude et de précision, combien vous pouvez faire et quelle sera votre vitesse d’un sprint à l’autre
Le meilleur des deux mondes
Un burn-up de version n’est pas une solution miracle qui résoudra tout, mais il vous permet d’être empirique et transparent avec vos prédictions. Celles-ci doivent encore être communiquées avec soin afin de ne pas lier votre équipe à la date fixe et à une portée fixe qu’elle tentait d’éviter en premier lieu. Il doit être fortement qualifié avec des mots comme «les choses changent» et «c’est notre meilleure vision actuelle». Il est certainement avantageux de préparer vos parties prenantes à un changement complet d’orientation si de nouvelles informations suggèrent que cela pourrait être la bonne chose à faire.
De même, il doit également être clair que la vitesse et le flux d’une équipe fluctuent pour toutes sortes de raisons et une conversation honnête sur la raison pour laquelle cela peut se produire est essentielle. Velocity n’est utile que pour aider l’équipe à améliorer la prévisibilité de sa sortie. Il ne doit pas être utilisé comme mesure de performances lorsque le fait de ne pas atteindre un nombre spécifique indique une sorte d’échec même s’il existe de bonnes raisons derrière les fluctuations.
En fin de compte, les parties prenantes ne sont difficiles à gérer que lorsqu’elles ne sont pas régulièrement rassurées sur la prise en compte des éléments qui leur tiennent à cœur. Le burn-up de la version ne remplace pas la communication et ne fonctionne pas seul sans d’autres outils; vous devez toujours le faire vous-même.
Mais cela reflète le fonctionnement réel des équipes de développement de logiciels modernes – qui consiste à s’adapter et à changer de direction à mesure que davantage d’informations émergent plutôt que de s’en tenir à une vue fixe. Dans le bon environnement, avec les bons outils complémentaires, j’ai constaté que la combustion de versions peut être un moyen très efficace de combiner des objectifs qui semblent en désaccord: effectuer une planification réaliste à long terme sans ôter l’agilité ou la flexibilité. Et à mes yeux, toute idée qui offre même une petite chance d’y parvenir mérite d’être explorée.
