Agile Manifesto – działające oprogramowanie i dokumentacja

book

Wiedza | PROCES

Koniec sprintu to nie koniec świata, to koniec eksperymentu.

Jestem konsultantem, mam “przyjemność” obserwować niezadowolonych z oprogramowania klientów.

  • Co następnym razem zrobimy inaczej? – pytam twórców oprogramowania, kiedy wychodzą z takich smutnych spotkań.

 

Dostaję odpowiedź:

  • Lepiej spiszemy wymagania, będziemy dokładniejsi.
  • Co innego możecie zrobić?
  • No można by było zrobić jakieś makiety.
  • Co byłoby jeszcze lepsze? – pytam.

 

Cisza…

  • A może zróbcie mniejszy kawałek i pokażcie klientowi, jak to działa wcześniej?

 

Cisza…

  • Tego się nie da podzielić – mówią.
  • Wdrażanie tak często nie ma sensu, będzie to męczyć klienta.
  • Nasz klient nie ma czasu tak często się spotykać.
  • Nie da się wymyślić mniejszych kawałków, które będą możliwe do użycia.

 

I wiele wiele innych. Tak naprawdę często powodem jest brak wiary w to że to ma sens i strach przed nowym zupełnie innym podejściem do tworzenia oprogramowania. Zamiast zmiany, wolimy więc zostać przy starym.  Aby upewnić się, że klient zapłaci spisujemy spisujemy i jeszcze raz spisujemy. Spisujemy coraz dokładniej, aby upewnić się, że się zrozumieliśmy. A co się dzieje w czasie tego spisywania?

 

Spróbujmy zademonstrować:

Dostarczacie mi proszę trójkąt równoboczny, czarny, bez wypełnień. W środku mają być dwie identyczne gwiazdy, czerwone. Na rogach koła niebieskie.

Agile Manifesto - Beata Nowakowska

 

Jeżeli próbujemy opisać coś skomplikowanego to z każdym dodatkowym elementem opisu, nie zawsze rośnie precyzja przekazu, często rośnie ilość nieporozumień i założeń poczynionych nieświadomie przez każdą ze stron.

 

Często jedno niewychwycone duże nieporozumienie na początku, sprawia że wynik pracy jest bez sensu, mimo precyzji w szczegółach. Patrząc na powyższy rysunek: co jeżeli tego trójkąta nie da się tak łatwo obrócić?

 

Dlatego najlepszym sposobem weryfikacji nie jest doprecyzowanie, a sprawdzenie wyniku. Klient patrząc na gotowy kawałek wychwyci dużo więcej, niż jest w stanie doprecyzować.

 

Koniec sprintu to nie koniec świata, to koniec eksperymentu.

 

Niektórzy myślą o końcu iteracji jak o końcu świata, bo trzeba pokazać coś klientowi i co jak temu klientowi to się nie spodoba?

 

Otóż nic. Powie nam co mu się nie podoba i poprawimy się. Łatwiej poprawić coś co robiliśmy 2 tygodnie niż coś co robiliśmy 2 miesiące.

 

A jakie jest prawdopodobieństwo że gdzieś się nie zrozumieliśmy i coś mu się nie spodoba?

No tak z 90%. Szczególnie po pierwszej iteracji.

 

Początki mogą być ciężkie, bo klient też myśli, że koniec sprintu to koniec świata, ale z każdą następną iteracją obie strony uczą się, że spotykamy się tak często właśnie po to aby nanosić poprawki na stworzone rozwiązanie, więc to że nie jest ono idealne, nie jest tragedią.

 

A jak to się ma do tego że Scrum mówi że na koniec Sprintu ma być GOTOWY produkt?

 

A no tak, że jak ten mały fragment jest gotowy, to weryfikujemy maksymalną ilość założeń.

Wiemy, że udało nam się zrobić wszystko co jest potrzebne na każdej z warstw. Wiemy że udało nam się wdrożyć to na środowisko produkcyjne. Ścieżka została przetarta w każdy możliwy sposób.

 

Często porównuje się oprogramowanie do tortu. Użyjmy więc tego porównania. Jak mamy już cały kawałek tortu, to sprawdziliśmy,

  • czy krem ładnie łączy się ze spodem,
  • czy świeczka się nie przewraca,
  • czy smak kremu i spodu na raz w ustach jest wyśmienity,
  • czy kawałek stoi pionowo i się nie przewraca.

 

Oraz mnóstwo rzeczy, o których nawet nie pomyśleliśmy, a widać je dopiero na gotowym produkcie.

 

A co jeżeli produkt nie jest w pełni funkcjonalny? Na przykład jest cześć na dla adminów ale nie ma dla użytkowników końcowych, więc nie da się tego w pełni używać?

 

Gotowy produkt ma być używalny niekoniecznie użyteczny.

 

Czyli lepiej jest zrobić najpierw dla adminów i już oni mogą dać nam feedback, niż zrobić samą bazę danych pod wszystko. Jak tylko skończymy część dla adminów, robimy dla użytkowników końcowych, aby sprawdzić jak to razem działa, a dopiero potem zabieramy się za kolejną cześć.

 

Chcemy podejmować decyzje na podstawie działającego oprogramowania, nie na podstawie dokumentacji, bo daje nam to więcej informacji i pozwala ostatecznie stworzyć lepszy produkt, a ostatecznie to jest najważniejsze.

Najlepsze artykuły:

Powiązane artykuły, mogą Cię też zainteresować!

Agile Manifesto - Ludzie i interakcje

Kto nie powiedział choć raz “jestem/używam agile”, niech pierwszy rzuci kamieniem. Bycie agile jest obecnie czymś obowią...

Ilustrowany Scrum Guide - darmowy e-book do ściągnięcia

Scrum: jest lekki, łatwy do zrozumienia i trudny w implementacji. Dlatego 7 listopada 2017 Jeff Sutherland i Ken Schwab...

Sprint Review - zgodne ze sztuką

Celem Sprint Review JEST uzyskanie feedbacku od interesariuszy o Inkremencie i zaplanowanie dalszego rozwoju produktu.

Czwarty element motywacji - o czym zapomniał Pink?

Tak naprawdę, to pieniądze motywują. Tylko w inny sposób. Stałe dostawy godziwego wynagrodzenia redukują stres. Bo nie t...

Najlepsze artykuły: