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?
źródło
Odpowiedzi:
„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):
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.
źródło