Gdy zespół przekroczy 10, czy nadal możesz wspólnie planować wydania?

Czy podejmując decyzję, nad czym pracować w następnej wersji i szacując czas dla każdej historii użytkownika (i zadań podrzędnych dla danej historii), czy robicie to w grupie, czy tylko w zarządzie?

Czy dla zespołu liczącego 10 osób jest to praktyczne?

Jak dużo czasu to zajmuje?

Priorytetyzacji powinien dokonać jeden właściciel produktu z udziałem różnych interesariuszy, w tym starszego programisty, który jest interesariuszem dla kodu i tak samo odpowiedzialny za niefunkcjonalne wymagania, jak interesariusz biznesowy dla wymagań funkcjonalnych.

Oszacowania powinni bezwzględnie dokonywać ludzie, którzy wykonają pracę, nigdy menedżer, który jest pod presją dostarczenia, jednak twój instynkt ma rację, że więcej niż pół tuzina ludzi będzie spierać się o to. W idealnym świecie naprawdę powinieneś rozbić drużynę tak, aby w jednej drużynie było nie mniej niż 4 i nie więcej niż 7 - 5 jest idealne, IMHO.

Jeśli z jakiegoś powodu nie jest to absolutnie niemożliwe - i musisz zaakceptować 5 powodów, zanim zaakceptujesz, że jest to niemożliwe - zespół powinien wybrać zespół 4-5 osób, który dokona oszacowań w ich imieniu.

Moim zdaniem NIE powinieneś planować wydań jako zespół 10 osób. Najprawdopodobniej skończysz na gigantycznym spotkaniu, na którym w każdej dyskusji 6-8 osób poczuje się całkowicie rozłączonych i znudzonych. Dodaj do tego wyczerpanie 3-4 godzin zamkniętych razem w pokoju. I zastanów się, że jeśli 10 osób mówi, masz o wiele za dużo rozmowy. Jeśli nie rozmawiają, możesz nie uzyskać cennego wkładu.

Zrobiliśmy coś bardzo podobnego do firmy Josepha. W poprzedniej wersji mieliśmy 8 inżynierów, a planowanie wydania zajęło 2 solidne tygodnie. I to było absolutnie brutalne. Wydaje mi się, że po kilku godzinach każdego z nas staramy się mówić jak najmniej, aby spotkanie się zakończyło wcześniej.

Ta wersja naszego zespołu powiększyła się ponad dwukrotnie. Rozpadliśmy się więc na mniejsze zespoły, które przejęłyby na stałe własność obszaru produktu. Każda z mniejszych drużyn miała przewagę. Następnie przeprowadziliśmy planowanie wydania na wysokim poziomie tylko z potencjalnymi klientami, co poszło zdecydowanie szybciej i wydajniej, ponieważ teraz mieliśmy tylko 4 programistów w pokoju. W tym czasie ustaliliśmy, który zespół zrobi, jakie historie i jak produkt zostanie podzielony. Dało to również leadom większy obraz całego produktu.

Następnie każdy trop powrócił do swojego zespołu i przejrzał część wydania, za którą odpowiedzialny był tylko ten zespół. W tym czasie wprowadziliśmy kilka szczegółów i przypisaliśmy wartości punktów opowieści.

Na koniec wszystko zostało zebrane razem i zrobiliśmy jeden ostatni krok (bardziej prezentacja niż dyskusja), aby wszyscy w zespole wiedzieli, co się dzieje z całym zespołem.

Chociaż nie mieliśmy pełnego udanego wydania tej metody, myślę, że ogólne planowanie wydań poszło znacznie płynniej niż wcześniej i uzyskaliśmy znacznie więcej. Kluczem było to, że nigdy nie mieliśmy więcej niż 3-4 programistów na danym spotkaniu, a głos wszystkich był nadal słyszalny.

Jeśli to możliwe, zalecam podzielenie 10 programistów na 3 grupy. Jeśli nie możesz podzielić swojej ogólnej wersji na 3 obszary, które w większości się nie pokrywają, to nawet 2 grupy byłyby lepsze niż jeden duży zespół.

Tak naprawdę jestem częścią wielu projektów (i wielu zespołów) jako lider, a kilka z nich to 10+. Przy prawie wszystkich projektach, nad którymi pracuję, planowanie wydania jest prowadzone przez potencjalnych klientów i analityków biznesowych. Jednak w naszej sytuacji licencjaci nie są menedżerami, więc menedżerowie tak naprawdę nie uczestniczą w planowaniu wydania.

Oszacowania dokonuje jednak zespół wdrożeniowy i chociaż obie części są osobne, są ze sobą bardzo powiązane.

Oszacowanie określa, ile czasu zajmuje wykonanie zadania, podczas gdy planowanie wydania ma miejsce, gdy zaplanowane jest wykonanie tych zadań.

Planowanie powinno odbywać się zgodnie z obawami biznesowymi, a szacowanie powinno być dokonywane zgodnie z obawami technicznymi. Stąd rozpad szacunków i planowania.

To zadanie jest wydajniej wykonywane przez kierownika. W małych zespołach role często się mieszają. Wszyscy są zaangażowani we wszystko. Ale wraz z rozwojem zespołu staje się to niemożliwe do zarządzania i role muszą być jasno określone.

Chociaż bardzo pragnę angażować się we wszystko, to po prostu nie jest produktywne.