Agile - Cosa stiamo facendo di sbagliato?

Sono uno sviluppatore di un team agile e proviamo a usare Scrum.

Quindi metterò qui un ipotetico problema per illustrare la situazione.

Abbiamo un'app molto vecchia, che utilizza un codice JQuery disordinato e di cattiva manutenzione. Abbiamo anche parti dell'app che usano React e quelle parti sono molto più facili da aggiornare / mantenere. Oltre a ciò, l'obiettivo dell'azienda è quello di creare un'app per client a pagina singola, su React, quindi l'utilizzo di JQuery ti allontana ulteriormente.

Quando facciamo la pianificazione, cerchiamo sempre la soluzione semplice in termini di tempo di sviluppo, quindi ad esempio se stiamo facendo una nuova finestra di dialogo o qualcosa del genere, utilizziamo il vecchio JQuery perché è più veloce e diciamo che torniamo indietro più tardi per riordinare e trasformare in React, ma ciò accade raramente.

Otteniamo i requisiti di ciò che dobbiamo fare dalle storie degli utenti (che sono ben fatte IMO, sono magre ma spiegano cosa stiamo facendo e perché lo stiamo facendo).

A volte, i requisiti delle nuove funzionalità sono molto ridotti, quindi per esempio se un requisito dice "crea una finestra di dialogo che carica tonnellate di contenuti" ma non dice di implementare una funzione di caricamento, nella maggior parte dei casi non la implementeremo , anche se sappiamo tutti che sarebbe meglio per i clienti, con la ragione che ciò potrebbe compromettere il nostro obiettivo di sprint (anche se personalmente credo che non lo farebbe).

Il risultato è che la nostra base di codice è un gran casino con una cattiva manutenibilità e le nuove funzionalità a volte sono molto piccole e richiedono uno sprint completo (qualcosa che potrebbe essere ottenuto in un solo giorno in una buona base di codice) principalmente a causa di questo sviluppo strategia, vai veloce, fai il minimo.

In questo caso, cosa stiamo facendo di sbagliato? Dovremmo affrontare le soluzioni in un modo più completo in modo da non scrivere mai codice errato e riscrivere il codice che abbiamo appena scritto la scorsa settimana? O dovremmo continuare a farlo solo per assicurarci che tutto quel codice venga riscritto? Quale sarebbe un buon approccio agile a questo problema?

Questo non ha nulla a che fare con Agile o Scrum.

Il problema con "canalizza il nastro ora e lo ripareremo in seguito" è che in seguito non arriva mai e nel frattempo stai accumulando molti debiti tecnici .

Il primo passo per il recupero è riconoscere il problema e smettere di peggiorarlo.

Per ogni nuova user story, il team dovrebbe considerare "qual è il modo giusto per codificare questo?", Non "qual è il modo più veloce per hackerarlo?" e pianificare gli sprint di conseguenza.

Per ripulire il problema esistente, vedi le eccellenti risposte a cui ho ereditato 200.000 righe di codice spaghetti: e adesso?

Quello che hai lì è quello che Martin Fowler chiama "mischia flacida".

Se leggi correttamente tutti e 12 i Principi alla base del Manifesto Agile , scoprirai di fallire nella maggior parte di essi.

Fornisci frequentemente software funzionante, da un paio di settimane a un paio di mesi, con una preferenza per i tempi più brevi.

Puoi dire che offri software veramente funzionante? O solo software che funziona a malapena?

I processi agili promuovono lo sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere un ritmo costante a tempo indeterminato.

Puoi dire che il tuo processo è sostenibile? Prendi delle decisioni pensando alla sostenibilità? Oppure scegli soluzioni che risolvono il problema attuale senza tener conto degli effetti a lungo termine?

L'attenzione costante all'eccellenza tecnica e al buon design aumentano l'agilità.

Il principio veramente importante. Credo che questo dovrebbe essere inserito in LETTERE ROSSE ENORMI sulla pagina. Questo è dove fallisci di più.

A intervalli regolari, il team riflette su come diventare più efficace, quindi sintonizza e regola di conseguenza il suo comportamento.

E ovviamente. Se scopri che il tuo comportamento non sta portando ai risultati desiderati, dovresti cambiarlo. Se la tua squadra non riesce a vedere che ha problemi, non può iniziare a risolverli.

Dal tuo commento

Come prevenirlo in agile?

Innanzitutto, imparando cosa è realmente agile. Scrum non è agile. Alcuni direbbero che Scrum è il peggiore dei framework agili, poiché è troppo facile raggiungere la tua situazione esatta. Dovresti conoscere altri framework agili. Quello che consiglierei è la programmazione estrema. Il che risolve chiaramente i tuoi problemi. Le soluzioni non sono semplici (attenzione all'eccellenza tecnica attraverso test automatici automatizzati, programmazione di coppie e consegna continua), ma altamente efficaci. Come riportato nel rapporto sullo stato di DevOps .

Quello che descrivi è - almeno nella mia esperienza - un modello emergente abbastanza comune di team che cercano di "essere agili". È aperto al dibattito se questo fa effettivamente parte dell'Agile stesso o di una sua errata implementazione, è contro il manifest / principi agili o una conseguenza intrinseca di esso, e così via. Solo da un punto di vista empirico e basato solo sul mio piccolo set di esperienze (e sulle persone con cui parlo), se una squadra è agile sembra avere una probabilità superiore alla media di imbattersi in questo schema. Lasciamolo e concentriamoci sul tuo esempio concreto.

Ci sono due aspetti separati in ciò che descrivi:

• Manca comprensione / visione comune e quindi non essere efficiente
• Come misurare successo / progresso e costo totale

Percorrendo la strada sbagliata o correndo in cerchio

Nella mia esperienza, il motivo principale per cui ciò accade è che nel tentativo di produrre rapidamente codice, i team mettono attivamente da parte i casi d'uso o i requisiti che già conoscono o che potrebbero facilmente conoscere. Pensala in questo modo: 10-20 anni fa, le persone hanno provato a scrivere specifiche gigantesche e pensare a tutto in anticipo e spesso hanno fallito. O impiegarono troppo tempo o trascurarono qualcosa. Uno degli apprendimenti del passato è che nello sviluppo del software ci sono cose che non si possono sapere e le cose cambiano molto, quindi l'idea di iterare rapidamente e produrre velocemente un output sensato. Qual è un ottimo principio. Ma oggi siamo all'estremo opposto: "Non mi interessa questo perché fa parte del prossimo sprint" o "Non file quel bug, lo risolvo quando si ripresenta".

1. Raccogli tutti i casi d'uso , i requisiti, le dipendenze e le restrizioni di alto livello che puoi trovare. Inseriscilo in qualche wiki in modo che tutti gli stakeholder e gli sviluppatori possano vederli. Aggiungi a loro quando arriva qualcosa di nuovo. Parla con i tuoi azionisti e utenti. Utilizzare questo come una lista di controllo durante lo sviluppo per impedire l'implementazione di cose che non contribuiscono al prodotto finale o sono soluzioni alternative / hack che risolvono un problema ma ne causano tre nuovi.
2. Formulare un concetto di alto livello . Non sto parlando di progettare interfacce o classi, ma piuttosto delineare approssimativamente il dominio del problema. Quali sono gli elementi, i meccanismi e le interazioni principali nella soluzione finale? Nel tuo caso, dovrebbe essere ovvio quando si utilizza jquery-workaround aiuta come passaggio intermedio e quando causa solo lavoro aggiuntivo.
3. Convalida il tuo concetto utilizzando l'elenco che hai raccolto. Ci sono ovvi problemi in esso? Ha senso? Esistono modi più efficienti per ottenere lo stesso valore per l'utente senza causare indebitamento tecnologico a lungo termine?

Non esagerare. Hai solo bisogno di qualcosa in modo che tutti nel team (inclusi i non sviluppatori) abbiano una comprensione comune di quale sia il percorso migliore per il tuo MVP. Tutti dovrebbero concordare sul fatto che non ci sono svantaggi ovvi e che potrebbe effettivamente funzionare. Questo in generale aiuta a prevenire i vicoli ciechi o a dover ripetere la stessa cosa più volte. Agile può aiutarti a gestire meglio gli imprevisti, non è un argomento ignorare ciò che è noto.

Siate consapevoli dell'errore sommerso : se inizi con un'architettura o un tipo di database, la maggior parte delle persone è titubante nel cambiarlo a metà progetto. Quindi è una buona idea investire un po 'di tempo nell'avere una "ipotesi migliore educata" prima di iniziare a implementare cose. Gli sviluppatori hanno la tendenza a voler scrivere codice rapidamente. Ma spesso avere un paio di beffe, prototipi live, schermate, wireframe, ecc. Consente un'iterazione ancora più veloce rispetto alla scrittura di codice. Basta essere consapevoli del fatto che ogni riga di codice scritta o anche unit test rende più difficile cambiare di nuovo il tuo concetto generale.

Misurare il successo

Un aspetto completamente separato è come misurare i progressi. Diciamo che l'obiettivo del tuo progetto è quello di costruire una torre alta 1 m usando le cose intorno. Costruire un castello di carte può essere una soluzione totalmente valida se ad esempio il time to market è più importante della stabilità. Se il tuo obiettivo è costruire qualcosa che duri, usare Lego sarebbe stato meglio. Il punto è: ciò che è considerato un hack e ciò che una soluzione elegante dipende interamente da come viene misurato il successo del progetto .

Il tuo esempio di "caricamento" è abbastanza buono. Ho avuto cose del genere in passato, in cui tutti (compresi vendite, ordini di acquisto, utenti) erano d'accordo sul fatto che fosse fastidioso. Ma non ha avuto alcun impatto sul successo del prodotto e non ha causato debiti a lungo termine. Quindi l'abbiamo lasciato cadere perché c'erano cose più preziose da fare con le risorse di sviluppo.

Il mio consiglio qui è:

1. Conserva tutto, anche piccoli bug, come biglietti nel tuo sistema di ticket . Prendi una decisione attiva su cosa rientra nell'ambito del progetto e cosa no. Crea pietre miliari o altrimenti filtra il tuo backlog in modo da avere sempre un elenco "completo" di tutto ciò che deve ancora essere fatto.
2. Hanno un ordine di importanza rigoroso e un chiaro punto di interruzione in cui il progetto potrebbe essere considerato un successo. Di quale livello di stabilità / qualità del codice / documentazione è effettivamente necessario il prodotto finale? Cerca di trascorrere ogni giorno di lavoro nel miglior modo possibile scegliendo dall'alto. Quando si lavora su un biglietto, provare a risolverlo completamente senza introdurre nuovi biglietti (a meno che non abbia senso postare le cose a causa di una priorità inferiore). Ogni impegno dovrebbe portarti avanti verso il tuo obiettivo finale, non lateralmente o all'indietro. Ma per sottolinearlo di nuovo: a volte un hack che produce lavoro aggiuntivo in seguito può ancora essere un netto positivo per il progetto!
3. Usa i tuoi PO / utenti per capire il valore dell'utente, ma fai anche capire ai tuoi sviluppatori il costo della tecnologia . I non sviluppatori in genere non possono giudicare quale sia il vero costo a lungo termine (non solo i costi di implementazione!), Quindi aiutali. Siate consapevoli del problema dell'ebollizione delle rane: molti problemi piccoli e irrilevanti possono col passare del tempo una squadra in attesa. Cerca di quantificare l'efficienza della tua squadra.
4. Tieni d'occhio l'obiettivo / i costi complessivi. Invece di pensare da uno sprint all'altro, piuttosto mantenere una mentalità di "possiamo noi come squadra fare tutto il necessario fino alla fine del progetto" . Gli Sprint sono solo un modo per scomporre le cose e avere check-points.
5. Invece di voler mostrare qualcosa in anticipo, traccia il tuo percorso sul percorso più veloce verso un prodotto minimo praticabile che può essere dato all'utente. Tuttavia, la tua strategia generale dovrebbe consentire risultati verificabili nel mezzo.

Quindi, quando qualcuno fa qualcosa che non rientra nel tuo obiettivo finale di implementazione, idealmente non considerare la storia fatta. Se è utile chiudere la storia (ad es. Per ottenere feedback dai clienti), apri immediatamente una nuova storia / bug per affrontare le carenze. Rendi trasparente che prendere scorciatoie non riduca i costi, li nasconde o li ritarda!

Il trucco qui è discutere con il costo totale del progetto: se per esempio un PO spinge a prendere scorciatoie per fissare una scadenza, quantificare la quantità di lavoro che deve essere fatto in seguito per considerare il progetto fatto!

Attenzione anche all'ottimizzazione basata su criteri : se il tuo team è misurato dal numero di storie che può mostrare in una recensione sprint, il modo migliore per ottenere un buon "punteggio" è quello di tagliare ogni storia in dieci minuscole. Se viene misurato dal numero di unit test scritti, tenderà a scrivere molti di quelli non necessari. Non contare le storie, piuttosto avere una misura di quanto funzioni la funzionalità utente necessaria, quanto è grande il costo del debito tecnologico da risolvere nell'ambito del progetto, ecc.

Sommario

Per farla breve: andare veloce e minimale è un buon approccio. Il problema è interpretare "veloce" e "minimo". Si dovrebbe sempre considerare il costo a lungo termine (a meno che non si disponga di un progetto in cui questo è irrilevante). L'uso di una scorciatoia che richiede solo 1 giorno ma produce un debito tecnologico di 1 mese dopo la data di spedizione costa alla tua azienda più di una soluzione che ha richiesto 1 settimana. Iniziare immediatamente a scrivere test sembra veloce, ma non se il tuo concetto è difettoso e cementano un approccio sbagliato.

E tieni a mente cosa significa "a lungo termine" nel tuo caso: conosco più di una società che ha fallito cercando di scrivere un ottimo codice e quindi spedito troppo tardi. Una buona architettura o un codice pulito - dal punto di vista dell'azienda - è prezioso solo se il costo per raggiungerlo è inferiore al costo di non averlo.

Spero che sia d'aiuto!

Dal punto di vista della mischia, sembra che ciò che stai facendo di sbagliato sia che non stai lavorando con il cliente. È necessario collaborare con il cliente per comprendere ciò di cui hanno bisogno e non solo ciò che desiderano . Hanno bisogno di una serie di soluzioni rapide o hanno bisogno di un sistema stabile e gestibile che li servirà a lungo termine? Ciò può essere difficile da determinare, ma la qualità è tanto un requisito quanto un colore di sfondo o un benchmark delle prestazioni. Il cliente deve essere consapevole che la stabilità e la manutenibilità non sono gratuite e devono essere ingegnerizzate nel prodotto.

Se dicono che è il primo, non stai facendo nulla di male - supponendo che stai spiegando loro nelle recensioni dello sprint che stai tagliando gli angoli di ingegneria per raggiungere i loro obiettivi.

Se dicono che è quest'ultimo, allora quello che stai facendo di sbagliato è che non stai dando loro quello che vogliono.

Uno dei cardini di Scrum è la trasparenza. Se stai facendo scrum, dovresti fare recensioni di sprint con il cliente. In quelle recensioni, stai dicendo al cliente che stai tagliando gli angoli per consegnare il software più velocemente? Se no, dovresti esserlo. È necessario essere chiari al 100% con i propri clienti sulle ramificazioni delle proprie scelte di progettazione, per dare loro la possibilità di prendere una decisione informata sul fatto che si stia offrendo il proprio software con un livello di qualità adeguato.

Ewan ha ragione. Il motivo per cui al management piace la mischia è perché possono richiedere funzionalità in stile staccato e ottenere risultati rapidamente. Fino a quando il pasticcio risultante non è un problema per qualcuno.

Ora che ho la tua attenzione, ti prego, lasciami spiegare. Non è Scrum in quanto tale. È l'impostazione tipica di un forte product manager e di un debole team di sviluppo che non è in grado di elaborare stime ragionevoli e realistiche perché avvertono la pressione. Quindi escogitano stime molto ottimistiche e si mettono più nei guai, tagliando gli angoli per consegnare in tempo.

In mischia tu (come sviluppatore) puoi fare la tua pianificazione. Nessuno ti sta dicendo di offrire alcune funzionalità in x giorni. Se qualcuno ti sta dicendo di consegnare entro x giorni, non stai facendo Scrum.

Qualunque sia il problema che deve essere risolto, richiedi il tuo tempo. Pensi di aver bisogno di tempo per rielaborare qualcosa prima? Incorporalo nel tuo preventivo. Puoi permetterti di farlo?

Esaminiamo cosa stai facendo, mettendo da parte Agile per un momento.

Quando facciamo la pianificazione, cerchiamo sempre la soluzione semplice in termini di tempo di sviluppo, quindi per esempio se stiamo facendo una nuova finestra di dialogo o qualcosa del genere, usiamo il vecchio jquery perché è più veloce e diciamo che torneremo più tardi a riordinare e trasformare in reagire, ma ciò accade raramente.

Questo si chiama "Assunzione di debito tecnico". Martin Fowler descrisse il "Quadrante del debito tecnico" in un suo post sul blog lungo i due assi: "Reckless vs. Prudent" e "Deliberate vs. Inadvertent".

Decidi esplicitamente di utilizzare il noto jquery della vecchia tecnologia che ti allontana da uno dei tuoi obiettivi espressi (vale a dire un'app a pagina singola). Lo fai per consegnare "rapidamente". Questo è deliberato.

Ciò che questo calcolo di "rapidamente" non include è il tempo necessario per implementare la funzionalità in seguito. Scegli un'alternativa che ha solo degli svantaggi rispetto all'alternativa che conosci per essere quella corretta (vale a dire prendere il tempo per implementare la funzione in reagire) sulla base di una valutazione che la velocità è essenziale. Questo è spericolato.

Martin Fowler riassume questo tipo di debito in "Non abbiamo tempo per il design". Questa è una scelta appropriata in un ambiente in cui non ti aspetti di mantenere il codice o addirittura non ti aspetti di codificare per più di qualche giorno. Ma il tuo progetto è un progetto di lunga durata che prevede esplicitamente la manutenzione per i tuoi clienti

Quello che stai facendo è sbagliato a livello di base. È una cattiva ingegneria !

Hai assunto un debito tecnico, ignorando che questo debito deve essere rimborsato e addebita interessi. E hai continuato a farlo fino a quando il tasso di interesse sul tuo debito ha iniziato a chiudersi sul lavoro disponibile durante lo sprint.

Quello che dovresti fare è ridurre il livello del debito . Parla con il tuo capo, parla con il tuo cliente. Devi lavorare sulla manutenibilità ieri.

Basta smettere di usare Agile ...

O meglio, smetti di provare a fare qualcosa in un certo modo puramente perché questo è ciò che (la tua comprensione di) agile (o mischia ecc ...) impone. Cercare di applicare una (errata) interpretazione di uno di questi termini a un progetto nella fase sbagliata può rapidamente diventare il peggior modo di agire. Usa invece la tua ragione.

Il motivo per cui il tuo progetto, e quasi ogni altro progetto al mondo, è un caos di codice e approcci divergenti, è dovuto alla mancanza di un design architettonico centralizzato e onnisciente (lì, l'ho detto).

Le ragioni che potrebbero mancare sono:

• L'architetto non ha l'esperienza (come i tuoi primi dieci progetti di hobby)
• L'architetto non ha tempo
• L'architetto non ha il potere (il manager dice di no o sì, ma solo per alcune parti)
• Il team ha fiducia in una metodologia vudù che li salverà (si risolverà da sola perché stiamo usando Agile)

La semplice soluzione è eliminare tutte queste parole magiche e guardare la realtà della situazione, che può essere riassunta come:

1. Lo stato del codice impedisce la capacità del team di consegnare in tempo e senza errori.
2. Più funzionalità aggiungiamo, peggio diventerà.
3. Quindi ha davvero senso mettere in pausa, rivalutare e (forse drasticamente) ridisegnare le parti.

Verrai naturalmente a chiederti perché sia ​​arrivato a questo stato in primo luogo, con il dito della colpa che gira e rigira. La risposta è che questo è inevitabile: man mano che il tuo progetto matura ti rendi conto che avresti dovuto farlo diversamente, ma non avresti potuto prevederlo. Inoltre, questa non è una realizzazione una volta per progetto, accadrà più volte e dovrai pianificarla.

Detto questo, ci sono molte cose che i manager possono fare per esacerbare le cose:

1. Deathmarching i tuoi sviluppatori alle scadenze.
2. Affermare che gli sviluppatori possono registrare il tempo solo contro i biglietti, senza che ci siano biglietti per "pensiero, consolidamento e refactoring di qualità" e una generosa indennità di tempo su quelli.
3. Non dare a nessuno la proprietà dell'architettura per il tempo necessario a controllarla
4. Non consentire a quella persona di apportare le modifiche che ritengono necessarie

Guardandolo in questo modo, è facile vedere come alcune interpretazioni di Agile & Scrum ti guideranno su questa strada ancora più velocemente!

Un approccio è quello di creare ticket per ogni bit di refactoring. Il problema è che spesso non ti rendi conto di aver bisogno di un grande refactor fino a quando non inizi a lavorare su un biglietto più piccolo, che riporta indietro le scadenze e il biglietto passa attraverso i cicli di approvazione che rallenta tutto.

Un altro approccio è pianificare gli sprint per utilizzare solo il 25-50% della capacità della tua squadra. Gli sviluppatori registrano quindi il loro tempo sui ticket reali (registra il tempo che avrebbe dovuto impiegare senza refactoring) e il tempo di refactoring (un ticket grande per la settimana, nessun loop di approvazione, solo discussione tra gli sviluppatori). Se non c'è refactoring, puoi estrarre i biglietti dallo sprint della prossima settimana. Regoli il cursore percentuale per le prossime settimane man mano che il codice sottostante del progetto migliora.

Quindi, per rispondere "cosa stiamo facendo di sbagliato", direi che stai affidando una metodologia al buon senso. Chiedete persino un "approccio agile a questo problema" . Direi di abbandonare le parole e pensare al problema reale. Se poi vuoi davvero separare i vari manifest cercando di decifrare se il tuo ultimo approccio di buonsenso cade davvero sotto le sembianze di "agile" o "mischia", provalo sicuramente :-)

Non stai facendo niente di male. Questo tipo di metodologia è progettato per fornire funzionalità alle specifiche e il più rapidamente possibile.

Se hai obiettivi secondari a cui stai lavorando, è meglio esprimerli come "requisiti non funzionali" o una "definizione di fatto".

ad esempio, potresti avere un requisito non funzionale:

"Tutte le nuove funzionalità devono essere scritte in React"

e

"Tutte le chiamate asincrone devono implementare uno spinner di caricamento e la gestione degli errori"

Devi solo convincere il tuo Product Owner (o equivalente) a concordare sul fatto che queste sono cose che vale la pena fare, piuttosto che intrufolarle perché agli sviluppatori piacciono.