Jak obsługiwać prognozy dla programistów dołączających do zespołu?

11

Iteracja już się rozpoczęła, nowy programista dołącza do zespołu, zadanie X zostało już oszacowane na 30 godzin przez innego programistę.

Jaka jest najlepsza praktyka w tej sytuacji?

  • nowy programista działa z podaną wartością szacunkową (pomysł polega na tym, że wszelkie rozbieżności zostaną skorygowane przy obliczaniu prędkości?)
  • nowy programista dokonuje ponownej oceny zadania? (jeśli tak, co jeśli jest znacznie wyższy i nie mieści się już w iteracji?)
  • podnieść ręce i wrócić do wodospadu?
  • coś jeszcze całkowicie?
Jeremy Heiler
źródło

Odpowiedzi:

4

Mówię:

Nowy programista dokonuje ponownej oceny zadania. Jeśli trzeba go przenieść z iteracji, wówczas zostanie on przeniesiony.

Nie wiesz, czy nowy programista będzie w stanie, czy nie, zrobić to w czasie, gdy zajmie to pierwotny programista. A dzięki zwinnym metodologiom programista wykonuje pracę, która powinna powiedzieć, ile to zajmie.

Ponadto zastosowałbym mnożnik (jak duży w zależności od programisty), ponieważ programista musi pasować do zespołu / projektu / firmy.

Miyamoto Akira
źródło
15

Nie dodałbym tej osoby do tego indywidualnego sprintu. Zamiast tego daj mu kolejne zadanie, aby zająć się bazą kodu (może nisko zawieszone poprawki?).

Dodanie nowej osoby do zespołu prawdopodobnie spowolni Twoje postępy w tym konkretnym celu, ponieważ będzie musiał przyzwyczaić się do twojego środowiska i dowiedzieć się, jak tam działa. Włącz go do następnego sprintu z odpowiednimi szacunkami opartymi na nowym zespole.

Daenyth
źródło
6

Po pierwsze, słyszę „Agile Task” i myślę, że praca trwa od jednego do dwóch dni, a nie tygodnia. Zadania dzielą się na historie, gdy sama historia mieści się w iteracji, a prawdziwą rzadkością jest posiadanie historii, której nie można podzielić na mniejsze części.

Po drugie, w zasadzie prosisz tego nowego programistę, aby rozpoczął działalność. Jeśli można oczekiwać, że wskoczy on od razu i utrzyma tempo reszty drużyny, oryginalne oszacowanie powinno się utrzymać. Jeśli nie jest w stanie, prawdopodobnie nie powinien trzymać się tego szacunku, przynajmniej nie sam.

Po trzecie, jaka jest sytuacja? Jestem prawie pewien, że sytuacja nie polegała na tym, że zespół oszacował ich pracę, potem ktoś wyszedł, a ty zastąpiłeś go następnego dnia. Więc myślę, że X facetów w zespole oszacowało pracę tego sprintu i wzięło to, co według nich mogli poradzić, a potem przedstawiłeś nowego faceta, a teraz są X + 1 faceci, którzy wykonaliby prace pierwotnie powierzone przez X facetów . Dopóki zespół nie wybierze obciążenia pracą, a zamiast tego zalegałby zaległości w zarządzie, nie dałbym nowemu facetowi wiele do zrobienia w tym tygodniu. Jeśli harmonogram został ustawiony przez kierownictwo, nie jest on zwinny.

Osobiście ustawiłbym tego faceta na sparowanie z bardziej doświadczonym programistą na jego pierwszy sprint (jeśli twoi programiści nie łączą się przez cały czas, co sugeruję, że nie robią tego z faktu, że rozważasz podanie jednego zadanie jednemu facetowi). Spoglądając przez ramię i zadając pytania, zacznie uczyć się podstaw kodowania, a jeśli jego ogólna umiejętność programowania zależy od tabaki, niemal natychmiast sprawnie oceni kod, wykrywając błędy, nieefektywny kod itp.

KeithS
źródło
Niestety sytuacja była w zasadzie taka - ktoś oszacował pracę, a następnie straciliśmy sporą siłę roboczą. Teraz nowa siła robocza ma zadania, które zostały oszacowane przez starą siłę roboczą.
7
To wyjątkowy przypadek, w którym to przypadku nowy zespół (nie tylko nowy) ponownie oszacuje zaległości. Rozważałbym również anulowanie sprintu; jeśli połowa twojej drużyny opuściła środkowy sprint, to nie jest już ta sama drużyna i nie należy oczekiwać, że osiągnie cele starej; będą mieli nową prędkość stanu ustalonego i inny sposób patrzenia na rzeczy.
KeithS,