Co to jest „rój”?

Słyszałem o roju w kontekście programowania zwinnego lub ekstremalnego. Wydaje się być uzupełnieniem parowania.

Co to dokładnie jest Kiedy należy to zastosować? Jak to robisz dobrze?

Chodzi o to, że wszyscy w twoim zespole pracują nad tą samą historią w tym samym czasie. Zamiast skupiać się na różnych zadaniach, wszyscy koncentrują się na jednym zadaniu na raz, aż do jego ukończenia. Następnie przechodzą do następnej rzeczy, gdzie wszyscy razem nad tym pracują.

Pomaga to drużynom, które mają problemy z ukończeniem historii przed końcem sprintu. Często drużyny kończą 80% wszystkich opowiadań, ale żadna nie jest kompletna. Jest to mniej przydatne niż całkowite ukończenie 80% historii, ponieważ niedokończone historie (skutecznie) nie mają żadnej wartości dla użytkownika końcowego. Ukończenie historii jest łatwiejsze, gdy wszyscy w zespole skupiają się na jednej historii na raz. Taka jest motywacja roju.

Tutaj są pewne trudności. Na przykład QA nie zawsze może testować rzeczy przed ich zbudowaniem (lub nawet zaprojektowaniem). W takim przypadku powinieneś ustalić projekt razem wcześnie, a następnie QA może napisać (początkowo nieudane) testy w stosunku do projektu, a nie faktycznej implementacji.

Rój odnosi się tylko do faktu, że wiele osób współpracuje ze sobą, aby ukończyć zadanie lub historię. Z mojego doświadczenia nie robisz tego często.

Zazwyczaj każdy członek mojego zespołu pracuje nad innym zadaniem i / lub inną historią. Jeśli ktoś pozostaje w tyle lub istnieje chęć wcześniejszego ukończenia zadania lub historii, inni przestaną pracować nad innymi zadaniami i „roją się”, aby je wykonać, co oznacza, że ​​wszyscy pracują razem nad jednym zadaniem lub historią, dopóki jest zakończony.

Niedawno mieliśmy niewielką liczbę opowiadań, które były dość nudną, nieciekawą pracą. Dałem zespołowi niewielką zachętę (pizza) i termin (koniec dnia) na zakończenie pracy, więc zajęli się tą historią i znokautowali co najmniej kilka dni pracy w ciągu jednego popołudnia. Wykonali pracę wcześnie, a następnie każdy członek zespołu powrócił do tego, nad czym pracowali. Dostali bezpłatny lunch, wcześnie wykonałem pracę, która mogła ciągnąć się z powodu nudnej natury, a zespół wyprzedził ich sprint. Win-win-win.

„Rój” to nic innego, jak wymyślne określenie „hej, pomóżmy w tym”.

Rój jest tak naprawdę centralną koncepcją zwinności. Nie robi się tego „w przypadku problemów”. Rój, w najprostszej formie, oznacza, że ​​zespoły pracują wspólnie nad przedmiotami (opowiadaniami) i pracują nad nimi do końca. Podstawową koncepcją jest „rzucić i zacząć kończyć”. Innymi słowy, zamiast każdego dewelopera pracującego niezależnie nad historią, zespół skupia się na bardziej ograniczonym zestawie historii / zadań i każdy z nich wykonuje wcześniej. Potraktuj to jako różnicę między systemem jednowątkowym a wielowątkowym. Jeśli historia użytkownika ma 10 zadań do wykonania, a każde z nich trwa 8 godzin, przy założeniu, że nie było żadnych komplikacji, jeden programista może wykonać każde zadanie sekwencyjnie i ukończyć historię w 80 godzin lub około dwóch tygodni (przy 10-dniowym sprincie 8 godzin programistycznych dziennie). Co się stanie, jeśli dwóch programistów podzieli zadania i wykona je jednocześnie? W ten sam sposób można ukończyć te same 80 godzin pracy w ciągu jednego tygodnia. Dodaj trzeci, a zobaczysz, że można to zrobić za 3 do 4 dni.

Rój można wykonać na kilka sposobów:

1. Programowanie w parach (dwóch programistów siedzących obok siebie, aby pracować nad kodem, jeden to „sterownik” piszący kod, drugi to nawigator, pamiętający o długoterminowym kierunku i pomagający jednocześnie przeglądać kod.
   2. Praca w parach: programista i tester pracują jednocześnie nad tą samą pracą, jednym kodowaniem, a drugim testowaniem, automatyzacją pisania itp.
   3. Roi się, jak wspomniałem powyżej, co jest bardzo częste. Zwykle członkowie zespołu roją się od Historii, ale każda z nich ma indywidualne zadania w tej metodzie.
   4. Programowanie mobów: cały zespół koncentruje się na jednej historii (lub nawet zadaniu) na raz.

Zespoły, które opowiadają historię każdemu programistowi, zwykle mają zbyt dużo „pracy w toku” lub WIP, a często wiele historii zaczyna się, ale nie kończy. Jest to ANTYPATTERN i NIE jest to najlepsza praktyka.

Zespoły, które roją się, mają zwykle mniej PWT i uzupełniają więcej historii - a przez gotowe mam na myśli Opracowane, Testowane, Zatwierdzone, gotowe do wdrożenia. Jest to więc praktyka, która jest podstawą zwinności.

Poniższy artykuł na temat InfoQ opisuje jedno podejście do roju:

• Zespół używa programowania mob do większości swoich zadań związanych z kodowaniem
• Część zespołu lub poszczególni członkowie zespołu często dzielą się i dołączają do zespołu w krótkich odstępach czasu
• Wszyscy robią wszystko (bez ról)
• Zespół nie używa szacunków, WIP jest zawsze jeden, nie ma potrzeby stójek lub podobnych ceremonii

Przeczytaj artykuł, aby uzyskać szczegółowe wyjaśnienie.