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?

9

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.

entrez la description de l'image ici

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?

Bob Tway
la source
2
Si je vous dis qu'un ordinateur ou un service peut également être traité comme un «utilisateur», cela modifie-t-il votre analyse?
Robert Harvey
1
@mmathis J'ai vu cette question, et elle est similaire et pertinente. Cependant, aucune des réponses ne répond réellement à cette question. Surtout lorsque vous tenez compte de la façon de le faire dans les cadres existants comme TFS.
Bob Tway
@RobertHarvey partiellement, oui. Cela couvrirait le service dans ce cas, mais pas le code hérité. Je peux penser à d'autres situations où cette approche pourrait ne pas couvrir les exigences. Je serais également intéressé de savoir à quel point cela est largement accepté: cela semble être un changement sémantique pour contourner le problème "en tant que développeur".
Bob Tway
2
Vous pouvez tricher à avoir des utilisateurs du système, et itération0, ou vous coupez le gâteau différemment. La première fonctionnalité donne quelques fonctionnalités utilisateur et l'infrastructure nécessaire pour le faire fonctionner. Ensuite, la fonctionnalité 2 qui apporte par conséquent un peu plus d'infrastructure, de cette façon, vous ne perdez pas de temps à configurer une infrastructure dont vous n'avez pas besoin. Si vous criez maintenant mais que cela signifie que je dois repenser, alors vous ne faites pas d'agilité.
ctrl-alt-delor

Réponses:

12

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.

Graham
la source
J'allais répondre de la même manière à celui-ci. Si une histoire a besoin de quelque chose, elle en fait partie. Certaines histoires pourraient simplement avoir l'avantage de venir après une autre histoire qui a construit l'infrastructure. Cependant, vous devez conserver toutes les histoires qui en ont besoin, au cas où elles seraient redéfinies. Vous ne pouvez pas être sûr de ce que sera le premier.
Jay S
1
+1 Cela touche à un grand point. Que ce soit appelé itération 0, 1 ou quoi que ce soit une bagatelle. Tous, sauf les plus déraisonnables ou mal informés, comprennent que des travaux préparatoires sont nécessaires. Si vous peignez, vous préparez les murs, si vous cuisinez, vous hachez, si vous êtes musicien, vous pratiquez.
Robbie Dee
6

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.

Jon Raynor
la source
4
+1 parce que nous l'utilisons également, mais en réalité Interation Zero est le nouveau Iteration One. C'est juste une itération qui ne préoccupe pas vraiment les parties prenantes de l'entreprise, mais qui est nécessaire pour arriver aux choses qui les intéressent.
Greg Burghardt
Vous pouvez avoir une itération 0 de bonne foi, mais cela ne veut pas dire que vous ne pouvez pas commencer à fournir de la valeur à partir du jour 1. Vous n'avez pas besoin d'un serveur de construction, d'un déploiement automatisé et d'un référentiel de code source pour commencer à couper le code - cela peut arriver plus tard (ou même en parallèle).
Robbie Dee
3

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.
John Wu
la source
Les gars du hardware ont une fâcheuse tendance à tenir un serveur et à le dire quand il n'a pas été validé du tout. Bon point - d'où la prévalence récente de DevOps.
Robbie Dee