En agile, comment les tâches d'infrastructure de base au début d'un projet sont-elles planifiées et réparties à l'aide de cadres de gestion stricts comme TFS en ligne?

Ici, je suis en train de délimiter et d'estimer un projet de développement logiciel relativement petit. J'ai parcouru les histoires d'utilisateurs suggérées par le client et placé les tâches les unes contre les autres, avec une estimation et quelques brèves notes sur la façon dont la tâche sera accomplie. Il y a des critères d'acceptation. Tout devrait être bon avec le monde.

En regardant le travail que j'avais prévu, j'ai réalisé qu'il manquait quelque chose. Il va y avoir une dépense initiale en configurant simplement les choses dans lesquelles nous pouvons boulonner la fonctionnalité. Les choses qui appartiennent à toutes les user stories, pas à une user story particulière.

Par exemple, une partie de cette application est un service qui analyse XML. Du point de vue de l'utilisateur, il y a des histoires spécifiques où différentes choses devront être faites en fonction du contenu du XML. En fait, écrire un analyseur XML - les bits qui recherchent un fichier, le lisent et extraient les données pertinentes avant de décider quoi faire avec le contenu - fait partie de toutes ces histoires. Tout comme l'envelopper dans un service Windows avec un programme d'installation, etc. C'est une tâche centrée sur le développeur sans pertinence directe pour un utilisateur.

Un autre exemple pertinent de cette application particulière est de prendre et de réécrire un bloc de code hérité médiocre qui est utile pour les fonctions de cette application. Encore une fois, cela n'a pas de résultats immédiats pour l'utilisateur, mais c'est un travail nécessaire. Où la planification et l'exécution de ce travail "vivent" dans un plan de projet axé sur les user stories?

J'ai vu des gens résoudre ce problème en écrivant des histoires d'utilisateurs "En tant que développeur, je veux ..." mais comme cela a été discuté ailleurs, ce n'est pas une histoire d' utilisateur . C'est un développeur.

Je cherche une réponse concrète à cela, pour m'aider (et d'autres) à planifier des projets en utilisant des cadres de gestion stricts comme TFS en ligne. Ceux-ci n'ont généralement pas la fonction de créer des «histoires de parties prenantes» ou d'autres méta-solutions vagues mentionnées dans les réponses à Comment une équipe Scrum rend-elle compte des tâches d'infrastructure lors de la réunion de planification?

J'aime les autres réponses qui disent de mettre autant de code "d'outillage" que possible dans l'itération 0. Cependant, parfois, ces types d'outils apparaissent après le démarrage du projet. Peut-être que dans Iteration 3, vous réalisez que vous avez besoin d'un widget d'analyseur XML généralisé pour être utilisé dans diverses histoires à l'avenir.

Dans ce cas, la première User Story qui s'appuie sur ces pièces architecturales internes est celle à laquelle elles appartiennent . Si vous êtes sur le point de travailler sur l'histoire # 345, et que cela dépendra de votre analyseur XML avant qu'il puisse être compté comme `` terminé '', votre analyseur réutilisable sera joint en tant que travail pour que cette histoire soit terminée.

Mon équipe a utilisé l'approche ci-dessus et cela semble bien fonctionner pour nous.

S'il s'agit d'une infrastructure, elle est généralement placée dans Iteration Zero. Qu'est-ce que l'itération zéro? C'est généralement le temps entre le lancement et la planification avant le début des itérations réelles.

Par exemple, disons que nous avons besoin d'un nouveau service Web. Donc, je dois créer le projet, mettre en place une intégration continue, mettre en place un référentiel de contrôle de source, configurer un script de construction et un déploiement automatisé, etc. Les utilisateurs ne s'en soucient pas vraiment, mais nous en avons besoin malgré tout.

Ainsi, ce travail serait effectué dans l'itération 0. Au moment où l'itération 1 a commencé, il y aurait déjà un nouveau shell de projet qui compilerait, disposerait d'un script de génération automatisé et se déploierait. Maintenant, aucune des fonctionnalités utilisateur ne serait là, mais elle est prête à fonctionner.

Je continuerais à suivre et à planifier ce travail dans le cadre du travail d'itération 0.

Le refactoring sonne comme une histoire technique qui peut aller dans n'importe quelle itération.

Dépend de l'infrastructure.

Si l'infrastructure est très importante ou doit respecter des réglementations de conformité complexes, vous pouvez avoir une équipe d'infrastructure distincte, qui peut avoir son propre calendrier. Ce pourrait être Agile, ce pourrait être une cascade. Dans ce cas, la construction de l'infrastructure serait gérée dans votre projet comme une dépendance externe .

Si l'infrastructure doit être gérée par votre équipe et configurée une seule fois, vous pouvez utiliser la technique d'itération 0 décrite par Jon.

Si la configuration de l'infrastructure prendra plusieurs itérations (par exemple, vous configurez peut-être votre serveur de build maintenant mais que les serveurs QA et préprod seront construits un peu plus tard), leur buildout peut être géré comme des PBI non fonctionnels. Les PBI fonctionnels peuvent avoir certaines dépendances sur ceux-ci, que vous pouvez codifier dans TFS en utilisant le lien "prédécesseur".

Et bien sûr, vous pouvez mélanger et assortir tout ce qui précède. Par exemple, vous ne pouvez pas faire grand-chose sans un serveur de génération continue, vous pouvez donc le mettre dans l'itération 0. Entre-temps, vos serveurs préprod peuvent être définis comme des tâches pour les itérations 2 et 3, et ils peuvent avoir des dépendances externes sur votre équipe DBA ( qui ne sont pas agiles) qui vous allouera des instances de base de données dans votre centre de données. Ou peut-être devez-vous attendre que des certificats SSL soient émis pour certaines fonctionnalités; ils peuvent aller dans l'itération 4, et tous les éléments fonctionnels qui s'appuient sur ces certificats doivent être liés à eux avec une relation prédécesseur / successeur.

Dans tous les cas, n'oubliez pas:

1. Définissez toujours des critères d'acceptation clairs. Les gars du hardware ont une fâcheuse tendance à tenir un serveur et à le dire quand il n'a pas été validé du tout.
2. Lors du lancement de l'itération de votre équipe, l'équipe devra examiner les dépendances et leur disponibilité avant de s'engager sur un PBI ou un élément de travail.