Agile - Pics et chronologie globale

L'équipe lance son premier projet Agile capital-A, et le projet semble correspondre parfaitement à la méthodologie (c'est-à-dire que nous pouvons probablement simplement prendre un livre agile et le suivre comme une recette), avec un peu de confusion:

Le projet implique trois choses que personne dans l'équipe n'a aucune expérience avec: intégrer avec le système de paie Foo, être capable de gérer le type de fichier XYZ89 (où "XYZ89" = un type de fichier dont vous n'avez jamais entendu parler), et convertir certains d'autres fichiers afin qu'ils puissent être gérés par Frobnobdicator.

Si je comprends bien, la pratique Agile standard serait de planifier des pics pour chacun d'eux, après quoi nous pouvons déterminer combien de temps ils vont prendre (je ne suis pas sûr qu'il y ait beaucoup de chance que le client décide de ne pas le faire). eux, car ils sont à peu près des exigences solides du projet)

Mes questions sont donc:

1. Faisons-nous tous les pics à l'avant lors de la première itération pour obtenir une meilleure estimation du temps qu'il faudra pour les faire et / ou obtenir un "squelette ambulant" et le faire fonctionner?

2. Sinon, le calendrier total du projet ne serait-il pas à la merci d'un de ces pics qui reviendrait avec des données selon lesquelles cette histoire particulière prendrait beaucoup plus de temps que nous ne l'avons prévu?

Quelle est la meilleure façon de gérer plusieurs pointes alors qu'il s'agit essentiellement d'exigences non négociables d'un projet?

La façon dont j'ai traité ces inconnues louches dans mon plan de projet auparavant est d'essayer de configurer le temps pour l'équipe de développement de faire des prototypes de la fonctionnalité inconnue au préalable. Cela donne l'avantage de faire clairement savoir ce qui sera nécessaire pour effectuer les tâches spécialisées, prouve que celles-ci sont techniquement réalisables et éduque le reste de l'équipe sur les pièges possibles à éviter lorsque le développement actif commence.

C'est pourquoi de nombreux projets Agile commencent généralement par un, ce que j'aime appeler, Sprint 0 .

Considérez-le comme laçage de vos chaussures de course, étirement et mise de pansements sur vos mamelons juste avant de commencer un marathon. Ce temps peut être utilisé pour faire la planification initiale du projet et la création de la user story, la conception et le déploiement de l'architecture, la création du cadre logiciel et les développeurs peuvent travailler sur tous les prototypes et preuves de concepts pour toute nouvelle technologie ou les défis techniques inconnus qui rendront la user story intéressante estimation beaucoup plus facile.

Vous devez faire les choses dans l'ordre de priorité défini par le propriétaire du produit (ou le client). Il n'y a aucun sens à se suicider pour quelque chose qui était vraiment agréable à avoir. L'idée est que si vous manquez de temps et que quelque chose ne se fait pas, ce devrait être les éléments les moins prioritaires.

S'ils ne donnent pas la priorité à ce qu'ils veulent, vous allez avoir du mal.

Si les choses sont relativement égales, ne commencez pas par l'élément le plus difficile - commencez par une victoire facile, qui donnera à l'équipe une chance de s'habituer à travailler ensemble en utilisant la nouvelle méthodologie et au client une certaine confiance qu'il peut livrer des choses de cette façon. Une fois que c'est établi, affrontez quelque chose de difficile. Mesurez la complexité de l'élément difficile par rapport à la complexité des choses plus faciles que vous venez de faire, et vous commencerez à avoir une idée du temps qu'il faudra pour le traverser.

Les articles complexes ne sont pas vraiment des "pointes". Ce sont simplement des choses qui demandent plus d'efforts pour être comprises. Décomposez-les autant que possible en tâches plus simples.

Une solution possible est de créer une tâche pour faire une preuve de concept afin de comprendre comment résoudre le problème et le temps, puis ajouter cette histoire à un sprint avec d'autres histoires.

Vous êtes sûr de livrer de la valeur et un produit à la fin du sprint, même s'il s'agit d'une application de console de piratage. L'idée est que vous ne réduisez pas la productivité de toute l'équipe, si vous manquez de temps, vous ajoutez une autre tâche similaire au prochain sprint.