La planification de release et le burndown de release ont disparu
Auteurs : Ralph Jocham et Henk Jan Huizer
Source : Gone are Release Planning and the Release Burndown
Date : 06/09/2011
Traducteur : Fabrice Aimetti
Date : 06/09/2011
Traduction :
Tout Chef Produit qui a livré avec succès un produit à un client sait combien il est important de Planifier une Release. Malgré cette importance, le Guide Scrum 2011, publié en Juillet par Ken Schwaber et Jeff Sutherland, supprime toute discussion sur la Planification de Release et le Burndown de Release associé. Ralph Jocham et Henk Jan Huizer, tous deux Professional Scrum Trainers, expliquent ces changements :
Sommaire
Pourquoi avoir retiré ces éléments du Guide Scrum ?
Le Guide Scrum, le corpus de connaissances de Scrum, a grandi au fil des ans pour répondre au nombre croissant de questions que les gens ont à propos de la bonne utilisation de Scrum. Dans la mise à jour récente du Guide Scrum, Ken et Jeff ont décidé de supprimer la plupart des astuces et des stratégies et de ne garder que les règles de base pour jouer à Scrum. Cela peut sembler être un choix étrange étant donné qu'il y a encore des milliers de questions possibles sur l'utilisation de Scrum.
Mais il y a une bonne raison pour avoir supprimé la mise en œuvre de ces stratégies et astuces. Simon Sinek soutient que l'on devrait toujours commencer par le "Pourquoi", et seulement ensuite passer au "Comment" pour enfin terminer par le "Quoi". La version précédente du Guide Scrum décrit beaucoup de choses sur ce qui doit être fait. Cependant, décrire le Quoi ferme la porte à des approches alternatives et, éventuellement, à de meilleures approches. En revanche, décrire le Pourquoi pousse les gens à penser par eux-mêmes sur la façon d'appliquer les concepts dans leur contexte propre et unique. Avoir retiré la plupart des Quoi du Guide Scrum se prémunie également des comportements copiés / collés, de suivre aveuglément les règles, sans les comprendre, juste parce qu'elles ont eu du succès dans une autre situation ; créant ainsi un phénomène culte du cargo.
Cet article se concentre sur la supression de la Planification de Release et du Burndown de Release du Guide Scrum.
Pourquoi a-t-on besoin de la Planification de Release ?
Dans l'industrie du logiciel, les produits sont généralement livrés aux clients dans des releases officiels. Cela peut être une grosse et unique release à la fin d'un projet, ou des releases plus incrémentales sur une base trimestrielle ou même annuelle dans le cas du développement de produits. Bien que les releases soient fréquentes, elles sont conformes aux faiblesses du développement logiciel et ne tirent pas partie du processus incrémental et itératif d'un framework Agile comme Scrum. Lorsque Scrum est bien utilisé, une valeur potentielle est générée à chaque Sprint. Mais si un incrément n'est pas livré à chaque Sprint, nous ne livrons pas cette valeur à nos clients. Nous recherchons activement des réactions de la part des utilisateurs, donc pourquoi ne pas les faciliter en livrant un incrément de Sprint en Sprint ?
Cette pratique des releases logicielles existe car il n'est pas toujours facile de constamment livrer ce qui a été construit. Scrum spécifie qu'un Incrément produit à la fin d'un Sprint soit potentiellement utilisable. Cela ne signifie pas qu'il soit nécessairement utile. Il y a donc souvent un besoin de lotir des Incréments utilisables dans une série de Sprints pour fournir quelque chose qui soit potentiellement utile pour un client.
Malheureusement, certaines organisations utilisent les releases pour compenser de mauvaises pratiques de développement. Un incrément utilisable est un incrément sans travail dans l'état "non fini" à la fin d'un sprint. Si les équipes sont incapables de créer des Incréments vraiment utilisables, alors le reste des travaux (tests, documentation, tests d'acceptation par les utilisateurs, etc.) sont effectuées dans le cadre du processus de la release, parfois nommé la phase de stabilisation. Dans ce cas, le planning de la release accepte officiellement des pratiques de développement médiocres, et rend incroyablement difficile la tâche pour le Product Owner de prévoir efficacement quand une release sortira.
Cependant, même si une release est composée d'Incréments utilisables, et est potentiellement utile pour un client, beaucoup de choses doivent se passer pour qu'un client en retire réellement de la valeur. Ce processus d'intégration d'une release afin d'en extraire la valeur est appelé absorption.
Pour facilement absorber une release, les clients devront peut-être avoir à passer par des installations, des versions d'essai, des pilotes, des déploiements, des formations, des certifications, et une foule d'autres processus avant que la release ne fournisse de la valeur. Etre conscient, et effectivement planifier, ces activités qui doivent être réalisées pour aider les clients à extraire la valeur du produit, motive la planification d'une release. C'est la raison pour laquelle le précédent Guide Scrum incluait la planification de release.
Pourquoi a-t-on besoin du Burndown de Release ?
Scrum est un framework empirique reposant sur les trois piliers que sont la transparence, l'inspection et l'adaptation. Afin de nous adapter, nous devons inspecter, et afin d'inspecter nous avons besoin de transparence. Nous utilisons un burndown parce qu'il fournit la transparence nécessaire sur la façon dont nous procédons sur une période de temps donnée. Il donne des réponses rapides à des questions comme "Sommes-nous sur la bonne voie, sommes-nous en avance ou sommes-nous à la traîne ?"
Scrum est utilisé dans des environnements complexes, comme le développement de produits, où la situation peut changer quotidiennement. Les besoins changent, les défis techniques apparaissent souvent et l'environnement organisationnel change tout autour. Scrum accepte que les changements fassent partie du processus de développement de logiciels complexes et les accueillent très volontiers. Afin de faire face aux changements, nous avons besoin d'informations précises et à jour.
Le burndown de release fournit exactement ce type d'information concernant l'atteinte de l'objectif de la release. L'opportunité d'inspection du burndown de la release offre la capacité précieuse de s'adapter immédiatement lorsque des changements sont opérés. Il donne à l'Equipe Scrum la chance de se poser des questions difficiles dès le départ au lieu d'attendre la dernière semaine avant la date de sortie planifiée de la release.
Pourquoi la Planification de Release a-t-elle été retirée du Guide Scrum ?
La réponse est simple et brève : il est possible d'utiliser avec succès Scrum sans avoir recours à la planification de release. Ne pas avoir besoin d'une planification de release peut effectivement être un indicateur positif de la bonne santé d'un produit. Scrum est conçu pour livrer continuellement de la valeur aux clients grâce à des itérations courtes. Utiliser des releases peut réellement retarder la livraison de cette valeur, le feedback des clients et le retour sur investissement (ROI). Avec des pratiques de développement efficaces et des stratégies de déploiement excellentes, la livraison de la valeur peut avoir lieu à chaque Sprint.
Est-ce que la Planification de Release n'est plus autorisée dans Scrum ?
La planification de release reste encore très précieuse dans de nombreux cas. Il est souvent difficile de fournir une solution métier complexe en un laps de temps réduit à un unique sprint. Parfois des périodes d'essai étendues sont nécessaires pour satisfaire les exigences rigoureuses de qualité. Les grandes entreprises exigent parfois des changements d'infrastructure. Et parfois, les clients n'aiment pas les releases fréquentes parce qu'elles génèrent plus de douleur que de valeur. Dans ces scénarios, la planification de release est une activité de grande valeur, une manière de préparer une stratégie, une feuille de route de ce à quoi on peut s'attendre après quelques sprints, et communiquer sur ce qui fera partie de le release et sur ce ne qui n'y sera pas.
Pourquoi le Burndown de Release a-t-il été retiré du Guide Scrum ?
Puisque Scrum n'exige plus de planification de release, cela n'a aucun sens d'exiger le burndown de release. Scrum s'efforce de rendre les processus de développement logiciel et de livraison transparents. Un burndown peut être très utile pour y aider. Mais, il peut y avoir d'autres façons d'atteindre ce même objectif. En supprimant les lignes directrices sur le Quoi faire, Scrum peut bénéficier de futures innovations.
Le Guide Scrum 2011 revient à ses racines. Moins de choses peut être un plus ! Mais ne vous laissez pas berner par 16 pages de règles ; le jeu Scrum est simple à comprendre, mais difficile à maîtriser.
