Comment représenter un projet agile auprès de personnes axées sur la cascade [fermé]

Notre équipe a été invitée à représenter nos efforts de développement dans un plan de projet. Personne n'est mécontent de notre travail ou remet en question notre capacité à livrer, nous participons simplement à un appel informatique pour des plans de projet. Le problème est que nous sommes une équipe agile et n'avons pas pensé à notre travail en termes de plan de projet formel.

Bien que nous ayons une idée générale de ce sur quoi nous travaillons ensuite, nous ne sommes pas sûrs à 100% jusqu'à ce que nous planifions une itération. Jusqu'à présent, notre équipe a fonctionné en grande partie dans le vide et n'a pas été tenue de présenter notre méthodologie ou nos paramètres à des tiers. Nous suivons la plupart des pratiques adoptées dans la programmation extrême .

Nous tenons des réunions de planification trimestrielles pour avoir une idée générale des histoires sur lesquelles nous allons travailler pendant un trimestre. Cela dit, nos histoires sont documentées sur des cartes 3x5 et ne sont estimées qu'au début de l'itération dans laquelle elles vont être travaillées. Après estimation, nous documentons l'histoire dans Team Foundation Sever . Pendant une itération, nous attachons du code aux histoires et marquons les histoires comme terminées une fois terminées. À partir de ces données, nous pouvons générer des graphiques de combustion et de vitesse. Plus important encore, nous connaissons notre vitesse moyenne pour une itération nous empêchant de mordre plus que nous ne pouvons mâcher.

Je ne cherche pas à modifier la façon dont nous faisons le développement, mais je veux présenter nos activités de développement dans un rapport que quelqu'un qui ne connaît que la cascade comprendra. Dans À quoi ressemble un plan de projet agile , Kent McDonald fait un bon travail en exposant les différences entre les plans de projet agile et en cascade. Il précise les différences de balles consommables:

• Un plan de projet agile est basé sur les fonctionnalités
• Un plan de projet Agile est organisé en itérations
• Un plan de projet Agile a différents niveaux de détail selon le laps de temps
• Un plan de projet Agile appartient à l'équipe

Être capable d'expliquer les différences est formidable, mais comment présenter au mieux les données?

Montrez-leur le manifeste agile à demi-arsé .

Il vous explique clairement en quoi consiste le système Agile en le comparant aux méthodes en cascade :

Les individus et les interactions sur les processus et les outils
et nous avons des processus et des outils obligatoires pour contrôler la façon dont ces individus (nous préférons le terme «ressources») interagissent

Logiciel de travail sur une documentation complète
tant que ce logiciel est documenté de manière exhaustive

La collaboration du client sur la négociation des contrats
dans les limites des contrats stricts, bien sûr, et sous réserve d'un contrôle rigoureux des modifications

Répondre au changement en suivant un plan à
condition qu'un plan détaillé soit en place pour répondre au changement, et qu'il soit suivi avec précision

J'ai dû faire ça, une fois. L'équipe voulait faire Agile, le Client voulait (et comprenait Agile), une tierce partie externe (appelez-les "Auditeurs"), voulait voir les rapports Waterfall.

Une raison importante pour laquelle nous pouvions mentir était parce que la 3e partie ne s'en souciait pas vraiment, elle voulait juste cocher les cases. Si le Client était satisfait et que l'Équipe était heureuse, les "Auditeurs" ne reviendraient guère et regarderaient les rapports que nous leur aurions remis, avant de cocher les cases finales.

Ne faites pas cela si la tierce partie est importante et se soucie réellement que vous utilisez une cascade . Si les auditeurs savent que vous êtes agile et n'ont tout simplement pas mis à jour leurs documents pour vous soutenir, alors vous pouvez mentir.

Que faire? Mensonge , mais mensonge blanc.

• Reformuler les fonctionnalités, comme exigence "Doit avoir une fonctionnalité".
• Votre travail est en itérations, les itérations durent généralement plus de X semaines, un plan en cascade aime voir les choses en général en semaines, donc pas de gros problème. Vous pouvez étiqueter la fin de chaque itération comme un jalon. Les jalons sont la cascade. Les itérations ont tendance à avoir un thème (ou une épopée associée), vous pouvez donc coller le thème / titre épique sur le jalon (par exemple, 21/11 Avoir l'interface graphique complète.)
• Calculez votre vitesse (à partir de vos graphiques de gravure / augmentation) et déterminez combien de temps un Story Point, en moyenne, représente (au moins à votre vitesse actuelle), cela vous donnera la durée des tâches. Souvent inexactes, mais elles auront un sens dans une certaine mesure.
• Votre plan a un niveau de détail différent selon le calendrier - essentiellement le même pour la cascade. Différent possible un plan de cascade a des détails différents selon le public.

• Un plan Agile appartient à l'équipe. Un plan de cascade appartient au gestionnaire de projet. Vous avez déjà un chef de projet, et ils font probablement cette traduction . Ils devraient s'approprier ce document traduit et protéger l'équipe contre les failles qui pourraient tomber sur eux à cause de cela. C'est le travail d'un chef de projet Agile ou Waterfall de protéger l'équipe des distractions qui les empêcheront de travailler.

• Bien sûr, vous ne savez pas vraiment ce que vous faites lors de la prochaine itération, mais vous savez à peu près ce que vous faites. Vous avez une idée de cela, et encore plus grossier l'itération après. (J'ai entendu ce qu'on appelle le radar d'itération). Mentez et dites que vous le faites. et lorsque vous mentez entre vos dents sur une carte d'histoire qui n'est pas sur votre radar d'itération, et mettez-la quelque part. J'espère que vous n'aurez pas à soumettre trop de mises à jour sur le plan du projet, sinon ils remarqueront que vous n'avez pas fait ce que vous aviez dit.

Fondamentalement, c'est une douleur. La traduction nécessitera de nombreuses heures de travail. Si vous devez le faire beaucoup, automatisez-le.

La première question à se poser est: que veut réellement l'entreprise? Certaines entreprises sont parfaitement satisfaites de voir des sprints agiles représentés / décomposés en un diagramme de Gantt. Cela peut ne pas avoir de sens pour quiconque comprend réellement les sprints et peut changer régulièrement, mais il est familier aux personnes qui le demandent. Ensuite, avec le diagramme de Gantt, présentez le burndown, etc.

Nous avons vécu quelque chose de similaire et finalement (si Agile fonctionne), il se vendra (si ce n'est pas le cas, alors pourquoi le faites-vous?). Les gens commencent à comprendre «l'effort» et qu'une certaine équipe est capable de «brûler» 40 points d'effort en un sprint de 2 semaines et est en fait assez bonne pour estimer ces points d'effort. Une fois qu'ils verront les avantages pour eux, ils vendront le processus au reste de l'entreprise pour vous. Mais l'essentiel est que vous ne pouvez jamais, jamais le forcer sur quelqu'un, car il ne fera que riposter.