Wiele zespołów scrumowych przechodzi do pojedynczych zaległości

Obecnie mamy 5 zespołów scrumowych, które pracują nad własnym portfelem produktów w ostatnim roku. Każdy zespół działa na własnym systemie dedykowanym, ale podstawowa technologia jest taka sama .Net.

Wiele dyskusji poświęcono przestawianiu się na zespoły oparte na funkcjach, które pracują na jednym zaległości. Powodem jest to, że jeden z naszych głównych systemów wymaga znacznej ilości pracy, a ich pojemność nie wystarcza do wykonania całej pracy w ciągu roku. Innym powodem, który moim zdaniem jest znaczący, jest większa elastyczność w szybkim dostosowywaniu się do zmian w portfelu.

Podjęto decyzję o zmianie dwóch zespołów na jedną zaległość, ale deweloperzy nie mają doświadczenia w innych systemach. Jedną z rzeczy, które robimy, jest cross-Skilling, przenosząc programistę systemu doświadczenia do zespołu.

Moje pytanie brzmi: czy doświadczyłeś przejścia do jednego zaległości dla dwóch lub więcej różnych systemów? Jakie były twoje wyzwania? Co musiałeś zrobić, aby to zadziałało?

Zarządzamy około pół tuzinem projektów za pomocą jednego zaległości. Mówię „o”, ponieważ zależy to od tego, jak chcesz różnicować projekty.

Luźno mamy pięciu lub sześciu właścicieli produktów, z których niektórzy posiadają więcej niż jeden produkt. Mamy dość mały zespół z siedmioma programistami i liderem zespołu, który także koduje, kiedy ma czas. Mamy też kilku ewangelizatorów, którzy współpracują z ludźmi z naszego procesu, aby wprowadzać pomysły w życie. Oczywiście, niektórzy ludzie noszą kilka kapeluszy, które mętnieją, ale zignoruję to dla mojej odpowiedzi. Co ciekawe, nie mamy formalnego mistrza scrum.

Nie musieliśmy łączyć zaległości, ale brzmi to jak proste zadanie po twojej stronie.

Utrzymywanie porządku może być prawdziwym bólem, więc oto kilka kwestii, które warto rozważyć.

• Zarządzanie jest kluczowe. Każdy, kto ma palec administracyjny na torcie, musi komunikować się z innymi przed dokonaniem istotnych zmian. I / lub osoby dokonujące zmian muszą czuć się swobodnie ze swoim autorytetem, aby to zrobić (i być przygotowanym na przyjęcie upału za złą zmianę). Nasi twórcy zmian mają silne wsparcie wykonawcze, a linie są dość wyraźnie nakreślone wokół obszarów. Ale gdy pojawią się wątpliwości, pytamy, zanim się zmienimy.

• Może być więcej narzutów związanych z pielęgnacją zaległości, ustalaniem priorytetów i rozpoczęciem. Priorytetyzacja jako rytuał najbardziej ucierpiała, ponieważ trudno jest zebrać wszystkich właścicieli regularnie. Korzystamy z wielu go-betweens do negocjowania priorytetu i / lub dostarczamy złych wieści o nieprzestrzeganiu priorytetu.

• Wiele naszych prac opiera się na zaangażowaniu zewnętrznym. To odbiera część autonomii naszym decyzjom, ale taka jest rzeczywistość biznesu. Twoi deweloperzy powinni być jednak świadomi tej zmiany. Pióra mogą zostać potargane, jeśli nastąpi domniemana utrata kontroli. Staramy się jednak nie nadmiernie angażować i musieliśmy powiedzieć „nie” niektórym właścicielom produktów, którzy usiadli na szczycie sprintu.

• Zasadniczo używamy dwóch metod do oznaczenia produktu, do którego należy element zaległości produktu. Używamy obu po prostu dlatego, że ułatwia pielęgnację i inne zadania.

  1. Poprzedzimy tytuł PBI nazwą produktu lub wersją skróconą.
  2. Mamy oddzielne pole, które wskazuje ogólny produkt, i należy je również wypełnić.

• Musimy włożyć świadomy wysiłek w szkolenie przekrojowe i upewnić się, że wszyscy dostaną rękę w różnych obszarach. Mamy bardzo dużą bazę kodu w stosunku do naszego zespołu programistów. Część kodu, który tworzymy, jest również bardzo specjalistyczna. Nasz zespół jest niesamowity pod tym względem, a on obniży poziom naszego zaangażowania, abyśmy mogli sobie pozwolić na nieefektywność wynikającą z treningu krzyżowego. Silne prowadzenie zespołu jest w tym względzie niezwykle ważne.

• Dokładamy wszelkich starań, aby zachować ramy czasowe sprintu. Skomplikowane projekty z nowszymi członkami zespołu przekładają się na nierzadkie krwawienie ze zobowiązaniami. Proces wokół rozgałęzienia naprawdę tutaj pomoże. Cała nasza praca jest wykonywana na gałęzi, która jest następnie scalana z powrotem do wersji trunk. Mamy również serwer kompilacji, który działa co noc oprócz wyzwalaczy ad-hoc. Twórcy, którzy złamią kompilację, wiedzą i rozwiązują problem w ciągu 24 godzin. Kropka. Brak rozwiązania w ciągu 24 godzin oznacza, że ​​twoje zatwierdzenie jest wycofane, a starsi deweloperzy dają im żal. A starsi deweloperzy są najtrudniejsi, jeśli chodzi o utrzymanie kompilacji.

• Przejścia do kodu i recenzje stają się jeszcze bardziej krytyczne. Pomaga informować wszystkich na bieżąco o zmianach w różnych obszarach.

• Podobnie, codzienny standup obejmuje wszystkich deweloperów plus naszych ludzi z interfejsu użytkownika. Jesteśmy na granicy korzystnej współpracy i nieefektywności ze strony zbyt wielu osób. Ale utrzymujemy czas gotowości na mniej niż 15 minut i szybko przejdziemy do dyskusji bocznych. Zwykle robimy to w 5 do 10 minut.

• Nie mogę mówić o wpływie na wskaźniki, takie jak prędkość lub ogólne zaangażowanie i wskaźniki wypalenia. Te aspekty po prostu nie były wystarczająco ważne, abyśmy mogli z bliska je obserwować. YMMV, więc weź to pod uwagę. Zakłada to również, że każda drużyna ma dość podobną definicję punktu fabuły. Jeśli nie, zepsuje to wstępne szacunki po scaleniu. Powoduje to również pewne problemy dla porównań historycznych, ponieważ nie używasz tej samej jednostki miary, co wcześniej. Łatwym wyjściem jest po prostu ogłosić, że jest to „nowy zespół” dla wskaźników i rozpocząć gromadzenie danych po scaleniu.

• Widzieliśmy znaczne korzyści z tego podejścia. Mieliśmy kilka sprintów, w których wszystkie ręce są skoncentrowane na jednym obszarze i możemy w krótkim czasie znokautować wiele zmian. Nie należy lekceważyć wartości wynikającej z możliwości szybkiego zastosowania podwójnej normalnej liczby programistów w danym projekcie. Ale przed czasem musisz przejść szkolenie krzyżowe. Oznacza to również, że nigdy nie mieliśmy programistów z „niczym do zrobienia” z powodu cykli testowych, pielęgnacji czy cokolwiek innego. Zawsze mamy zaległości do rozwiązania.

• Poświęć czas na projekty badawczo-rozwojowe. W przeciwnym razie prześlizgnięcie się przez szczeliny będzie dla nich zbyt łatwe, a Ty stracisz okazję do inwestowania w te obszary.

• Naprawdę pracuj nad kodowaniem bez ego i że chociaż możesz mieć ekspertów w danej dziedzinie, nie masz właścicieli obszaru kodu. Zapobieganie możliwości powstawania posiniaczonych ego jest ważne, gdy w danym obszarze wprowadzane są różne style. Tak długo, jak nowy kod spełnia standardy zespołu i jest funkcjonalny, powinien być dobry. To, że nie zrobiłby tego ekspert, nie ma znaczenia.

• Upewnij się, że zaangażowane zespoły stosują te same konwencje i styl kodowania. Nie ma tu nic takiego jak niespójność, która może siać spustoszenie w twoich próbach integracji.

• Trzymaj swoje retrospektywy i trzymaj je jako grupę. Ważne jest, aby uzyskać od wszystkich opinie na temat tego, co działa, co nie działa i co należy wypróbować inaczej. Pomaga to budować poczucie koleżeństwa w zespole i daje poczucie odpowiedzialności za cały proces rozwoju.

Prawidłowa odpowiedź Scruma to „Zapytaj zespół (zespoły)”. Jest to zasada samoorganizacji, w której powinni być w stanie dokonać restrukturyzacji, aby szybko wykonać zadanie. Widzisz, że wiele osób w zespołach ma większą wiedzę kontekstową niż osoby z zewnątrz i wiedzą, co jest najlepsze. Dotyczy to również właściciela produktu.

Rozumiem, że przyszedłeś tutaj i zadałeś pytanie, ponieważ jest coś, co nie wydaje się właściwe i masz ukryte obawy. Dlatego dam wam kilka wskazówek do przedyskutowania z zespołem w celu podjęcia właściwej decyzji.

Właściciel Produktu

Backlog ma tylko jednego właściciela produktu i powinna to być osoba biznesowa lub osoba reprezentująca firmę. To nie powinno być zarządzanie IT. Duże zaległości mają wiele elementów, a przy wielu zespołach może to być zbyt wiele dla pojedynczego zamówienia zakupu. Z tego powodu możesz chcieć oddzielić zaległości.

Jeśli istnieje wiele PO, to na pewno potrzebujesz wielu zaległości, ponieważ zespoły powinny zostać przydzielone w sprincie do jednego PO i zaległości. Powodem jest to, że zespół nie musi zarządzać konfliktami między priorytetami właścicieli produktów.

Rozwój produktu a konserwacja

Zespoły serwisowe pracują nad wieloma małymi ulepszeniami, błędami kilku różnych produktów i prawdopodobnie z kilkoma właścicielami produktów. Te zespoły BAU potrzebują wsparcia zarządzania IT, aby pomóc w planowaniu konfliktów między wieloma właścicielami produktów i zarządzaniu nimi.

Zespoły projektowe powinny skupiać się na jednym produkcie na raz, aby zminimalizować przełączanie kontekstu i dostarczać jeden świetny produkt na raz. Zmiana kontekstu może spowodować dostarczenie wielu miernych produktów o pewnym stopniu technicznego zadłużenia.

Przełączanie kontekstu

Praca nad wieloma produktami lub różnymi funkcjami powoduje przełączanie kontekstu, co spowalnia produktywność zespołów. Organizacja producentów powinna wziąć to pod uwagę, pracując nad tym, co będzie następne i jaki zespół powinien pracować nad tym, jaki kawałek pracy. Ilość zmian nie jest nieznaczna i nie jest tylko kwestią teoretyczną, jest prawdziwa i byłem świadkiem spadku wydajności zespołu do 80% z tego powodu.

Dobry PO spróbuje funkcji grupowych i rodzaju pracy, aby pomóc zespołom w mniejszym przełączaniu kontekstu, poprawiając w ten sposób ich wydajność.

Ryzyko

Niestety, zarząd stara się narażać zespół na ryzyko związane z czasem, pieniędzmi, budżetem i biznesem; i zespoły akceptują to, wyrażając na to zgodę. Jako specjalista ds. Rozwoju powinieneś po prostu podać fakty i wpływ decyzji, a firma powinna ponosić własne ryzyko.

Przykłady

• Zgadzam się na niedorzeczny czas. Zamiast tego powiedz, jaki wysiłek trzeba podjąć, aby właściwie wykonać zadanie i sprawić, że firma poradzi sobie z problemem czasu

• Oszacowania Firmy oczekują od zespołów dokładnego oszacowania w świecie złożoności i niepewności. Zespoły powinny zapytać biznes, co robią, aby złagodzić ryzyko, jeśli szacunki zostaną przekroczone z powodu nieprzewidzianych wyzwań, które są bardzo prawdopodobne. Zespoły nie powinny uwzględniać tłuszczu, ale interesy powinny.

• Dług techniczny Zespoły powinny oszacować wykonanie wysokiej jakości kodu, który jest w pełni przetestowany i oszacować na tym, tj. Przestać pisać usterki z powodu nacisków. Jeśli firma chce niższej jakości, ryzykuje to, a gdy coś pójdzie nie tak, stanowi problem.

Profesjonalizm

Bądź profesjonalistą, stwierdzając, że budujesz odpowiednie rzeczy do uzgodnionej jakości. Oszacuj swoją najlepszą zdolność na podstawie dostępnych faktów. Kiedy te fakty się zmienią, przekaż to i dostosuj oszacowanie. Jako zespół programistów buduj świetne produkty i nie podejmuj ryzyka biznesowego. Komunikuj się i zarządzaj oczekiwaniami.

Sprawdź i dostosuj

Zespoły powinny zawsze szukać sposobów na poprawę, a jeśli uważają, że poprawi to sytuację, powinny spróbować. Następnie sprawdź, czy są jakieś ulepszenia. Wreszcie, powinni dostosować i ulepszyć swoje nowe podejście lub zrzucić je, jeśli nie działa. Zawsze należy dążyć do poprawy.

Dolna linia

Ostatecznie zarządzanie zaległościami jest wyborem OP. To, jak chce zarządzać kolejką pracy, zależy od nich. Jedyną myślą jest to, że MUSZĄ utrzymać ciągłość pracy WSZYSTKICH zespołów w zdrowiu i dobrym stanie. Zatem decyzja należy do OP.

Umowa

Podczas sesji planowania sprintu zespół powinien spodziewać się listy przygotowanych elementów rejestru produktów, które są jasne, jednoznaczne i uporządkowane. Po krótkiej dyskusji z PO zespół powinien dokładnie wiedzieć, czego chce PO; menu Co . Zespół następnie skupia się na tym, jak zamierzają zbudować.

Jeśli organizacja producentów przyjdzie na spotkanie planistyczne dobrze przygotowane, kogo obchodzi sposób zarządzania zaległościami. Jeśli PO przyjdzie nieprzygotowany na spotkanie w sprawie planowania sprintu, SM powinien to rozwiązać i uczynić go bardzo widocznym, ponieważ jest to całkowicie niedopuszczalne i nie stanowi problemu dla zespołu.

Niedawno wchłonęliśmy zaległości innego zespołu. Zespół miał tylko jednego członka (wiem, że nie jest to zbyt duży zespół), ale ich zaległości dotyczą faktycznej pracy. Nie znamy ich pracy i nie znają naszej.

Nawet jeśli zaległości są scalone, nie oznacza to, że wszyscy muszą od razu nad wszystkim pracować. Nie można się tego spodziewać, więc nie przejmuj się zbytnio tym, że każdy może od razu zrobić wszystko w obu zaległościach.

Zamiast tego zacznij od tego, aby oba zespoły pracowały dokładnie nad tym, nad czym wcześniej pracowały; jedyną różnicą jest to, że wszystko jest w tym samym zaległości.

Następnie, w każdej iteracji / sprincie niektórzy członkowie z każdego zespołu pracują nad historiami z innych zaległości. Nie zmuszając wszystkich do pracy nad nieznanymi przedmiotami w tym samym czasie, rozkładasz koszty uczenia się nawzajem . Z czasem twój zespół będzie stopniowo wchłaniać wiedzę innych.

Jeśli wykonasz całą naukę z góry, będą obowiązywać znaczne kary za wyniki. Ktoś z kierownictwa wyższego szczebla na pewno to zauważy, a ty będziesz zmuszony wchłonąć zaległości innego zespołu w nadziei, że nowy zespół może zrekompensować słabe wyniki ... :) Żartuję, ale to byłoby moje zalecenie.

Zakładam, że powodem, dla którego ty (lub kierownictwo) chcesz utworzyć scalony backlog dla dwóch zespołów, jest to, że chcesz być w stanie wybrać tylko elementy zaległości dla jednego systemu i pozwolić, aby oba zespoły nad nimi pracowały.

W takim przypadku należy spodziewać się dużego tarcia ze strony zespołu, który jest zmuszony do pracy z systemem, którego nie zna. Spodziewaj się, że zespół weźmie każdą słomkę (tj. Drobny element zaległości związany z systemem „macierzystym”), aby kontynuować pracę nad systemem, nad którym wcześniej pracowali. Kto ich winien? Praca nad czymś, w czym nie jesteś dobry, nie jest przyjemnością. A fakt, że drugi zespół jest dobry jako coś, w czym nie jesteś dobry, pogarsza go - ponieważ sprawia, że ​​wyglądasz jeszcze głupiej.

Tak więc jedynym sposobem na osiągnięcie sukcesu jest rozbicie dwóch drużyn i utworzenie ich w dwie mieszane drużyny. Tylko wtedy istnieje szansa, że ​​szybko przyspieszysz pracę wszystkich programistów w (obecnie) „ważnym” systemie.

To nie jest zbyt dobre, żeby tak było. Moja poprzednia firma przeszła w tryb pojedynczego produktu dla pojedynczego zespołu, ponieważ w dużej firmie mieliśmy różnych ludzi pracujących nad różnymi rzeczami.

Przełączanie się między projektami również kosztuje wysiłek, a jeśli nowa osoba zaczyna rozwijać koszty ogólne, jest naprawdę duża. Trzeba uzyskać prawa dostępu do opracowanego systemu, innego repozytorium itp.

Wolę specjalizację, ludzie wiedzą, co robią, mają wszystkie potrzebne informacje, znają pułapki projektu, a ludzie nie mają poczucia, że ​​trzeba je porzucić od projektu do projektu, aby zmusić ich do pracy, i wyssać z nich każdy grosz im.

Nawet jeśli pracują na biegu jałowym w swoim projekcie, są o wiele bardziej produktywni w tym, co znają, niż przechodzenie od projektu do projektu.