Planification à long terme et agile?

Mon équipe a récemment procédé à l'élaboration d'un plan de près d'un an pour notre travail. Nous avons séparé le plan en trois phases. Chaque phase comprendra quelques lancements.

Je me demande, d'un point de vue agile de vous, est-ce mal? Je pense que ce n'est pas une mauvaise idée, car nous n'avons pas passé trop de temps à concevoir autre chose que les premières étapes. Il nous est possible de changer de direction. En même temps, c'est bien que nous n'agissions pas uniquement avec le court terme en vue.

Avoir une vision de la direction du projet est une bonne chose ^TM .

Croire que c'est précisément ce qui va se produire ne l'est pas.

«Lors de la préparation de la bataille, j'ai toujours trouvé que les plans étaient inutiles, mais la planification est indispensable.»

- Dwight D. Eisenhower

L'approche adoptée par les méthodologies Agile consiste à décomposer les éléments en morceaux digestibles et à réajuster la vision une fois chaque morceau digéré.

Cela signifie que votre point d'arrivée dans un an ne sera pas exactement ce que vous pensez maintenant. Cependant, vous devriez avoir abordé tous les éléments de grande valeur de votre liste et avoir gardé vos parties prenantes engagées et heureuses dans votre progression.

OK, la gestion a été présentée avec un mythe pour planifier. J'espère, pour vous, qu'ils ne vous y tiennent pas. Parce que, à perte de vue, je suis prêt à parier que votre équipe n'accomplira rien de semblable à ce que dit ce plan à long terme. En fait, si vous atteignez la moyenne de l'industrie, vous manquerez d'environ un facteur 2. Et dans la plupart des organisations, une estimation, une fois donnée, devient le club avec lequel ils sont libres de vous battre autant qu'ils le souhaitent.

Vous pensez probablement que je suis juste cynique. Après tout, vous venez de communiquer des moments vagues pour des ensembles de fonctionnalités non spécifiés que tout le monde sait que cela pourrait arriver beaucoup plus lentement ou plus rapidement que prévu, non? Désolé, la plupart de ces informations peuvent être vraies, mais ce n'est pas ainsi que les gens ont tendance à entendre ces chiffres. Ils ont entendu des dates, et une date prononcée a tendance à être plus solide que vous ne l'avez dit. De plus, s'il existe une chaîne de communication, elle deviendra encore plus solide. Et une fois que les ventes ont été promises aux clients externes sur la base de ce que vous avez dit, vous constaterez soudainement qu'il y a beaucoup moins de flexibilité dans ces chiffres qu'il ne devrait y en avoir. Et je vous garantis que vous avez sous-estimé le temps que les choses prendront.

Avec ce point évident à l'écart, je vais vous recommander de lire Estimation logicielle pour apprendre quelque chose sur la façon dont l'estimation logicielle doit vraiment être effectuée. Vous en apprendrez beaucoup sur ce que vous avez fait de mal et comment faire mieux la prochaine fois. (Dans le processus, vous apprendrez pourquoi je suis si confiant que vous avez surestimé ce que vous ferez.)

Cela dit, l'agile consiste en grande partie à réduire le processus à ce qui convient à une petite équipe. Souvent, un bon moyen de réduire le processus est d'essayer de réduire la planification à long terme à grande échelle en faveur de la planification de petites choses à court terme. Cela a également tendance à être plus honnête - parce que vous ne savez pas ce qui se passera à l'avenir. Cependant, cela ne correspond souvent pas à des besoins commerciaux plus importants, et donc, que vous vous déclariez agile ou non, vous devez parfois prévoir des plans plus longs.

Cela dit, je vous conseille fortement de découvrir un fait clé concernant les dates que vous avez communiquées, qui risquent malheureusement de revenir sous forme de délais pour vous mordre. Et ce fait est ceci. De quoi les gens se soucient-ils, de la date ou de l'ensemble de fonctionnalités? Voici ce que je veux dire par là. Les organisations ont souvent des dates précises qui comptent. Par exemple, faites quelque chose pour une conférence ou avant la ruée vers les vacances. Dans ce cas, l'important est de libérer quelque chose, et non pas de savoir si ce quelque chose est complet. D'autres fois, il existe un ensemble de fonctionnalités qui doivent vraiment être publiées ensemble, et l'exhaustivité importe plus que quand exactement cela se produit. Si vous pouvez découvrir dans quelle situation vous vous trouvez, alors votre équipe sera bien mieux placée pour planifier la manière de gérer les craquements (presque) inévitables à venir.

C'est bien d'avoir un plan tant que vous le considérez comme étant en cours de réalisation et non quelque chose d'écrit dans la pierre.

La clé ici est de publier régulièrement (au moins une fois par mois), de recueillir de véritables commentaires de vos utilisateurs et de mettre à jour votre plan en fonction de ces commentaires.

Cela signifie que votre plan changera lorsque la portée du projet changera. C'est une bonne chose , car cela signifie que vos utilisateurs en ont appris davantage sur ce qu'ils veulent.

En supposant par project-managementet agilevous vouliez dire Scrum, ce ne serait pas exactement la voie à suivre.

Dans la Scrumperspective, si vous avez un plan d'un an, vous devriez au moins avoir autant de sprints qu'il y a de mois dans une année. Par conséquent, votre plan d'un an devient plus agile car il peut être changé entre deux Sprints.

A Sprintne peut pas durer plus d'un mois, date à laquelle le Teams'engage à porter Sprint Backlog Itemsle statut à Done.

Doneest un mot important ici, et chacun des Scrum Teamdoit avoir une définition de fait, c'est-à-dire où il n'y a plus de travail à faire. Quand a Sprint Backlog Itemest Terminé , cela signifie que l'analyse, l'architecture et la documentation technique sont écrites, et que la fonctionnalité a été testée en profondeur (tests unitaires, tests d'intégration, tests fonctionnels ...).

Une fois que le système Product Backlogest en place et que les éléments sont classés par ordre de priorité avec des fonctionnalités moins importantes en bas et les plus importantes en haut, l'équipe (des développeurs) détermine combien de temps le développement de chacun Product Backlog Itemdoit prendre en fonction de sa propre expérience. C'est là que vous pouvez déterminer que le projet nécessitera une année complète de travail. Considérez que seul leProduct Ownerdoit prioriser les Articles car c'est lui qui est responsable du retour sur investissement, sinon il sait ce qui est le plus important pour l'utilisateur final. De plus, l'équipe doit évaluer le temps nécessaire pour développer pleinement une fonctionnalité, bien qu'il puisse y avoir des morceaux de code réutilisables ici et là qui pourraient répondre aux besoins de cette fonctionnalité, c'est-à-dire pour éviter toute complexité supplémentaire et être certain qu'un élément ne devrait pas prendre plus long que ce que l’équipe a déclaré qu’elle exigerait. Le Product Backlog n'a pas besoin d'être parfait! L'énumération simple des histoires d'utilisateurs que nous pouvons penser au système à développer suffit à cette étape du processus.

C'est durant le Sprint Planning Meetingque l'équipe s'engage sur ce qui sera développé pour le prochain Sprint, créant ainsi le Sprint Backlog. Le se Sprint Backlogcompose d'un sous-ensemble basé sur celui Product Backlog Itemsque les Teamcommits doivent être effectués à la fin du sprint. Considérant par exemple un Product Backlog de 50 articles, et tous les 50 articles doivent nécessiter un an, alors l'équipe peut vouloir sélectionner disons 5 articles dans le Product Backlog, et créer le Sprint Backlog avec ces 5 articles. Ces 5 mêmes éléments peuvent être étendus / éclatés en plusieurs autres éléments si nécessaire, ce qui oblige peut-être l'équipe à changer d'avis après la révision et à s'engager à ne faire que 4 éléments sur 5 précédemment sélectionnés dans le carnet de produits.

Une fois la réunion de planification du sprint terminée, qui ne peut pas durer plus de 8 heures pour un mois complet, au cours de laquelle l'équipe ne s'engage pas seulement à faire le travail pour les éléments sélectionnés, mais prévoit comment elle fera le travail pour que tout le monde dans l'équipe sache exactement ce qu'il doit faire, le Sprintdoit commencer. Il est important que l'équipe soit interfonctionnelle pour le projet.

Cela dit, à la fin de chaque Sprint, qui dure un mois dans la situation actuelle, tous les éléments que l' Teamengagement est de fournir seront des éléments livrables de fonctionnalités entièrement fonctionnelles ciblant les éléments sélectionnés dans le carnet de produits. Il doit être livrable, mais il n'est pas obligatoire qu'il soit livré s'il n'a pas de sens de le faire selon la Product Owner.

Il est au cours de l' Sprint Review Meetingoù Product Ownerdoit être convoqué que le Teamdémontre ce qui a été fait au cours de la Sprint, et où il a besoin de dire pourquoi il n'a pas fait, le cas échéant, tout le travail engagé. Le travail annulé est ensuite remis dans le Product Backloget disponible pour le suivant Sprint. Assurez-vous que ces articles annulés seront inclus dans le prochain sprint, sauf indication contraire du propriétaire du produit, au cas où l'objectif aurait changé. Mais le plus important, bien que l'objectif d'un système ait changé pendant un Sprint, ne l'interrompez pas sauf en cas de nécessité absolue. Seul le Product Owner est autorisé à interrompre le Sprint.

Une fois la Sprint Review Meetingfin, qui ne devrait pas durer plus de 4 heures pour un sprint mensuel (si je me souviens bien), il est temps de se rendre à la Sprint Retrospective Meeting. Le Sprint Retrospectiveest nécessaire pour que le Teamproduit se produise afin qu'il puisse discuter, en présence du Scrum Master et du Product Owner (facultatif) de ce qui n'a pas fonctionné, de la manière dont l'équipe Scrum peut améliorer ses performances, etc. et apporter des ajustements en conséquence.

Lorsque le délai pour le Sprint Retrospectiveest terminé, le nouveau Sprint Planning Meetingdoit se produire pour planifier le prochain Sprintet créer le nouveau Sprint Backlog.

N'oubliez pas qu'il Teamest de la responsabilité de tenir Daily Scrumune réunion debout de 15 minutes où chaque membre de l'équipe répond aux trois questions (pas dans cet ordre particulier):

1. Qu'avez-vous fait depuis le dernier Daily Scrum?
2. Que comptez-vous faire jusqu'à la prochaine mêlée quotidienne?
3. Quels sont les problèmes ou les obstacles que vous avez rencontrés depuis le dernier Daily Scrum?

Le Scrum Mastern'est pas obligé d'être là mais doit s'assurer que l'équipe se réunit au Daily Scrum et que les membres répondent correctement aux trois questions.

Le Scrum Master est responsable du respect des règles Scrum par les autres membres de l'équipe Scrum (Scrum Master, Product Owner et Team).

Au final, en suivant ces règles simples, votre équipe de développement deviendra agile. L'agilité est la capacité de rattraper tout changement aussi rapidement que l'équipe le peut, c'est-à-dire à la fin de chaque sprint, où elle peut prendre connaissance des modifications apportées par le Product Owner au Product Backlog. En cas de catastrophe totale et de changement d'orientation complet, le maximum perdu que l'entreprise doit absorber est un mois de développement, ce qui est assez négligeable, étant donné qu'il n'y a qu'environ 20 jours ouvrables par mois.

Si vous avez besoin d'informations supplémentaires sur Scrum et le développement de logiciels agiles, veuillez consulter Scrum.org et leur guide Scrum .

Eh bien, c'est tout à fait une réponse! J'espère que cela vous aidera au moins dans votre gestion de projet.

EDIT # 1

Pendant que vous envisagez de faire trois ou quatre phases, comme vous l'appelez, il est plus probable que votre équipe perd le focus du point de vue de l'objectif principal. Si vous démontrez après seulement le premier trimestre ce que votre équipe a fait, il pourrait y avoir des changements importants à apporter qui nécessiteront une refonte importante et une refonte de l'architecture de votre logiciel, le reprenant peut-être plus de 20 jours de travail perdu. Le principe de l'agilité est de pouvoir rattraper les changements dès qu'ils se produisent, ou dès que cela est possible dans un délai raisonnable, c'est-à-dire pour Scrum, le time-box d'un Sprint.

1. Je pense que vous devriez avoir autant de lancements que possible. Le seul véritable feedback / métrique pour l'avancement du développement logiciel est le code déployé en production. Quel que soit le processus que vous utilisez, plus vous déployez en direct, plus vous êtes agile. C'est-à-dire que vous obtenez des commentaires réels de vrais utilisateurs plus tôt et que vous pouvez vous adapter plus tôt.

2. Bien que vous ne devriez pas faire de Big Design Up Front , je pense qu'il est bon de penser à la grande image chaque fois que vous êtes sur le point d'ajuster et de reconstituer le backlog, à la fois pour Scrum (pour le prochain sprint) et Kanban / flow (quand il y a de la place) dans la limite WIP). Si vous considérez l'ensemble (produit, service, etc.), il est plus facile de considérer quels éléments de travail vous donneront plus de valeur ensuite.

3. Soyez conscient que la situation dans son ensemble change. Aussi souvent que vous considérez l'arriéré, l'ajustement des priorités, etc., considérez également les changements à la vue d'ensemble. Les choses changent avec le temps, y compris les besoins de clients spécifiques et même de marchés entiers. Votre vue d'ensemble doit refléter cela afin que vos priorités puissent être alignées sur la réalité chaque fois que vous reconstituez l'arriéré, et pas seulement au début lorsque vous faites le plan.

En somme, je pense que vous devenez plus agile plus vous inspectez et vous adaptez.

La planification globale ne prend pas autant de temps, et il est crucial pour les grands projets d'avoir une vue d'ensemble lorsque vous définissez vos sprints, sinon les raccourcis pris dans un sprint pourraient créer des problèmes plus tard.

Vous devriez:

1. Ayez un plan directeur (de préférence sans échéances), qui évoluera au fur et à mesure.

2. Lorsque vous définissez un sprint, vous vous assurez que le sprint est cohérent avec la vue d'ensemble. Cela ne signifie pas toujours que vous changez votre idée de ce qui est souhaité pour le sprint. Parfois, vous découvrirez, lors de la définition d'un sprint, que votre vue d'ensemble doit être ajustée. D'une manière ou d'une autre, le plan d'ensemble et le sprint doivent être cohérents l'un avec l'autre avant le sprint.

3. Le plan directeur doit être ajusté au fur et à mesure. Vous apprendrez des choses en travaillant. De nouvelles opportunités se présenteront, des points de conflit apparaîtront dans le plan. Vous pouvez ajuster le plan directeur à la volée, au fur et à mesure. Mais presque toujours, vous devriez le revoir entre les sprints - pour incorporer les leçons du dernier sprint et pour vous assurer que le prochain sprint est en harmonie avec la vue d'ensemble.

Je pense qu'il vaut mieux que l'arriéré et le grand plan de projet soient des structures distinctes. Le grand propriétaire du projet conserve le plan directeur dans un format hiérarchique pour maintenir le contexte, puis des fonctionnalités / tâches peuvent en être extraites pour alimenter le backlog, qui, à son tour, alimentera le prochain sprint.

Le backlog, contrairement au plan directeur, peut être ajouté par d'autres membres de l'équipe. Il appartient au propriétaire du projet principal de s'assurer que les éléments du carnet de commandes et le plan d'ensemble restent en harmonie - parfois en ajustant l'élément du carnet de commandes et parfois le plan d'ensemble.

Cette méthode maintient le pouvoir de l'agilité et le pouvoir d'aligner tous les éléments de votre projet du mieux que vous pouvez à un moment donné grâce à une planification globale.

Jim

J'ajouterai ici la forme abrégée de ma diatribe anti-Agile.

Agile peut être très destructeur pour les grands projets, en particulier lors de la création de bibliothèques et de cadres qui seront fondamentaux pour le développement futur. Une préoccupation très importante dans les premières phases est "ma conception prendra-t-elle en charge les fonctionnalités dont nous aurons besoin au cours de la prochaine année?". La plupart des stratégies Agiles ne permettent pas ce type de réflexion prospective, et donc des points d'échec de projet sont créés.

Je suis un peu endolori sur ce point parce que je viens juste d'être brûlé par ça. Nous réécrivons certaines de nos bibliothèques principales. Les premières phases ont été terminées et ont atteint les objectifs de fonctionnalité pour leurs sprints. Tout cela est très agile. Ensuite, j'ai été amené à bord pour ajouter des fonctionnalités de chargement dynamique. Cependant, j'ai été bloqué pendant environ six semaines parce que ce qui était écrit avant supposait qu'il n'y aurait jamais de chargement dynamique, j'ai perdu beaucoup de temps à réécrire et à contourner ce qui était déjà là. Le pire, c'est que le chargement dynamique était dans les spécifications au début; si le travail initial avait gardé à l'esprit toutes les exigences futures et effectué le `` gros travail de conception à l'avance '' que les pratiques agiles considèrent comme mauvais, j'aurais pu implémenter ma fonctionnalité en quelques jours.

La leçon est, utilisez agile pour les petites choses que vous êtes prêt à jeter. Ça peut être génial parfois. Cependant, ce n'est pas la seule façon de développer un logiciel. Lorsque vous écrivez du code fondamental à haut risque ou qui aura une longue durée de vie, faites le grand design.