Décider du niveau de détail nécessaire pour un plan de livraison

Publié: 2022-08-23

« De combien de détails avons-nous besoin pour notre plan de publication ? »

C'est une question importante à poser au début d'un projet de développement logiciel, ou dans le cas d'une équipe produit de longue date, avant le développement d'une version majeure d'un système.

La réponse à cette question déterminera la quantité d'efforts initiaux que nous déployons pour documenter notre plan, ainsi que la quantité d'efforts dont nous aurons besoin pour maintenir le plan documenté au fil du temps. D'un point de vue agile, nous voulons profiter de la planification , qui consiste à réfléchir à l'avance aux problèmes critiques, mais sans prendre le risque de trop réfléchir ou de prendre des engagements trop tôt.

En bref, les agilistes visent juste assez de planification.

Connaissez votre contexte lors de la planification de la version

Un principe fondamental de l'agilité commerciale est que le contexte compte : différentes équipes se trouvent dans des situations différentes et doivent ajuster leur approche en conséquence si elles veulent être efficaces.

Une implication intéressante de ceci est qu'il n'y a pas de "meilleures pratiques". Au lieu de cela, toutes les pratiques sont de nature contextuelle. Toute pratique donnée a des compromis : elle fonctionne bien dans certaines situations et s'avère être une mauvaise idée dans d'autres.

Pour choisir une méthode de travail efficace (WoW), vous devez comprendre les compromis des différentes techniques à votre disposition, puis sélectionner la combinaison qui vous convient le mieux compte tenu de la situation à laquelle vous êtes confronté, ainsi que des compétences et de la culture de les personnes concernées. Reconnaissant cela, les options de planification de publication suivantes sont des choix plutôt que des prescriptions.

options de niveau de détail pour le plan de version

Figure 1. L'objectif du processus Planifier la mise en production.

Dans la figure 1, vous voyez le diagramme d'objectifs de processus indiquant comment une équipe peut planifier la version initiale d'une solution logicielle. Remarquez comment un plan peut aborder le calendrier/le temps, le coût, la valeur, les considérations de personnel ou des combinaisons de ceux-ci.

En relation: Comment financer un projet de développement de logiciel

L'un des points de décision que vous devez prendre en compte est la quantité de détails que vous allez saisir dans votre plan, le cas échéant. C'est l'objet de cet article, comme le montre le rectangle rouge.

Vous pouvez voir sur le diagramme des objectifs qu'il y a huit points de décision que vous devez prendre en compte lors de la planification d'une version et que chacun de ces points de décision a des options. Lorsqu'il y a une flèche à côté de la liste des options, on dit que les options sont ordonnées ; quand il n'y a pas de flèche, elles ne sont pas ordonnées.

Dans le cas des options commandées, nous avons pu classer l'efficacité relative des options, avec les options les plus efficaces vers le haut de la liste et les options les moins efficaces vers le bas. Il est important de noter que les classements présentés dans la figure 1 concernent les équipes logicielles, même si nous pensons que les classements sont susceptibles de s'appliquer également aux équipes non logicielles.

Options de niveau de détail dans un plan de version

Je pense qu'il existe quatre options pour planifier la publication d'une solution ; bien que je reconnaisse qu'il peut y en avoir plus et que vous pourrez peut-être combiner des stratégies. Comme vous pouvez le voir sur la figure 1, il y a une flèche à côté de la liste des options indiquant qu'elle est commandée. Du plus efficace au moins efficace, les options sont :

  1. Vague roulante : le plan est continuellement mis à jour tout au long de la version, comme une vague, avec plus de détails pour les travaux à venir et moins de détails pour les travaux ultérieurs. Un plan de vague continue commence comme un plan de haut niveau, et les détails, le cas échéant, sont ajoutés juste à temps tout au long de la version.
  2. Haut niveau : le plan de publication indique les principaux jalons , toutes les phases, toutes les itérations/sprints (si votre équipe travaille de cette façon) et toutes les dépendances entre eux. Il n'aborde pas le détail des travaux à effectuer. Au lieu de cela, il fait confiance à l'équipe pour s'auto-organiser et faire tout ce qui est approprié à ce moment-là.
  3. Détaillé : le plan de publication contient des détails importants sur le travail à effectuer et peut même attribuer ce travail à des rôles ou à des personnes spécifiques. Les détails sont identifiés au début de la version, pendant une période que les équipes agiles et scrum appellent souvent « Sprint 0 », Inception ou Initiation. Les détails sont généralement mis à jour au fil du temps au fur et à mesure de l'avancement des travaux.
  4. Aucun : Le plan de release n'est pas documenté du tout. La planification peut toujours se produire, mais le plan lui-même n'est pas capturé.

Comparaison de vos options de planification de release

Comme indiqué précédemment, il n'existe pas de «meilleure pratique», mais chaque pratique fonctionne bien dans certaines situations et moins bien dans d'autres. Le tableau 1 présente les compromis associés aux stratégies détaillées de planification des versions décrites ci-dessus.

En relation : Modèle de plan de projet gratuit

Lorsque vous connaissez les compromis associés à une option, vous pouvez prendre une meilleure décision quant à l'approche la plus adaptée à la situation à laquelle vous êtes confronté. De meilleurs choix conduisent à de meilleurs résultats.

Tableau 1. Comparaison de chaque stratégie pour le niveau de détail d'un plan.

Option de financement Avantages Désavantages
Vague roulante ·Très efficace dans les environnements fluides, notamment lorsque les besoins évoluent rapidement ou que les membres de l'équipe ne sont pas encore totalement connus.

·Fonctionne bien avec la budgétisation par vague continue car elle aligne les pratiques de financement continu avec la planification continue.

·Permet aux équipes de produire des échéanciers et des budgets honnêtes pour leurs parties prenantes.

 · Nécessite de la flexibilité de la part des parties prenantes, car elle supprime le sentiment (réconfortant) de fausse prévisibilité en faveur de leur donner la capacité de diriger et de guider l'équipe vers le succès.
Haut niveau · Fonctionne bien pour les équipes expérimentées qui n'ont pas besoin de beaucoup de détails sur le plan.

·Utile pour donner aux parties prenantes une prévision de haut niveau de ce qui sera livré au fil du temps et pour identifier les dépendances avec d'autres équipes.

·Fournit un certain sentiment de « prévisibilité » sans assumer les coûts d'une planification détaillée.

 ·Peut être inconfortable pour les personnes recherchant le faux sentiment de sécurité qui accompagne les plans détaillés.
Détaillé · Uniquement pratique pour les initiatives triviales où le degré d'incertitude lié aux exigences et à la technologie est faible, et le calendrier est en fait prévisible.

·Souvent justifié par un besoin de se conformer à la réglementation, même si les réglementations exigent rarement une planification préalable détaillée.

 ·Fournit une fausse impression de prévisibilité aux parties prenantes lorsqu'elle est appliquée dans des situations où les exigences varient (ce qui est la grande majorité des situations).

· Nécessite des efforts importants, et généralement inutiles, à maintenir plus tard dans le cycle de vie à mesure que la situation évolue.

· Fait baisser le moral de l'équipe.

Aucun ·Convient aux initiatives simples à faible risque dans un environnement hautement collaboratif.

·Aucune surcharge de documentation.

 ·N'offre pas de transparence aux parties prenantes qui ne collaborent pas activement avec l'équipe.

Le choix est bon lors de la planification des versions

Si vous voulez être efficace, vous devez adapter votre approche à la situation à laquelle vous êtes confronté. Parce que différentes équipes font face à des situations différentes, une seule approche ne conviendra pas à tous, et à la place, vous devez avoir des choix que vous comprenez et pouvez appliquer de manière appropriée.

Plus important encore, vous devez être prêt à faire évoluer votre approche à mesure que votre situation évolue. Comme le montre cet article, vous disposez d'une gamme de choix pour le niveau de détail de votre plan de publication. Notre recommandation est de faire de votre mieux dans la situation à laquelle vous êtes confronté et de toujours essayer d'apprendre et de vous améliorer.

Que vous planifiez en détail ou que vous suiviez un cadre agile et que vous planifiez de manière plus souple, en laissant une place libre à l'itération, vous devez toujours planifier. ProjectManager est un logiciel de gestion de projet basé sur le cloud qui vous offre la flexibilité de planifier comme bon vous semble. Avec des tableaux Kanban, des diagrammes de Gantt et un tableau de bord en temps réel qui fournit des données à jour une fois que vous avez mis ce plan en marche, vous êtes toujours au courant des changements et pouvez réagir rapidement. Voyez par vous-même en prenant cet essai gratuit de 30 jours.