Tag: zwinne zarządzanie

Walking skeleton – coś o zwinnym realizowaniu projektów

Dobry lider powinien oczywiście wykazywać się umiejętnościami przywódczymi i jednocześnie rozwijać się w zakresie kompetencji twardych. Jako że nasz świat ostatnich lat konsekwentnie zmierza w kierunku podejścia projektowego, odbywającego się w otoczeniu o dużej zmienności, tak ważne stają się kompetencje z zakresu zwinnego realizowania projektów.

O co chodzi z tym walking sekeleton?

Koncepcję tę po raz pierwszy przedstawił Alistair Cockburn (jedna z ważniejszych postaci w świecie zwinnego realizowania projektów) w książce: „Growing Object-Oriented Software Guided by Tests”.
W mojej opinii, walking skeleton idealnie oddaje ducha agile (cóż za ironia, że szkielet ukazuje ducha).
Chcę również podkreślić, że w moim rozumieniu agile (czyli zwinność) jest bardziej sposobem myślenia i patrzenia na świat niż konkretną metodyką czy narzędziem. Elementy z tego podejścia można również z powodzeniem stosować w innych dziedzinach, nie tylko IT (o tym dalej).

Szkielet, czyli…?

Szkielet to inaczej minimalna wersja tego, co chcemy finalnie zrealizować. Cała idea zwinnego realizowania projektów opiera się na budowaniu rozwiązań krok po kroku. Przyjęta na początku koncepcja rozwiązania nie musi być tą ostateczną i może się zmieniać wielokrotnie w trakcie trwania projektu.
Najpierw powstaje więc podstawa — szkielet, wokół którego dobudowujemy z czasem kolejne warstwy, lub nawet przebudowujemy jego podstawy. Taki szkielet często stanowi podwaliny pod finalne rozwiązanie.

No, ale on chodzi…

Dokładnie tak! Tutaj pojawia się druga istotna kwestia. Szkielet realizowany w sposób zwinny nie może być tylko prototypem, jakąś pół-funkcjonalną makietą. On chodzi, czyli faktycznie działa. Jest to więc pełnowartościowy produkt, zwykle bardzo ubogi w funkcje, ale jednak produkt.
Co ważne, do jego ukończenia powinny być zaangażowane wszystkie zespoły, które następnie będą budować rozwiązanie docelowe. Chodzi o to, aby przećwiczyć w praktyce wszelkie mechanizmy i punkty styku pomiędzy zespołami. Często nie zdajemy sobie sprawy z tego, co może pójść nie tak, dopóki faktycznie nie zbudujemy chociaż szkieletowego rozwiązania.
Do typowych problemów możemy zaliczyć np.:

  • Testowanie i automatyzacja testów rozwiązania
  • Zarządzanie wersjami i utrzymywanie kompatybilności
  • Przygotowywanie danych testowych i ich utrzymywanie
  • Proces wydawania wersji na różne środowiska
  • Odtwarzanie systemu po awarii

Zalety chodzącego szkieletora

O podstawowych zaletach takiego podejścia wspominałem już trochę w poprzednim rozdziale, czyli o możliwości przetestowania w praktyce wielu istotnych mechanizmów.
Kiedy projekt trafi do faktycznej fazy realizacji, wtedy zwykle wystarczy te działania przeskalować, czyli rozszerzyć na więcej zespołów i osób, jednocześnie zostawiając sprawdzone mechanizmy bez zmian.

Sytuacja byłaby zupełnie inna, gdyby zacząć inaczej, czyli od zbudowania szerokiego zakresu funkcjonalności, ale tylko na określonym poziomie, np. przygotować jedynie API, bez uruchomienia pełnej funkcjonalności chociażby tylko w ramach jednego, małego modułu.
Jeżeli przy takim podejściu odkryjemy jakieś nieprawidłowości w późniejszych fazach, to może okazać się konieczne zmodyfikowanie całego kodu dla warstwy API, bądź nawet napisanie jej od nowa.

Przykłady — IT

W IT większość przedsięwzięć da się podpiąć pod tę koncepcję.
Powiedzmy, że budujemy duży system wspierający pracę fabryki mebli. W skład systemu będą wchodziły moduły do obsługi zamówień, produkcji, magazynu, księgowości i zakupów. Aby przekonać się, czy mamy wystarczające procesy i narzędzia do zrealizowania projektu, możemy wybrać jeden moduł i przygotować go w uproszczonej wersji. Powiedzmy, że wybieramy magazyn, gdzie implementujemy obsługę przyjęcia i wydania z magazynu. Tylko tyle. Jednocześnie weryfikujemy wszystkie procesy pozwalające nam budować rozwiązania wysokiej jakości, takie jak CI, CD i wszelkie automatyzacje testów, zarówno te funkcjonalne jak i niefunkcjonalne.
Dopiero gdy mamy to przećwiczone na szkielecie, wtedy możemy założyć że w większej skali te same rozwiązania również się sprawdzą.

Przykłady — inne branże

Tutaj trochę zaimprowizuję, ale wydaje mi się, że podobne mechanizmy można stosować na przykład w biznesach typu:

  • cateringu — jeżeli chcesz wystartować z firmą obsługującą przyjęcia dla kilkuset osób, to może warto zacząć od mniejszej skali i spróbować zorganizować urodziny dla kilkunastu gości. Zobaczysz wtedy jakiego typu problemy logistyczne, związane z dostawcami, przechowywaniem żywności itp. mogą się pojawić. Jeżeli znajdziesz rozwiązania w mniejszej skali, wtedy dużo łatwiej pokonasz te trudności w większym przedsięwzięciu.
  • ogrodnictwo — gdy chcesz zająć się uprawą jakichś roślin, to również warto zacząć od mniejszej skali. Przekonasz się wtedy jakie czynniki mogą wpłynąć na powodzenie Twojego biznesu. Być może po takich pierwszych testach zmienisz koncepcję, zajmiesz się uprawą czegoś innego, co będzie bardziej odporne na zmieniające się warunki.

Nie polecam natomiast takiego podejścia na przykład w budownictwie lub służbie zdrowia 🙂

Artur GułaArtur Guła, pasjonat tematyki zarządzania i przywództwa z życiową misją dzielenia się wiedzą i doświadczeniami z innymi menedżerami.
Doświadczony lider w projektach IT z różnych dziedzin.
Autor książki Fascynujący świat przywództwa.

Read More