web-dev-qa-db-fra.com

Comment gérer la dépolarisation des travaux terminés sur Scrum agile

La description est trop long, mais cela est un point de douleur. Je veux juste comprendre si cette pratique est aussi agile, si oui, comment à surmonter certains des problèmes mentionnés ci-dessous. Merci.

Nous utilisons agile Scrum pour nos projets et nous avons 2 semaines sprints. A chaque sprint, nous honorons " quelque chose ". Nous avons d'énormes quantité de micro-services avec le travail de plusieurs équipes de dev sur chacun. Par conséquent, nous avons beaucoup d'intégrations internes et les dépendances quand il y a des changements. Normalement, un CR s'ajouté comme Epic, chaque épopée peut avoir des tâches de développement multiples pour chaque micro services touchés.

En ce qui concerne les sous tâches, parfois il peut y avoir des tâches qui prend plus de 1 sprint. Ces CRs/Epics normalement se livrer dans le prochain sprint ou quand ils sont prêts.

Supposons que nous avons des tâches suivantes. (Gardez en se concentrant sur MicroService03)

sprint

Epic 1
  - Task E1T1 --> MicroService01 -> DevTeam01  -> Estimate: 1 week
  - Tast E1T2 --> MicroService02 -> DevTeam02  -> Estimate: 2 weeks
  - Task E1T3 --> MicroService03 -> DevTeam03  -> Estimate: 2 days

Epic 2
  - Task E2T1 --> MicroService03 -> DevTeam03  -> Estimate: 1 day
  - Task E2T2 --> MicroService04 -> DevTeam04  -> Estimate: 2 weeks

Epic 3
  - Task E3T1 --> MicroService03 -> DevTeam03  -> Estimate: 1 day

Epic 4
  - Task E4T1 --> MicroService05 -> DevTeam03  -> Estimate: 1 day

Supposer Epic 1, 2, 3 et 4 Sont commandés par des priorités. Ce qui signifie Epic 1 Est le plus élevé important pour les utilisateurs finaux/clients.

Statut à la fin du sprint,

Epic 1
  - Task E1T1 --> MicroService01 -> DevTeam01  -> Estimate: 1 week  - COMPLETED
  - Tast E1T2 --> MicroService02 -> DevTeam02  -> Estimate: 2 weeks - WIP 
  - Task E1T3 --> MicroService03 -> DevTeam03  -> Estimate: 2 days  - COMPLETED

Epic 2
  - Task E2T1 --> MicroService03 -> DevTeam03  -> Estimate: 1 day   - COMPLETED
  - Task E2T2 --> MicroService04 -> DevTeam04  -> Estimate: 2 weeks - WIP 

Epic 3
  - Task E3T1 --> MicroService03 -> DevTeam03  -> Estimate: 1 day   - COMPLETED

Epic 4
  - Task E4T1 --> MicroService03 -> DevTeam03  -> Estimate: 1 day   - COMPLETED

Alors le Epic 3, et Epic 4 Sont prêts à être aller vivre, mais assumer Epic 3 Est maintenue en raison de tenir d'autres changements. Puis le MicroService03 Devrait être libéré qu'avec le Epic 04 changements.

DevTeam03 Peut gérer des branches de code de manière suivante.

  1. Faire les branches fonctionnelles totalement isolées -> Peut libérer Epic 04 facilement
  2. Faire du développement progressif -> Donc Epic 4 Base contient précédemment développé également Epic 1, Epic 2 et Epic 3 modifications du code. Si tel est le cas, ne délivrant que le Epic 4 changements n'est pas possible.

Supposons que nous allons avec # 1 et nous sommes dans Sprint 2. Maintenant, il est difficile de dire quelles fonctionnalités que nous devrions fusionner depuis,

  • une). Plus de nouveaux changements sont là dans le 2ème sprint pour MicroService03
  • b). DevTeam03 N'obtient savoir sur Epic 1 et Epic 2 État de dépendance à la fin du sprint

Permet de supposer que d'autres dépendances sont terminées. Ensuite, les tests unitaires que DevTeam03 Achevé en sprint précédent ne sont pas plus valables en raison de la fusion de la branche. Et il pourrait y avoir des conflits de code à fixer par un examen de code complet.

Si nous regardons l'estimation et tracez un diagramme de Gantt, nous facilement décider des priorités des sous-tâches, mais il ne se produit pas en raison de la priorité de la tâche.

Vous pouvez également supposer qu'il ya seulement plusieurs tâches totalement isolées pour MicroService03 Dans le premier sprint et PO/SM peut décider de ne pas libérer certains des changements et/ou, version terminée, mais faibles éléments prioritaires en premier.

Comment DevTeam03 Devrait surmonter des situations comme celles-ci? Je pense personnellement que c'est une façon d'avoir abusé Agile. L'ont appris Agile/Scrum I est beaucoup plus facile que cela :(

Très apprécié vos commentaires.

MISE À JOUR : Epic est une histoire de haut niveau.

agilescrumbranchingproduct-ownerscrum-master
4
sura2k

La combinaison de ces deux devrait vous rendre super agile et livrer facilement dans de petites itérations par des équipes indépendantes:

  • EPIC serait en principe décomposé dans petit, indépendant et des histoires précieuses, qui sont chacune mise en œuvre dans un sprint. La priorisation au niveau de l'histoire devrait aider à décider de ce qui est dans le sprint, indépendamment de la valeur de l'épopée.

  • Microservices sont censés être couplés de manière lâche et de manière indépendante . Donc, si E1T1 est terminé, il devrait être rentable, même sans E1T2 n'est pas prêt.

Si vous êtes dans la situation complexe que vous décrivez, vos microservices pourraient ne pas être aussi indépendants qu'ils le devraient. Et décider de l'arriéré Sprint de l'équipe basé sur les ambitions épiques mondiales au lieu d'histoires individuelles et indépendantes, pourrait simplement être moins agile que souhaitée.

Je recommanderais de répondre à la cause première: réviser votre approche pour utiliser le meilleur parti de l'indépendance et de l'autogestion de chaque équipe.

4
Christophe

comprendre si cela se passe dans l'industrie comme une pratique

Cela me rappelle quelque chose que j'ai vu quelque part ", pensais-je Dilbert était la satire, je sais maintenant que c'est un documentaire." Oui, cela arrive d'autres endroits, assez souvent, mais pas parce que nous avons compris comment le faire fonctionner, simplement parce que nous avons également une gestion confuse et de mauvaises idées.

On dirait que dans ce cas, cependant, Scrum est travaillant comme prév . Scrum (ou toute méthodologie) ne résout pas les problèmes. Ce que Scrum fait la visibilité dans les problèmes, de sorte que vous puissiez reconnaître les causes profondes et les fixer avec de vraies corrections.

Avec des itérations plus courtes et un temps dédié pour la rétrospection, vous pouvez effectuer des changements incrémentiels, les tester, voir si elles aident de manière à ce que vous souhaitiez, ajustez si nécessaire. Cela rend également certains problèmes beaucoup plus faciles à documenter, tels que dans votre cas - il est facile de voir que vous avez trop d'interdépendance entre les équipes/services et en conséquence, des travaux sont fréquemment bloqués. Être capable de documenter c'est une étape pour obtenir des changements de gestion et une étape pour pouvoir démontrer si des changements sont/ne pas aider (par exemple lorsque la direction dit qu'ils changeront, puis ils ne le font pas).

Donc, cela n'a pas encore échoué d'agile, échoué Agile, c'est lorsque vous avez documenté tous les problèmes et qu'il est toujours impossible de les changer ... il est préférable de revenir à vos patchs et de bandages fonctionnent mieux avec ces problèmes en place . (Dans ce cas, cela traiterait probablement de tous vos services comme s'ils sont un monolithe et vos équipes sont toutes une grande équipe.)

0
user3067860