Storie di utenti e un sacco di trattative su ciò che è essenziale e ciò che è fluff.
Un sacco di negoziazione.
Anche un sacco di avanti e indietro sull'architettura. Scrum richiede un'architettura stabile e comprovata. Tuttavia, ci sono sempre aggiornamenti e miglioramenti. Come si adattano all'arretrato? Questo è un sacco di spinte politiche tra proprietario del prodotto, gente di tecnologia e (in una certa misura) utenti/acquirenti.
Il processo in intrinsecamente non lineare.
È più simile alla cristallizzazione. Hai una soluzione, inizi a scrivere storie, hai una visione tecnologica, hai una squadra con determinate abilità ed esperienza.
Ognuna di queste funzioni può servire da "nucleo" per decidere cosa va nel backlog e in quale ordine. Alla fine, qualcosa diventa il nucleo e la miscela si cristallizza. A volte il costo o il programma oi rischi sono inaccettabili, quindi lo riscaldi di nuovo, trovi un altro nucleo e vedi se cristallizza in modo accettabile attorno a quel nuovo nucleo.
La ricristallizzazione avviene dopo ogni sprint, a proposito, rendendolo ancora meno lineare.
Modifica. "stabile architettura comprovata".
Domanda: chi paga per l'apprendimento della nuova architettura?
Risposta: Ah ah. Non c'è una buona risposta. Quindi, fai attenzione a quanta formazione architettonica fai mentre hai degli sprint di sviluppo in corso.
Se non si dispone di un'architettura che (a) funziona e (b) può essere articolata da quasi tutti i membri del team, si passerà il tempo ad assemblare quell'architettura.
Quali sono i tempi e i costi di creazione di un'architettura per il tuo primo sprint?
È necessario integrare lo sviluppo dell'architettura nel primo sprint, ritardando le cose.
Supponiamo che tu decida di implementare uno stack LAMP. Non sai se unire PHP, Perl o Python. Quindi ne scegli uno. Come Python. E prometti il primo sprint in quattro settimane. Quindi lavori per 3 settimane alle prese con i moduli add-one di kabillion e le strutture. Dopo 3 settimane, pensi di avere uno stack tecnologico funzionante, ma non hai lo sprint promesso.
Ritardi?Se è così, tutti ti chiedono se hai il ritmo giusto e inizia a raddoppiare il tempo per tutti gli altri sprint.
Non consegnare nulla? Se è così, qual è il punto dello sprint se non hai nulla alla fine tranne l'infrastruttura?
È possibile modificare, modificare e migliorare l'infrastruttura - in pezzi gestibili. Ma per costruire una nuova architettura, provare i pezzi, addestrare tutti e sviluppare le migliori pratiche richiede tempo. Molto. E quella volta non dovrebbe - davvero - essere addebitata come tempo di sprint per creare un prodotto consegnabile. È tempo di overhead.
Modifica. Tooling.
Regola 1. I processi agili non utilizzano molti strumenti e processi complessi. Ecco perché ho detto che il processo è molto "negoziazione". Qualunque cosa ti renda produttivi.
Norma 2. Non pensarci troppo. Fallo.
La maggior parte della gente dice - nel modo più forte possibile - usa 5 "x8" carte di carta e attaccale al muro. Sul serio. Niente strumenti Semplice carta, pennarelli, nastro adesivo e spazio vuoto.
Leggi questo: http://www.agilemodeling.com/artifacts/userStory.htm
È possibile utilizzare un foglio di calcolo per raccogliere le storie degli utenti (e le epopee - storie che devono essere decomposto). È possibile aggiungere colonne per complessità (story point), costi, priorità e release e utilizzarle per la gestione dei progetti.
Usiamo i casi d'uso (non le storie degli utenti) ma gli strumenti sono gli stessi. Un caso d'uso è - in un certo senso - una user story con più dettagli in primo piano. Ma il nome del caso d'uso può riassumere come un attore interagisce con un sistema; l'interazione di solito può essere riassunta con nomi chiari e semplici e un verbo, che è molto simile a una storia di un utente.
I fogli di calcolo sembrano utili perché è possibile riorganizzare le righe alla fine di ogni sprint. Puoi fare semplici conteggi e somme per calcolare quanto costano ciascuna funzionalità e quando arriveranno.
Non uso un foglio di calcolo perché, nonostante la luminosità della GUI, lo trovo un po 'macchinoso. Ritenerei necessario scrivere un estrattore di fogli di calcolo che trasformasse il backlog da un file Org di Open Office in ReStructuredText (RST). Preferisco RST - markup di testo normale - su fogli di calcolo.
Questa è una trattativa protratta. Tutto cambia come risultato di ogni conversazione. Questo è il punto di un metodo Agile. Sprint veloce seguito da una negoziazione sulla direzione dello sprint successivo.
Il nostro backlog è un grande documento RST. Pubblichiamo tutta la nostra documentazione usando Sphinx ed è molto, molto semplice scrivere backlog, utilizzare casi, architettura, design, ecc. Nella marcatura RST.
I nostri sprint sono semplicemente sezioni di un grande albero di documenti. Sono decorati con alcuni campi di testo interpretati in modo speciale per le cose soggettive come la data di completamento stimata e lo stato (in corso, rilasciato).
Sto votando per chiudere questa domanda come off-topic perché non si tratta di programmazione. –