Sommario:
Essere un team di sviluppo software agile significa certamente cose diverse per persone diverse. Ci sono gradi di adozione in uno spettro molto ampio, con apparentemente pochissime organizzazioni che pensano di farlo bene. Secondo il sondaggio State of Agile di VersionOne (pubblicato nell'aprile 2017), l'80% degli intervistati afferma di essere "pari o inferiore a un livello ancora in fase di maturazione". Sfortunatamente, i team di sviluppo spesso non si impegnano molto nella parte "apprendi" dell'iterazione. Vogliamo sbrigarci e portare a termine le cerimonie di Scrum in modo da poter tornare a scrivere il codice. Dopotutto, c'è così tanto lavoro da fare! Ma il problema è davvero un tempo di codifica insufficiente?
Per molti di noi, la lotta agli incendi potrebbe anche essere specificatamente elencata nella nostra descrizione del lavoro. Andiamo a lavorare ogni giorno sapendo che dobbiamo essere pronti a scivolare giù dal palo in un attimo, afferrare i nostri cappelli e saltare sul camion. Lo accettiamo per come stanno le cose e presumiamo che non ci sia nulla che possiamo fare al riguardo. Ma cosa succede se la causa principale delle nostre lotte è una grave mancanza di efficienza? Tutti sanno quanto sia importante farlo meglio di quell'altra azienda laggiù. Sembra che non riusciamo ad arrivarci, sembra che non abbiamo la larghezza di banda. I manager aggiungono più persone e aumentano le dimensioni delle loro organizzazioni e hanno ancora le stesse difficoltà. Non riesci a superare il gobbo perché i tuoi team non stanno sviluppando software in modo efficiente (e non sei solo).
Principi per uno sviluppo efficiente
Pixabay
Allora cosa ci rende inefficienti? Per la maggior parte di noi, la prima cosa che viene in mente è la mancanza di automazione (build automatizzate, distribuzioni, test). "Una volta che avremo abbastanza automazione, la vita migliorerà." Purtroppo questa è solo una parte della soluzione. Considera l'effetto della rielaborazione sul tuo progetto. Il modo più efficiente per creare una funzionalità è costruirla correttamente una volta e non tornare mai più indietro e toccarla. Bug, refactoring e altre attività simili stanno essenzialmente riaprendo il paziente dopo che ha lasciato la sala operatoria e c'è un rischio intrinseco associato a ciò. Non possiamo eliminare la rilavorazione, ma dovremmo certamente cercare di ridurla al minimo.
"Ma l'agile non abbraccia la rielaborazione (es. Refactoring)?" In un certo senso lo fa, perché i creatori di agile hanno capito che due cause principali di rilavorazione sono circostanze impreviste e mutevoli requisiti aziendali. Si scopre che gli umani sono terribili nel predire il futuro. I creatori agili hanno anche capito che un enorme contributo all'inefficienza è ciò che gli sviluppatori chiamano "placcatura d'oro", comprendendo funzionalità che pensiamo che qualcuno utilizzerà anche se gli utenti finali non lo hanno mai richiesto. È come la carne di maiale per il tuo prodotto software: una completa perdita di tempo. "Non costruire una stazione spaziale quando tutto quello che chiedono è una Volvo." Quindi, le aziende hanno saggiamente iniziato a tralasciare il maiale e ad abbracciare invece il refactoring, aggiungendo funzionalità solo quando ce n'è una chiara necessità. Ma l'imprevedibilità della vita non è l'unico motore per la rielaborazione, vero?
I dettagli persi in qualsiasi fase dello sviluppo delle funzionalità alla fine faranno perdere tempo e denaro. Collaborare efficacemente in anticipo, nel tempo, ti farà risparmiare un sacco di rielaborazioni (affrontare i requisiti mancati, un design miope, ecc.). Abbiamo tutti punti ciechi e tutti abbiamo bisogno di un paio di occhi extra. Molti team di sviluppo lo adottano sul back-end durante la revisione del codice, ma dedicano molta meno energia alla collaborazione nelle prime fasi quando i problemi possono essere risolti a buon mercato e con un investimento minimo.
Quante volte hai implementato una funzionalità e hai riscontrato difetti significativi verso la fine che avrebbero dovuto essere rilevati durante le discussioni sui requisiti / progettazione? È come cercare di guidare da Atlanta a Montgomery e rendersi conto di diverse ore nel viaggio che invece sei andato accidentalmente a Birmingham. Quanto tempo è stato speso cercando di ottenere il codice giusto solo per riaprire il paziente in un secondo momento perché sono stati persi requisiti significativi? Sfruttare l'intelligenza collettiva risparmierebbe assolutamente tempo e denaro, ma invece, gli sviluppatori spesso lavorano sulle funzionalità in modo isolato.
Sciame tradizionale
Pixabay
Il brulicare tradizionale significa che il team lavora in modo collaborativo su storie con diverse persone che lavorano contemporaneamente su un piccolo elemento, abbreviando il ciclo di feedback e riducendo il tempo di completamento complessivo per l'elemento (cioè dividi e conquista). Questo è essenzialmente brulicante all'interno di ogni disciplina (sviluppatori back-end, sviluppatori dell'interfaccia utente, ecc.). Prima dell'inizio dello sviluppo, gli sviluppatori dell'interfaccia utente lavorano per identificare attività indipendenti che possono essere eseguite contemporaneamente. Discutono i punti dell'interfaccia in modo che ogni persona sappia come il loro pezzo si inserisce nel tutto. I membri del team possono quindi procedere al completamento delle attività assegnate e riunire tutto alla fine durante l'integrazione. I commit frequenti e le revisioni periodiche del codice aiutano a garantire che tutto rimanga sulle rotaie. Questo approccio richiede la collaborazione tra gli sviluppatori,che aiuta comunque a produrre un risultato finale migliore. Spesso diamo la priorità al tempo impiegato per scrivere codice (qualsiasi codice) rispetto al tempo impiegato per assicurarci di non scrivere il codice sbagliato. Quando si considera il tempo potenzialmente risparmiato, il valore diventa chiaro.
Ottenere sbloccato
Pixabay
Un altro valido approccio allo sciame è quello di concentrare il team nella fase iniziale di mitigazione della dipendenza al fine di facilitare lo sviluppo simultaneo tra le discipline. Considera il flusso di sviluppo naturale di una funzionalità dell'interfaccia utente. I tester di automazione (SDET) dipendono da un'interfaccia utente funzionante su cui eseguire il test, gli sviluppatori dell'interfaccia utente dipendono da un'API di backend funzionante e gli sviluppatori di backend dipendono dalla configurazione, dagli aggiornamenti del database e da build / distribuzioni automatiche. Pertanto, gli sviluppatori dell'interfaccia utente potrebbero non iniziare il loro lavoro fino a quando le API non saranno terminate e gli SDET potrebbero non iniziare il loro lavoro fino al completamento della funzionalità. Ogni disciplina lavora in isolamento, il che ostacola la collaborazione perché le persone con cui devi interagire sono impegnate a lavorare su altre cose.Ma cosa succederebbe se fosse possibile mitigare le dipendenze prima e consentire alle discipline di lavorare contemporaneamente sulla stessa funzionalità?
Ecco alcuni esempi:
1. Interfaccia utente funzionale distribuita con stub
Per sbloccare gli SDET, gli sviluppatori dell'interfaccia utente possono fornire loro un'interfaccia utente funzionante che funzioni quanto basta per consentire loro di scrivere test. L'integrazione dell'API backend e gli stili CSS possono ancora essere in sospeso, poiché i framework di test automatizzati come Selenium non si preoccupano se queste cose sono incompiute. Può essere tutto fumo e specchi. Sebbene possano verificarsi modifiche che causano alcune rilavorazioni, il vantaggio di iniziare i test in anticipo supera tale rischio.
2. API di backend distribuite (dati bloccati, hardcoded)
Fornire API di back-end su cui gli sviluppatori dell'interfaccia utente possono testare consente il rilevamento precoce dei problemi di integrazione tra il front-end e le API. A volte si scopre che l'API fornita non soddisfa le esigenze degli sviluppatori front-end. Potrebbero mancare intere chiamate, la firma potrebbe essere sbagliata o la struttura dei dati potrebbe avere problemi. Se c'è una disconnessione, potresti anche scoprirla presto prima che qualcosa si sia indurito.
3. Creare una versione HelloWorld di nuove applicazioni e servizi.
Se è necessario un nuovo servizio (ad es. Un microservizio), crea il repository e crea una versione "hello world" del servizio. Ciò consente alle risorse dev-ops di avviare i lavori Jenkins e gli script di distribuzione prima che il servizio venga effettivamente sviluppato.
Queste ottimizzazioni facilitano un ciclo di feedback precoce in cui qualcuno può dire "Ho bisogno di qualcosa di diverso" prima che lo sviluppo sia completo sul componente che richiede la modifica.
Avvolgendolo
È incredibilmente importante capire come abbreviare il time to market delle funzionalità su cui stiamo lavorando. L'azienda non ottiene alcun valore dall'avere un gruppo di funzionalità in corso e gli sviluppatori hanno un disperato bisogno che le funzionalità vengano implementate rapidamente in modo che i difetti possano essere risolti il più vicino possibile al punto di iniezione. Gli sviluppatori hanno anche un disperato bisogno di interagire tra loro, anche se tutto ciò che vogliono veramente è scrivere codice. È meglio per tutte le persone coinvolte, compreso l'utente finale che desidera solo un prodotto migliore. Se non glielo dai, andranno da qualche altra parte a trovarlo.
Lo sciame è uno strumento estremamente prezioso nella cassetta degli attrezzi della tua organizzazione, se le persone si prendono il tempo per imparare come farlo. Non è una struttura né un'attività, è una mentalità. Per ogni user story, i membri del team si pongono due domande:
- Come organizziamo le attività per questa storia per ottenere più persone che contribuiscono contemporaneamente?
- Qual è il minimo che devo fare per sbloccare qualcuno che mi sta aspettando?
E se il tuo team costruisse rapidamente funzionalità insieme invece di costruirne lentamente una serie in modo indipendente? Potrebbero effettivamente rispondere alle mutevoli esigenze aziendali e soddisfare le esigenze dell'azienda quando l'azienda ha bisogno che vengano soddisfatte. I concorrenti ti temerebbero: i clienti ti adorerebbero. Questa è una ricetta per un'attività di successo.
© 2017 Mike Shoemake