Come dovrei passare a un ciclo di sviluppo agile / iterativo con distribuzioni di 3 settimane obbligatorie?

3

Io faccio parte di una piccola squadra di quattro persone, e sono il capo della squadra non ufficiale (sono praticamente in testa tranne il titolo). Siamo stati in gran parte un ambiente "da cowboy", senza architettura o struttura e ognuno ha fatto le proprie cose. In precedenza, le distribuzioni di produzione sarebbero avvenute ogni pochi mesi senza essere programmate, poiché le attività sono state aggiunte / rimosse all'elenco delle attività di ogni sviluppatore. Di recente, il nostro CIO (semi-tecnico ma non proprio un programmatore) ha deciso che avremo implementazioni ogni tre settimane; per questo motivo ho pensato subito che l'adozione di un processo di sviluppo iterativo (non necessariamente in fase di sviluppo Agile / XP, che sarebbe una cosa enorme per convincere tutti gli altri a fare) aiuterebbe a gestire correttamente le aspettative, quindi non c'è questa idea inverosimile che ogni nuova funzionalità verrà eseguita in tre settimane.

IMO il più grande ostacolo è che al momento non abbiamo alcun tipo di approccio allo sviluppo in atto (tra l'altro senza IC o test automatizzati di sorta). Non usiamo nemmeno Waterfall, usiamo "Dì a Developer X di fare un lavoro, aspettiamo che faccia tutto e che lo faccia".

Ci sono dei suggerimenti che potrebbero aiutarmi ad iniziare ad aiutarci verso un approccio iterativo e A) Accogliere gli altri sviluppatori con esso e B) Acquisire la gestione per capire come funziona l'iterativo? Finora la mia idea implica di provare a configurare un server CI e di automatizzare il processo di compilazione (in questo momento occorrono circa 10-20 minuti per creare semplicemente l'applicazione per metterlo sul nostro server di sviluppo), poiché spingere test e / o TDD incontriamo molta resistenza a questo punto e ci costringono costantemente a rompere i progetti più grandi in blocchi più piccoli che potrebbero essere fatti in modo iterativo in un ciclo di tre settimane; la mia unica preoccupazione è che, a meno che non stia fraintendendo, un processo agile / iterativo può o meno rilasciare il software (a seconda dello scopo del progetto si potrebbe avere software "funzionante" dopo tre settimane, ma lì non è abbastanza che funzioni per permettere agli utenti di farne uso), mentre penso che l'aspettativa qui da parte del management sia che ci sarà sempre qualcosa di "pronto all'uso" tra tre settimane, e che la disconnessione potrebbe causare problemi.

Su questa nota, ci sono pubblicazioni o riferimenti che spiegano l'approccio agile / iterativo dal punto di vista del business ? Tutto ciò che ho visto si concentra solo sugli sviluppatori, su come farlo, ma nulla sembra descriverlo dal punto di vista di ottenere effettivamente il buy-in dagli uomini d'affari.

    
posta Wayne Molina 27.05.2012 - 17:39
fonte

4 risposte

4

Stai attento. In primo luogo, perché è il tuo che chiede un ciclo di tre settimane? Scopri se non l'hai già chiesto. Questo è fondamentale perché potrebbe affrontare un problema percepito con la soluzione sbagliata. Scopri il problema specifico che sta cercando di risolvere. Sei percepito come lento ma preciso? consegnare le cose sbagliate? Consegnare le cose sbagliate in ritardo? ecc ecc.

Se sei il caposquadra non ufficiale, ora è un buon momento per iniziare a disegnare negli altri. Per prima cosa metti insieme una proposta per il capo che spiega come affronterai i problemi specifici. È importante essere una persona che può fare.

Una build CI sarà un buon punto di partenza. Ottieni uno degli altri sviluppatori per farlo. Se l'idea di far fare qualcosa a un altro sviluppatore non fa appello, dobbiamo affrontare ciò che questo team non ufficiale conduce in pratica. Potrebbe significare che sei stato usato, e lo intendo nel modo più educato possibile.

Infine parla con gli sviluppatori. Non compreranno nulla finché non parlerai con loro. Scopri cosa non apprezzano del sistema attuale e poi vendi un approccio più agile basato su come migliorerà i loro problemi.

Riguarda la comunicazione e finirò su questo. Se non riesci a far funzionare la comunicazione, a tutti i livelli, con la migliore volontà del mondo, agile non funzionerà per te. È il 90% della comunicazione e della collaborazione e il 10% di tutti gli altri bit.

    
risposta data 27.05.2012 - 17:57
fonte
3

Concentrati sulle persone e sul processo e su come interagiscono.

Questa è un'iniziativa nuova (vale la pena) per l'azienda. Ti raccomando:

  • Parla con il tuo CIO. Intendo davvero parlare. chiedi forse un incontro per il pranzo e poi esponi il tuo discorso su cose come le tue emozioni sulla compagnia, la missione, il tuo lavoro, ecc. Quindi ruota attorno alle tue preoccupazioni e quanto sei turbato e come vuoi contribuire a migliorare le cose per l'azienda in modo che tu possa dormire meglio la notte. Ascolta attentamente anche il loro tono su ciò che stanno cercando di ottenere (ascolta prima, capisci 2, chiedi / suggerisci 3)

  • Nominare un team leader per fare tutto questo. Potrebbe essere necessario essere questa persona, anche se non è la tua cosa ideale. La compagnia deve riempire formalmente la posizione per dare a quella persona l'autorità per implementare queste cose senza un sacco di domande / risentimenti / doppie ipotesi. Devono essere in grado di commettere degli errori anche durante il percorso.

  • Concentrati sugli oggetti di piccole dimensioni. Non dovrebbe essere difficile avere alcune cose ogni volta, anche se è solo cambiando la posizione del logo o correggendo un refuso. Se eri impegnato a fare un sacco di altre cose per un determinato sprint, va bene. Hai la tua riunione per lo sprint planning e poi dici perché questo è stato il caso per lo sprint passato e quali sono stati i motivi. Se stai lavorando su cose più grandi che richiedono prima l'infrastruttura, allora lo dici e guarda cosa può essere effettivamente consegnato nel prossimo sprint. Se questo accade MOLTO che le 3 settimane non sono un buon periodo, o i risultati dei tuoi sforzi non sono visibili a meno che non ci sia un componente di front-end.

  • Buona comunicazione - una parte fondamentale del compito del lead del progetto è spiegare ai proprietari e ai proprietari dei prodotti cosa sta succedendo tecnicamente, ma in termini non tecnici. Se c'è una buona comunicazione e fiducia (quelle cose richiedono tempo e impegno) funzionerà meglio.

  • Concentrati sui vantaggi che otterrai seguendo le best practice. Non significa magia o che ci saranno grandi cambiamenti ogni sprint, ma a lungo termine, l'aderenza al processo migliorerà notevolmente i risultati.

  • Chiedi agli sviluppatori se stessi su come ottenere i vari dettagli completati, una volta che il quadro generale è pronto per la gestione. Dare a tutti un compito da svolgere è parte del cambiamento. Forse una persona imposta il ci, un altro definisce il processo qa, un altro il processo di compilazione automatizzato, un altro il responsabile della pianificazione dello sprint, ecc. Per ottenere il coinvolgimento e il coinvolgimento.

risposta data 27.05.2012 - 17:54
fonte
0

Il Sviluppo agile e iterativo di Craig Larman: una guida per i gestori è una grande panoramica manageriale / aziendale di agile e sviluppo iterativo. Lo consiglio vivamente.

Oltre a questo, ho seguito @MichaelDurrant: parla di questo con il tuo CIO.

    
risposta data 28.05.2012 - 08:32
fonte
0

Wayne, in qualità di consulenti specializzati nell'adozione di Agile, devo dire che l'approccio raccomandato è quello di assumere un mentore: qualcuno che ha già svolto il processo in precedenza, e quindi sa cosa aspettarsi e se le cose stanno andando bene. Spesso le cose stanno andando bene: ma, se è la prima volta, la natura leggera di Agile ti renderà nervoso.

Michael Durrant dà alcuni ottimi consigli. Si tratta di "persone". Tuttavia, sei anche corretto per identificare la necessità di un processo. Quindi, Wayne, scegline uno e adottalo! Così semplice. Il punto è che qualsiasi processo è migliore di nessun processo. E, una volta che hai adottato un processo, puoi valutare quanto bene sta funzionando. Solo allora puoi decidere cosa modificare o modificare. Agile significa essere audaci; tuttavia, poiché eseguirai in breve iterazioni, è facile correggere eventuali errori. Essere Agile si applica tanto al tweaking del processo quanto al tweaking del software che stai sviluppando.

Per quanto riguarda la produzione di software "utilizzabile" da un ciclo di iterazione di tre settimane. Sì, è possibile. È necessario concentrarsi su requisiti misurabili. In questo modo fornirai qualcosa di significativo. Tuttavia, non si produrrà una suite software completa con l'approccio frammentario: lo sviluppo iterativo riguarda la scoperta dei riquadri (esplorazione) e la gestione dei rischi - ma, come la tua intuizione ti dice, c'è un po 'di più che semplicemente accumulare le iterazioni su uno sopra l'altro. Inoltre, mentre stai usando XP, non dimenticare la documentazione e l'estensione future del progetto. esigenze di formazione!

La maggior parte delle società di consulenza sull'adozione di Agile, come Gatethorn, fornirà alcuni consigli gratuiti a chi sta andando avanti. Non aver paura di chiamarli. Dopotutto, sappiamo solo che cosa serve ai nostri clienti rispondendo alle domande sui forum o prendendo chiamate. Quindi, Wayne, continua a tornare su questo forum se hai bisogno di aiuto.

Tutto il meglio, Richard (CEO Gatethorn Pensiero agile )

    
risposta data 30.05.2012 - 23:10
fonte

Leggi altre domande sui tag