piątek, 31 stycznia 2014

Proces estymacji wymagań w Scrum

metody estymacji w scrum
Rolą estymacji jest przede wszystkim dostarczenie informacji o potencjalnym czasie wykonania w oparciu o złożoność wymagań w produkt backlog. Wiedza która za sobą niesie estymacja jest istotna dla zespołu który w oparciu o nie zobowiązuje się dostarczyć w ramach iteracji określoną porcję nowych funkcjonalności (tzw. sprint commitment), jak również dla Produkt Ownera który musi zaplanować kalendarz releasów produktu. Zazwyczaj wstępny szacunek jest dodawany do itemu podczas tworzenia go w product backlog a modyfikowany podczas aktualizacji (np. rozszerzania zakresu o nowe przypadki biznesowe, podzielenia itemu na mniejsze, dospecyfikowania szczegółów funkcjonalnych czy technicznych). Estymacje na różnych poziomach budowania produktu niosą za sobą nieco inną informację. Estymacje na poziomie planowania releasów nie są aż tak zobowiązujące dla zespołu, są jedynie inicjalną wartością która jest brana w oparciu o wiedzę i przewidywania doświadczonych członków zespołu. Estymacje dostarczane podczas backlog grooming czy sprint planning muszą być znacznie dokładniejsze, przedstawiać orientacyjny czas pozwalający w oparciu o niego zaplanować ilość pracy w sprincie. Wszelkie estymacje powinny być dostarczone przez zespół który później będzie implementował dane wymaganie, w przeciwnym razie istnieje duże ryzyko, że estymacje nie pokryją się z czasami wykonania. Podsumowując to krótkie wprowadzenie należy zaznaczyć, iż Scrum sugeruje estymować itemy w oparciu o abstrakcyjne jednostki zamiast przypisywać itemom konkretne wartości czasu.

Jednostki estymacji itemów w product backlog:
  • Rozmiar Tshirt (XS, S, M, L, XL,XXL)
  • Story Points (zmodyfikowany ciąg Fibonacciego)
  • Idealny czas (dni/godziny)

Estymowanie rozmiarem T-shirt - bardzo prosta technika estymowania polegająca na przypisywaniu każdemu z wymagań predefiniowanego rozmiaru (XS- bardzo mały, S-mały, M-średni, L-duży, XL-bardzo duży, XXL- ogromny). Jak dobrze widzicie są to wartości odpowiadające rozmiarom ubrań. Metoda bazuje na przełożeniu dobrze rozumianej przez ludzi różnicy pomiędzy rozmiarami ubrań na rozmair wymagań. Zaletą metody jest jej szybkość i prostota, każdy zespół bez większych problemów będzie w stanie przypisać każdemu wymaganiu wartość rozmiaru. Istotną kwestią aby robić to wydajnie jest ustalenie i zrozumienie wielkości bazowej dla XS tak aby zespół miał  odniesienie estymując itemy o większym rozmiarze. Minusami metody jest jej niedeterministyczność, itemy mogą mieć przydzielane rozmiary w oparciu o planning poker kartami z rozmiarami lub dyskusję członków zespołu, często podczas rozmowy rozmiar XL co innego znaczy dla kilku członków zespołu (nie wiedzą czy rozmiar L jest większy od M o 10% czy 20%). Kolejny minus to brak możliwości sumowania itemów, na koniec procesu szacowania mamy x itemów w każdym z rozmiarów. Metoda zalecana zespołom które dopiero zaczynają przygodę z estymacją, sugerowane aby po pewnym czasie zaczęły operować na  liczbach (najlepiej story points).

Estymowanie w story points - abstrakcyjna metoda estymacji itemów w produkt backlogu w oparciu o przypisywanie każdemu estymowanemu itemowi określonej liczby punktów. Tak samo jak w przypadku pozostałych metod należy na początku określić porcję pracy której będzie odpowiadać jeden story point a dopiero później w oparciu o tą wiedzę przypisywać liczbę punktów itemom o większej złożoności. Zaleca się ustalenie wspólnego zrozumienia story point dla wszystkich zespołów scrumowych w organizacji w przeciwnym razie jest prawie pewne, że zespoły przyjmą różną definicję 1 story point. Warto nadmienić, że ilość dostępnych do przypisania wartości jest ograniczona zmodyfikowanymi wartościami ciągu Fibonacciego (0.5,1,2,3,5,13,40,100) przez co proces estymacji idzie sprawniej. Ważny jest fakt, że zespół ustala między sobą końcową wartość estymacji dopóki wszyscy się na nią nie zgodzą. Posługując się techniką planning poker zespół przydziela odpowiednią liczbę strory points do każdego wymagania. Kolejną zaletą tej metody jest możliwość zliczania i sumowania story points wszystkich dostarczonych podczas iteracji itemów co przekłada się na trackowanie velocity zespołu. Z iteracji na iterację tendencja velocity, czyli suma story points wszystkich dostarczonych itemów powinna wzrastać. Natomiast dla pełnego badania velocity należy ustawić bramkę jakości tak aby monitorować liczbę błędów, aby zobaczyć czy velocity zespołu nie wzrasta kosztem jakości produktu, wiekszej ilości błędów. Jednostka szczególnie rekomendowana przez scrum.

Estymacja w idealnym czasie (dni/godziny) - ostatnia z prezentowanych metod to estymacja w oparciu o idealne dni lub godziny. Większość ludzi ma wspólne rozumienie idealnego dnia roboczego lub idealnej roboczogodziny. Zastosowanie tej metody wymaga jak w przypadku poprzednich wspólnego rozumienia co kryje się pod pojęciem idealnego dnia czy godziny. Zazwyczaj estymowanie w oparciu o idealne dni/godziny wymaga od zespołu bardzo dobrego zrozumienia wymagania i określonych predyspozycji. Trzeba mieć również na uwadze, że estymując wymagania w czasie idealnym możemy często spotkać się z przekroczeniem. Przykładem na to może być mecz piłkarski który trwa według idealnego czasu 90 minut lecz prawie zawsze po 90 minutach się nie kończy... zazwyczaj zajmuje więcej czasu.

Sugerowane jednostki estymacji na różnych poziomach rozwoju produktu: 
  • Portfolio Management (portfel projektów) - stosujemy rozmiar
  • Release Management (2-5 miesięcy) - stosujemy story points lub idealne dni
  • Backlog Refinement Meeting (zakres 1-2 najbliższych sprintów) - stosujemy story points lub idealne dni
  • Sprint Planning (zakres sprintu wraz z podzialem na taski) - stosujemy idealne godziny 

Drodzy praktycy Scrum a jak Wasze wymagania są estymowane na poszczególnych etapach ??

    4 komentarze:

    1. Czy artykuł nie opisuje miar używanych w estymacji? Metodą estymacji wydaje się planning poker?
      Radek

      OdpowiedzUsuń
    2. Post opisuje zarówno jednostki/miary estymacji jak i metody i miejsca ich użycia. Zgadzam się iż najpopularniejszą metodą szacowania jest planning poker (wspomniany zresztą w kontekście rozmiaru Tshirt i story points) natomiast nie jedyną. Metodą samą w sobie jest estymowanie w opariu o idealne dni czy godziny.

      OdpowiedzUsuń
    3. Witam, bardzo dobry i bogaty merytorycznie blog.

      Odnosząc się do mojego małego zespołu i braku wszystkich sugerowanych ról w metodyki scrum, ciężko mi jest zrozumieć sens estymacji w innych jednostkach niż godziny.

      W moim rozumieniu sens estymacji polega na prawidłowym oszacowaniu czasu wykonania konkretnych tasków, które łącznie będą wchodzić w skład Sprintu. Czy nie lepiej wycenę przygotowywać w oparciu o konkretne wartości godzinowe co ułatwi nam później szacunki co do estymacji całego sprintu?
      Po estymacji tasków zespół powinien dokonać reorganizacji user stories i przedstawić Product Ownerowi ile będzie w stanie wykonać w danym Sprincie - w jaki sposób ma zostać to oszacowane jeśli nasza estymacja czasowa nie jest oszacowana w godzinach tylko w przyjętych jednostkach?
      Domyślam się, że w grę tutaj wchodzi doświadczenie zespołu oraz scrum mastera pod kątem wydajności zespołu oraz umiejętność odniesienia tej wydajności do jednostki czasu, lecz w niewielkich zespołach które rozpoczynają dopiero przygodę z Scrumem chyba najefektywniejsza będzie estymacja godzinowa gdyż łatwo wtedy odnieść estymację sprintu do jego długości.

      Pozdrawiam

      OdpowiedzUsuń
      Odpowiedzi
      1. Czesc Maciek,

        na wstępie przepraszam Cię za naprawdę długi czas oczekiwania na odpowiedź, ten miesiąc był dla mnie "wyjątkowo wymagający".

        Co do Twojej wypowiedzi, dobrze rozumiesz proces estymacji w godzinach i robi się to tak jak opisałeś. Jednakże zanim dotrzemy do wyceny godzinowej, która jest drugim etapem planowania iteracji powinniśmy wcześniej zespołowo razem z obecnym Produkt Ownerem oszacować wymagania w punktach.

        Taka wycena jest istotna z kilku względów, pierwszy to taki aby zespół rozeznał się w oparciu o wymaganie referencyjne jaka jest złożoność kolejno omawianych wymagań. Następnie PO mając informację o złożoności, listę priorytetów od klienta oraz uwzględniając wydajność zespołu z poprzednich sprintów będzie potencjalnie wiedział ile może się spodziewać od zespołu w ramach kolejnej iteracji.

        Oczywiście zespół który dopiero zaczyna przygodę ze scrum nie będzie miał określonej stabilnej wydajności, to przyjdzie z czasem w ramach prac nad kolejnymi sprintami. Warunkiem koniecznym aby ta metryka zespołu miała sens jest stałość zespołu i niezmienność długości sprintu. Warto tu również obalić mit że wydajność zespołu rośnie w nieskończoność, otóż nie rośnie do pewnego momentu i się wysyca...

        Idąc dalej złożoność wymagań powinna być wyceniana przez cały zespół nieco wcześniej, np. podczas spotkania pielęgnującego product backlog gdzie zespół może w oparciu o wiedzę Product Ownera dokładniej określić złożoność wymagania w punktach. Warto tutaj zaznaczyć że często stosuje się technikę tabeli porównawczej gdzie zestawia się ze sobą wszystkiewymagania z tą samą liczbą punktów np.wszystkie 8 i jeszcze raz decyduje czy dokonać zmian.

        Mając tak określone wymagania product owner przychodzi na spotkanie planujące sprint i negocjuje z zespołem potencjalny zakres nowego sprintu. Na koniec zespół zgadza się na pewien zakres czyli tzw. prognozę zakresu iteracji. Dopiero wówczas dochodzi do wyceny każdego z wymagań w rozbiciu na zestaw zadań estymowanych w godzinach. Warto podsumować na koniec spotkania wartości godzinowe w ramach konkretnych działek/unikalnych umiejętności np. testów automatycznych, implementacji backendu i upewnić się że są zabezpieczone w zespole. Jeśli nie należy negocjować z PO zakres iteracji.

        Wszystkie te techniki i praktyki są stosowane tylko i wyłącznie po to aby na koniec sprintu zespół był w stanie dostarczyć daną prognozę, mając tak działający proces jest to z korzyścią dla obu stron.

        Usuń