Pomysł na Retrospekcję Sprintu – technika 4L

Pomysł na retrospekcję - technika 4L

Pomysł na retrospekcję – technika 4L

Przeglądając ostatnio zagraniczne blogi, trafiłem na ciekawą technikę przeprowadzenia Retrospekcji Sprintu, nazwaną przez autorkę The 4L’s.

Ta pozornie prosta technika przeprowadza retrospekcji potrafi dać naprawdę ciekawe rezultaty, ze względu na odpowiednio dobrane słowa, które zachęcają do spojrzenia na przeszłość z różnych perspektyw.

Lekko zmodernizowaną wersję tego ćwiczenia znajdziecie poniżej:

Co potrzebujemy?

  • cztery duże arkusze papieru, najlepiej z możliwością przyklejenia na ścianę
  • cztery bloczki kartek samoprzylepnych w różnych kolorach
  • pisaki / długopisy

Jak przebiega Retrospektywa?

  1. Przygotowujemy cztery duże arkusze papieru i wpisujemy na górę każdego arkusza odpowiedni nagłówek, tworząc obszar, na którym chcemy się skupić:
    • podobało mi się… (Liked)
    • nauczyłem się… (Learned)
    • brakowało mi… (Lacked)
    • tęskniłem za… (Longed for)
  2. Każdy członek Zespołu indywidualnie zapisuje cztery osobne kartki, obrazujące co mu się podobało w trakcie Sprintu, czego się nauczył, czego mu brakowało oraz za czym tęsknił. Następnie przykleja swoje kartki do odpowiednich arkuszy na ścianie
  3. Dzielimy zespół na cztery grupy – każda grupa otrzymuje jeden arkusz, zapoznaje się z kartkami stworzonymi przez Zespół, a następnie grupuje podobne kartki razem oraz identyfikuje główne tematy
  4. Każda grupa przedstawia reszcie Zespołu główne tematy z ich obszaru
  5. Zespół – stosując np. technikę głosowania kropkami – wybiera 3 tematy, które chce omówić

Na co zwrócić uwagę?

  • można modernizować obszary w ramach których się poruszamy, jednak autorka zaleca, aby nie rezygnować z obszaru „tęskniłem za” i ma rację. Sprawdziłem tę technikę w Zespole i faktycznie obszar ten potrafi dostarczyć ciekawej wiedzy od Zespołu.
  • jeśli mamy więcej czasu, możemy spróbować omówić wszystkie zgłoszone tematy – wymaga to jednak sprawnej moderacji spotkania

Fotografia użyta na licencji Creative Commons od użytkownika SuperFantastic.

Pociski smugowe, czyli szybkie dostarczanie wartości

Pociski smugowe w grze

Pociski smugowe w grze

Zanim internet zawitał na stałe do naszych domów, zamiast grania online spotykaliśmy się we własnych domach i używając techniki gorącego krzesła spędzaliśmy czas grając w proste, ale strasznie miodne gry.

Jedną z takich gier, przy których spędziliśmy setki godzin, była gra Scorched Earth. Zasada była prosta – każdy gracz ma swój czołg, którym wystrzeliwał pocisk w pozostałych graczy. Wygrywał ostatni pozostały na placu boju. Celowanie odbywało się poprzez ustawienie kąta strzału oraz jego mocy. Charakterystyczna była smuga, która powstawała po wystrzale. Pozwalała ona precyzyjniej wycelować w kolejnej turze. Jej brak znacząco utrudniał grę i zmniejszał celność graczy.

Pociski smugowe w programowaniu

Pociski smugowe bywają wykorzystywane przez programistów – pomagają im one dosięgnąć celu w trudnych warunkach, które wynikają z niełatwego zadania kompletowania wymagań użytkowników.

Zasada ich działania jest bardzo prosta. Możemy podejść do rozwoju oprogramowania na dwa sposoby:

  1. określając na starcie bardzo precyzyjnie wymagania systemu, ograniczenia, niewiadome oraz ograniczenia środowiska, tak by za jakiś czas – po zakodowaniu oraz integracji wszystkich funkcji –  przekazać gotowe rozwiązanie użytkownikom,
  2. szukając rozwiązań, które w szybki i tani sposób przeniosą nas od koncepcji do działającego systemu, który – pomimo surowości oraz braku wszystkich funkcji – będziemy mogli wkrótce czasie pokazać użytkownikom, aby uzyskać od nich informację zwrotną i zadecydować, czy chcą rozwijać system dalej, czy to co zobaczyli jest dla nich wystarczające.

Drugie podejście jest nieco trudniejsze – wymaga od zespołu tworzenia kompletnych rozwiązań end-to-end w trakcie pojedynczej iteracji, jednak efekt wart jest wysiłku.

Co to oznacza w praktyce?

Załóżmy, że mamy stworzyć prosty proces zakupowy składający się z 3 kroków:

  • KROK 1: dodanie produktu do koszyka
  • KROK 2: wybór adresu dostawy, rodzaju płatności oraz sposobu dostawy
  • KROK 3: wysłanie zamówienia

Podejście pierwsze

Po określeniu precyzyjnych wymagań na starcie, efektem pierwszego tygodnia prac może być dobrze zaimplementowany pierwszy krok procesu – możemy dodać produkt do koszyka. Możemy podać liczbę przedmiotów, zwiększać oraz zmieszać ich liczbę, a także zobaczyć zdjęcia obrazujące produkt wraz z ich opisem.

Efekt: Nie możemy de facto zrealizować zamówienia – dysponujemy wyłącznie jednym krokiem z trzech.

Podejście drugie

Wystrzeliwujemy pocisk smugowy. W trakcie tygodnia pracy implementujemy kompletny proces, składający z trzech kroków, który pozwala nam faktycznie zrealizować zamówienie. Oczywiście, możemy dodać tylko jeden przedmiot do koszyka, nie wyświetlamy zdjęć produktu, musimy ręcznie wpisać adres dostawy (nie napisaliśmy jeszcze modułu logowania), a zapłacić można tylko przy odbiorze przesyłki.

Efekt: Pomimo surowości rozwiązania, możemy zrealizować zamówienie. Możemy również pokazać rozwiązanie użytkownikom i zapytać, czy zmierzamy w dobrym kierunku.

Na koniec…

Ważna sprawa – stosowanie pocisków smugowych nie oznacza rezygnacji z jakości. Pamiętamy o obsłudze błędów, dokumentacji czy ogólnej walidacji danych. Obszar, którym możemy sterować, to liczba funkcji, którą decydujemy się zaimplementować.

Życzę udanych strzałów :)

Źródło zdjęcia: http://en.wikipedia.org/wiki/File:Scorched_Earth_gameplay.png

MoSCoW – szybkie nadawanie priorytetów

MoSCoW, czyli szybkie nadawanie priorytetów

MoSCoW, czyli szybkie nadawanie priorytetów

Pracowałem ostatnio z Zespołem nad nowym, dużym produktem. Oczekiwania Właściciela Produktu oraz interesariuszy były ambitne, jednak dopiero niedawno zostały urealnione przy pomocy Zespołu Scrumowego, który przyglądnął się zadaniu i zaproponował bardzo zgrubne estymaty dla konkretnych obszarów.

Wstępne szacunki pokazały, że cały zakres prac może być gotowy za pół roku. Był to kubeł zimnej wody dla interesariuszy. Jeśli by spojrzeć na wymagania, wszystkie zdawały się jednakowo istotne. Trudno było dostrzec obszary, z których łatwo moglibyśmy zrezygnować.

By temu zaradzić, wraz w Właścicielem Produktu zorganizowaliśmy spotkanie, na którym poprosiliśmy interesariuszy, aby wybrali wymagania, które:

  • muszą zostać spełnione i bez których pierwsze wdrożenie produktu nie miało by sensu
  • powinny zostać spełnione, jednak można w stosunku do nich zastosować alternatywne rozwiązania
  • mogą zostać spełnione, jednak nie są konieczne i pojawią się w produkcie, wyłącznie jeśli czas oraz środki na to pozwolą
  • nie muszą zostać spełnione dla najbliższego wdrożenia

Powstała w ten sposób czytelna lista wymagań, podzielona na cztery kategorie, które precyzyjnie odzwierciedlają ważność konkretnych obszarów. Pozwoliło to przygotować zakres naprawdę niezbędnych prac, który zadowoli interesariuszy, z drugiej strony pozwolił skrócić estymowany czas do pierwszego wdrożenia do dwóch miesięcy.

Technika, z której skorzystałem to MoSCoW (Must, Should, Could, Won’t) i świetnie nadaje się do szybkiego nadawania priorytetów dla list elementów dowolnego typu –  w tym konkretnym przypadku były to elementy Rejestru Produktu. Nic nie stoi na przeszkodzie, aby skorzystać z tej techniki w innych okolicznościach.

Fotografia użyta na licencji Creative Commons od użytkownika o_z_ge.