Co zrobić, jeśli członek zespołu nie zdoła zaplanować sprintu?

Powiedzmy, że członek zespołu korzysta z corocznego urlopu. Nie będzie uczestniczył w planowaniu sprintu, ale wróci do połowy iteracji / sprintu. Powiedzmy, że ma on 50% pojemności, tj. Ponieważ będzie on dostępny w późniejszej połowie iteracji, jeśli:

1. umów się z nim na spotkanie po powrocie.

2. odbyć z nim sesję planowania przed wyjazdem na coroczny urlop, tj. przed planowaniem sprintu.

3. nie planuj go do żadnego zadania i nie przydzielaj go do zadań innych niż sprint, np. skoków itp

4. niech jego rówieśnicy planują w jego imieniu podczas planowania sprintu, a nieobecna osoba może wtedy dodawać zadania, gdy wróci, a jeśli nie będzie w stanie wykonać całej pracy, może zejść.

5. pozwól mu usiąść z innym programistą i przez chwilę programować w parach.

6. coś jeszcze..

jestem zainteresowany wiedzieć, co robisz ..

Uwaga: wykonujemy (1) i nie wydaje się to właściwe.

Planowanie polega na zaangażowaniu się i podzieleniu historii zaangażowanych użytkowników na zadania.

umów się z nim na spotkanie po powrocie.

Zdecydowanie nie. Planowanie sesji po jego powrocie nie ma sensu, ponieważ zaangażowanie musiało być już wykonane.

odbyć z nim sesję planowania przed wyjazdem na coroczny urlop, tj. przed planowaniem sprintu.

Zdecydowanie nie. Nie należy planować, kiedy bieżący sprint nie zostanie zakończony = wynik bieżącego sprintu jest nieznany i nikt nie wie, czy wszystkie historie użytkowników zostaną ukończone, a klient będzie zadowolony z ich przeglądu.

nie planuj go do żadnego zadania i nie przydzielaj go do zadań innych niż sprint, np. skoków itp

Zdecydowanie nie. Wróci i jego pojemność powinna zostać wykorzystana do celu sprintu.

niech jego rówieśnicy planują w jego imieniu podczas planowania sprintu, a nieobecna osoba może wtedy dodawać zadania, gdy wróci, a jeśli nie będzie w stanie wykonać całej pracy, może zejść.

To jest poprawne. Zespół angażuje się - nie konkretny członek zespołu. Zespół zobowiązuje się do zestawienia historii użytkowników, ponieważ znają ich szybkość i na podstawie ich profesjonalnych przypuszczeń mogą modyfikować zaangażowanie na następny sprint w oparciu o dostępną pojemność. Nie powinno być żadnych zadań przypisanych do pojedynczego programisty z góry. Programiści powinni być funkcjonalni, nawet jeśli nie zawsze jest to możliwe, powinni być w stanie przynajmniej podzielić historię użytkowników na zadania. Może być problem z oszacowaniem zadań, ale moim zdaniem nie jest to wcale konieczne.

pozwól mu usiąść z innym programistą i przez chwilę programować w parach.

Zdecydowanie nie. Programowanie par powinno być objęte samą prędkością. Jeśli nie liczyć się z deweloperem, to tak samo, jak powiedzieć, że nie będzie go cały sprint. Dlaczego klient miałby płacić za czas dewelopera, który nic nie zrobił podczas sprintu?

W idealnym zwinnym zespole członkowie czują się komfortowo ze wszystkimi technologiami zastosowanymi w projekcie, a każde zadanie może wykonać (prawie) dowolny członek zespołu. Jeśli tak jest, po zmianie wielkości zadań w zaległości, zdefiniowaniu iteracji i wybraniu przez członków zespołu pierwszego zestawu zadań z zaległości, możesz po prostu zostawić resztę zadań w wiadrze, a zespół zostanie odebrany przez zespół członkowie, w tym ten, który opuścił sesję planowania.

W innej typowej sytuacji członkowie zespołu są wyspecjalizowani (jeden jest facetem od interfejsu użytkownika, inny jest ekspertem od baz danych, trzeci jest guru oprogramowania pośredniego itp.). W takim przypadku brakującemu członkowi zespołu przydzielono by jego zadania pod nieobecność. Być może jednak będzie musiał zmienić ich rozmiar po wejściu na pokład.

W zespole, w którym działa „scrum”, sam zespół odbierze luz i zaproponuje kreatywne rozwiązanie. Ta sytuacja nie pojawia się wystarczająco często, aby uzasadnić opisywanie szczególnych przypadków, wystarczy „iść z prądem” przez resztę sprintu. W końcu te sprinty i tak nie są długie.

Wakacje, czy planowane / nieplanowane, to tylko część gry. @Aim Ghaffar, sugerowane metody - przynajmniej większość z nich wydaje się kryminalizować osobę, która nieobecna była na spotkaniu dotyczącym planowania sprintu. W zespole, który ma dla siebie zdrowy szacunek, zrozumie osobiste potrzeby danej osoby, aw takich zespołach panuje zdrowa pewność co do rodzaju wykonywanej pracy. Z tą pewnością siebie planują, co mogą zrobić, biorąc pod uwagę czas, w którym różne osoby byłyby wolne od pracy na określoną iterację / sprint.

To trudne czasy pokazują, jak profesjonalny jest zespół. W średnim zespole w naszej firmie zawsze znajdzie się osoba, która przegapi spotkanie w sprawie planowania sprintu. Nie kryminalizujemy go / jej. Uważamy, że jest na tyle dojrzały, aby podjąć decyzję / ją :)

Doceniam twoje pytanie, dopóki pragniesz się uczyć i doceniasz ducha zwinnej metodologii tworzenia oprogramowania.

Tam, gdzie pracuję, najczęściej stosowanym rozwiązaniem byłoby 4. Osoba (osoby) opuszczające spotkanie może być na wakacjach, być chora lub mieć coś innego, co należy zrobić zamiast tego w kilku przypadkach, gdy to, że ktoś zaginął, nie oznacza, że ​​sprint nie powinien być kontynuowany. Chodzi o to, aby zespół rozpoznał, jakie korekty można wprowadzić, jeśli ktoś jest nieobecny na połowę sprintu, chociaż na koniec może być więcej niż kilka korekt.

Ludzie zawsze mają urlop :-) bez szkody.

W zwinnej grupie, jeśli ktoś potrzebuje wakacji, jeśli zwinny działa poprawnie, brak jednej osoby nie powinien mieć większego znaczenia, tak, grupa może zrobić mniej niż zwykle, ale oznacza to po prostu mniej funkcji w tej iteracji.