Risposta breve
Il Dev Team scrive le cose tecniche. Scrum ti aiuta un po ', ma non molto con il resp tecnico. iniziare su una User Story. Scrum è quasi solo What-World . Il guasto tecnico è How-World .
La ripartizione fornita da Scrum è:
- User Story -> Criteri di accettazione
La ripartizione che le persone usano spesso in aggiunta a questo è:
- Epico -> Racconti utente
- User Story -> Sottoattività
- Criteri di accettazione -> Test di accettazione
Inoltre, il team potrebbe scrivere Task tecnici per le cose che sanno che devono essere fatte (ovvero installare IntelliJ IDEA per tutti all'inizio del progetto) ma che non hanno valore commerciale.
Per ulteriori indicazioni su come eseguire i guasti, cercare XP (Extreme Programming), Clean Code , Programmazione pragmatica , Ingegneria del software , CRC-Cards , OOP / OOA / OOD , Pattern di progettazione , Refactoring , Lavorare in modo efficace con il codice legacy , TDD ( Test-Driven Development), BDD (Behavior-Driven Development), ATDD (Acceptance-Test Driven Development).
Risposta lunga
Come pensa Scrum
What-World e How-World
C'è un What-World e un How-World . Come hai sentito correttamente, User Story è per gli utenti , generando valore aziendale noto anche come valore secondario nel What-World . Scrum è principalmente solo What-World. Non dice quasi nulla sul How-World , praticamente niente di più di "How-World è la responsabilità del Dev-Team".
User Story vs Task
Di solito, gli oggetti arretrati che sono per il How-World non sono chiamati User Story ma Task tecnici o Sottoattività . Molti strumenti consentono di scomporre la User Story dal What-World in Subtasks nel How-World .
Come Scrum aiuta e dove finisce quell'aiuto
L'aiuto di Scrum for the How-World termina in alcuni punti della riunione di Sprint Planning :
- [Sprint Planing Meeting] Il team scopre l'incomprensione della storia se diversi compagni di squadra escogitano diverse stime di Story Point durante il Planning Poker -> Discussione.
- [Definizione di Pronto] Il team non accetta storie utente troppo grandi (punti trama troppo alti). Una regola empirica trovata in molte definizioni di pronto è che i punti storia devono essere inferiori alla metà della velocità della squadra.
- [Definizione di pronto] Il team non accetta le storie utente senza una descrizione sufficiente dei criteri di accettazione. I criteri di accettazione sono sufficienti se il team ha abbastanza fiducia su come iniziare a scrivere i test di accettazione.
Alcuni consigli sul livello di Scrum
Ho trovato utile analizzare le storie utente in sottoattività durante le riunioni di perfezionamento del backlog o almeno nella seconda parte della riunione di Sprint Planning (per alcuni team Sprint Planning 2 Meeting).
Con team inesperti ho trovato utile lottare per le storie degli utenti Atomic durante il perfezionamento del backlog e la pianificazione dello sprint. Una User Story Atomic è una User Story che non può essere ulteriormente suddivisa in User Story più piccole senza perdere del tutto il suo valore aziendale. In generale, le User Story non devono necessariamente essere Atomic, ho appena scoperto che mi aiuta con team inesperti.
E non fare "(Architecture | Design | Implementation | Test) di Feature X" come User Story. Ti consiglio anche di provare a evitarlo come sottoattività.
Se ho le storie degli utenti Atomic e sembrano aver bisogno di un'ulteriore suddivisione oltre ai criteri di accettazione da implementare, significa per me che qualcosa non funziona al livello ottimale. L'architettura è sbagliata / troppo complicata, ovvero tecnica anziché orientata al business. Oppure la squadra è inesperta. O entrambi. In ogni caso, sarebbe necessaria un'azione per migliorare la situazione attraverso la formazione e la diffusione delle conoscenze.
Oltre Scrum
Lo Scrum Master oltre Scrum
Oggi, lo Scrum Master è principalmente inteso come un ruolo manageriale , e questa è una cazzata. Inizialmente, lo Scrum Master era, e lo sostengo, un ruolo tecnico , non un ruolo manageriale, proprio come il Coach in XP .
È fin troppo facile affidarsi a Scrum e Scrum Master e quindi cadere in un enorme divario perché Scrum non dice quasi nulla sul How-World.
Scrum Master rotante
Idealmente, Scrum Master ruota tra quegli sviluppatori esperti che hanno anche sufficienti capacità manageriali e comunicative fino a quando tutti nel team non vivono "Ispeziona e adatta" così profondamente che lo Scrum Master diventa ridondante; nessuno e tutti sarebbero Scrum Master allo stesso tempo.
Ma attenzione, Scrum Mastery è più come cucinare, non come pulire il tavolo e lavare i piatti. Potresti voler ruotare chi pulisce il tavolo e lava i piatti, poiché tutti potrebbero farlo. Ma non vorrai ruotare la cucina su tutti, perché ci sono persone che non sanno cucinare o che non amano cucinare, e vuoi mangiare del buon cibo.
La cosa buona di ruotare Scrum Master tra sviluppatori esperti è che il team ha maggiori probabilità di conoscere più metodi.
Il team auto-organizzante
Dal punto di vista di Scrum, il team deve scoprire se stesso, idealmente con l'aiuto dello Scrum Master .
Scrum parla anche del Dev Team . Ruoli come architetto o ingegnere capo non esistono in Scrum. Ciò non significa che sono vietati, significa solo che Scrum non dice nulla su di loro. Scrum proclama un team auto-organizzante , il che significa che se il team dichiara un architetto, il team ha un architetto. Questo non è definito da Scrum, ma è conforme a Scrum. Non sto proclamando architetti dedicati (ho lavorato come architetto designato per anni, e anche se mi è piaciuto, sono fondamentalmente contrario all'idea di architetto designato), solo per fare un esempio.
Test di accettazione
Le storie utente hanno criteri di accettazione . Questi criteri di accettazione vengono trasformati in test di accettazione
Altre cose
Per un elenco di più elementi per la suddivisione, vedere Come suddividere un progetto di programmazione in attività per altri sviluppatori?
Spero che questo ti aiuti.