-
Notifications
You must be signed in to change notification settings - Fork 0
Pivotal Tracker
- Feature - wykonanie tego zadania polega na zaprojektowaniu, zaimplementowaniu, przetestowaniu oraz zintegrowaniu funkcjonalności dostarczającej nową wartość biznesową.
- Bug - story posiadające kroki do reprodukcji buga, jego rezultat oraz rezultat oczekiwany (gdyby bug nie istniał). Cykl życia podobny jak dla feature'a, z tą różnicą, że nie dodajemy nowej wartości biznesowej, a przywracamy już istniejącą.
- Chore - wykonanie zadania ulepsza techniczną warstwę aplikacji, zmniejsza dług technologiczny, natomiast nie dodaje żadnej wartości biznesowej i jest niezauważalne z punktu widzenia użytkownika końcowego.
- Release - story określające konkretną wersję softu lub konkretny milestone oraz jego deadline.
Stories mogą posiadać bardziej wyspecyfikowane zadania, których wykonanie zbliża nas do ukończenia danego story. Te zadania nazywamy taskami i widnieją one na liście "tasks" w szczegółach story. Najcześciej taski są odniesieniami do konkretnych issues na githubie. Task uznajemy za zakończony i oznaczamy ptaszkiem w momencie, kiedy pull request jego dotyczący zostanie zamknięty.
- Feature: unstarted -> started -> finished -> delivered -> accepted
- Bug: tak samo jak feature
- Chore: unstarted -> started -> accepted
- Release: unstarted -> accepted
- Unstarted - story nie zostało zaczęte.
- Started - story jest w trakcie realizacji (Developer).
- Finished - wszystkie taski do tego story zostały ukończone - pull requesty zamknięte (Developer).
- Delivered - kryteria akceptacji sprawdzone przez testera (Tester), w przypadku braku testera w zespole stan ten jest jednoznaczny ze stanem finished (Developer).
- Accepted - wartość biznesowa zostaje potwierdzona (Product Owner).
W nawiasie podana jest osoba, która jest odpowiedzialna za ustawienie danego stanu.
Dla feature'ów istnieje jeszcze możliwość odrzucenia danego zadania, czyli stan "rejected". Ustawiany jest on przez Product Ownera po stwierdzeniu, że story nie wnosi określonej wartości biznesowej. W przypadku odrzucenia story Product Owner zobowiązany jest w komentarzu podać powód odrzucenia. Jeśli story spełnia wartość biznesową, ale posiada jakieś niewielkie bugi, story zostaje zaakceptowane, a bugi zgłoszone oddzielnie.
Zadania typu feature estymujemy w story pointach. Dozwolone wartości to 0 oraz potęgi dwójki: 1, 2, 4, 8. Punkty określają nie tyle czas potrzebny na wykonanie zadania, co raczej jego trudność. Wynika to z faktu, że ludziom dużo łatwiej szacować skomplikowanie zadania od czasu potrzebnego na jego wykonanie, a przy odpowiedniej ilości danych statystycznych punkty można skonwertować na czas, co pozwala oszacować prędkość całego zespołu. Inne typy stories ze względu na to, że nie dostarczają wartości biznesowej, nie otrzymują także story pointów. Ma to na celu odpowiednie ukierunkowanie pracy zespołu na wartości biznesowe. Wysiłek konieczny na wykonanie innych stories jest po prostu "wliczony w koszt" wykonania feature'ów.
Aby ułatwić estymację danego story, możemy sobie zadać 3 pytania:
- Czy wiemy dobrze co zrobić?
- Czy wiemy jak to zrobić?
- Czy zadanie wygląda na małe?
Następnie liczymy ile razy odpowiedzieliśmy "nie" i do tej potęgi podnosimy liczbę 2. Otrzymany wynik to liczba story pointów danego feature'a.
Przykłady:
- Wylogowanie użytkownika: wiemy dobrze co zrobić, wiemy jak to zrobić oraz zadanie jest małe - liczba odpowiedzi "nie" to 0, czyli estymacja wynosi 2^0 = 1.
- Implementacja paska pokazującego siłę hasła podczas tworzenia nowego konta oraz zmiany hasła: wiemy co zrobić, wiemy jak, ale zadanie nie jest małe, ponieważ policzenie entropii danego hasła jest trudne ze względu na skomplikowane kryteria, pasek musi zostać odpowiednio zaprojektowany graficznie oraz umieszczony w różnych miejscach. Liczba odpowiedzi "nie" to 1, estymacja jest równa 2^1 = 2.
- Użycie technologii intel SGX w celu dokonania podpisu cyfrowego: dość dobrze wiemy co zrobić. Natomiast nie wiemy jak, ponieważ nie znamy bibliotek oraz możliwości technologii. Zadanie nie wygląda na małe, ponieważ być może nie będziemy mogli skorzystać z gotowych rozwiązań. Liczba odpowiedzi "nie" to 2, estymacja: 2^2 = 4.
Dodatkowo 0 oznacza, że mamy coś praktycznie za darmo (np. wbudowane w framework) i nie musi przechodzić całego procesu dodawania danego feature'a, natomiast stories estymowane jako 8 powinny być raczej rozbite na mniejsze stories, które będą ponownie estymowane. Generalnie powinniśmy w miarę możliwości dążyć do rozpisania zadań na dużo łatwych do wykonania stories. Dzięki temu śledzenie postępu jest łatwiejsze, nowe zmiany integrowane są częściej, a sam proces ich integracji jest prostszy.