Nel nostro avvio, fino ad ora abbiamo lavorato con il tradizionale modello a cascata, ma vogliamo provare il nostro prossimo progetto utilizzando la metodologia Agile.
Siamo praticamente estranei all'intero processo Agile, quindi considerando questo, qual è il modo migliore per capire Agile (le risorse e un manuale pratico possono essere d'aiuto), decidere su una metodologia specifica (Scrum, ecc.), e avviarlo nel nostro prossimo progetto?
Hai detto che vuoi adottare Agile perché riduce il time-to-market e aumenta la produttività dei tuoi sviluppatori, quindi mi piacerebbe concentrarti su quegli aspetti particolari.
Tempo di commercializzazione
Nei tradizionali prodotti a cascata, le parti interessate hanno solo una possibilità di sottoscrivere i requisiti. In Agile, è possibile produrre una visione molto più piccola e quindi aggiungere ulteriori requisiti in seguito. Questo è il tuo modo migliore per arrivare sul mercato velocemente. Per fare ciò, devi assicurarti che
Quindi dovrai fare un po 'di educazione ai tuoi stakeholder. Leggi intorno a soggetti come Story Mapping e Feature Injection e parla loro di ciò che vorrebbero ottenere da Agile. Tieni presente che la certezza che hanno usato per ottenere l'analisi di Waterfall non ci sarà (se mai lo fosse!), Ma avranno più possibilità di cambiare idea e modellare la direzione del prodotto, invece.
Per le pratiche che ti aiuteranno a mantenere il codice base facile da cambiare, ti suggerisco "XP Explained" di Kent Beck. Guarda anche approfonditamente TDD, BDD e Continuous Integration and Deployment.
Avere delle vetrine per le parti interessate all'interno di un ambiente il più vicino possibile alla produzione aiuta davvero. Consiglio di farlo ogni due settimane. Se ritieni che sia molto semplice da implementare e le parti interessate desiderano un maggiore coinvolgimento, puoi ridurre le iterazioni a una settimana. Se trovi che è molto difficile da implementare, assicurati di ottenere un feedback in qualche forma ogni due settimane - anche se deve essere su una macchina per sviluppatori - quindi rilasci ogni mese o due se puoi. Mentre lo fai, scopri cosa rende la distribuzione così difficile e inizia ad automatizzarla. Se ci sono organi politici che ti impediscono di dispiegare regolarmente, scopri cosa potresti essere in grado di mostrare loro come abbinare i loro processi di gate e vedere se riesci a trasferirli in un ruolo in cui educano la squadra e controllano continuamente invece di avere un grande controlla alla fine.
Aumento della produttività
Agile non è davvero un modo per convincere gli sviluppatori a fare più lavoro in meno tempo. Invece, gli sviluppatori hanno meno rielaborazioni, meno sforzi inutili in termini di lavoro svolto "nel caso" e un approccio più collaborativo che consente loro di imparare gli uni dagli altri e dal resto del team.
Il fatto che il team abbia co-localizzato è il fattore più importante per consentire che ciò accada, IMO. Gli sviluppatori devono essere in grado di collaborare con i tester per trovare i bug in anticipo, mentre ricordano ancora come risolverli; con gli analisti in modo che possano mettere in discussione qualsiasi parte dei requisiti che non capiscono; e l'uno con l'altro in modo che possano condividere nuove idee, progetti e cose che apprendono. La maggior parte delle pratiche di XP, in particolare la programmazione della coppia, la proprietà del codice collaborativo e TDD, ridurranno i bug e quindi rielaboreranno anche.
Un avvertimento su Scrum
Questo si applica in particolare se stai usando le misure di stima e velocità.
Molto di ciò che stai per fare sarà nuovo per te, e sarà difficile trovare un inizio per quanto tempo ci vorrà. Se inizi a utilizzare le stime e le misurazioni della velocità per tenere traccia del lavoro, le stime potrebbero essere abbastanza lontane per iniziare. Questo è normale.
Scrum inoltre non impone alcuna pratica tecnica che possa aiutare a mantenere il codice facile da modificare. Per le cose che cerchi - time to market e produttività - quelle pratiche tecniche saranno essenziali . Per questo motivo, ti preghiamo di non mettere semplicemente in opera Scrum, ma anche di iniziare ad adottare l'eccellenza nel tuo lavoro di sviluppo e di rendere flessibile il tuo processo. Avrai molti vantaggi solo grazie alla qualità superiore, al codice collaborativo e ad un ambiente di apprendimento elevato.
Coaching e formazione
È molto probabile che ti imbatti in problemi. Ho incontrato solo una compagnia che si è auto-allenata da un paio di lezioni di CSM, e avevano una cultura straordinaria. Non aver paura di chiedere aiuto e leggi molto. Scrum non è l'unica metodologia là fuori e puoi ottenere idee anche da altre fonti.
Per un libro agile leggi . Consiglio vivamente di assumere qualcuno con esperienza in progetti agili. Inizia anche leggendo manifesto agile
Mi piace l'approccio delineato in Jim Shores libro .
Raccomanda che l'organizzazione trascorra un'ora al giorno, per una settimana o due, imparando i valori e le pratiche di XP. Lui lo chiama études , e l'idea è di leggere su un argomento agile e poi discuterlo in coppia mentre è in una casella di tempo per rispondere a determinate domande (come è questo nuovo per noi? un problema con esso? ecc). Alla fine le persone dovrebbero iniziare a fare grokk ed essere in grado di prendere una decisione informata se l'agile sembra una buona idea oppure no.
Personalmente ho usato questo approccio e ha funzionato molto bene. Mi piace che introduca le persone a pratiche agili (time boxing, pairing, collaborazione) che potrebbero essere solo il kick-start di cui la tua organizzazione ha bisogno.
Ho trovato molte indicazioni importanti nelle presentazioni della conferenza NDC2011: link cercare i tag Agile nella pianificazione. Per quanto riguarda come iniziare. Inizia con qualcosa di piccolo, preferibilmente un progetto che sarà destinato all'uso interno della tua organizzazione. In questo modo hai più informazioni sugli effetti e sulle scelte che devi fare per far funzionare il processo per te.
We are pretty much alien to the entire Agile process, so considering this, what is the best way to understand Agile (resources and a practical handbook can be of help), decide on a specific methodology (Scrum, etc), and start it in our next project?
Certo, fai quello che hanno detto tutti gli altri e inizia a leggere / imparare.
Oltre a ciò, non scegliere il tuo " progetto successivo ", scegli un progetto che riuscirà con i metodi agili. Per avere successo, il progetto deve essere di piccole dimensioni, avere un rischio basso, un alto valore per il cliente ed è realizzabile. Il team dovrebbe essere piccolo, co-localizzato e disposto ad abbracciare il cambiamento. Devi anche disporre di processi automatizzati (in particolare di build e test).
Una volta che hai queste cose, imposta il team per avere successo: avere un cliente entusiasta impegnato a collaborare con il team per un feedback continuo e una comunicazione aperta. Assicurati che il proprietario del prodotto sia disposto e in grado di articolare ciò di cui i clienti hanno bisogno e dare la priorità a ciò che dovrebbe essere lavorato per primo e su cosa dovrebbe essere lavorato in seguito. Quindi, chiedi al team di consegnare una build settimanale al cliente / PO per l'accettazione e il feedback.
Quello che ho descritto sopra è solo una parte di ciò che devi sapere, ma sono le parti essenziali che porteranno a un successo continuo e sostenibile.
Non iniziarei dal punto di vista "Devo fare agile".
Invece, guarda il tuo processo esistente e vedi come puoi risolvere i problemi che vedi. Il miglioramento continuo, a partire da quello che stai facendo attualmente, è la chiave IMHO.
Perché? Un sacco di processi agili "standard" non è adatto per una startup (divertente come sembra).
Invece, scegli e scegli le pratiche che ti aiutano a risolvere i tuoi problemi attuali e attacca le pratiche una per una come e quando ne hai bisogno.
A un meta livello:
A livello di pratica:
E se leggi un libro o partecipi a un corso di formazione su scrum o agile, queste sono le parti che non userebbero
Invece, farei qualcosa del genere:
Questo è tutto! Sei agile ora:)
Leggi altre domande sui tag development-process agile scrum waterfall