Decidere o non decidere, questo è il problema

Quando decidere utilizzando il principio dell’ultimo momento responsabile

Nella mia esperienza come sviluppatore ho imparato che una delle cose più importanti per il successo di un progetto è selezionare il momento giusto per prendere decisioni importanti.

Le ottimizzazioni premature sono buoni esempi:

Il vero problema è che i programmatori hanno passato troppo tempo a preoccuparsi dell’efficienza nei posti sbagliati e nei momenti sbagliati; l'ottimizzazione prematura è la radice di tutti i mali (o almeno della maggior parte di essi) nella programmazione.
Donald Knut

Per evitare problemi come ottimizzazioni premature dovremmo iniziare a coltivare l’ Ultimo Momento Responsabile (LRM), un principio di sviluppo snello definito come:

Una strategia che consiste nel non prendere una decisione prematura ma piuttosto ritardare l’impegno e mantenere aperte decisioni importanti e irreversibili fino a quando il costo di non prendere una decisione diventa maggiore del costo di prendere una decisione.

Il principio Last Responsible Moment ti aiuta a ridurre i costi.

Progettazione del software

Qual è il momento giusto per decidere come prenderà forma il tuo software?

Nell'approccio a cascata genererai una progettazione di alto livello del tuo sistema in base ai requisiti raccolti dalle parti interessate. Queste decisioni prese all'inizio del progetto verranno implementate molto più tardi (Big Design Up Front (BDUF)). Durante questo periodo i nostri stakeholder possono modificare i requisiti. Quindi quelle decisioni prese all’inizio sulla base di quelle esigenze ora sono inutili, ma hanno avuto un costo. Hanno creato team di sviluppo per implementare le cose, un modo che ora è difficile da risolvere. Ciò di solito produce soluzioni alternative (debito tecnologico) o ritardi imprevisti.

Design emergente

BDUF, nella sua migliore forma di uomo di paglia, incarna gli architetti della torre d'avorio che creano artefatti di design, lasciandoli cadere attraverso un buco nel pavimento affinché sfortunati programmatori possano implementarli senza modifiche. In forma non parodistica, questa metodologia di progettazione cerca diligentemente di scoprire tutto ciò che è interessante prima che inizi la codifica. È un modello predittivo e proattivo di progettazione del software.

Il design emergente non è uno stato binario. Non puoi dire con certezza che il tuo progetto sia agile al 100% o agile allo 0%; esiste su uno spettro Neal Ford

Alcuni team Agile evitano di applicare il BDUF (Big Design Up front), ma di solito praticano il DUF (Design Up Front). Me ne sono reso conto durante i perfezionamenti quando il team ha iniziato a dividere le storie in attività secondarie senza avere informazioni sufficienti sullo stato del codice sottostante.

La progettazione emergente è una conseguenza dell’applicazione delle metodologie Agile ed è sostanzialmente definita dall’Ultimo Momento Responsabile . In Agile dovresti definire l'architettura/design del codice relativo alla funzionalità o all'intero sistema nel momento in cui ci lavori. Non all'inizio né alla fine, ma mentre stiamo lavorando alla nuova funzionalità. Avrai bisogno di un test per verificare che le tue modifiche non influiscano su altre funzionalità, probabilmente dovrai rifattorizzarle per adattare la nostra funzionalità al nostro codice, creare nuove astrazioni, ecc. Sembra TDD:

Quando scriviamo unit test per una classe stiamo definendo la sua interfaccia, sia a livello sintattico che semantico. sviluppo software snello

TDD è una tecnica per progettare il nostro codice nell'Ultimo Momento Responsabile . Potremmo dire che il TDD è una conseguenza delle metodologie Agile.

Non sto dicendo che non dovremmo fare BDUF o DUF, solo che questi approcci comportano dei rischi e dobbiamo minimizzarli. Uno dei rischi maggiori è smettere di seguire il principio YAGNI e dedicare tempo a lavorare e mantenere cose inutili. Quindi le decisioni prese all'inizio del progetto o la funzionalità da implementare devono essere ridotte al minimo. Se il rischio è molto basso allora l' Ultimo Momento Responsabile non si applica.

C'è vita oltre allo sviluppo

Che dire di altre decisioni come quando tenere una riunione, discussioni nel team, quando testare un nuovo approccio a qualcosa?.
Secondo me l’Ultimo Momento Responsabile è un ottimo principio da tenere a mente da applicare in queste situazioni. Il feedback frequente ed efficace è uno dei migliori strumenti per identificare quei problemi che possono essere utilizzati come fattori scatenanti delle nostre azioni per prendere decisioni. Un altro strumento che può aiutarci a identificare l’Ultimo Momento Responsabile è la Urgent Important Matrix .

L’ Ultimo Momento Responsabile è il punto in cui i costi sono ridotti al minimo, quindi in sintesi penso che dovremmo concentrarci sull’identificazione in ogni situazione.