Sfide di sviluppo agili [duplicate]

Questo è un problema della funzionalità cross di squadra. Basic Scrum si aspetta che ogni membro della squadra sia libero di fare qualsiasi cosa - in alcuni ambienti (come l'industria dei videogiochi) questo non è il caso. Riuscire con agile descrive questo esempio su UI Designer. Come descritto in altre risposte, non c'è nulla di sbagliato quando il progettista di UI lavora con una sola iterazione per discutere e preparare la progettazione per gli sviluppatori. Puoi usare lo stesso approccio per la tua situazione.

Ma se lo fai per ogni tuo ruolo specializzato perderai il punto principale di Scrum: visibilità. Se la funzionalità incrociata non funziona nel tuo ambiente, dovresti controllare un'altra metodologia agile: Kanban dovrebbe funzionare nel tuo ambiente. Se vuoi saperne di più su Kanban, ti consiglio vivamente questo libro .

C'è anche uno speciale libro sull'implementazione di Scrum nell'industria dei videogiochi, ma non l'ho letto.

La sfida è questa.

Come evitare di essere dogmatici e irriflessivi.

Agile richiede flessibilità. Non dogma

However, since SCRUM is supposed to focus on user stories, how should I split the stories

Rilascia il "SCRUM dovrebbe" mentalmente. (Scrum è una parola, cercalo, non è un acronimo. È un gioco in Rugby, tutti spingono nella stessa direzione.)

Ideally, a user story should be completed by all the team members in the same iteration

No. Non c'è "user story dovrebbe essere" ovunque in qualsiasi descrizione Agile. Finisci qualcosa che è rilasciabile. Ciò non significa che tutto è fatto in una volta e arriva magicamente al traguardo insieme. Scrum significa che alla fine di uno sprint hai qualcosa che potresti rilasciare. Forse ne hai di più. Forse hai una lista raggelata di cose pronte e cose fatte presto. Va tutto bene. Davvero.

Either way, it's the same issue as above, splitting up user story tasks.

Relax. Smettila di concentrarti su qualcosa che "dovrebbe essere Scrum".

Rompere le cose sensibilmente. Pensaci. Parla tra di voi. Elabora qualcosa di logico.

Non essere dogmatico. Non attaccare pedissequamente a qualche metodo meccanico. Stop. Pensare. Parlare. Decide.

Lo scopo di suddividere le cose in piccole storie e perseguirle in iterazioni è ottenere un feedback su quelle storie più rapidamente e limitare i lavori in corso.

In alcuni team Scrum con cui sono stato coinvolto, gli analisti hanno cercato i requisiti per la prossima iterazione mentre il team di sviluppo termina quello attuale. La tua situazione sembra simile. Farei tutto ciò che sembra più sensato e ti consentirà di ottenere il feedback più rapido sugli aspetti più rischiosi del tuo lavoro.

Potresti essere interessato a osservare alcuni dei principi di Kanban, in cui usiamo "cadenza" invece di iterazioni, in quanto ciò potrebbe aiutarti a coordinarti. Kanban si concentra anche sulla riduzione del tempo per il feedback e la limitazione del WIP, quindi a volte è un buon passo avanti per una squadra che ha superato Scrum. L' elenco Kanbandev è su Yahoo e consiglio il libro di David Anderson .

Affrontiamo un problema simile, perché il nostro lavoro richiede spesso risorse esterne (cooperazione da partner tecnologici o risorse interne come un nuovo server o una modifica alla configurazione).

Cosa facciamo:

• Creiamo attività nella storia per quelle dipendenze esterne (come "Organizza nuovo server per il test del carico" , "Esegui test con il partner tecnologico X" , "Ottieni nuova icona per il pulsante X" ). Cerchiamo quindi di iniziare a lavorare su questi compiti non appena iniziamo con la storia, nella speranza che possa essere eseguita parallelamente al nostro lavoro e che venga eseguita quando il nostro lavoro è terminato.
• A volte la dipendenza esterna è pronta nel tempo, a volte non lo è. Se non lo è, contrassegniamo la storia come "bloccata", per indicare che non possiamo continuare a lavorare su di essa a causa di fattori esterni.
• Abbiamo organizzato il nostro team board in modo tale che queste storie si distinguano, e la risoluzione dei blocchi è considerata una priorità elevata. Inoltre, esiste un elenco di bloccanti tra i team, per fornire alla direzione informazioni sulle aree in cui i team potrebbero aver bisogno di supporto.

Di solito questo funziona bene, e una storia è solo in ritardo di una o due settimane al massimo. Se il ritardo si allunga, cerchiamo di scindere la parte che richiede risorse esterne o di trovare una soluzione alternativa (come un'icona predefinita). Se non c'è modo di cavarsela senza la risorsa esterna, la storia rimane bloccata.

Ciò significa che in rari casi una storia rimane aperta per mesi. Questo è brutto, ma riflette accuratamente la realtà, quindi riteniamo che questa sia la soluzione migliore.

Nota: Usiamo il Kanban, non lo Scrum, quindi non ci sono problemi con l'incontro con gli impegni di iterazione.

scrum è un modo per sapere veramente che sei fuori sincrono in un modo più veloce che faresti diversamente. quindi ecco una formula che posso suggerire:

• Ogni giorno quando inizi a lavorare, chiama una mischia
• Ottieni un controllo su chi è dove e se non sono più sincronizzati
• Assicurati di gestire entrambi gli scenari - qualcuno è in ritardo o in ritardo. Ricorda che non vuoi fermare qualcuno che si muove velocemente. Hai bisogno di prendere impegni da quelli che sono indietro quando finiranno. E hai bisogno di assicurarti che i membri che stanno crescendo in avanti, abbiano svolto compiti che si allineano con il piano e le dipendenze generali

Non penso che dovresti considerarlo come divisione dei compiti, ma dividere la storia.

La struttura della trama che stai usando dovrebbe essere un'epica. Crea due storie per bambini, una per la codifica per la progettazione grafica e la creazione. Dare priorità alla trama grafica sopra la storia del codice in modo che possa essere elaborata almeno due settimane prima della storia del codice. Al termine di entrambi, l'Epic è terminato.

L'altro problema non è così pulito, vorrei suggerire un allenamento interfunzionale e una programmazione accoppiata. A breve termine non sembra avere senso rallentare il tuo sviluppatore 2x lavorando con membri meno esperti del team, ma dopo due o tre iterazioni vedrai un notevole aumento della produttività complessiva del team

Penso che @ S.Lott abbia davvero catturato l'essenza del problema qui, ma considerando il desiderio di Bob di mantenere l'idea delle storie degli utenti, la risposta di @JDMyers è eccellente. Vuoi suddividere un problema in blocchi gestibili, e se aiuta a creare storie genitore-figlio, fallo. E attraversare il treno così ogni membro conosce almeno un po 'le proprie aree di non-competenza. Se il tuo front-end ha più tempo, fagli sapere di più sulle tecnologie di back-end in modo che possa aiutarti in quell'area. È membro di una squadra e il team sta cercando di raggiungere l'obiettivo (cioè, rilasciare rapidamente software utilizzabile) insieme .

Per quanto riguarda le storie degli utenti, ricorda, non importa se tutte le attività per una determinata storia sono completate o meno durante una determinata iterazione. Ciò che conta è che il tuo team stia consegnando ciò che è previsto quando dovrebbe (presumendo che vengano stabilite aspettative realistiche). Assicurati che il problema reale sia compreso. È che un certo processo non sembra "giusto", o che le aspettative del business non vengono soddisfatte? Le storie agili e di utenti non sono un fine a se stesse. Sono un mezzo verso un fine, vale a dire consegnare il prodotto in modo tempestivo. Affina il tuo processo in modo che supporti il tuo obiettivo finale.