Planowanie Wymiarowe w Agile

W ostatnich latach zauważyłem, że coraz częściej mówię o „Dimensional Planning". O Dimensional Planning dowiedziałem się od Koena van Exema, jednego z pierwszych belgijskich agile'owców. Pochodzi ono z wczesnych dni (belgijskiego) ruchu Agile i niestety trochę popadło w zapomnienie.

Wczoraj rozmawiałem o tym z JB (Rainsbergerem) i Alistairem (Cockburnem) i odkryłem, że mam jeszcze jedną ciekawą historię na ten temat.

Zanim ją opowiem, wyjaśnię najpierw pokrótce podstawy Dimensional Planning. Idea polega na tym, że dzielimy nasze Stories na różne wymiary implementacji. Robimy to, ponieważ wielu naszych klientów chce mieć na koniec tygodnia Lexusa. Może nam się to nie udać. Możemy jednak zaoferować im Toyotę już jutro. Większość klientów uznaje tę propozycję za świetną i może poczekać, aż będziemy mogli dostarczyć Lexusa (tzw. szybko osiągalny ROI).

Sposób, w jaki Koen wyjaśnia Dimensional Planning, bardzo mi się podoba

Wyobraź sobie, że Twój klient chce mieć autostradę między Amsterdamem a Heusden. Jesteś całkiem dobry w budowaniu autostrad, więc zaczynasz od razu. Po kilku miesiącach kończysz i z dumą pozwalasz klientowi po raz pierwszy skorzystać z autostrady. Przyjeżdża do Heusden, ale nie wygląda na szczególnie zadowolonego. Pytasz więc, czy stacje benzynowe, miejsca odpoczynku i zjazdy co kilka kilometrów są w porządku. Chociaż klient potwierdza, że wszystko jest dobrze, Twoje pytania zdają się go jeszcze bardziej irytować. W końcu wychodzi z tym na jaw: „To nie jest miejsce, do którego chciałem dojechać!"

Patrzysz na tablicę z nazwą miejscowości: Heusden. Czy nie chciał pojechać do Heusden? Owszem, chciał.

Okazuje się jednak, że istnieje jeszcze inne miejsce o nazwie „Heusden".

Teraz Twoi prawnicy i prawnicy klienta prowadzą długie dyskusje o tym, czyja to wina i kto musi zapłacić za niewłaściwą autostradę. (Jeśli masz dobrego prawnika, zapłaci klient i już nigdy nie wróci…)

W tym przypadku można by dobrze zastosować Dimensional Planning. Najpierw zbudowałbyś żwirową drogę między Amsterdamem a Heusden.

Po niecałym tygodniu byłbyś już gotowy i odkryłbyś, że trafiłeś do złego miejsca. Dla Ciebie nie stanowi to problemu, bo wiedziałeś, że mogą pojawić się pewne nieporozumienia. Dowiadujesz się więcej, znajdujesz inne Heusden i budujesz nową żwirową drogę. Po kolejnym tygodniu ta droga jest gotowa i wspólnie z klientem stwierdzacie, że to nadal złe Heusden. W Belgii są bowiem dwa miejsca o tej nazwie, a jeszcze jedno w Holandii. Kto mógł to przewidzieć?

Po kolejnym tygodniu klient jest szczęśliwy, mając w końcu żwirową drogę między Amsterdamem a właściwym Heusden. (I to o wiele szybciej niż pierwotnie planowane kilka miesięcy.)

Choć nie ma jeszcze wszystkich funkcjonalności, można już mówić o pewnym zysku, ponieważ klient może teraz dojeżdżać między dwoma lokalizacjami swojej firmy. To nie jest świetna droga i nie można jeździć zbyt szybko, ale jest znacznie szybsza niż poprzednia trasa z objazdem 100 km.

Dzień po ukończeniu żwirowej drogi zaczynasz pracować nad brukowaną wersją drogi, którą kończysz po trzech tygodniach. Możesz też pracować nad wersją asfaltową, smołową lub autostradą. W większości przypadków klienci nie chcą już autostrady, gdy tylko zaczną czerpać korzyści z poprzednich wersji.

Wszyscy wiemy, że klient zawsze powie „Tak", jeśli zapytamy go, czy chce autostradę, i że deweloperzy uwielbiają pracować nad wszystkimi funkcjonalnościami autostrady.

W naszym przykładzie z samochodem większość ludzi też wybrałaby Lexusa zamiast Toyoty – dopóki nie przyszłoby do płacenia, bo wtedy nagle Toyota też wystarczy. I podobnie nie każdy deweloper chce stale myśleć o wszystkich detalach, których wymaga Lexus.

Czy nie jest droższe budowanie trzech żwirowych dróg, brukowanej, smołowej i autostrady?

Oczywiście jest droższe niż zbudowanie tylko jednej autostrady. Wszyscy jednak wiemy, że błędy się zdarzają i że nadal jest to tańsze niż konieczność budowania trzech autostrad, co często zdarza się przy wytwarzaniu produktów.

Przy mojej metodzie przygotowujemy się tak dobrze, że nigdy nie popełniamy błędów…

Jeśli jesteś pewny i chcesz podjąć to ryzyko, oczywiście możesz to zrobić. I nawet jeśli masz rację (wątpię, że tak będzie zawsze), jestem jednak stosunkowo pewny, że większość klientów już zmieniła zdanie, kiedy zaczniesz budować autostradę. A na miesiące przed tym, zanim nawet zacząłeś budować, nasze żwirowe drogi przynoszą już zwrot z inwestycji.

Brzmi to teoretycznie nieźle. Ale czy naprawdę działa w praktyce?

Dobre pytanie! Prawie zapomniałem; w tym artykule chciałem przedstawić fajny przykład z prawdziwego życia:

Zmieniłem kilka szczegółów historii, aby chronić klienta.

Chodzi o stronę internetową firmy. Znajdowała się ona jednak w całkowicie zdemilitaryzowanej strefie sieci firmowej. Tam stworzono niewielki produkt, który miał być sprzedawany przez internet. Dyrektor finansowy (CFO) był wielkim zwolennikiem tego produktu i chciał regularnie otrzymywać dane sprzedażowe. Wymagałoby to jednak naruszenia stref bezpieczeństwa i wprowadzenia danych sprzedażowych do systemu SAP.

W dużej firmie to dość duży projekt, wymagający z pewnością sześciu miesięcy pracy deweloperskiej. Przygotowania rozpoczęły się od spotkań z co najmniej 20 osobami (eksperci ds. bezpieczeństwa, eksperci SAP, deweloperzy webowi i mnóstwo menedżerów na stanowiskach poniżej CFO).

Na kolejnym spotkaniu CFO skarżył się na słabą widoczność danych sprzedażowych produktu w ważnych pierwszych sześciu miesiącach. Zaproponowałem więc tymczasowe poboczne projekty z wykorzystaniem Dimensional Planning (jak w przykładzie z autostradą).

Wersja żwirowej drogi:

Każdego dnia generowaliśmy raport PDF na serwerze WWW i zapisywaliśmy go na dyskietce. (Pamiętajmy, że duża część sieci nie była połączona z serwerem.) Każdego dnia drukowaliśmy ten raport i przynosiliśmy kopię danych sprzedażowych do biura CFO, gdzie stażysta wprowadzał wszystkie dane do naszego systemu SAP. Raport PDF był tworzony przez jednego z naszych deweloperów w tym samym dniu, w którym produkt wszedł na rynek. Pod koniec dnia mieliśmy już dane dla CFO.

Pierwszy problem: CFO chciał czegoś dodatkowego; czegoś, o co klient miał być pytany na stronie internetowej. Deweloper z dumą pokazał raport CFO i wrócił do swojego miejsca pracy. Pół godziny później na stronie internetowej pojawiło się pytanie o dodatkową informację i stworzono nowy raport (bez danych z pierwszego dnia). Już następnego dnia ukazał się artykuł w gazecie i wielu klientów kupiło produkt. Dwa dni później zaczęły napływać pierwsze liczby, a nasz stażysta próbował przesłać dane do systemu SAP. Tu odkryliśmy nasze drugie Heusden. Okazało się, że używamy złej tabeli SAP. Naprawienie tego błędu zajęło kilka dni. CFO nadal otrzymywał swój raport, jednak w pierwszym tygodniu nie mogło to jeszcze nastąpić przez SAP. W piątek pierwszego tygodnia stażysta był w stanie przesłać dane. Była to jednak dość nudna praca, która absolutnie nie była skalowalna. (W pierwszym tygodniu mieliśmy kilka tysięcy sprzedaży.) Nadszedł czas na naszą:

Wersja brukowanej drogi:

Tym razem tworzyliśmy raport w formacie CVS. (Pamiętajcie, to było przed XML.) Każdego ranka deweloper, który jako pierwszy pojawiał się w biurze, szedł do serwera WWW, generował raport i kopiował go na dyskietkę. Następnie brał dysk i przesyłał dane do naszego systemu SAP. Ta wersja była bardziej skalowalna; bez względu na to, ile sprzedaliśmy poprzedniego dnia, praca naszego dewelopera pozostawała taka sama. Ale i w tej wersji mieliśmy mały problem. Jedno z pól było sformatowane jako tekst zamiast liczby. (Zupełnie normalny błąd.)

Praca musiała być wykonywana osobiście każdego dnia. Nie była zautomatyzowana i aktualizacja była przeprowadzana tylko raz dziennie (dla poprzedniego dnia).

Następnie rozpoczęły się spotkania dotyczące wersji autostradowej. Pod koniec jednego z tych spotkań zapytałem pracownika CFO, jak korzystają z danych i czy są zadowoleni z liczb. Zupełnie przypadkowo zauważyłem, że CFO przeglądał dane tylko w piątki. (Czyli nie codziennie.) Nie przeszkadzało mu nawet, że nie znał pełnych danych sprzedażowych z danego dnia ani tygodnia.

Wersja autostradowa:

Na szczęście następnego dnia miałem i tak spotkanie z dyrektorem finansowym i jego współpracownikiem. Rozmawialiśmy o postępach projektu autostradowego i o tym, że w zasadzie uniemożliwiał on ludziom pracę nad innym ważnym projektem. Uprzejmie zaproponowałem, żeby pozostać przy wersji brukowej i tymczasowo zamrozić projekt autostradowy. Wielu pracownikom firmy nie przypadło to do gustu, bo bardzo chcieli pracować przy tym super fajnym projekcie. Oficer ds. bezpieczeństwa był jednak z tego zadowolony, ponieważ serwer WWW mógł pozostać w bezpiecznej strefie. Ostatecznie firma zaoszczędziła sześć miesięcy pracy deweloperskiej na autostradę, która zagrażałaby sieci i tak naprawdę nie byłaby konieczna.

Po kilku latach znów spotkałem dyrektora finansowego. Przyznał, że projekt autostradowy był prawdopodobnie zbyt dużym przedsięwzięciem, bo produkt nigdy nie przyniósł nawet w przybliżeniu tyle pieniędzy, ile trzeba by było wydać na ten projekt. Dzięki projektowi żwirowej drogi mogli już dość wcześnie odkryć, że brakuje adresów e-mail klientów – i to było najlepsze, co mogło ich spotkać. Ta lista e-mailowa pozwoliła im bowiem przez kolejne lata sprzedawać klientom kilka dodatkowych usług, co uchroniło firmę przed bankructwem.

Poniższy tekst pochodzi z bloga Yvesa Hanoulle'a i został przez nas przetłumaczony na język polski.