Che cos'è uno "scheletro ambulante"?


42

Uno dei miei team agili ha adottato un approccio interessante nelle prime fasi del loro progetto. Invece di iniziare il progetto con uno Sprint 0 in cui hanno impostato l'infrastruttura del codice e hanno deciso l'architettura della soluzione, hanno iniziato a costruire uno "Walking Skeleton", che descrivono come una pratica DevOps.

Ciò a cui sembra giungere sta nel costruire qualcosa di molto piccolo (nel caso di un'API un singolo endpoint che ritorna appena 200-OK), farlo funzionare in continua integrazione e costruire la pipeline di distribuzione continua per distribuire questo in ciascuno degli ambienti:

Sviluppo ► Test ► UAT ► Pre-produzione ► Produzione

Nel processo sono riusciti a spuntare molti dei requisiti non funzionali che avrebbero potuto essere persi se le distribuzioni fossero state lasciate all'ultimo minuto.

La mia domanda è questa: che cos'è uno "scheletro ambulante" e quali vantaggi offre a un team Agile seguendo le pratiche DevOps?


1
Adoro questo, posso condividere una cosa reale (la scorsa settimana) e quali sono stati i risultati di questo dopo pranzo
Tensibai,

Risposte:


38

Uno "scheletro ambulante" è una forma di "prova del concetto" del tuo concetto architettonico di base. Laddove una dimostrazione del concetto si concentra in genere maggiormente su una singola funzionalità, uno "Walking Skeleton" è un'implementazione minimalista end-to-end. Uno "Scheletro ambulante" non è uno schema del tuo concetto (solo uno "scheletro") ma è davvero eseguibile e spedibile (può "camminare": O) e dovrebbe essere accompagnato da prove.

Alistair Cockburn lo ha descritto (e viene citato spesso):

A Walking Skeleton è una piccola implementazione del sistema che svolge una piccola funzione end-to-end. Non è necessario utilizzare l'architettura finale, ma dovrebbe collegare tra loro i principali componenti architettonici. L'architettura e la funzionalità possono quindi evolversi in parallelo.

Il vantaggio qui per DevOps è che uno "Walking Skeleton" dovrebbe essere sviluppato all'inizio del progetto e si traduce in codice funzionante, spedibile e testabile . In questo modo DevOps può impostare una catena di integrazione continua completa all'inizio del progetto, anziché essere integrato nella fase finale dei progetti. Ciò significa che qualsiasi problema che potrebbe sorgere viene anche affrontato in una fase iniziale anziché alla fine del lavoro urgente.


4
Bene, non è solo la catena CI, ma potrebbe letteralmente coprire la pipeline di produzione end-to-end, compresa la consegna e l'implementazione. Uno scheletro anche di questo - non è necessario avere tutte le verifiche di controllo qualità per il prodotto finale in atto il primo giorno, è possibile aggiungere progressivamente "carne" di verifica a questo scheletro mentre la storia "carne" si accumula sullo scheletro ambulante.
Dan Cornilescu,

1
Mi piace il termine "carne", si adatta molto bene alla terminologia utilizzata: P
7ochem

3
Bella risposta. Immagino sia l'equivalente della pipeline di consegna di un prodotto minimo praticabile.
Adrian,

4
Questo suona in modo simile al prodotto minimo praticabile, ma a un livello più granulare, forse "componente minimo praticabile". Restituire 200 da un servizio solo per farlo "funzionare" mi sembra uno stub.
Dave Swersky,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.