Agile per lo sviluppatore solista

• Eseguendo lo sviluppo basato su test
• Sviluppando in piccoli sprint
• Avendo molti contatti con il cliente

Ricordo di aver letto una tesi su Cowboy Development, che è essenzialmente Agile per sviluppatori solisti, ma non riesco a ricordare dove l'ho trovato.

Oltre alla risposta di klez (tutti i buoni suggerimenti), suggerirei quanto segue:

• Mantenere un backlog del prodotto
  Un backlog di prodotto è fondamentalmente un elenco di tutti gli elementi che intendi completare a un certo punto per questo prodotto.
• Gestione di un burndown dello sprint e di un burndown del prodotto
  Uno sprint burndown inizia con un elenco di tutte le attività che hai deciso di completare in questo sprint (un sottoinsieme del backlog del tuo prodotto da completare in un determinato periodo di tempo, ad esempio 2 settimane) insieme alla stima del lavoro richiesto. Quando segni le cose, le segni come completate; riducendo quindi (o bruciando) il lavoro rimanente per lo sprint.
  Allo stesso modo, un burndown del prodotto tiene traccia del lavoro rimanente per l'intero backlog del prodotto
• Adozione dei concetti di stima relativa e velocità
  La stima relativa è una tecnica di stima che utilizza le altre attività (o storie) come guida. Ad esempio, se si conosce che l'attività A è più semplice del compito B e circa due volte più complessa del compito C, ci si assicura che i "punti" per l'attività A siano corretti rispetto a tali aspettative.
  L'enfasi non è su indovinare correttamente la quantità di lavoro richiesto, ma mantenere le stime coerenti tra loro.
  La velocità è una misura di quanti "punti" si ottengono in uno sprint. Se la stima relativa garantisce coerenza, questa velocità può essere utilizzata per stimare quali attività è probabile che vengano eseguite nei prossimi sprint. Nota comunque che la velocità dovrebbe essere costantemente rivista.

• Limita lavori in corso (oltre al time-boxing). Anche se usi un metodo iterativo (al contrario di Kanban), diciamo che la tua velocità è di 8 punti per iterazione. Non iniziare a lavorare su tutti e 8 contemporaneamente. Limitare il WIP in base al numero di storie o punti della storia va bene.
• Avere test di accettazione automatici per tutte le tue storie utente. Automatizza il più possibile in generale.
• Err sul lato di rendere le storie degli utenti troppo piccole. Come regola generale, crea il rapporto tra la storia più grande e la più piccola 3: 1 . Se sottovaluti una storia in Scrum e risulta troppo grande, più sviluppatori possono scaldarla per rimetterla in pista. Ma non hai abbastanza persone.
• Se, in un contesto di squadra di dimensioni regolari, esiterei a spaccare un picco da una user story - nel contesto di assolo o di piccola squadra, fai il punto senza esitazione. Ciò aiuta a mantenere le storie più piccole e più prevedibili.
• Le Retrospettive sono importanti in generale, quindi Kanban (che sarebbe Kanban Personale) ottiene punti extra qui, perché il suo processo retrospettivo è più guidato dai dati. È difficile giocare a Triple Nickels quando non hai abbastanza persone.

Queste cose si applicano probabilmente alle situazioni in solitaria e in team (2 o 3 sviluppatori).

AGGIUNTO: qualche tempo dopo aver scritto questa risposta, ho trovato questo discorso in conferenza e sono rimasto molto colpito: Kanban personale: ottimizzazione del codificatore individuale

• Lavorare su sprint ben definiti o scegliere deliberatamente un approccio Kanban. Non finire accidentalmente in Kanban
• Prima di tutto, caratteristiche secondarie.
• Continua a focalizzare l'attenzione su valore rispetto alle funzionalità. (YAGNI over Gold Plating)
• Le retrospettive sono altrettanto preziose. E altrettanto importante, apportare modifiche al processo in piccoli blocchi. Non decidere che oggi inizierai a utilizzare TDD, Mock e IoC in un'unica operazione, a meno che tu non abbia davvero funzioni esterne per l'erogazione di ATM. Portane uno alla volta.

In definitiva, definisco Agile come "fare ciò che ha senso per la tua squadra e il tuo cliente e non aderire alle vecchie pratiche perché sembra che abbiano funzionato in passato".

Agile funziona altrettanto bene per le persone quanto per i team. Si tratta di trovare un processo che funzioni per te e di adattarti alle mutevoli circostanze una volta che il tuo progetto è già partito. Si tratta anche di offrire valore al cliente regolarmente, indipendentemente dal fatto che il software sia effettivamente "finito".

I processi agili sono altamente iterativi. Il lavoro è fatto in breve TimeBox / sprint / cicli / iterazioni. Alcuni lavori di progettazione possono essere richiesti in anticipo, ma possono essere rifattorizzati man mano che si impara di più su cosa è necessario un sistema. Il test delle unità è la spina dorsale di quasi tutti i metodi di sviluppo Agile, dandoti un'indicazione del funzionamento del tuo software, e se aggiunte / modifiche al tuo software interromperanno la base di codice esistente.

Se aderisci a BDD / TDD, consenti ai tuoi requisiti di cambiare con il vento e puoi adattare le tue priorità di funzione di conseguenza, se costruisci l'intero sistema ed esegui tutti i test spesso, e se fornisci codice funzionante alla fine di ogni sprint, sei già Agile.

Wow. Cercherò di tenere un amico al gancio che potrei chiamare quando ero nei guai e di parlare del problema di codifica. Sai cosa intendo ... solo l'atto di spiegare ad alta voce un problema porta una soluzione alla mia mente il 90% delle volte.