Scrum e sciami di attività non parallelizzabili

So, how officially are issues of dependencies between stories and inherently serial stories handled by the methodology?

Come con qualsiasi altra cosa in Agile: Individuals and interactions over processes and tools

Se il tuo processo non ti sta servendo, allora lo metti in qualcosa di utile. Per questo, vorrei inserire storie con priorità inferiore (o qualche debito tecnico / crescita personale che forse non è visibile nel backlog) fino a quando il pre-requisito non sarà risolto. Supponendo che tu abbia fatto la tua due diligence e che sia veramente un pre-requisito duro e veloce. Per un sacco di cose, le interfacce e i mock possono sbloccare il lavoro finché la cosa reale non è pronta.

Una delle caratteristiche di kanban, che credo trasuda in mischia, è che il processo nel suo complesso ottimizza il team , non l'individuo. In altre parole, non è peccato se qualcuno del team è inattivo per parte dello sprint.

Se la squadra nel suo insieme sceglie X punti storia, non importa (agli stakeholder) se una persona abbia fatto tutto il lavoro o se il lavoro fosse equamente diviso. Quindi, se il proprietario del prodotto è contento del numero di punti che è stato portato in uno sprint (e questa è la chiamata del proprietario del prodotto, non dello scrum master!), Allora è tutto ciò che conta.

Ovviamente, detto questo, se alcuni membri del team non sono direttamente coinvolti nella prima storia, possono essere impegnati a scrivere test o fare tutto ciò che possono sulle altre storie.

Come nota finale, il maestro di mischia ha poco da fare "scavando alle calcagna". Il maestro di mischia dovrebbe lavorare per te per rimuovere gli ostacoli alla produttività, non creare barriere. Se la squadra nel suo insieme sente di poter inserire un'altra storia a priorità più bassa, questa è una decisione che la squadra deve prendere; il maestro di mischia non ha l'ultima parola in merito.

È possibile fare un'eccezione se la squadra è giovane e sta ancora imparando la mischia, ma se la squadra è matura, l'intero punto di mischia è quello di potenziare la squadra piuttosto che i manager.

Per come la vedo io, hai due problemi diversi:

1. Come ottimizzare la produttività del tuo team.
2. Come ordinare il prodotto e eseguire sprint di backlog in base alle dipendenze.

Per la tua produttività del team , posso simpatizzare con il tuo Scrum Master: ho scoperto, a causa della natura umana, che molte persone vogliono tenere tutti occupati, piuttosto che ottimizzare l'intero team. Essere occupato non equivale alla produttività. Il minimo potrebbe essere la cosa migliore da fare per un membro del team in un dato momento.

Sulla questione specifica dell'attività di installazione: sembra qualcosa che dovrebbe essere automatizzato. Dato il tuo articolo, se lavorassi con il tuo team, vorrei dedicare del tempo a capire cosa sta succedendo con questo processo di installazione che richiede sia tempo che blocchi, dal momento che sembra un ottimo candidato per migliorare l'efficacia della squadra.

Spero anche che tu non sia l'unica persona della squadra in grado di farlo. Se hai un giorno libero, mi auguro che il team abbia altre persone in grado di gestire questo processo di collo di bottiglia. Lo sciame potrebbe essere un'opportunità per garantire che più persone apprendano come farlo.

Supponendo che tu abbia una dipendenza inevitabile tra Product Backlog Items (PBI), prenderei in considerazione tutti i PBI dipendenti come bloccati finché non viene indirizzata la dipendenza di blocco. In generale, questo significa lasciare i PBI bloccati fuori da uno Sprint. Dal momento che hai il controllo sulla dipendenza da blocco, posso vedere portare i PBI dipendenti nello sprint, ma sembra una mossa rischiosa. In Sprint Planning, generalmente mi aspetto di considerare solo i PBI che non sono bloccati.

In conclusione, però, è trovare ciò che funziona meglio per fornire software valido, testato e funzionante nel modo più efficace possibile.

La regola numero 1 per costruire il backlog sprint (aggiungendo gli elementi del backlog del prodotto o PBI) dovrebbe seguire il principio base di INVEST:

1. Indipendente: Il PBI deve essere autonomo, in modo che non ci siano dipendenze intrinseche su un altro PBI.
2. Negoziabile: i PBI, fino a quando non fanno parte di un'iterazione, possono sempre essere modificati e riscritti.
3. Prezioso: Un PBI deve fornire valore agli stakeholder.
4. Stima: Devi sempre essere in grado di stimare la dimensione di un PBI.
5. Small: I PBI non dovrebbero essere così grandi da diventare impossibili da pianificare / task / prioritizzare con un certo livello di certezza.
6. Testabile: Il PBI o la sua descrizione correlata devono fornire le informazioni necessarie per rendere possibile lo sviluppo del test

Sembra che il tuo Scrum Master stia costringendo il team a infrangere la prima regola, tutte le storie in uno sprint dovrebbero essere indipendenti - cosa fai se sei bloccato su quella storia che devi completare per ottenere qualsiasi altra storie chiuse? In questo caso, probabilmente fallirai lo sprint.

Sono d'accordo sul fatto che lo swarming / pair programming sia un buon modo per collaborare e condividere le conoscenze nel team - ma se non c'è bisogno di sciamare su qualcosa di simile, allora resterei fedele alle tue pistole e citerei INVEST:)

Copiato da Wikipedia: link