Poradniki

Wycena skrojona na miarę. Omawianie zadań trwa zbyt długo?

06.08.2018, Krzysztof Grześkowiak

Czy zdarzyło Ci się, że po godzinie trwania refinementu, nie przystąpiliście jeszcze do głosowania? Wyceny w projektach IT to jeden z ważniejszych i bardziej ryzykownych elementów. Od dobrej estymacji zadania czy projektu zależy przyszłość całego przedsięwzięcia. Zbyt wysoka wycena to brak zamówienia od klienta, zbyt niska to strata dla firmy.

Wyceniamy kilkanaście zadań tygodniowo i stale monitorujemy dokładność naszych wycen dlatego na podstawie naszego doświadczenia, nie skupiając się na porównaniu technik przeprowadzania wycen, a zwróceniu uwagi na miękkie i organizacyjne aspekty, chciałbym podzielić się naszymi dobrymi praktykami w cyklu czterech artykułów, które pokażą jakie techniki można zastosować aby samo spotkanie było efektywniejsze.

W dzisiejszym artykule otwierającym nasz cykl chciałbym zwrócić uwagę na pierwszy etap przygotowywania zadań do wyceny, który pełni kluczową rolę, jeśli chcemy aby nasze spotkania były efektywne. Trafne oszacowywanie zadań programistycznych jest bardzo trudną sztuką i wymaga dużej wiedzy i dyscypliny zarówno po stronie programistów, jak i osoby prowadzącej spotkanie. Od początku funkcjonowania scruma w naszej firmie przeprowadziliśmy setki refinementów, w trakcie których tysiące User Stories zostało oszacowanych, zaprogramowanych i dostarczonych do klienta. Przez lata efektywność na wycenach zdecydowanie wzrosła, dlatego chciałem się podzielić z Tobą doświadczeniami, które pomogły usprawnić nam spotkania i przyczynić się do lepszej estymacji.

Dobre przygotowanie zadań

Efektywność wycen User Stories można poprawić już na etapie opisywania zadania i przygotowywania go do wyceny. Polecam zwrócić uwagę na:

  • Czytelne tytuły zadań – tytuł zadania powinien być jednoznaczny, czytelny i korespondować z treścią zadania. Bardzo ogólne tytuły typu „Błąd przy otwarciu formularza” czy „Kiepsko działający filtr” utrudniają nawigację po backlogu. Zamiast tego zadania mogłyby nazywać się „Użytkownik bez uprawnień otrzymuje nieczytelny błąd” oraz „Niespójne filtrowanie po datach”.
  • Stały format zadaniaprzygotowując zadania zachowaj ich stały układ, tak aby zespół nie tracił czasu na szukanie informacji pośród treści zgłoszenia. Zwróć uwagę na to, żeby struktura User Story, miała zachowaną strukturę i przedstawiała informacje o tym, kto ma jaką potrzebę i dlaczego. Przykładowy układ:

[User Story]

[Sprawdzić, że]

[Logi]

[Makieta]

  • Odpowiednia wielkość zadań – sprawne realizowanie tego punktu wymaga doświadczenia. Z czasem będziesz potrafił ocenić, że dana potrzeba biznesowa jest zbyt rozległa i najpewniej zadanie zasługuje na rozbicie na mniejsze zadania. Bardzo dobrym sprawdzianem czy dane zadanie mieści się w pojedynczym zgłoszeniu, jest łatwość napisania User Story. Jeśli w uzasadnieniu biznesowym lub powodzie podjęcia chcesz wpisać więcej, niż jedną rzecz, to znaczy, że czas na rozdzielenie zadań.
  • Unikaj dzielenia zadań na częścizamiast napisać Wyszukiwanie zakończonych spraw cz. I, cz. II, cz. III, lepiej jest sprecyzować co konkretnie mamy na myśli np.  Wyszukiwanie zakończonych spraw – projekt UX, Wyszukiwanie zakończonych spraw – Okno wyszukiwania, Wyszukiwanie zakończonych spraw – Wyszukiwanie po nazwie użytkownika
  • Obraz wart więcej niż tysiąc słów – jeśli możesz do danego zadania dołączyć mapę procesu, opisany zrzut ekranu z aplikacji, makietę czy nawet prosty film obrazujący zachowanie aplikacji – zrób to. Zespół będzie potrzebował mniej czasu na zrozumienie problemu.

Pozwól zespołowi zapoznać się z zadaniami przed spotkaniem

Lista zadań do wyceny powinna być ogólnie dostępna, tak aby każdy członek zespołu mógł w dowolnym momencie się z nimi zapoznać. Osobą odpowiedzialną za utrzymanie kolejki zadań jest Product Owner. Możesz np.

  • Na około 30 minut przed spotkaniem przygotować listę zadań, które są celem refinementu i przekazać ją zespołowi deweloperskiemu np. na komunikatorze firmowym.
  • Już na etapie planowania sprintu wydzielić czas na przygotowanie się do wycen oraz zadbać o to, aby rozpoznaniem każdego z zadań zajął się przynajmniej jeden programista.

Dzięki zastosowaniu tych kilku zasad, zespół zyskuje możliwość przygotowania się do wycen, a sam czas potrzebny na zapoznanie z zadaniem jest o wiele krótszy. Pamiętaj, że ceremonia wycen jest szczególnie trudnym spotkaniem i wymaga zdobycia doświadczenia zarówno przez Product Ownera, jak i zespół. Powyższe wskazówki to jedynie zbiór naszych dobrych praktyk, które ułatwiają nam precyzyjne planowanie. Pamiętaj, że najważniejsza jest praktyka w prowadzeniu spotkań i szczera wspólna ich ocena. Wyceny, jak każdy inny aspekt scruma czy po prostu naszej pracy, mogą być poddawane ulepszaniu i retrospektywie. W następnym artykule opiszę jak dobrać odpowiednią formę przeprowadzenia spotkania w zależności od rodzaju wycenianych zadań.

#contmanway
Więcej w kategorii >
23.05.2018, Autor: Magdalena Tuchowska
Zmiana pracy to jedno z bardziej stresujących wydarzeń w naszym życiu. Przejście przez pierwsze trzy miesiące w nowej firmie bez opieki przewodnika jest jak ...
Czytaj więcej
Aktualności
Więcej w kategorii >
31.07.2018, Autor: Piotr Szpakowski
W ostatnich dniach w sieci pojawiło się kilka wpisów m. in na portalu forsal.pl czy też cashless.pl przypominających o planowanym na październik przejęciu cz...
Czytaj więcej
Case Studies
Więcej w kategorii >
13.08.2018, Autor: Krzysztof Grześkowiak
Startujesz z nowym projektem? Chcesz zrobić wycenę nowych funkcji dla już budowanego produktu? A może klient zgłosił jedynie Change Request do istniejącego p...
Czytaj więcej
Po godzinach
Więcej w kategorii >
13.09.2016, Autor: Dawid Tomaszewski
Ansel Adams kiedyś powiedział: „prawdziwa fotografia nie musi być wyjaśniana, ani nie może być zawarta w słowach”. Każdy z nas widział zdjęcie, na które pier...
Czytaj więcej
13.08.2018, Autor: Krzysztof Grześkowiak
Startujesz z nowym projektem? Chcesz zrobić wycenę nowych funkcji dla już budowanego produktu? A może klient zgłosił jedynie Change Request do istniejącego p...
Czytaj więcej