Tworzenie produktywnych zespołów

Inżynierowie rozwijają się w środowiskach, w których mogą się skupić i wejść w tryb maksymalnego skupienia. Zespoły często napotykają rozproszenie uwagi i konkurencyjne priorytety, które zmuszają inżynierów do zmiany kontekstu i dzielenia uwagi. Walczą o zrównoważenie głowy w dół czasu z głowy w górę czasu. Dodanie nowych funkcji wymaga, aby członkowie zespołu byli w pełni skupieni i skoncentrowani. Reagowanie na problemy klientów i rozwiązywanie kwestii związanych z witryną na żywo wymaga, aby zespół był czujny i świadomy aktualnych zdarzeń.

Aby ograniczyć rozproszenie uwagi, zespół może podzielić się na dwie zespoły: jeden dla funkcji i jeden dla utrzymania strony na żywo.

Podejście dwuosobowe daje większą produktywność i przewidywalność. Pomyślna implementacja opiera się na następujących kluczowych elementach:

• Jasno zdefiniowane role załogi
• Dobrze zdefiniowany proces rotacji załogi
• Częste korekty wielkości załogi

Zespół funkcji

Zespół funkcjonalności, lub F-crew, koncentruje się na przyszłości. Pracują one jako efektywna jednostka mająca wyraźną misję i cel: tworzenie i dostarczanie wysokiej jakości funkcji.

Zespół F jest osłonięty przed codziennym chaosem serwisu live, aby mieli czas na zaprojektowanie, zbudowanie i przetestowanie swojej pracy. Mogą polegać na minimalnym rozpraszaniu i braku konieczności rozwiązywania problemów, które pojawiają się losowo. Zachęcamy ich do rzadkiego sprawdzania poczty e-mail i unikania angażowania się w inne problemy, chyba że są to kwestie krytyczne.

Kiedy członek załogi F dołącza do rozmowy lub od czasu do czasu przyciągany do wątku e-mail, inni członkowie zespołu powinni go upominać: "Jesteś w załodze F, co robisz?" Jeśli członek załogi F musi rozwiązać krytyczny problem, zachęcamy ich do przekazania go do zespołu ds. klienta i powrotu do pracy nad funkcjami.

Załoga F działa jako ściśle zgrany zespół, który koncentruje się na niewielkim zestawie funkcji. Dobry limit pracy w toku (WIP) to dwie funkcje lotu dla 4-6 osób. Ściśle współpracując ze sobą, tworzą głęboki wspólny kontekst i znajdują krytyczne usterki lub problemy projektowe, którego nie wychwyciłaby pobieżna recenzja kodu. Dedykowana załoga umożliwia bardziej przewidywalną szybkość przepływności i czas realizacji. Członkowie zespołu często odnoszą się do załogi F jako spokojnej i skoncentrowanej. Uważają, że skupienie pełnej uwagi na jakimś aspekcie jest spokojnym i odmładzającym doświadczeniem. Ludzie opuszczają F-crew czując się odświeżeni i spełnieni.

Załoga klienta

Zespół obsługi klienta lub zespół C-crew koncentruje się na teraźniejszości i zapewnia wsparcie na pierwszej linii dla klientów oraz problemów związanych z witrynami na żywo, usterek, telemetrii i monitorowania. Załoga C często gromadzi się wokół komputera, debugując krytyczny problem na działającej stronie. Ich priorytetem numer jeden jest kondycja lokacji na żywo. Skupieni na tym środowisku, rozwijają specjalistyczne umiejętności debugowania i analizy. Załoga klienta jest często nazywana zespołem ochronnym, ponieważ chroni resztę zespołu przed niepotrzebnymi zakłóceniami. Zamiast pracować nad nadchodzącymi funkcjami, zespół C-crew jest mostem między klientami a bieżącym produktem. Członkowie załogi są aktywni w wiadomościach e-mail, Twitterze i innych kanałach opinii. Klienci chcą wiedzieć, że są słyszani, a zadaniem zespołu C-crew jest ich wysłuchać. Zespół C-crew natychmiast klasyfikuje zgłoszone przez klientów problemy oraz szybko angażuje się i pomaga zablokowanym klientom.

Praca w szybko rozwijającym się zespole C, przy zalewie zadań, czasami może być emocjonująca. W napiętym tygodniu zajmują się wieloma wiadomościami e-mail, inspekcjami na żywo i błędami. Gdy operacje stają się spokojniejsze, pracują nad ulepszeniem telemetrii i raportowania, inwestując swój czas, aby ułatwić utrzymanie usług.

Załogi C pozwalają zespołowi rozwiązywać problemy bez ściągania członków zespołu z innych priorytetów i zapewnić, że klienci i partnerzy są wysłuchani. Reaktywność na pytania i problemy staje się powodem do dumy dla załóg C. Jednak to tempo może być wyczerpujące, co wymaga częstej rotacji wśród załóg.

Rotacja załogi

Dobrze zdefiniowany proces rotacji sprawia, że system pracy z zespołami dwuosobowymi działa. Można po prostu zamienić załogi (załoga F staje się załogą C i na odwrót), ale ogranicza to dzielenie wiedzy między załogami i wewnątrz załogi. Zamiast tego wybierz cotygodniową rotację.

Pod koniec każdego tygodnia przeprowadzaj krótkie spotkanie wymiany, podczas którego zespół decyduje, kto zmienia zespoły. Możesz użyć wykresu tablicowego, aby śledzić, kto jest obecnie na każdej załogi i kiedy zostały zamienione. Najdłużej pracujące osoby w każdej załodze powinny zwykle zamieniać się miejscami. Jednak w danym tygodniu ktoś może chcieć pozostać w celu ukończenia pracy nad badaniem lub funkcją na żywo. Chociaż jest elastyczność, im dłużej ktoś jest na załogi, tym bardziej prawdopodobne, że powinny zostać zamienione.

Cotygodniowe rotacje pomagają zapobiegać silosom wiedzy w zespole i zapewnić stały przepływ informacji i perspektywę między załogami. Częsty ruch inżynierów tworzy wspólną wiedzę na temat pracy zespołu, która pomaga zespołowi w rozwiązywaniu problemów bez pomocy innych osób. Często nowi członkowie załogi F szybko znajdą wcześniej pominięty projekt lub wadę kodu.

Rozmiar załogi

Rozmiar załogi różni się w zależności od kondycji zespołu. Jeśli zespół ma wysoką stopę przychodzących problemów na żywo lub ma dużo długu technicznego, załoga C staje się większa i na odwrót. Dostosowywanie rozmiarów co tydzień zwiększa przewidywalność elementów dostarczanych i zależności zespołu. W ciągu kilku tygodni zespół może przenieść wszystkich do ekipy C-crew, aby odpowiedzieć na uwagi związane z dużą wersją.

Ta strategia upraszcza komunikację z zarządzaniem. Bez systemu dwuosobowego inżynierowie często pracują nad wieloma rzeczami jednocześnie. Gdy w ciągu jednego tygodnia występuje kilka zakłóceń, funkcje w toku są często opóźnione. W związku z tym zespół może nie być w stanie pewnie nadać harmonogramu przyszłych prac nad funkcjami.

Dedykowana załoga F prowadzi do przewidywalnej przepustowości i czasu realizacji. Dzielenie zasobów między zespołami zwiększa odpowiedzialność w zespole oraz wobec kierownictwa co do tego, co zespół może osiągnąć co tydzień i w każdym sprincie.

Dalsze kroki

System dwuosobowy może pomóc zespołom zrozumieć, gdzie inżynierowie powinni poświęcić czas i poczynić postępy w wielu konkurencyjnych priorytetach.

Oprócz poprawy produktywności i przewidywalności, system dwuosobowy może zwiększyć morale zespołu. Inżynierowie w każdym zespole jasno rozumieją swoje role i obowiązki oraz działają niezależnie i z znacznie większą odpowiedzialnością. Takie podejście jest idealne dla zespołów DevOps, odpowiedzialnych za programowanie i operacje. Takie podejście można jednak zastosować do niemal każdego zespołu Agile zajmującego się konkurencyjnymi priorytetami.

Firma Microsoft jest jedną z największych firm Agile na świecie. Dowiedz się , jak firma Microsoft organizuje zespoły w planowaniu metodyki DevOps.