- Czym jest Refinement Backlogu Produktu? — 27/11/2024
- Czym jest burndown chart? — 22/11/2024
- Czym jest Retrospektywa Sprintu? — 18/11/2024
Golf Club Against Ball by kulicki
Tytuł tego artykułu przyciągnął Twoją uwagę i obiecuję, że się nie rozczarujesz. Najpierw zarysuje krótki wstęp, a potem dowiesz się ile ogólnych zasad takich jak te z gry w golfa możesz zastosować na swoim projekcie. Proszę o chwilkę cierpliwości.
Wprowadzenie
Kolega z zespołu zaczął grać w golfa. Niespodziewanie okazuje się, że to przestał być drogi sport i nie potrzeba być członkiem klubu. Oczywiście do golfa trzeba mieć partnera, więc kolega zaczął namawiać mnie do towarzyszenia w jego ćwiczeniach. Okazało się, że uderzenie piłki wcale nie jest takie łatwe, a kontrola jej lotu to już wyższy poziom wtajemniczenia. Często rozmawiamy na ten temat i ostatnio zaskoczyły mnie dwie wskazówki przekazane przez jednego z trenerów.
2 uniwersalne wskazówki, które wykorzystasz w Scrum
- “Nie skupiaj się na piłce, tylko na uderzeniu (tzw. swing). Piłka jest tylko wskaźnikiem. Piłka Ci pokaże jak na prawdę uderzyłeś.”
- “Gdybyś nie widział przeszkody wodnej, posłałbyś piłkę dalej bez żadnego wysiłku.”
#1 Nie skupiaj się na piłce
To jest blog o projektach prowadzonych przy użyciu metod zwinnych, o projektach agile. Czasami poruszam też temat testowania oprogramowania i agile testing. Pytasz pewnie siebie “Co ma z tym wspólnego golf?”
Spójrzmy najpierw na pierwszą radę, w skrócie “Nie skupiaj się na piłce”. Jeżeli dobrze opanujesz uderzenie, nie będziesz musiał skupiać się na piłce, bo zawsze uderzysz tak samo i będziesz wiedział gdzie piłka powinna polecieć. Kontrolując obrót ciała i układ rąk, wiesz gdzie znajdzie się kij w decydującym momencie. Piłka tylko pokaże, jak wykonałeś ruch i oceniłeś warunki środowiska. Skup się, bądź tu i teraz i wykonaj uderzenie jak najlepiej potrafisz. Często początkujący gracze skupiają się na tym, żeby “przyłożyć” w piłkę jak najsilniej. Czasem trafią, czasem nie, ale na pewno nie potrafią posłać piłki dwa razy w to samo miejsce.
Czy nie jest tak samo z Sprint Burndown? Spójrzmy na powszechne błędy.
- Często zespoły, zwłaszcza te wdrażające Scrum skupiają się na idealnym Sprint Burndown.
- Project Manager albo Scrum Master naciskają na członków zespołu, żeby zaniżyli ilość oszacowanej pracy dla zadania.
- Nowe zadania i zgłaszane defekty nie mają estymat, bo przecież to może zepsuć wykres Sprint
- Zapomina się o koncepcji “ideal day” i oczekuje się rejestrowana 8 godzin pracy w zadaniach każdego dnia. Bo przecież “za 8 godzin im płacimy” i pojemność Sprintu została określona poprzez pomnożenie ilości dni roboczych w Sprincie przez 8h.
No i czasem uda się, że te dwie linie Sprint Burndown i Ideal Sprint Burndown spotkają się na koniec Sprintu. Ale jednak Product Owner nie będzie zadowolony, wyjdzie na jaw kilka defektów, kilka niedokończonych zadań i w kolejnym Sprincie Burndown będzie wyglądał dużo gorzej. A może Sprint Burndown zejdzie do zera, a część zadań nie będzie DONE. Dlaczego? Bo skupiasz się na piłce a nie na technice. Jeżeli nauczysz się dobrze planować i szacować oraz pozwolisz zespołowi zorganizować prace, to Sprint Burndown będzie to obrazował. Sprint Burndown to tylko wykres i nie jest celem sam w sobie. Jest tylko narzędziem. Tak samo jak piłka pokazuje Ci jak uderzyłeś, tak Sprint Burndown pokazuje Ci jak Zespół oszacował zadania i jak idzie ich wykonywanie. Te same zasady dotyczą drugiego burndownu, Release Burndown.
#2 Skup się na celu, nie na przeszkodach
Jak zapewne orientujesz się na polu golfowym są umieszczone przeszkody takie jak piasek czy woda. Trzeba je pokonać na drodze do dołka. Często gracz tak bardzo skupia się na tym, żeby nie trafić w przeszkodę, że w końcu w nią trafia. To może mieć podstawy w jednym z podstawowych założeń NLP — mózg nie rozpoznaje słowa “nie”. Jest ono sztuczne i nie ma przypisanego obrazu, filmu dźwięku itd., które by określały co to jest “nie”. Dlatego jeżeli napiszę: “Nie wyobrażaj sobie zielonego ogra pożerającego autobus”, to pewnie właśnie zrobiłeś na odwrót. Fakt jest taki, że początkujący gracz wybija piłkę na odległość przynajmniej 80 metrów. Woda jest 50 metrów przed nim, więc ma 30 metrów zapasu. Wystarczy skupić się na dołku i piłka nie wpadnie do wody.
Na projektach agile czasem skupiamy się na przeszkodach, zamiast na celu. Skupiamy się, żeby:
- nie mieć żadnych defektów,
- zautomatyzować wszystkie przypadki testowe,
- architektura była jak najbardziej elastyczna,
- interfejs użytkownika był doskonały
i w efekcie mamy nieudany Sprint.
Często początkujące zespoły dopada bezlitosne prawo Parkinsona, które w skrócie polega na tym, że na wykonanie zadania zużyjesz tyle czasu, ile masz dostępne. Bardzo dobrze widać to przy każdego rodzaju pracach zaliczeniowych. Student odda pracę dopiero przy końcu terminu, a nawet wykona tę pracę dopiero blisko terminu, albo dołoży różne, nie wymagane w specyfikacji, żeby wypełnić czas. Kolejnym z powszechnych błędów jest realizowanie łatwiejszych zadań na początku i odkładanie tych trudniejszy, mniej przyjemnych na później, nazywa się to zjawisko prokrastynacją. W efekcie dochodzi sytuacji, że odkładana zadania okazują się trudniejsze niż przewidziano, albo powodują pewne problemy, których rozwiązanie wymaga czasu, którego na koniec Sprintu już nie mamy.
Jak sobie z tym radzić? Skupiaj się na celu. Skup się na zrealizowaniu celu Sprintu, gola i dostarczeniu wartości biznesowej. Omijanie przeszkód i rozwiązywanie problemów jest częścią gry i przyjdzie Ci naturalnie, kiedy pamiętasz co chcesz osiągnąć.