Mentalità agile vs meccanismi agili

https://flic.kr/p/bkcj5q

Trovo ripetutamente che i team di software si concentrano troppo sui meccanismi e perdono di vista il principio di base. Ciò è particolarmente vero per le metodologie Agile. Metodi come Scrum hanno così tanti meccanismi che i nuovi agili si perdono completamente. Inizialmente l'ho scritto come e-mail al mio team per chiarire quale fosse la mia visione di Agile, ma ora l'ho inviata a così tante persone, che seguendo il consiglio di Scott Hanselman, lo sto trasformando in un post sul blog.

Mi considero in qualche modo qualificato per fornire questa intuizione. Sono un praticante agile dai tempi in cui lo sviluppo Agile comportava l'uso di un cacciavite - per smantellare i tuoi cubicoli e creare un piano di posti a sedere aperto!

All'inizio della mia carriera ho lavorato con una società di software medico. Abbiamo creato un software desktop per la revisione delle immagini installato sul desktop di Doctor negli ospedali. Il processo di distribuzione prevedeva il viaggio con i CD in un'altra città e l'installazione dei desktop e dei server di immagini. Eravamo soggetti all'approvazione della FDA, quindi abbiamo dovuto costruire su specifiche che erano state approvate dalla FDA. Ciò ha creato un ambiente ideale per la metodologia a cascata dall'alto verso il basso. Tutte le specifiche sono state scritte, approvate, approvate e abbiamo creato solo quelle specifiche e quelle specifiche. Non è stato fino a quando il team di sviluppo ha iniziato a viaggiare con il team di installazione e guardando i medici che utilizzano il nostro software, ci siamo resi conto che potevamo fare molto meglio solo se avessimo potuto parlare con il cliente all'inizio del ciclo. Abbiamo codificato per specifiche esatte, e tuttavia abbiamo consegnato qualcosa che non era così utile come avrebbe potuto essere. Questo grafico mostra parte della mia esperienza.

Come lo sviluppo del software può andare storto da https://blogs.perficient.com/perficientdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

In questo periodo il mio team ha sentito parlare di qualcosa chiamato il Manifesto Agile e una pratica chiamata Extreme Programming. Dato che è stato firmato da veterani del settore i cui libri stavamo leggendo attivamente, persone come Martin Fowler e Kent Beck, hanno prestato molta pratica alla pratica. La mia squadra di cinque persone ha smantellato i nostri cubicoli, ha attirato il nostro PM (procura per il nostro cliente) per sederci accanto a noi, ha creato un tabellone con le schede e si è messo al lavoro, componendo XP mentre procedevamo. Abbiamo avuto un ciclo settimanale di pianificazione e dimostrazioni, molti accoppiamenti e discussioni. Ho lavorato in varie iterazioni e varianti di questo, in diverse aziende per circa 15 anni. Un team sembrava non seguire affatto la metodologia, ma era perché tutti i membri del team provenivano da un background agile, l'iterazione e la collaborazione erano il loro stato operativo predefinito e non avevano bisogno di un processo imposto.

Quindi Agile parla di open space o parla molto? Se hai stand-up e retros puoi essere considerato Agile? Dove si inserisce Scrum o TDD? Spesso le persone restano troppo coinvolte nelle specifiche del processo: Scrum o Kanban? Sprint di due settimane o una settimana? Se non si ha la cura degli arretrati, sei davvero Agile? Essendo cresciuto facendo uno sviluppo attivo usando i metodi Agile, con altri sviluppatori ugualmente impegnati, sviluppando e adattando le pratiche, mi ha dato una buona idea e questo post è quello di identificare i principi di base.

Essere agili è essere in grado di soddisfare rapidamente le esigenze dei clienti. Ciò significa che scriviamo il codice più velocemente? No. Non possiamo battere le leggi della fisica e una solida applicazione multifunzionale richiede tempo per essere costruita.

Quello che dobbiamo fare è

  1. Identifica i problemi aziendali essenziali che vogliamo risolvere con il codice
  2. Fornire rapidamente una soluzione teorica per verificare l'ipotesi
  3. Iterare e adattarsi quando cambiano le esigenze o impariamo di più
  4. Fallo in collaborazione, con il cliente una parte impegnata del team

Tutto il resto che facciamo è meno doloroso di 2 e 3: sapere se stiamo soddisfacendo il bisogno il prima possibile e se non saremo in grado di cambiare rapidamente. Se hai deciso di creare (vs acquistare), stai scrivendo un software personalizzato. Ciò significa che ha requisiti e ambienti specializzati.

Ottenere qualcosa di visibile, anche se si tratta di un piccolo sottoinsieme della funzionalità, di fronte al cliente il più presto possibile ci consente di ottenere un feedback più velocemente. Questo è il motivo per cui sostengo sempre di concentrarmi sulla costruzione di una piccola parte della funzionalità, end-to-end, e su come arrivare fino alla produzione. Ad esempio, stai creando una pagina per i tuoi agenti di supporto per vedere tutti i dati su un cliente. Invece di dedicare molto tempo alla ricerca delle origini dati per l'intera pagina e alla scrittura di tutte le API prima, prova a ottenere un sottoinsieme di dati sulla pagina fino alla produzione. Sarai in grado di esercitare i tuoi meccanismi di integrazione e distribuzione, puoi iniziare a ricevere feedback sul framework dell'interfaccia utente, su come questa pagina si adatta al resto della tua applicazione ecc. Queste cose sono più facili da regolare quando hai una piccola quantità di codice, al contrario a quando hai creato un intero framework API.

Ecco alcuni degli altri meccanismi essenziali per l'agilità

Sprint: lo sviluppo in cicli temporizzati ci consente di ispezionare e adattare e incorporare nuovi dati a intervalli regolari per garantire che stiamo ancora lavorando su funzionalità pertinenti. Il software è una responsabilità. Dovremmo costruire solo ciò di cui abbiamo bisogno ed essere in grado di aggiungere ciò che è necessario, quando è necessario. Quindi è essenziale esaminare regolarmente ciò che abbiamo costruito finora e dove andremo dopo. Questo porta al secondo punto.

Dato che stiamo pianificando di valutare e cambiare costantemente, il nostro software dovrebbe essere facile da cambiare. Cosa succederebbe se, dopo che un cliente avesse iniziato a utilizzare l'applicazione, desiderasse che alcuni dati venissero visualizzati diversamente rispetto a quanto originariamente progettato? Potremmo farlo senza toccare tutto il resto della pagina? Oppure è necessario chiamare un'API diversa per ottenere i dati: è possibile apportare tale modifica in modo sicuro? È qui che entrano in gioco buone pratiche e meccanismi di sviluppo

Test unitari: disponiamo di test automatici a vari livelli, quindi esiste una rete di sicurezza per le modifiche. È anche fondamentale essere consapevoli di ciò che i test unitari effettivamente testano. I test unitari dovrebbero testare la logica. Se prendi l'esempio sopra, l'utilizzo di un'API diversa per ottenere i dati, idealmente, non dovrebbe richiedere alcuna modifica ai test delle unità per la nostra API che fornisce dati all'interfaccia utente. Esistono test unitari per darti la sicurezza di riformattare il codice, il che a sua volta ti dà la libertà di scrivere solo ciò di cui hai bisogno ora, e di riposare più tardi, per non produrre comunque una metrica di copertura del 100%.

CI / CD: questo ci consente di ridurre la distanza tra commit e consegna. Questo è essenziale per l'agilità. Quando vengono rimossi gli ostacoli alla distribuzione e possiamo spingere piccole modifiche alla produzione, il rischio derivante dalle modifiche viene notevolmente ridotto. Se le distribuzioni sono noiose, sono meno frequenti. Gli schieramenti meno frequenti spingono fuori un sacco di cambiamenti, toccando una vasta area di superficie e quindi sono più rischiosi. Se scopri di più sul perché le prestazioni di consegna del software contano e su quale metrica utilizzare per ottimizzarlo, consiglio vivamente questo libro di Nicole Forsgren.

Separazione delle preoccupazioni: un'architettura debolmente accoppiata è essenziale per un software facile da modificare. Riduce la superficie di un cambiamento. Microservizi e contenitori sono alcuni dei meccanismi utilizzati per esercitare la separazione delle preoccupazioni. È importante ricordare questo ed essere sicuri di tenere presente la separazione delle preoccupazioni quando si creano API, componenti e applicazioni.

Ricorda
Il buon codice può essere facilmente modificato

Il codice migliore può essere facilmente eliminato

Il miglior codice è quello che non è stato scritto affatto

È essenziale che i bit che crei incontrino il mondo reale il prima possibile, quindi sai come devono apparire i tuoi nuovi bit e non perdi tempo a creare bit inutili.