Co to jest „chodzący szkielet”?

Jeden z moich zwinnych zespołów zastosował ciekawe podejście na wczesnych etapach projektu. Zamiast rozpocząć projekt od Sprint 0, w którym konfigurują infrastrukturę kodu i decydują o architekturze rozwiązania, zaczęli budować „Walking Skeleton”, który opisują jako praktykę DevOps.

Wydaje się, że sprowadza się to do zbudowania czegoś bardzo małego (w przypadku interfejsu API pojedynczego punktu końcowego, który właśnie powraca 200-OK), uzyskania ciągłej integracji i zbudowania ciągłego dostarczania w celu wdrożenia tego w każdym środowisku:

Rozwój ► Test ► UAT ► Przedprodukcja ► Produkcja

W trakcie tego procesu udało im się odreagować wiele niefunkcjonalnych wymagań, które można by pominąć, gdyby wdrożenia pozostawiono na ostatnią chwilę.

Moje pytanie brzmi: co to jest „Walking Skeleton” i jakie korzyści zapewnia on zwinnemu zespołowi po praktykach DevOps?

terminology patterns practices

— Richard Slater
źródło

Uwielbiam ten, mogę podzielić się faktem (w zeszłym tygodniu) i jakie były tego rezultaty po obiedzie

— Tensibai

„Chodzący szkielet” jest formą „dowodu koncepcji” podstawowej koncepcji architektonicznej. Tam, gdzie dowód koncepcji zwykle koncentruje się bardziej na pojedynczej funkcjonalności, „Walking Skeleton” jest minimalistyczną implementacją typu end-to-end. „Chodzący szkielet” nie jest obrysem twojej koncepcji (tylko „szkielet”), ale naprawdę jest wykonywalny i możliwy do wysyłki (może „chodzić”: O) i powinien mu towarzyszyć test.

Alistair Cockburn opisał to (i jest często cytowany):

Chodzący Szkielet to niewielka implementacja systemu, która wykonuje niewielką, kompleksową funkcję. Nie musi używać ostatecznej architektury, ale powinien łączyć ze sobą główne elementy architektoniczne. Architektura i funkcjonalność mogą ewoluować równolegle.

Zaletą DevOps jest to, że „Walking Skeleton” powinien zostać opracowany na wczesnym etapie projektu, co skutkuje działającym, nadającym się do wysyłki i testowania kodem . W ten sposób DevOps może skonfigurować pełny ciągły ciąg integracji na początku projektu, zamiast być włączany w końcową fazę projektów. Oznacza to, że wszelkie pojawiające się problemy są również rozwiązywane na wczesnym etapie zamiast pośpiechu na końcu.

— 7ochem
źródło

Cóż, to nie tylko łańcuch CI, ale może dosłownie obejmować cały proces produkcji, w tym dostawę i wdrożenie. Szkielet z tym równie dobrze - nie trzeba mieć wszystkie weryfikacje QA dla końcowego produktu w miejscu, w dniu 1, można stopniowo dodawać weryfikację „mięso” do tego szkieletu jako story „mięso” gromadzi się na szkielecie spaceru.

— Dan Cornilescu

Podoba mi się termin „mięso”, bardzo dobrze pasuje do stosowanej terminologii: P

— 7ochem

Świetna odpowiedź. Wydaje mi się, że jest to odpowiednik minimalnego możliwego do zrealizowania produktu.

— Adrian

Brzmi to podobnie do minimalnie opłacalnego produktu, ale na bardziej szczegółowym poziomie - być może „minimalnym opłacalnym komponencie”. Zwracanie 200 z usługi tylko po to, aby ją „uruchomić”, brzmi dla mnie jak skrót.

— Dave Swersky