Strumenti per aiutare il team di Agile a fornire valore [chiuso]

Senza rimodellare tutta la letteratura là fuori per quanto riguarda l'organizzazione agile, dirò solo, a mio parere, è il più importante per un progetto Agile di successo:

• Comunicazione Potresti averlo letto da qualche parte, è la verità: l'agilità riguarda la comunicazione. Tutto si basa sul fatto che ricevi frequenti aggiornamenti dagli utenti (se sono effettivamente coinvolti nella stesura di una storia, e forse anche nel progettare test di accettazione, è ancora meglio), ma anche dare loro frequente feeback (rilascio dopo ogni iterazione) e anche comunicazione all'interno del team : paia di programmazione, stand-up quotidiano, riunioni di pianificazione dell'iterazione, riunioni retrospettive, ecc. Ho trovato che un valore inestimabile lo strumento per la comunicazione è il storyboard : nonostante tutti i nostri tentativi per le versioni online, siamo sempre tornati a un forum fisico. Non c'è niente di meglio che essere in grado di gestire manualmente le carte per spostarle, selezionarle quando ci si sta lavorando e avere la riunione in piedi intorno alla lavagna dove tutti possono vedere di cosa parlano le persone e decidere cosa fare per il giorno .

• In termini di sviluppo , il più importante è testing . Mirare ad una copertura molto alta (idealmente al 100%, ma la più importante è la copertura funzionale), questo è l'unico modo per abilitare il refactoring (fondamentale in dev agile) in modo sicuro ed efficiente. La copertura del test ideale prevede tre livelli di test:

  • Test di accettazione (idealmente scritti dagli utenti) forse usando qualcosa come JBehave o FITness per dare la possibilità di scrivere le storie in linguaggio naturale, mentre si corre dinamicamente contro il tuo codice di produzione. Pertanto, questi test / storia fungono anche da documentazione per il tuo progetto. Molto utile per fornire feedback visivi a utenti e visitatori e ricordare tutto ciò che il tuo codice sta facendo. ALL le storie su cui stai lavorando devono essere associate ad almeno uno di questi test, in modo che tu sappia quando il lavoro è completo su quella storia: quando il test di accettazione è (sono) ) passing.

  • Test di sistema / integrazione : si tratta di test progettati per assicurarsi che tutti i vari componenti del progetto (database, server Web, ecc.) possano interagire in modo appropriato (questo include test CRUD per le tue identità db).

  • Test unitari preferibilmente utilizzando TDD (idealmente BDD) per progettare i dettagli del sistema. Utilizzo di JUnit e di una struttura di simulazione (il mio preferito è JMock v2 )

E anche

• Flessibilità . Non cercare di seguire ciecamente XP o Scrum come scritto nei libri. Prova diversi approcci, per un paio di settimane ogni volta, vedi cosa funziona con il tuo team e aumenta la tua produttività, e non aver paura di adottare o respingere le pratiche. Riguarda il pragmatismo e ciò che funziona con la tua squadra. Per esempio, sono stato in un progetto in cui abbiamo cambiato coppia ogni giorno, ogni due giorni e anche ogni due ore. Ciò che è meglio per te dipenderà dalla velocità del tuo progetto, dai tuoi utenti e dagli sviluppatori del team. Prova tutto, poi decidi. E sentiti libero di cambiare ogni volta che ritieni che sia un vantaggio farlo. Utilizza riunioni retrospettive (ogni mese o paio di mesi) per discutere cosa funziona e cosa no e ottenere feedback da tutti. È molto importante discutere di come le varie pratiche sono percepite dal team. Invita alcuni utenti e alcuni osservatori esterni a questi. È incredibile come qualcuno che non sa nulla del tuo progetto possa a volte contribuire e portare un punto di vista fresco molto interessante su un problema che potresti avere.

Un altro paio di cose che ci hanno servito bene in passato:

• Conserva sempre un documento note di rilascio molto dettagliato. Idealmente disponibile per i tuoi utenti come riferimento (attraverso un sito Web o un wiki), mostra cosa è andato in una versione di rilascio dopo l'iterazione. Collegati a quel documento tutte le volte che puoi. Un progetto agile si evolve molto rapidamente (se si rilascia dopo ogni iterazione) e talvolta confonde gli utenti oi sistemi correlati, che non sono abituati a quel ritmo per le versioni e si aspettano versioni "big bang" meno frequenti. Educali.

• Favorisci sempre un approccio flessibile (basato su fogli di calcolo?) per misure e rapporti: un grafico di burndown è molto bello da mantenere ogni giorno e disponibile durante gli standup, per vedere quanto sei bravo a stimare le storie (è < strong> non una misura della produttività degli sviluppatori, in XP si presume che tutti facciano il meglio che possono)

Usiamo una combinazione di FogBugz e l'eccellente scheda Kanban di Stefan Rusek. FogBugz gestisce il monitoraggio dei ticket, i grafici di burndown (e molto altro) e recentemente hanno aggiunto il forno, che è un Mercurial integrato e ospitato.

• link

Inoltre, anche se non l'ho ancora provato, capisco che alcune persone intelligenti di Java che conosco sono interessate a JBehave, un framework BDD per Java.

• link

Sono pienamente d'accordo con la risposta molto più approfondita di @Guillaume. Aggiungerei comunque una cosa, anche se sono a rischio di affermare l'ovvio:

Affinché funzioni con agilità, devi scrivere storie di utenti per esprimere la funzionalità che desideri. Forse quello che voglio dire è che non si può lasciare che le persone scrivano solo le specifiche funzionali della vecchia scuola e si aspettino che funzioni agile. La storia dell'utente è davvero il mattone di base per tutta la faccenda.