Controlla link

e link

Aggiornamento:
Il primo collegamento è per il Solo Google Scrum Group. Il vantaggio più ovvio di cui si parla qui è l'utilizzo di sprint con time box per gestire l'ambito e determinare la velocità del progetto, entrambe cose molto buone.

Il secondo link riguarda una discussione precedente su Stackoverflow, che potrebbe indicare che si tratta di una domanda duplicata, ma ho pensato che sarebbe stato più utile collegarci ad essa. A sua volta collega a link che contiene molti link e informazioni su come eseguire XP solo (programmazione con sans pair).

una

la dimensione minima della squadra è una

Agile è una raccolta di principi e pratiche, che scegli di personalizzare il flusso di lavoro. Se sei un one man show, scegli ciò che funziona per te.

XP / TDD funziona magnificamente per i team di un solo uomo. E puoi saltare le pratiche potenzialmente inutili delle riunioni quotidiane di stand-up e la programmazione della coppia.

Il tuo problema principale non è "andare agile", ma la documentazione. Questo articolo sulla documentazione Agile / Lean di Scott Ambler sarebbe probabilmente una lettura interessante per te e per i tuoi colleghi.

Agile non si tratta di non documentare. Si documenta ancora, è solo che si sceglie cosa e come si sta per documentare al fine di massimizzare il valore riducendo al minimo il tempo speso per crearlo. Continuerai a cogliere i requisiti, a eseguire la progettazione, a documentare le decisioni di implementazione e a disporre di una completa tracciabilità per tutto il ciclo di vita, se necessario, ma solo nella misura in cui il progetto ha bisogno. Non acquisire le informazioni e le decisioni chiave del progetto è un modo sicuro per far fallire un progetto.

Per un piccolo bonus divertente, ecco la mia versione di agile per le persone:

Le metodologie agili sono progettate per i team. Scrum di solito ha bisogno di circa 3-9 sviluppatori insieme a un Product Owner e Scrum Master (e il Product Owner e Scrum Master non dovrebbero essere la stessa persona). Extreme Programming richiede spesso 4-7 persone.

La ragione è che un certo numero di pratiche comunemente usate nelle metodologie agili tradizionali non si ridimensionano a un singolo sviluppatore. Un primo esempio di questo è l'enfasi sulla programmazione della coppia e le revisioni del codice in XP: non puoi davvero farlo con uno sviluppatore solista.

Un singolo sviluppatore può essere agile, ma dovrà essere un processo su misura. I metodi più agili richiedono una combinazione di integrazione continua, test delle unità, sviluppo basato sui test, refactoring, principi KISS e YAGNI e così via. Molti di questi sono diventati "best practice", anche su metodologie più pianificate. Non c'è motivo per cui uno sviluppatore solista non possa avvantaggiarne alcuni, purché non interferiscano con la produzione e la distribuzione del software.

Se vuoi limitare la documentazione, mi concentrerei su questo se questo ti trattenesse. La documenazione è solo un pezzo di agilità e non sembra che ci sia qualcuno nella tua azienda che saprà come implementarlo. Questo potrebbe ritardare il rilascio del codice a breve termine a causa di formazione, buy-in, aggiustamenti, ecc. I poteri che saranno saranno semplicemente buttare fuori e cercare la prossima grande panacea per i ritardi di produzione dopo un licenziamento del 90%.

Venendo da una squadra di un solo uomo (anche se si spera non per molto tempo).

Mi sforzo di raggiungere Agile per me stesso in un senso che intendo per loro essere più sviluppatori di me stesso solo per progetti futuri. Scrivo una WBS di alto livello, creo storie degli utenti, attività sotto user story, casi di test e mantieni una buona traccia dei progetti in un modo che il mio manager possa osservare e capire. Può essere un po 'macchinoso perché "so solo" nella mia testa dove sono, ma mi prendo il tempo di farlo comunque puramente per rimanere diligente per la mitica futura squadra che mi è stata promessa ma che non si è ancora verificata. Mi piacerebbe pensare che sto promuovendo buoni processi per le persone che verranno dopo di me.

La documentazione che faccio in piccole quantità e che è per lo più diagrammi di flusso e schemi di casi d'uso, ma generalmente niente di basso livello a meno che non ci sia qualcosa di veramente complicato o importante che non voglio dimenticare. Faccio anche diagrammi di distribuzione a beneficio delle persone future quando devono creare un nuovo ambiente per "formazione" o simili.

Sto insegnando a me stesso TDD lentamente, ma non l'ho ancora perfezionato, è estremamente difficile da fare in senso stretto per le applicazioni legacy senza refactoring di ampie e rischiose funzionalità. Nuove funzionalità complicate Continuo a lottare, ma continuo a mirare al 100% di copertura che è il gioco finale di TDD dopo tutto. Non posso prendere il percorso migliore per arrivarci però.

Può sicuramente essere fatto, ma soprattutto per necessità.

Perché scegliere Agile come un team one man quando invece puoi formare un unico team di cinque sviluppatori con un unico backlog di prodotti per i tuoi cinque prodotti. Prova una o due settimane di iterazioni e concentrati su un prodotto alla volta e scopri come la tua produttività migliora con cinque ingegneri che lavorano insieme come un team auto-organizzato e coeso. A seconda della frequenza con cui si pianifica di rilasciare, potrebbe essere necessario regolare la lunghezza dello sprint. Immagino che l'azienda non voglia attendere 10 settimane tra gli aggiornamenti di un prodotto, nel qual caso le lunghezze di sprint di 1 settimana potrebbero funzionare meglio. Potresti lavorare su due prodotti in un singolo sprint, ma farei del mio meglio per evitarlo, così puoi concentrarti su un singolo obiettivo del prodotto e farlo in modo produttivo e con qualità.

L'IMO con una singola persona dedicata a un singolo prodotto è probabilmente un approccio poco saggio quando ci sono cinque sviluppatori e cinque progetti in totale, indipendentemente dalla metodologia scelta.

Un sacco di pratiche agili pagano per i team > 0. Il controllo del codice sorgente e lo sviluppo senza attrito, ad esempio, pagano sempre indipendentemente da quanto sia piccola la squadra.

Questo dipende molto dal fatto che ci sia un buy-in dal lato business, o solo una cosa nuova da incolpare di gestione per lo sviluppo (che suona come la situazione, basato sulla riduzione del 90% delle dimensioni della squadra). higher visibility and more communication between team members non significa solo tra gli sviluppatori. È importante per il lato business vedere dove va il tuo tempo e impostare le priorità corrette.

Abbiamo assistito ad un enorme aumento di fiducia tra il lato business e IT della nostra azienda, perché ogni team ha ora un Product Owner che prende parte ai saldi quotidiani e vede dove va il nostro tempo, e loro Sono quelli che prendono le decisioni su ciò su cui lavoriamo in seguito. Invece dei manager costantemente bombardati da richieste, e poi lo sviluppo viene incolpato quando le cose scivolano attraverso le fessure o non c'è abbastanza tempo nel giorno per fare tutto, ora sono i Product Owner che hanno la responsabilità di stabilire le priorità e fare il decisioni su ciò che viene incluso in uno sprint.

Quindi, se c'è un impegno da parte dei proprietari dei prodotti che saranno coinvolti nel processo, allora sì, il processo Agile può essere molto efficace anche per una squadra di uno. Ma se questo è solo un altro modo per trasformare gli sviluppatori in capri espiatori, allora Agile fallirà per tutti.