W mojej firmie jedno zadanie nigdy nie może zostać wykonane przez jedną osobę. Do każdego zadania będzie osobna osoba do kontroli jakości i przeglądu kodu. Oznacza to, że każda osoba poda szacunkowe dane dla każdego zadania, ile czasu zajmie wykonanie zadania.

Problem w tym, jak podejść do spalenia? Jeśli sumuję godziny razem, przyjmij następujące oszacowanie:

10 godzin - czas Dev

4 godziny - QA

4 godz. - przegląd kodu.

Oszacowanie zadania = 18 godzin

Na koniec każdego dnia proszę o aktualizację zadania o „ile czasu pozostało do wykonania”. Jednak każda osoba na ogół myśli tylko o swojej części. Czy powinni oznaczyć pozostały wysiłek, a następnie DODAĆ oszacowania wysiłku do tego? Jak się macie?

AKTUALIZACJA

Aby wyjaśnić kilka rzeczy, w mojej organizacji każde zadanie w historii wymaga 3 osób.

1. Ktoś, kto opracuje zadanie. (wykonaj testy jednostkowe itp.)
2. Specjalista ds. Kontroli jakości do przeglądu zadania (wykonują głównie testy integracji i regresji)
3. Technik do przeglądu kodu.

Nie sądzę, że istnieje zły lub właściwy sposób, ale to jest nasz sposób ... i to się nie zmieni. Pracujemy jako zespół, aby w miarę możliwości ukończyć nawet najmniejszy poziom historii. Nie możesz faktycznie sprawdzić, czy coś działa, dopóki nie zostanie ukończone, i nie możesz też sprawdzić jakości kodu ... więc najlepiej, co możesz zrobić, to podzielić rzeczy na małe logiczne segmenty, aby można było przetestować absolutną minimalną funkcjonalność i sprawdzone tak wcześnie, jak to możliwe.

Moje pytanie do tych, którzy działają w ten sposób, brzmi: jak wypalić „zadanie”, gdy są skonfigurowani w ten sposób. O ile Zadanie nie ma własnych poddziałań (na które JIRA nie zezwala) ... Nie jestem pewien, jak najlepiej śledzić „to, co zostało” na co dzień.

To 3 zadania, a nie jedno.

Może to być jedna funkcja / historia, ale są to trzy zadania. Pojedyncze zadanie może wykonać jedna osoba w określonym czasie.

TL; DR

Używasz wypalenia nieprawidłowo na kilka sposobów. Zadania i historie są albo wykonane, albo niezrealizowane; próbując śledzić odchylenia od szacunkowych planów opartych na czasie w ramach wypalenia, w rzeczywistości ponownie szacujesz swój harmonogram, a nie szacujesz pozostały produkt pracy.

W Scrumie powinieneś mierzyć postępy w osiąganiu celu sprintu, a nie mierzyć jego ramy czasowe. Dzięki temu nacisk kładziony jest na wydajność zespołu i dostarczanie funkcji, a nie na ciągłe dostosowywanie harmonogramu.

Zadania a historie

Łączycie zadania i historie. Historie obejmują wszystkie zadania wymagane do ukończenia historii zgodnie z „definicją wykonanego” zespołu. Fabuła jest uważana za w 100% niekompletną, chyba że wszystkie jej zadania zostaną ukończone. W Scrumie historie są zawsze w pewien sposób szacowane; najczęściej są one szacowane w punktach opowieści.

Zadania to kroki lub kamienie milowe potrzebne do ukończenia historii. Chociaż każde zadanie może mieć zależności i wymagania wstępne, z pewnością można powiedzieć, że przegląd kodu jest kompletny lub nie, niezależnie od innych zadań.

Spalić

W Scrum wykres wypalenia pokazuje ilość pracy pozostałej do sprintu lub projektu. Prawdziwe wykresy spalania często mają płaskowyże; w niektórych przypadkach wykres może nawet wzrosnąć. Na przykład na tygodniowym sprincie z dwiema historiami o wartości 3 i 5 punktów twoje punkty danych mogą wyglądać mniej więcej tak:

Mon | Tue | Wed | Thu | Fri
--- | --- | --- | --- | ---
 8  |  5  |  5  |  5  |  0

W tym idealistycznym scenariuszu zaczynasz od 8 punktów historii. Historia 3-punktowa została ukończona we wtorek po południu, a historia 5-punktowa została ukończona dopiero w piątek. Punkty opowieści nie są odejmowane od wypalenia, dopóki historia nie spełni definicji ukończenia. Jeśli używasz idealnych godzin zamiast punktów fabularnych, jedyną rzeczą, która się zmienia, jest twoja skala.

Boks czasowy

Powszechnie przyjętą praktyką jest upewnienie się, że twoje zadania są podzielone na mniejsze kawałki od 1/2 dnia do 2 dni. Rozbieżność na więcej niż jeden dzień powinna być oczywista na podstawie codziennych pojedynków lub Backlogu Sprintu; nie powinno być potrzeby formalnego pobierania statusu.

Możesz także przeprowadzić analizę statystyczną na wykresie wypalenia, aby ustalić, czy Twój sprint jest prawidłowo trenowany. Małe odchylenia lub płaskowyże są normalne, ale jeśli nikt nie podnosi blokerów w codziennych awariach, ale twoje wypalenie wydaje się utknąć, jest to zazwyczaj znak, że Backlog Sprint został źle oszacowany lub istnieje „niewidzialna praca”, która musi być wyraźnie określone w twoim procesie.

Czy możesz zdefiniować zadanie deweloperskie jako „wykonane”, zanim QA wykona swoją część? Czy możesz zdefiniować przegląd kodu jako „zrobiony” przed zakończeniem tworzenia? Czy QA można „zrobić”, jeśli nie jest napisane przez programistę i przegląd kodu?

Powiedziałbym, że powinieneś połączyć trzy elementy w jedno zadanie, a trzy osoby powinny nad nim pracować.

Scrum NIE mówi, że jakikolwiek przedmiot jest obowiązkiem jednego członka zespołu. Wręcz przeciwnie - za pozycje dziennika sprintu odpowiada ZESPÓŁ. Jeśli wykonanie zadania zajmuje trzy osoby, to tyle.

To nie ma znaczenia Tak długo, jak jest względnie spójny w różnych historiach, twoja tabela wypalenia będzie nadal działać w obie strony. Użyj dowolnego sposobu, który jest najbardziej naturalny dla Twojego zespołu.

Mój zespół faktycznie robi coś w rodzaju hybrydy, choć nie na podstawie formalnego porozumienia. Poświęcamy 16 godzin, jeśli uważamy, że zadanie zajmie jednej osobie dwa dni, ale jeśli dwie osoby skończą razem nad nim, nie zmieniamy go.

Po wstępnym oszacowaniu nieoficjalnie staje się on dla naszego zespołu bardziej procentowy niż pozostała godzina. Jeśli początkowo sądziliśmy, że zajmie to dwa dni, ale po jednym dniu, uważamy, że jest to tylko 25% ukończenia, bierzemy 4 z pierwotnych 16 godzin wolnych. Pozostawia to 12 godzin, a technicznie szacujemy 24, ponieważ prawdopodobnie odejmiemy 4 godziny przez pozostałe 3 dni.

Z początku denerwowało mnie to jako mistrza scrum, ale wydaje się to dziwne, że jest to bardzo naturalny sposób na oszacowanie, ponieważ programiści naprawdę nie lubią dodawać godzin do oszacowania. To wszystko uśrednia, aby wypalenie nadal było przydatne, i to jest ważne.

Pozostały czas na zadanie nie ma większego znaczenia: nic nie może zostać dostarczone, dopóki cała historia nie zostanie ukończona.

Jeśli chcesz śledzić, ile czasu pozostało w historii (ogólnie), poprzez wypełnianie pozostałego czasu na zadaniach, podziel zadania na osobę.

To mówi:

• Duże zadania mogą wskazywać, że twoje historie są zbyt duże. W takim przypadku najlepszym rozwiązaniem jest zmniejszenie zakresu i rozmiaru opowieści, a jeśli je zredukujesz, wystarczające śledzenie pozostałego czasu na zadaniach nie ma już znaczenia (są albo wykonane, albo nie - suma szacunków na nie wykonane zadania jest wystarczająco ziarnisty).
• SCRUM zachęca wszystkich do wybierania potrzebnych działań. Jeśli przypisujesz zadania osobom (w przeciwieństwie do ról), potencjalnie uniemożliwiasz dostarczanie historii, nawet jeśli programista nic nie robi - ponieważ kontrola jakości jest wąska.

Podziel zadanie na wiele zadań i wprowadź je jako zadania, z których każdy jest obsługiwany przez inną osobę.

Oryginalne zadanie: Napraw coś

Nowe zadania: (dziecko rodzica pierwotnego zadania)

• Dev A - Rozwiązanie problemu
• Dev B - Pomoc Dev A w rozwiązaniu problemu (tj. Programowanie par, przegląd kodu)
• Dev A - programista testujący poprawkę za pomocą zestawu danych X
• Dev B - programista testujący poprawkę za pomocą zestawu danych Y.