Wyobraź sobie, że piszesz książkę. Zarywasz noce, zalewasz zmęczenie kolejnymi kubkami kawy, przemywasz przekrwione oczy zimną wodą… Po kilku miesiącach takiego maratonu – jest! Wysyłasz do najbliższych przyjaciół i z niecierpliwością czekasz na wyrok. Kilka rozmów później już wiesz, że lektura jest ciekawa, ambitna, nowatorska… ale? Ale byłaby znacznie lepsza, gdyby główny bohater był dojrzałą kobietą, a nie młodym chłopakiem. I co teraz? Przepisywać całą książkę? Ach, gdybyś tylko wiedział to wcześniej! Może po pierwszym rozdziale? Zaraz, zaraz, to czemu nie wysłałeś pierwszego rozdziału zaraz po jego ukończeniu?

Czemu nie uczymy się na cudzych błędach? Nie wyciągamy pomocnych wniosków, zanim doprowadzimy siebie i otoczenie do łez i frustracji? I jak możemy działać inaczej?

Spróbujmy przyjrzeć się popularnym podejściom do przyrostowego rozwoju produktu. Główną siłą napędową metodyk zwinnych jest szybka informacja zwrotna. Użytkownik otrzymuje „wydmuszkę” zaślepionej funkcji, która jednak pozwala mu choćby w minimalnym zakresie ją wykorzystać czy przetestować. Taką właśnie rolę pełni pierwszy napisany rozdział książki. Podobnie będzie wyglądało projektowanie środków komunikacji pokazane na poniższym rysunku.

Zakładając, że potrzebą użytkownika jest przemieszczenie się z miejsca na miejsce, możemy uznać, iż przyjęty harmonogram prac jest daleki od ideału. Pierwsze użycie produktu może nastąpić dopiero po ostatniej fazie projektu, czyli montażu kół. Analogicznie w projektach programistycznych jest to koncentracja na kwestiach technicznych. Zaczynamy od utworzenia modelu bazy danych, później implementujemy warstwę serwisową, a na samym końcu dostarczamy interfejs użytkownika. Dopiero teraz pozwalamy mu zapoznać się z budowanym (a w zasadzie już zbudowanym) systemem.

Jak inaczej zatem można planować pracę? Najczęściej spotykanym modelem iteracji jest ten przedstawiony poniżej.

Tutaj sytuacja pozornie wygląda znacznie lepiej. Już od samego początku użytkownik jest w stanie realizować swoją najważniejszą potrzebę, czyli przemieszczenie się z miejsca A do miejsca B. Czemu zatem pozornie? Problem w powyższym podejściu polega na porzucaniu wyników poprzednich iteracji. Oczywiście, w mocy pozostają retrospekcje i informacja zwrotna od użytkowników, jednak sam produkt jest realizowany poniekąd od zera. W przypadku projektów informatycznych problem taki wynika głównie z braku strategicznego planowania produktu, które broni się w zasadzie jedynie w przypadku niezwykle innowacyjnych projektów, przy których nie do końca jesteśmy w stanie przewidzieć zachowania, czy nawet potrzeb potencjalnych klientów.

Rozwiązanie idealne? Oczywiście wiemy, że takie nie istnieje. Natomiast w większości przypadków najlepiej sprawdza się sposób pokazany poniżej.

Klient otrzymuje podstawowy wariant realizacji wymagań już po pierwszej iteracji projektu. Co prawda, jechać można tylko do przodu i w dodatku „na pych”, ale worki z cementem możemy przetransportować na drugi koniec hali dość sprawnie. Po kolejnej iteracji możemy już kierować (okazało się to dość dużym brakiem pierwszej wersji) i siedzieć. Może nawet zakończymy projekt, bo klient nazwie to „buggy” i oceni, że całkowicie spełnia jego potrzeby? Jeżeli później przyjdzie jesień i okaże się, że karoseria i szyby chroniące przed deszczem jednak nie są przereklamowane, nic nie stoi na przeszkodzie, aby je „zaimplementować”.

Przenieśmy to teraz na grunt projektów software. Otrzymując jedynie interfejs użytkownika formularza rejestracji konta (zwracający zawsze informację, że wszystko zakończyło się sukcesem i nawet nie próbujący zapisywać nic do bazy danych), jesteśmy w stanie ocenić ergonomię rozwiązania. Jeżeli teraz okaże się, iż pól jest zbyt dużo i należy podzielić formularz na dwa rozdzielone kroki (np. jeden dostępny ze strony głównej, a drugi wyświetlany po pierwszym zalogowaniu do aplikacji), to dowiedzieliśmy się o tym, zanim wykonaliśmy jakąkolwiek implementację. Zmiana kodu, który jeszcze nie istnieje, nic nie kosztuje. Jeżeli jednak o tym samym dowiedzieliśmy się po dostarczeniu całej funkcji, podział formularza na dwa, zmiana walidacji i przepisanie API łączyłoby się z większym nakładem pracy i prawdopodobnie potraktowane zostanie jako zmiana wymagań. To właśnie takie modyfikacje opóźniają projekty i powodują dostarczanie rozwiązań dalekich od optymalnych.

Przytoczony na początku przykład z książką wyraźnie pokazuje, że im wcześniej uzyskamy informację zwrotną dotyczącą wykonanego produktu, tym bardziej efekt będzie dopasowany do potrzeb końcowego użytkownika. Co równie ważne, satysfakcja z wykonanej pracy będzie znacznie większa, a koszt jej wykonania zauważalnie niższy niż przy klasycznym podejściu, które przeprowadzenie ewaluacji zostawia na sam koniec. Oczywiście, nawet najbardziej zwinny system pisania książki nie pomoże, o ile recenzent odmówi czytania pojedynczych rozdziałów i postanowi czekać na ukończoną powieść. Ale warto próbować!

Pamiętajmy – miesiąc prac i planowania może zaoszczędzić nam godzinę poświęconą na uzyskanie opinii użytkownika 🙂

1
Dodaj komentarz

avatar
1 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
1 Comment authors
Michał Kuliński Recent comment authors
  Subscribe  
najnowszy najstarszy oceniany
Powiadom o
Michał Kuliński
Gość

Doooobre to 🙂 A tak BTW. Na bazie wózka do przenoszenia rzeczy w hali powstał VW Transporter w latach 40-tych. I to się nazywa „agile”.