Metodo agile per un proprietario di un prodotto non tecnico + uno sviluppatore

Non devi seguire lo Scrum completo, ma puoi sicuramente trarre vantaggio dal suo approccio iterativo incrementale che sostituirà la tua cascata.

Come cambierà il processo:

• Gli OP non dovranno definire in anticipo tutti i casi d'uso.
• Le OP definiranno solo i casi d'uso di cui sono assolutamente sicuri al momento e le daranno priorità.
• Lo sviluppatore seguirà il processo di impegno per prendere più casi d'uso più importanti alla successiva iterazione (con una lunghezza fissa).
• PO sarà in grado di verificare tali casi d'uso durante (o peggio dopo) l'iterazione.
• Lo sviluppatore consegnerà una nuova "release" dopo ogni iterazione (questo può trarre grande vantaggio da alcuni strumenti di automazione).

Professionisti della modifica:

• Migliore visibilità del processo di sviluppo
• Migliore gestione delle modifiche in cui i problemi vengono scoperti molto prima nella fase di sviluppo e possono essere indirizzati immediatamente alla successiva iterazione senza effetti cumulativi (aggiungendo più funzionalità in base a funzionalità implementate in modo errato)
• Consegna incrementale in cui, dopo ogni sviluppatore iterativo, è necessario fornire prodotti funzionanti con nuove funzionalità
• Le funzionalità più importanti verranno fornite più rapidamente e saranno quindi più utilizzate durante lo sviluppo / test del resto del prodotto = potrebbero esserci più feedback sulla loro usabilità a lungo termine

Contro del cambiamento:

• Gli OP dovranno accettare un nuovo modello e comunicare continuamente con lo sviluppatore. Se le OP non sono disposte a partecipare allo sviluppo e forniscono feedback e chiarimenti continui + convalidano i casi d'uso il più presto possibile, puoi rinunciare a qualsiasi tentativo di cambiamento.
• Gli OP dovranno cambiare il modo in cui definiscono i casi d'uso. I casi d'uso dovranno essere abbastanza piccoli per l'iterazione e dovranno essere indipendenti il più possibile. Se lo sviluppatore deve lavorare su cinque casi d'uso contemporaneamente per completarli tutti, non funzionerà.

Il punto principale del cambiamento: se vuoi essere agile, devi avere molto spesso feedback (piccole iterazioni con consegna incrementale del prodotto funzionante) e devi avere molta più comunicazione tra sviluppatore e PO.

In un unico ambiente di sviluppo le cose fondamentali sono:

Source control
Continuous build server
Task/bug tracking system
Defined sprints
Unit tests
Code coverage
Independent testing in parallel to development

Questo ti renderà abbastanza agile senza rispettare la definizione rigorosa di una delle metodologie documentate. Se i team crescono, guarda gli aspetti comunicativi di come funziona il team.

Scrum è eccessivo, ma Agile è più naturale per i piccoli team, anche per i team di una sola persona. Il punto di Agile è la creazione di un backlog di storie utente in anticipo che descrivano accuratamente i casi d'uso del cliente.

Prima dell'inizio di ogni sprint, priorità e LOE (livello di sforzo o punti) sono determinati per le storie degli utenti e in base a ciò che è possibile nel periodo di sprint di 2-3 settimane, le storie degli utenti vengono aggiunte allo sprint.

Alla fine dello sprint, tutte le user story dovrebbero essere sviluppate e testate e l'aspetto più importante di tutte è che tutte le funzionalità degli sprint precedenti non dovrebbero essere influenzate e il software non dovrebbe essere lasciato alla fine dello sprint in uno stato rotto.

Ha senso rilasciare al client dopo ogni sprint? No, non è così e questo è un malinteso comune di Agile che vedo sempre. Incontro pochi clienti che desiderano un rilascio di lavoro dopo ogni sprint. Ad esempio, alcuni potrebbero volere un rilascio ogni tre mesi e, se Agile viene seguito, l'ultimo sprint rilasciato dovrebbe essere sempre in uno stato utilizzabile in cui è possibile preparare un rilascio per il client su un intervallo regolare. Alcuni clienti potrebbero anche desiderare un ambiente in cui possano autorizzare, dimostrare e valutare l'ultimo sprint in modo che possano essere aggiornati sull'avanzamento in tempo reale del progetto.

E le sfide di fornire software in uno stato utilizzabile nei primi sprint di un nuovo progetto? I primi sprint di un nuovo progetto possono essere una grande sfida perché la quantità di architettura e il lavoro di progettazione, nonché il lavoro di fondazione che deve verificarsi, ha sempre dei picchi all'inizio di un nuovo progetto e diminuisce gradualmente durante lo sviluppo.

Questo può essere affrontato in diversi modi, molti negozi useranno l'arretrato iniziale di storie di utenti per fare e documentare le decisioni fondamentali dell'architettura prima che inizi il primo sprint. Altre volte il progetto è invisibile per essere strutturalmente simile ad altri progetti precedenti e viene utilizzato un modello di progetto che getta le basi per la progettazione di base e lo sviluppo futuro. Ho anche lavorato a team in cui il team di architettura inizia a dare il via al progetto con un Preambolo di 2-3 settimane prima che il primo sprint inizi ufficialmente. Il primo sprint può iniziare in piccolo, anche per gli sviluppatori, per un'applicazione CRUD tipica. Mi piace sempre iniziare con una pagina di accesso e un'autenticazione. È facile da avviare, definisce chiaramente cosa è finito e può essere chiaramente testato dal QA nelle prime fasi del progetto.

EDIT: così come questo aiuta il cliente a fare in modo che le modifiche possano essere apportate alle storie degli utenti lungo tutto il processo e questo può riflettere in timeline modificate, stime, tempi di risposta più rapidi per il cliente, più feedback a il cliente e più trasparenza per il cliente. Ciò ti consente di essere più agile nell'affrontare le modifiche all'ambito originale nel bel mezzo di un progetto.