Agile per lo sviluppatore solo

In che modo qualcuno implementerebbe i concetti di processo Agile come sviluppatore solista? Agile sembra utile per sviluppare applicazioni ad un ritmo più veloce, ma sembra anche molto orientato al team ...

• Effettuando uno sviluppo guidato dai test
• Sviluppandosi 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 ricordo dove l'ho trovata.

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

• Conservare un backlog di prodotto
  Un backlog di prodotto è fondamentalmente un elenco di tutti gli articoli che si intende completare a un certo punto per questo prodotto.
• Mantenimento di un burndown dello sprint e di un burndown del prodotto
  Un burndown dello sprint inizia con un elenco di tutte le attività che hai deciso di completare in questo sprint (un sottoinsieme del backlog del prodotto da completare in un determinato periodo di tempo, ad esempio 2 settimane) insieme a la stima del lavoro richiesto. Quando contrassegni le cose, le contrassegni come fatte; riducendo così (o bruciando) il lavoro rimanente per quello sprint.
  Allo stesso modo, un burndown del prodotto tiene traccia del lavoro rimanente per l'intero arretrato del prodotto
• Adozione dei concetti di stima relativa e velocità
  La stima relativa è una tecnica di stima che utilizza gli altri compiti (o storie) come guida. Ad esempio, se si conosce l'attività A è più semplice dell'attività B e circa il doppio rispetto all'attività C, si dovrebbe assicurarsi che i "punti" per l'attività A siano corretti rispetto a tali aspettative.
  L'enfasi non è sull'indovinare correttamente la quantità di lavoro richiesta, ma mantenendo le stime coerenti tra loro.
  La velocità è una misura di quanti "punti" si ottengono in uno sprint. Se la tua stima relativa garantisce coerenza, questa velocità può essere utilizzata per stimare quali attività potresti svolgere nei prossimi sprint. Nota che la velocità dovrebbe essere costantemente rivista.

• Limitare i lavori in corso (oltre al time-boxing). Anche se usi un metodo iterativo (al contrario di Kanban), supponiamo che la tua velocità sia di 8 punti per iterazione. Non iniziare a lavorare su tutti e 8 contemporaneamente. Limitare il WIP in base al numero di storie o ai punti della storia va bene.
• Avere test di accettazione automatizzati per tutte le storie degli utenti. Automatizza il più possibile in generale.
• Err dal lato di rendere le storie degli utenti troppo piccole. Come regola generale, fai il rapporto tra la storia più grande e quella più piccola 3: 1 . Se sottovaluti una storia in Scrum e risulta troppo grande, più sviluppatori possono sciamarla per riportarla in pista. Ma non hai abbastanza persone.
• Se, in un contesto di squadra di dimensioni regolari, esiterai a dividere un picco da una storia utente - nel contesto da solo o in piccoli team, esegui il picco senza esitazione. Questo aiuta a mantenere le storie più piccole e più prevedibili.
• Le retrospettive sono importanti in termini di agilità 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 a situazioni sia da soli che in piccoli team (2 o 3 sviluppatori).

AGGIUNTO: poco dopo aver scritto questa risposta, ho trovato questa conferenza e sono rimasto molto colpito: Kanban personale: ottimizzazione del codificatore individuale

• Lavorare con sprint ben definiti o scegliere deliberatamente un approccio Kanban. Non finire accidentalmente in Kanban
• Prima i bug, poi i secondi.
• Mantieni ancora un focus sul valore rispetto alla funzionalità. (YAGNI su placcatura in oro)
• Le retrospettive sono altrettanto preziose. E altrettanto importante, apportare modifiche al processo in piccoli pezzi. Non decidere che oggi inizierai a utilizzare TDD, Mock e IoC in un colpo solo a meno che tu non abbia davvero funzionalità esterne per fornire ATM. Portane uno alla volta.

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

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

I processi agili sono altamente iterativi. Il lavoro viene svolto in brevi TimeBox / sprint / cicli / iterazioni. Alcuni lavori di progettazione possono essere richiesti in anticipo, ma possono essere sottoposti a refactoring man mano che apprendi di più su ciò che ti serve un sistema. Il test unitario è 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 spezzeranno la base di codice esistente.

Se aderisci a BDD / TDD, consenti alle tue esigenze di cambiare con il vento e puoi adattare di conseguenza le priorità delle tue funzioni, se costruisci l'intero sistema ed esegui spesso tutti i test e se consegni il codice di lavoro alla fine di ogni sprint , sei già agile.

Wow. Proverei a tenere un amico all'amo che potrei chiamare quando ero nei guai - e parlare attraverso il problema di codifica. Sai cosa intendo ... solo l'atto di spiegare ad alta voce un problema mi fa venire in mente una soluzione il 90% delle volte.