it-swarm.it

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 ...

136
kelleystar
  • 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.

66

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

  • Conservare un arretrato del prodotto
    Un backlog di prodotto è fondamentalmente un elenco di tutti gli articoli che intendi completare ad un certo punto per questo prodotto.
  • Mantenimento del burndown dello sprint e del 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 tuo prodotto da completare in un determinato periodo di tempo, ad esempio 2 settimane) insieme alla stima di il 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 portafoglio ordini del prodotto
  • Adozione dei concetti di stima e velocità relativa
    La stima relativa è una tecnica di stima che utilizza le altre attività (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.
39
Damovisa
  • Limita 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, crea 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 normali, 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 generale in modo agile, quindi Kanban (che sarebbe Kanban personale) ottiene qui punti extra, 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: qualche volta dopo aver scritto questa risposta, ho trovato questa conferenza e sono rimasto molto colpito: Kanban personale: ottimizzazione del codificatore individuale

21
azheglov
  • Lavorare con sprint ben definiti o scegliere deliberatamente un approccio Kanban. Non finire per caso in Kanban
  • Prima i bug, poi i secondi.
  • Continua a concentrarti 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.

Alla fine, 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".

9
MIA

Agile funziona altrettanto bene sia per gli individui che 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.

3
S.Robins

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 un problema ad alta voce porta una soluzione a mio mente il 90% delle volte.

1
codeyoung