Come spieghi a un team "agile" che devono ancora pianificare il software che scrivono?

Questa settimana al lavoro mi sono agitato ancora una volta. Avendo attraversato l'agile standard, TDD, la proprietà condivisa, la metodologia di sviluppo ad hoc di non pianificare nulla al di là di poche storie utente su un pezzo di carta, masticare verbalmente la coccole sulle tecnicalità di un'integrazione di terze parti fino alla nausea senza mai fare alcun reale pensando o dovuta diligenza e abbinando architettonicamente tutto il codice di produzione al primo test che viene in mente a qualcuno negli ultimi mesi, raggiungiamo la fine di un ciclo di rilascio ed ecco che la principale caratteristica visibile esternamente che stiamo sviluppando è troppo lenta per uso, buggy, diventando labirinticamente complesso e completamente inflessibile.

Durante questo processo sono stati fatti "picchi" ma mai documentati e non è mai stato prodotto un singolo progetto architettonico (non c'erano FS, quindi che diavolo eh, se non sai cosa stai sviluppando, come puoi pianificarlo o ricercarlo ?) - il progetto è passato da coppia a coppia, ognuno dei quali si è sempre concentrato su una storia per singolo utente alla volta e il risultato è stato inevitabile.

Per risolvere questo, sono uscito dal radar, sono andato (la temuta) cascata, pianificato, codificato e fondamentalmente non ho scambiato la coppia e ho provato il più possibile a lavorare da solo - concentrandomi su solide architetture e specifiche piuttosto che su unit test che arriverà dopo che tutto sarà bloccato. Il codice ora è molto meglio ed è in realtà totalmente utilizzabile, flessibile e veloce. Alcune persone sembrano aver davvero risentito del fatto che io abbia fatto questo e si sono prodigate per sabotare i miei sforzi (forse inconsciamente) perché vanno contro il santo processo di agilità.

Quindi, come sviluppatore, come spieghi al team che non è "non agile" pianificare il proprio lavoro e come si adatta la pianificazione al processo agile? (Non sto parlando dell'IPM; sto parlando di sedermi con un problema e delineare un progetto end-to-end che dice come un problema dovrebbe essere risolto in modo sufficientemente dettagliato che chiunque lavori sul problema sa cosa architettura e schemi che dovrebbero usare e dove il nuovo codice dovrebbe integrarsi nel codice esistente)

Penso (e potrei uscire di qui) che TUTTI i progetti dovrebbero avere un po 'di cascata classica: la fase iniziale di analisi e specifica è essenziale. Devi sapere cosa stai facendo e devi averlo per iscritto. Ottenere i requisiti per iscritto è difficile e richiede tempo e è facile farlo male. Ecco perché molti lo saltano - qualsiasi scusa farà: "Oh, facciamo agile, quindi non abbiamo bisogno di farlo." C'era una volta, prima di agile, era "oh, sono davvero intelligente e so come risolverlo, quindi non abbiamo bisogno di farlo." Le parole sono cambiate un po 'ma la canzone è sostanzialmente la stessa.

Questo è ovviamente tutto toro: devi sapere cosa devi fare - e una specifica è il mezzo con cui lo sviluppatore e il cliente possono comunicare ciò che è destinato.

Una volta che sai cosa devi fare, disegna un'architettura. Questa è la parte "ottenere il quadro generale giusto". Non esiste una soluzione magica qui, nessuno nel modo giusto e nessuna metodologia che ti possa aiutare. Le architetture sono la SINTESI di una soluzione e provengono da un genio ispirato in parte e da una conoscenza in parte conquistata a fatica.

Ad ognuno di questi passaggi ci sarà iterazione: trovi cose sbagliate o mancanti e vai a sistemarle. Questo è il debug. È appena fatto prima che qualsiasi codice venga scritto.

Alcuni vedono questi passaggi come noiosi o non necessari. In effetti, questi due passaggi sono i più importanti di tutti nella risoluzione di qualsiasi problema: sbagliali e tutto ciò che segue sarà sbagliato. Questi passaggi sono come le basi di un edificio: sbagliali e hai una torre pendente di Pisa.

Una volta che hai il WHAT (che è la tua specifica) e il HOW (che è l'architettura - che è un progetto di alto livello) allora hai dei compiti. Di solito molti di loro.

Riporta le attività come vuoi, assegnale come vuoi. Usa la metodologia della settimana che preferisci o che funziona per te. E fai quei compiti, sapendo dove stai andando e cosa devi fare.

Lungo la strada ci saranno tracce false, errori, problemi riscontrati con le specifiche e l'architettura. Questo suggerisce cose come: "Beh, tutta quella pianificazione era una perdita di tempo allora". Anche questo è toro. Significava solo che hai MENO insulti da affrontare in seguito. Quando trovi problemi con le cose di alto livello dei primi giorni, RISOLTI.

(E su un lato del problema qui: c'è una grande tentazione che ho visto ancora e ancora per cercare di soddisfare una specifica che è costosa, difficile o addirittura impossibile. La risposta corretta è chiedere: "La mia implementazione è rotta, o le specifiche sono rotte? "Perché se un problema può essere risolto in modo rapido ed economico modificando le specifiche, allora è quello che dovresti fare. A volte funziona con un client, a volte no. Ma non sai se non chiedere.)

Infine, devi testare. Puoi usare TDD o qualsiasi altra cosa ti piaccia, ma ciò non garantisce che alla fine hai fatto quello che hai detto che avresti fatto. Aiuta, ma non garantisce. Quindi devi fare il test finale. Ecco perché cose come la verifica e la convalida sono ancora elementi importanti nella maggior parte degli approcci alla gestione dei progetti, che si tratti dello sviluppo di software o della fabbricazione di bulldozer.

Riepilogo: sono necessarie tutte le cose noiose in anticipo. Usa cose come Agile come mezzo di consegna, ma non puoi eliminare il pensiero vecchio stile, le specifiche e il design architettonico.

[Ti aspetteresti seriamente di costruire un edificio di 25 piani mettendo sul posto 1000 operai e dicendo loro di formare squadre per fare qualche lavoro? Senza piani. Senza calcoli strutturali. Senza un progetto o una visione di come dovrebbe apparire l'edificio. E sapendo solo che si tratta di un hotel. No - non la pensavo così.]

Sono ancora sorpreso dal fatto che molte persone pensino che TDD significhi scrivere prima i test unitari. No, significa scrivere test necessari prima di scrivere il codice. Il test in realtà può essere un unit test, un test di integrazione, un test end-to-end e ovviamente un test delle prestazioni (probabilmente non scriverete test delle prestazioni prima del codice testato, ma ciò non significa che non dovreste scriverlo affatto). Il tipo necessario di test dovrebbe essere visibile dalla definizione di done per la user story. Se uno dei criteri di accettazione per la user story dice che la funzionalità dovrebbe fornire il risultato entro 500 ms con 50 utenti simultanei, la user story non può essere considerata completa fino a quando non si avrà un test delle prestazioni che dimostrerà che questi criteri di accettazione sono soddisfatti. Una volta che hai il test automatico puoi controllare ogni giorno che sta passando mentre aggiungi altre funzionalità.

Sembra più che i criteri di accettazione non siano stati definiti correttamente e per questo motivo non è stato possibile testare le prestazioni. Tuttavia può succedere che l'applicazione funzioni male una volta che la si distribuisce nell'ambiente reale e lo si utilizza sotto carico pesante, ma può sempre essere considerata come un fallimento dei requisiti (se il requisito non è definito, lo sviluppatore non lo prende in considerazione quando si lavora su il codice) o team di sviluppo (test insufficienti rispetto a requisiti definiti).

Un'altra cosa interessante è che gli sviluppatori del tuo team si stanno concentrando sulla storia di un singolo utente. Agile riguarda la comunicazione, quindi gli sviluppatori dovrebbero comunicare quali storie utente richiedono e in che modo influiscono sul resto dell'applicazione: la collaborazione è un must. Il test dovrebbe riguardare anche questo, quindi se uno sviluppatore rompe la funzionalità necessaria per un'altra user story dovrebbe essere visibile nei test automatizzati. Se ritieni ancora che non sia sufficiente o che non funzioni, puoi presentare una riunione di architettura in cui l'intero team coopera e discerne l'architettura dell'applicazione. Di solito è sufficiente tenere una riunione del genere una volta alla settimana.

Molte cose del processo a cascata vengono sostituite con comunicazioni e test automatici. Nessuno dice che non puoi scrivere documentazione o design di alto livello! Puoi e molti team usano ad esempio Wiki per questo.

[il nostro prodotto] era troppo lento da usare, difettoso, diventando labirinticamente complesso e completamente inflessibile.

Ciò non ha nulla a che fare con l'agile, è un segno che i programmatori non svolgono correttamente il loro lavoro.

Un'idea di base di agile è che il team ha il controllo completo sul processo. Ciò significa che devono concordare la quantità di pianificazione, documentazione, test e il modo in cui gestiscono il refactoring. Tutta questa potenza è eccezionale, ma ha anche responsabilità e questo è probabilmente il punto in cui la tua squadra ha fallito. Hanno accettato la loro libertà, ma hanno trascurato le loro responsabilità.

Alla fine si tratta solo di spiegare la qualità del codice e di cercare di concordare un modo per aumentarlo e mantenerlo così. Si applicano le normali pratiche di programmazione.

Suggerimento pro: usa la tua "Definizione di Fine" per farla valere. Assicurati che tutti siano d'accordo su di esso e rendilo visibile a tutti. Usalo come un guardiano rigoroso per decidere se una storia è stata completata o meno. È anche possibile aggiungere requisiti non funzionali (come le prestazioni) anche a tale elenco.

Si. I tuoi compagni di squadra sono idioti. Il tuo progetto ha fatto schifo a causa di Agile. Sentirsi meglio? Va bene, andiamo avanti. : P

Penso che tu e il tuo team sarete in grado di comunicare in modo più efficace su ciò che è andato storto se vi concentrate di meno sui nomi delle vostre metodologie Capital-M e di più sul perché il software che avete scritto fosse così lento e pieno di errori. Non usare affatto i termini Agile o cascata . Sono chiaramente caricati emotivamente nel tuo ufficio.

Agile funziona a volte. Questa volta non ha funzionato per la tua squadra. Alcune persone diranno che è perché hai sbagliato Agile. Dopotutto, Agile funziona, quindi se l'avessi fatto bene avrebbe funzionato, giusto? Qualunque cosa.

Non sembra che nessuno sia d'accordo sul fatto che ci sia stato un fallimento, ma non vincerai amici, influenzerai le persone o farai meglio la prossima volta se biasimerai una metodologia. Ciò probabilmente ha poco a che fare con ciò che è andato storto.

Invece, concentrati sull'individuazione delle cause più dirette del fallimento e lavora con il team per assicurarti che non si verifichino più. Ciò richiederà abilità delle persone.

Parlando delle abilità delle persone, non dovresti essere sorpreso dal fatto che il tuo team non ti abbia apprezzato se hai fatto brutta figura facendo tutto il loro lavoro e facendolo meglio di loro. In questo modo "sotto il radar" potresti aver danneggiato alcune relazioni che ora dovrai ricostruire per essere un membro efficace del team.

Penso che il modo migliore per guardare a una situazione come questa sia considerare l'output totale a lungo termine della squadra nel suo insieme. Questa volta potresti aver risparmiato la settimana, ma potresti aver fatto meglio nel lungo periodo per la tua azienda creando un team migliore .

Ti sto dicendo tutte queste cose, ma penso che probabilmente ne conosci già molte e potresti spiegarle a qualcun altro se non fossi così vicino a questa situazione.

Se vuoi aggiungere una citazione pithy alle tue discussioni, Eisenhower ne ha fatta una buona:

"I piani non sono nulla; la pianificazione è tutto".

http://www.brainyquote.com/quotes/quotes/d/dwightdei149111.html

Voleva dire che dovresti aspettarti di cambiare i tuoi piani e quindi non dare troppo valore al piano così com'è esistente, ma allo stesso tempo il processo di pianificazione focalizzerà drasticamente le tue energie in modo cruciale. Devi fare piani prima di poterli testare e perfezionarli.

+1 Questa è la migliore descrizione dell'impresa agile che ho letto di recente.

Tutti coloro che vanno d'accordo con l'agile sottolineano che non avrebbe mai dovuto significare questo, ma una volta che tutti vengono catturati dalle metriche questo è esattamente ciò che ottieni da un team che non ha passione per la qualità del prodotto ed è ossessionato da testare la copertura sopra ogni altra cosa o rispettare le scadenze settimanali consegnabili indipendentemente dall'angolo in cui hanno dipinto tutti gli altri perché è tutto ciò che lo rende al livello di gestione su base settimanale.

Non l'ho mai visto risolto con niente di meno che una riorganizzazione. Se sei una società di livello medio con niente di speciale per attirare persone davvero appassionate, anche questo non lo risolverà a meno che il prossimo management non cambi metodologie a volte.

Agile sembra funzionare bene solo in organizzazioni in cui il team di sviluppo si prende abbastanza cura di realizzare un buon prodotto nonostante il lavoro extra e non accreditato necessario. In effetti, devono preoccuparsi abbastanza da renderlo buono nel loro tempo libero, lottare per il miglioramento (ed essere disposti a perdere molto tempo extra a ripetere i test in alcuni casi di TDD)

Ovviamente ti interessa spedire un buon prodotto, ovviamente si preoccupano di passare attraverso una serie di movimenti con script e di ricevere una busta paga per ripulire continuamente il disordine che fanno.

Cercherei un lavoro meno irritante altrove, che sia agile o no.

Se sei completamente bruciato dall'agile, ci sono molti posti che fanno ancora altre metodologie. Quasi tutto su un'offerta o un contratto, ad esempio.

Tendo a usare una specie di ibrido. Il piano generale è a cascata, ma è agile nell'esecuzione.

La mia ipotesi è che se la situazione è grave come dici tu, la tua squadra non sta usando l'agile, sono solo pigri o indisciplinati. Agile non si tratta di non pianificare, si tratta solo di essere flessibile e, beh, agile.

Abbiamo gli stessi problemi con alcuni membri del personale.

Fondamentalmente "Non lo so fino a quando non lo scrivo" è un'affermazione preferita. Quindi abbiamo fatto il contrario, abbiamo lavorato con il cliente per definire i risultati finali con punti di approvazione. L'ultimo è "ora scrivi il codice per fare X".

Se abbiamo "scrivi design / testing / plan etc" nello stesso sprint consegnabile di "fai il codice divertente e interessante", allora la prima parte non accade mai ...

MA se inserisco "non puoi fare alcun codice divertente e interessante fino a quando non hai detto cosa stai per costruire e il cliente ha firmato"

• in primo luogo ricevi un'accettazione lamentosa, e alcune lacrime e ho dovuto fare molto il riempimento del lavoro in bianco e uno sforzo extra ...
• poi ottieni il riconoscimento nascente quando chiedi loro "così come è stato il processo" che è meglio aver tentato la prima versione su carta
• quindi hai i casi di test che gli sviluppatori possono vedere e puoi puntare esattamente all'aspettativa di "cosa significa".
• quindi i clienti firmano sullo sviluppo ha un tasso di rifiuto dell'80% in meno ...
• inoltre guardi tutti gli sviluppatori che camminano tenendo in mano i documenti di progettazione e parlando tra di loro sui progetti ... iniziano a capirlo davvero.
• Quindi scopri come suddividere il piano di progetto in blocchi di dimensioni ridotte e farne un processo.

La parte agile arriva quando il cliente poi cambia dal piano e puoi adattarti in un ciclo di 2 settimane NON volare dal sedile dei pantaloni e truccarlo lungo la strada.

Nel nostro caso il "big design upfront" è stato suddiviso in 9 fasi (uscite di produzione effettive) con una media di 5 sottostadi. I progettisti e gli sviluppatori tengono il passo l'uno con l'altro, i progettisti sono 1-3 sottostasi davanti agli sviluppatori ... troppo lontano e le scoperte nello sviluppo rompono troppo il design, troppo vicino e le modifiche per progettare costano quanto sono state già implementato "set in stone" all'interno dello sviluppo. Ogni sottostazione è di 2-4 sprint per 1 sviluppatore.

Nei progetti più piccoli abbiamo solo lo stesso sviluppatore che progetta prima> firma> fattura> sviluppa> firma> fattura ... in cicli.

Il problema di denominazione del test

Il test ha molte facce, formalmente ci sono circa 7 categorie di test ognuna con sottosezioni ... una di queste successive è "scrivere test di unità automatizzati".

È un brutto nome avere "test del primo sviluppo" esclusivamente a causa della comprensione da parte degli sviluppatori di cosa significhi "test" in questo contesto, vedono i test mentre scrivono il codice effettivo per il test sull'interfaccia per l'implementazione. Quando non è affatto così ... puoi farlo quando si tratta di scrivere il codice, ma è davvero "convalidare il design contro casi d'uso e storie utente PRIMA di iniziare a scrivere il codice" ... fatto correttamente questo rimuove molti dei problemi normalmente scoperti durante lo sviluppo mentre è ancora nella versione molto più economica "carta che può essere buttata via".

Uno degli elementi chiave di Agile è l'idea di miglioramento continuo e l'idea che l'intero team sia il proprietario del progetto. Quindi l'approccio corretto sarebbe stato quello di esaminare i problemi con il team e chiedere al team di decidere come correggerlo.

Un membro del team che se ne va da solo, abbandonando tutti i principi di Agile e facendo le cose a modo suo può comportare una piccola quantità di codice che funziona bene, ma in realtà non fa avanzare l'intero progetto in modo positivo.

Un modo per farli funzionare potrebbe essere quello di creare una T-Map che copra tutto il back-log dello sprint

Ogni squadra ha una discussione, ogni sprint è un punto. Tutto si collega (che è dove la tua squadra sembra cadere). Appuntalo da qualche parte e ottieni magneti per rappresentare le coppie / i sotto-gruppi. Possono persino "correre". Ma tutti sanno dove sono loro e le altre squadre. Metti qui le dipendenze se ce ne sono.

Il punto qui è trasmettere l'intero processo ma anche scomporlo in sprint. Anche se lì viene effettuato solo il primo sprint e gli altri periodi sono vuoti, questa dovrebbe essere una tabella di marcia eccellente per terminare il progetto.

Hai due problemi: non abbastanza forma sui requisiti e scarsa architettura.

Requisiti

Sono necessari sia un obiettivo finale complessivo sia una tabella di marcia dettagliata su come arrivarci.

Nel mondo delle cascate, l'obiettivo finale è la specifica funzionale e la tabella di marcia su come arrivarci è il piano del progetto.

Nel mondo agile, un modo è catturarlo in una storia utente epica. Quindi la roadmap sono le storie utente dettagliate che arricchiscono i dettagli dell'epopea.

Non sono mai stato completamente contento di quella storia, perché la storia epica non cattura mai abbastanza carne per farsi un'idea. Quindi quello che ho avuto la tendenza a utilizzare è un documento sui requisiti di sistema di alto livello in combinazione con una storia utente epica o due. Dopodiché, la roadmap è la user story dettagliata.

La cosa bella di avere un documento sui requisiti di sistema è che i criteri di accettazione per molte delle storie degli utenti possono essere estratti.

Pensa al documento sui requisiti di sistema di alto livello come a un "foglio singolo" che il marketing potrebbe utilizzare per vendere il prodotto a un cliente tecnicamente esperto.

Architettura

Una delle cose che ti dà il "foglio singolo" è che pone dei limiti al sistema che stai progettando. Ciò consente di prendere decisioni informate, all'inizio, sull'architettura da utilizzare.

Se il tuo team avesse avuto un documento del genere all'inizio, non dovrai affrontare il dolore di riprogettare il sistema in seguito.

In realtà, un terzo problema che hai è la scarsa comunicazione. La comunicazione è una strada a doppio senso (o a più vie tra più persone). Tuttavia, questo è solo un fallimento umano e richiede (a volte) sforzi sovrumani per ottenere il giusto.