Jakiś czas temu jeden z moich klientów powiedział, że ma drobną sprawę. Od 10 miesięcy w jego projekcie trwają prace nad aplikacją. Jest ona w 95% gotowa jednak coś się przeciąga. Poprosił mnie o pomoc w znalezieniu przyczyny. Zapytałem go, kiedy ostatnio robili release’a albo chociaż gotową do tego wersję softu. Odpowiedział, że nigdy.

W tym momencie już wiedziałem, że mam trudne zlecenie na przynajmniej kilka miesięcy. Brak działającej wersji gotowej do releasa zawsze oznacza poważne kłopoty w projekcie. Moje doświadczenie pokazuje, że „gotowość” może być na jednym z sześciu poziomów.

1. Ready 95%

Development trwa od wielu miesięcy. Mamy dużo wykonanej pracy jednak nigdy nie było gotowej w 100% wersji softu. Takiej, w której nie trzeba „zrobić jeszcze tylko jednej małej rzeczy”. Praca jest rozgrzebana.

Przykład:
Kod nie jest zintegrowany, nie przeprowadzono odpowiednich testów, niektóre feature’y są tylko częściowo zrobione albo istnieją poważne błędy, którymi „zajmiemy się później”.

Konsekwencje:
Jest to niesamowicie niebezpieczna sytuacja. Transparencja w takim projekcie praktycznie nie istnieje. Nawet jeżeli jakieś wskaźniki mówią nam o poziomie zaawansowania prac, to zwykłe wróżenie z fusów.

W momencie, gdy mamy wrażenie, że jesteśmy blisko końca zawsze pojawia się dodatkowa niezaplanowana praca. Prawie na pewno pojawi się regresja. Wiele razy widziałem, jak prace na sam koniec „nie chcą się spiąć” i jedyne co można zrobić to zacząć projekt od nowa.

2. Programmer Ready

Mamy wersję softu, w której niczego nie brakuje z punktu widzenia technicznego. Wersja jest w 100% DONE.  Jednak zamiast gotowych funkcjonalności dających wymierną wartość biznesową, stworzyliśmy zadania o charakterze technicznym.

Przykład:
Od 3 miesięcy nie zrobiliśmy demo dla klienta, gdyż pracujemy nad API, które później użyjemy do tworzenia feature’ów.

Konsekwencje:
Niewątpliwie mamy działający soft, do którego można wrócić, gdy sprawy przyjmą fatalny obrót. Redukujemy prawdopodobieństwo, że regresja „eksploduje” w najmniej oczekiwanym momencie. To ogromne zalety.

Problemem jest jednak fakt, że deweloperzy skupiając się na danej warstwie architektonicznej tracą perspektywę całej aplikacji. Dlatego istnieje ryzyko, że zostanie zrobione coś w niewłaściwy sposób albo coś czego nie użyjemy w przyszłości. To wygeneruje niepotrzebne koszty.

Największym jednak zagrożeniem jest to, że całkowicie tracimy biznesowy punkt widzenia. Nie mamy w ogóle potwierdzenia, że produkt jest rozwijany we właściwym kierunku. Bazujemy na wymaganiach zebranych dawno temu.

Prawie na pewno stworzymy coś, co nie spełnia w pełni potrzeb użytkowników i celów biznesowych Stakeholder’ów. Spotkałem się wiele razy z sytuacją, że przy takim podejściu stworzono aplikację, która pod względem technicznym była znakomita. Jednak pod względem biznesowym nie miała żadnej wartości.

3. Product Owner Ready

Zadania są w 100% DONE i reprezentują funkcjonalności z punktu widzenia użytkownika np. za pomocą User Story1. Wersja została odebrana tylko i wyłącznie przez Product Ownera. Żaden Stakeholder nie dał swojego feedbacku, na podstawie którego planowane są dalsze prace.

Przykład:
Klient zamawia aplikację, jednak nie ma czasu na regularne odbiory i dawanie feedbacku. Product Owner stara się najlepiej jak potrafi zrozumieć wizję klienta. Następnie sam daje feedback zespołowi na temat aktualnej wersji produktu.

Konsekwencje

Jest to ogromny postęp w stosunku do „Programmer Ready”. Deweloperzy mają przed sobą cel biznesowy. Patrzą też na funkcjonalność jako całość. Ich praca staje się bardziej efektywna, powstanie mniej kodu, który jest zbędny.

Nastąpiła inspekcja produktu pod względem dostarczanej wartości. Dlatego jest dużo większa szansa, że jest rozwijany we właściwym kierunku.

Mimo wszystko występuje ryzyko, że Product Owner nie „wszedł w skórę” Stakeholderów odpowiednio dobrze. W konsekwencji klient może dostać coś, co wyobrażał sobie zupełnie inaczej i może się okazać, że jest niezadowolony z rezultatów.

4. Stakeholder Ready

W tym przypadku oprócz Product Ownera również Stakeholderzy odebrali produkt. Ich wizja biznesowa jest potwierdzona. Na podstawie ich feedbacku planowane są kolejne wydania.

Przykład
Zespół pracuje w Scrumie i na każdym Sprint Review2 odbywa się demo dla Stakeholderów. Dają oni feedback na temat tego co zobaczyli. Na tej podstawie modyfikuje się Product Backlog i planuje odpowiednio pracę w kolejnych iteracjach.

Konsekwencje
Regularnie przeprowadzane dema dla Stakeholderów dodają deweloperom skrzydeł. Dzięki nim widzą, że ich praca ma sens i daje komuś wartość.

Największą jednak zaletą jest to, że zweryfikowano czy produkt realizuje wizję Stakeholderów. Wiadomo, czy rozwija się po ich myśli. Diametralnie zwiększamy szanse, że kolejne wersje dokładnie odzwierciedlą dążenia interesariuszy.

Stakeholderzy włączając się w proces tworzenia software biorą częściowo za niego odpowiedzialność i wiedzą dokładnie co się dzieje w projekcie. Moje doświadczenie podpowiada, że w przypadku problemów są dzięki temu o wiele bardziej wyrozumiali i skłonni do pomocy.

Wydawać by się mogło, że to rozwiązanie idealne. Ma niestety bardzo poważną wadę. Stakeholderzy nie potrafią myśleć jak ostateczni użytkownicy aplikacji i wczuć się w ich potrzeby.

5.User ready

Oprócz Stakeholderów aplikacja jest poddana „inspekcji” przez ostatecznych użytkowników. Dają oni feedback z własnego punku widzenia.

Przykład:

Na Sprint Review zaprasza się kilku end userów, którzy dają feedback. Regularnie prosi się też ich o to, aby w czasie Sprintu testowali funkcjonalności i na bieżąco weryfikowali, czy poszczególne feature‚y spełniają ich potrzeby.

Konsekwencje:

Jest to kolejny krok, aby zwiększyć szansę na wydanie produktu, który będzie dawał maksymalną wartość biznesową.

6.Market ready

Aplikacja jest wydana na rynek. Może to być tylko BETA albo MVP3 dla wybranych użytkowników.

Przykład:

Aplikacja dotycząca footballu amerykańskiego jest tworzona dla userów z USA. Wersja BETA jest wydana najpierw w Brazylii, gdzie ten sport nie jest tak bardzo popularny. Jednak można szybko się dowiedzieć jak aplikacja jest odbierana i co możemy zrobić lepiej przed wydaniem jej w USA.

Konsekwencje:

Tak długo, aż naszego produktu nie zaakceptuje rynek docelowy tak długo żyjemy w strefie przypuszczeń. Dopiero po przetestowaniu produktu przez faktycznych użytkowników, otrzymujemy rzeczywisty feedback. Nawet jeżeli jest to dosyć bolesne doświadczenie, pozwala nam to wyjść całkowicie z iluzji. Należy do tego dążyć jak najszybciej.

Terminologia i dodatkowe uwagi:
1. User Story – to wymaganie biznesowe wyrażone w formie: „Jako , chcę , ponieważ „. Jest to najczęstsza forma elementów Product Backlogu w Scrumie.

2. Sprint Review – event scrumowy podczas którego zespół deweloperów dostaje feedback od Stakeholderów (między innymi).

3. MVP (Minimum Valuable Product) – wersja produktu zawierająca tylko i wyłącznie te funkcjonalności które są niezbędne do walidacji założeń biznesowych ze strony rynku/użytkowników.

5 thoughts on “6 poziomów działającego oprogramowania

  1. Pingback: Scrum 4 Najczęstsze Błędy Przy Wprowadzaniu - Agile Case Study

  2. Pingback: Developerzy renesansu - interdyscyplinarność na 4 poziomie - Agile Case Study

  3. Pingback: Scrum – 4 Najczęstsze Błędy - Agile Institute

Skomentuj Jontalanta Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany.