Scrum: Jak pracować nad jedną historią na raz

Zostałem nominowany na mistrza scrum w nowo powstałym zespole scrumowym. Zrobiliśmy już kilka sprintów. Na początku starałem się, aby mój zespół pracował nad jedną historią na raz. Ale to nie zadziałało. Mój zespół miał trudności z rozdzieleniem zadań w taki sposób, aby mogli pracować jednocześnie nad jedną historią. Może robimy coś złego?

Na przykład: mamy historię do utworzenia nowego okna dialogowego. Tworzymy następujące zadania:

• Utwórz klasy modeli
• Odczytaj dane modelu z bazy danych
• Połącz klasy modeli z widokiem
• Zaimplementuj obsługę okien dialogowych
• Zapisz dane przy zamknięciu
• Dokumentacja testowa
• Opis rozwiązania

Czy te zadania mogą być wykonywane jednocześnie przez więcej niż jedną osobę? Zadania - mniej więcej - opierają się na sobie. A może projektujemy zadania w niewłaściwy sposób?

Dlaczego cały zespół powinien pracować nad jedną historią?

Dlaczego nie uczynić opowieści wystarczająco małymi (i wystarczająco niezależnymi), aby jedna osoba (lub lepiej jedna para zajmująca się programowaniem par) mogła pracować nad jedną historią. Ten proces pomaga również lepiej zdefiniować wymagania i lepiej przemyśleć zarówno problem, jak i jego wdrożenie. Szacunki mogą być również bardziej dokładne, ale nie ma tutaj żadnych gwarancji.

Chociaż zależy to w dużej mierze od wielkości historii użytkownika, w wielu przypadkach do historii należy przypisać tylko jednego programistę, aby uniknąć sytuacji, w której programiści staną sobie na palcach. Większe lub bardzo złożone historie mogą wymagać większej liczby programistów, ale może być również możliwe podzielenie tych historii na wiele mniejszych historii, które można indywidualnie przypisać.

Generalnie dzielimy historie na podzadania deweloperów / infra / analityków.

1. Zasadniczo wszystko, co trwa dłużej niż jeden dzień pracy, jest historią.

2. Po podziale zadań jeden lub maksymalnie dwóch programistów pracuje nad historią, w zależności od liczby dostępnych zadań. Zwykle jest to jeden.

3. Rejestrujemy spędzony czas i aktualizujemy pozostałe szacunki na koniec dnia przed wyjazdem lub przed codziennym wstawaniem.

4. Podzadania są tworzone dla wszystkich nowych problemów pojawiających się podczas pracy.

5. Historia trwająca ponad 2 tygodnie jest uważana za epos.

6. Epos może składać się z wielu historii

To, co chcesz, aby twój zespół nazywał się rojem , ale nie każdy element zaległości może zostać zalany przez cały zespół. Powszechnie uważa się, że rój wymaga pewnych warunków wstępnych:

• połączony, funkcjonalny zespół
• nietrywialna historia
• definicja „zrobione”, która zakłada zaangażowanie całego zespołu

Podczas dzielenia historii na zadania zespół powinien być już w trybie roju, aby wygenerowane zadania były zgodne z rojem i mogły angażować cały zespół.

Ale bądź ostrożny, gdy zbyt często używasz roju lub zbyt wielu ludzi naraz, ponieważ możesz natknąć się na problem nadmiernego ocieplenia, gdy mogą wystąpić pewne konflikty między członkami zespołu, ponieważ zbyt wielu pracuje nad tym samym przedmiotem.

Być może zechcesz przeczytać artykuł Mike'a Cohna Czy zespół powinien roi się od jednego elementu zaległości naraz? lub ten artykuł, który napisałem (wczoraj), który dotyczy bardziej szczegółowo błędów: rój lub nie rój

Duża część SCRUM polega na tym, że zespół powinien podejmować tego rodzaju decyzje. Historia zaległości powinna zawierać historie użytkowników zawierające informacje wystarczające do wygenerowania zadań.

Chociaż może być możliwe przekonanie historii użytkownika do elementu, nad którym cały zespół może jednocześnie pracować, ważniejsze jest to, że zespół wybiera elementy, nad którymi ma pracować, określa zadania do ukończenia historii użytkownika i korzysta z codziennego stanowiska aby sprawdzić, czy jesteś na dobrej drodze do obiecanej pracy.

Zespół odczuwa ból, który odczuwasz, próbując pracować tylko nad jedną historią na raz, a podczas sprintu należy zastanowić się nad potencjalnymi rozwiązaniami. Dowiedz się, co robisz dobrze i co należy poprawić.

Korzystając z przykładu trudności w rozdzielaniu zadań, nad którymi można pracować jednocześnie, jednym z możliwych rozwiązań jest przejęcie wielu historii i dostarczenie 3 lub 4 przedmiotów w sprincie. Ponieważ zadania dla tej historii użytkownika budują się jedna na drugiej, trudno będzie rozpowszechniać pracę. Więc zamiast walczyć, to obejmuje.

Twoje zadania, jak wskazano, wydają się „wystarczająco małe”, aby je rozdzielić, ale istnieje pewne powiązanie między zadaniami, takimi jak zadanie modelowania danych i pobierania ich z bazy danych.

Możliwe byłoby podzielenie go na trzy główne rzeczy, nad którymi ludzie mogą pracować jednocześnie, z dodatkowymi pracami / konfiguracją:

• Back-end (baza danych, model itp.)
• Front-end (przy użyciu fałszywych danych)
• Testy (konfigurowanie oczekiwań, scenariusz itp.)

Zadania, których nie można podzielić, można wykonać parami. I oczywiście nie ma nic złego w tym, że w danym momencie trwa więcej niż jedna historia; tak długo, jak każdy członek zespołu wie, co robią inni, i może im pomóc, gdy zajdzie taka potrzeba (np. „własność wspólnego kodu”).

Powinieneś skupić swój zespół, tak, ale jednocześnie musisz dbać o to, aby wszyscy byli zajęci i wszyscy byli zaangażowani.

Jak duży jest twój zespół? To jest także czynnik; ciężko jest mieć dziesięć osób pracujących nad jedną historią, a jeśli możesz, twoja historia jest o wiele za duża i powinna być podzielona (podobnie jak twój zespół).