Qualcuno mi ha detto che la velocità è la cosa più importante per loro, quindi distribuiscono qualsiasi cosa (alla produzione presumo), risolvo, ridistribuisci / rilascio continuo e così via. Non riesco a ricordare esattamente, ma la mia impressione da asporto è che lui pensa che sia corretto spedire il codice buggy, se non riesci a raggiungere la velocità, ecc.
Si tratta di un metodo "fail-fast" e quale è una buona analogia per esso, se appropriato, utilizzando una casa o una barca?
Il time-to-market (TTM) è davvero un fattore importante per molte aziende, specialmente per le startup. Quando si tratta di prodotti software, TTM si traduce in integrazione continua e implementazione continua . L'idea qui non è che spedisci il codice buggy, ma che spedisci software pienamente funzionante su base regolare. Sebbene la frequenza varia da squadra a squadra, non è insolito che alcune aziende e team spediscano più volte al giorno , il che fa una grande differenza rispetto ai team in cui una funzionalità può essere spedita per sei mesi a una alcuni anni più tardi, dopo essere stato richiesto dal proprietario del prodotto.
In un contesto di implementazione continua, al fine di evitare che il codice bacato colpisca la produzione, i team stanno utilizzando test automatizzati approfonditi. Invece di spendere sei mesi per sviluppare una funzionalità e poi gestirla per il reparto di controllo qualità per una fase di test-fix-test di otto mesi, quei team scrivono test nello stesso momento in cui scrivono il codice. Questi test vengono eseguiti su ogni commit e, se una qualsiasi delle migliaia di test ha esito negativo, il prodotto non viene distribuito sui server di produzione e gli sviluppatori vengono informati che hanno interrotto la compilazione .
Si noti che TTM si traduce anche in un approccio di marketing (e non tecnico) che consiste nel dire che è più importante spedire un prodotto spesso incompleto e imperfetto ora, e vedere come gli utenti effettivi lo useranno, cosa vorrebbero, e dove avrebbero incontrato difficoltà. Sulla base di questo feedback, il prodotto viene quindi adattato alle esigenze dei clienti. Recentemente (vale a dire negli ultimi venti anni), questo approccio ha avuto successo e si è dimostrato efficiente in un contesto di startup, rispetto a un approccio ordinario consistente nel fare ricerche di mercato e molti studi prima dello sviluppo del prodotto.
Hai chiesto delle analogie casa / barca, quindi eccole qui.
Integrazione continua.
Immagina di costruire una barca. Potresti passare alcuni mesi a costruirlo, quindi metterlo in acqua e notare che ci sono alcuni difetti di ingegneria e di costruzione. Devi correggerli prima di poter usare la barca.
Invece, puoi costantemente testare come la tua barca si comporta mettendola in acqua ogni giorno. Quando commetti un errore di progettazione o di costruzione, riceverai un feedback entro un giorno che mostra che il cambiamento che hai apportato alla barca durante questo o il giorno precedente ha causato un problema.
Questo potrebbe non essere adatto per una barca, dal momento che queste cose potrebbero non galleggiare bene se sono costruite per metà (ad esempio se non sono ancora state dipinte). Per i prodotti software, tuttavia, anche una piccola caratteristica di un prodotto che non è stato ancora costruito può essere già testata, rendendo i prodotti software i candidati ideali per l'integrazione continua.
TTM in marketing.
Immagina di costruire una casa. Potresti passare alcuni mesi a costruirlo e mostrarlo al proprietario, solo per sapere che voleva una piscina dall'altra parte del giardino, e che si aspettava altre due finestre e un tetto diverso.
Oppure puoi consentire al proprietario di accedere al sito di costruzione una volta alla settimana per ricevere un feedback molto rapido, quando non è ancora troppo costoso apportare alcune modifiche.
Anche in questo caso, l'analogia non è perfetta, perché (1) il proprietario non può vivere nella casa che non è ancora stata costruita (mentre gli utenti possono iniziare a utilizzare un prodotto software privo di metà delle sue caratteristiche ), e perché (2) i cambiamenti strutturali saranno estremamente costosi da eseguire una volta iniziata la costruzione (che spesso non è il caso per i prodotti software che sono stati costruiti correttamente).
CI / CD è davvero un approccio a prova di errore. Prendo un piccolo problema con questo:
" pensa che sia corretto spedire il codice buggy "
Ho il sospetto che in realtà egli voglia dire che è noto che il software potrebbe avere dei difetti ma implementarlo rapidamente significa che i problemi saranno trovati, segnalati e risolti molto più velocemente dei metodi tradizionali.
Parte del problema con gli approcci legacy è rappresentato dalle funzioni software pensate che sapevano cosa voleva il cliente e lo spedivano mesi / anni dopo che era stato specificato solo per scoprire che non era in realtà ciò che il cliente desiderava tutti.
Prima puoi mettere qualcosa di fronte a un cliente e raccogliere critiche, prima puoi iniziare a risolvere i problemi e smettere di sprecare tempo di sviluppo nei vicoli ciechi.
Parte dell'ethile agile prende a prestito da wabi-sabi dove si capisce da subito che il software è imperfetto, impermanente e incompleto. Come per tutto ciò che viene creato, non deve necessariamente essere il migliore della classe per fornire valore.
Per quanto riguarda un'analogia, ciò che viene realmente creato qui è un prototipo.
Potrebbe essere compreso e fatto con stile "date all'utente un po 'in vita something e fagli provare quello per noi". E in questo modo è davvero molto pericoloso e praticamente praticamente in qualsiasi modo.
L'analogia potrebbe essere: Cargo-cult. Quando le tribù selvagge, dopo che una base americana si trasferì nel 1945, costruì un modello di un piano di bastoni e foglie e pensò che il suo spirito avrebbe portato loro prosperità. Il problema principale: non sanno a cosa serve questa cosa e in realtà non vogliono saperlo. Hanno le loro idee e sono contenti di loro. È una simulazione di lavoro.
Ma se il bersaglio era:
quindi è un ottimo modo in stile REAL agile.
L'analogia per quel caso è: Un cliente ha ordinato un nuovo modello di qualche macchina tecnica.
E in ogni fase il lavoro può essere controllato in modo solido e il cliente e il produttore possono correggere gli errori precedenti.