- Jak się czuliście podczas współpracy?
- Czy były problemy, których nie przewidzieliście na początku?
- Czy oszacowany czas zadań był zgodny z rzeczywistością?
- Co poszło nie tak?
- A co fajnie zadziałało i moglibyście zasugerować wdrożenie tego innym grupom?
To, że tak trochę rzuciliśmy was w ten projekt i zmusiliśmy do samoorganizacji było zabiegiem celowym.
Chcieliśmy wam pokazać, ilu rzeczy na początku w ogóle się nie uwzględnia przed rozpoczęciem prac nad projektem.
I nawet mając kilkuletnie doświadczenie w zarządzaniu projektami, pewnych rzeczy nie da się uniknąć.
- choroby członków zespołu
- niespodziewane wyjazdy
- dodatkowe, niezaplanowane zadania
- źle oszacowany czas zadań
- problemy techniczne (restartujący się komputer, git - konflikty, przerywający internet)
- zmieniające się wymagania lub ich interpretacje
Teoria wskazuje, że dość fajnym sposobem na lepsze szacowanie zadań jest pomnożenie początkowej estymaty przez PI 😄
Inne źródła wskazują, że należy zwiększyć rząd wielkości (np. z 5 godzin na 5 dni, z 3 dni na 3 tygodnie, itp.) 😄
W praktyce do estymacji wykorzystuje się pokera
- Zadań nie estymujemy w jednostkach czasu.
- Całym zespołem wybieramy jedno zadanie, które jest najłatwiejsze ze wszystkich innych. Dajemy mu wartość 1.
- Używamy tylko wartości z ciągu Fibonacciego (1, 2, 3, 5, 8, 13, 21, ♾, ? - nie mam pojęcia, ☕️). Dzięki temu bardziej skupiamy się na rzędach wielkości niż samych jednostkach, bo pomiędzy 9 a 10 dużej różnicy nie ma.
- Jednostką są Story Points (SP). Jest to zupełnie abstrakcyjna miara. Możecie o niej myśleć jak o dowolnej innej abstrakcyjnej. Np. to zadanie wyceniam na 5 kasztanów. Informacja zupełnie nieprzydatna, ale pozwala porównywać zadania. Skoro tamto jest warte 8 to jest bardziej wartościowe (trudniejsze).
- Dla jednej osoby 1 SP może oznaczać 1 godzinę pracy a dla innej 1 dzień.
- Całym zespołem omawiamy sobie jedno wybrane zadanie, aby mieć pewność, że wszyscy rozumieją je tak samo.
- Gdy wszyscy są gotowi _jednocześnie_ wyciągają kartę ze swoją estymatą, aby nie sugerować się innymi
- Jeśli rozbieżności są duże, to znaczy, że członkowie zespołu mają różne zrozumienie zadania i trzeba jeszcze o nim podyskutować. Warto zapytać osoby z najmniejszą i największą estymatą dlaczego tyle dają.
- Jeśli rozbieżności są małe to można je uśrednić lub wspólnie zgodzić się na którąś wartość (zazwyczaj wyższą)
Poszukajcie narzędzi typu Scrum Poker online i użyjcie do estymowania zadań na Planningu.
Ciężko winić kogoś, za to, że zachoruje. Ale można winić za to, że się do czegoś zobowiązał, a nie dał znać że to się nie uda. Dlatego ważne jest daily, aby mieć nawyk aktualizowania statusu co najmniej raz dziennie. Oczywiście można częściej.
Gdy tylko dowiecie się, że ktoś z załogi wam niedomaga, to powinniście od razu pomyśleć co z tym można zrobić. Jeśli były rozpoczęte prace to należy wkomitować / przekazać to co się do tej pory udało zrobić. To kolejny powód dla którego małe, a częste commity są dobrą praktyką. Każdy ma dostęp do bieżącej wersji kodu i łatwo wtedy przekazać pracę.
Dla nas, obserwatorów z zewnątrz nigdy nie możemy ocenić ile kto z zespołu zrobił. Dla nas po prostu zrobił to zespół. Jeżeli czujecie, że robicie za dużo / za mało i coś jest niesprawiedliwe, to możecie napisać nam o waszych problemach i w razie czego zmienić zespół.
- Pair programming
- Mob programming
- Peer code review
- Jak najszybsze dostarczanie zadań. Lepiej dostarczyć 4 na 8 zadań pracując po 2 osoby nad każdym niż 0/8 mając jednocześnie wszystkie rozpoczęte.
- Brak odgórnych przypisań osób do zadań. Osoba która właśnie ma czas bierze pierwsze z góry zadanie (lub jedno z pierwszych, jeśli nie są zablokowane)
- 1 osoba może maksymalnie mieć przypisane tylko 1 zadanie w danej chwili. Dopiero po zakończeniu poprzedniego zadania można wziąć kolejne.
Odkrywamy nowe metody programowania dzięki praktyce w programowaniu i wspieraniu w nim innych. W wyniku naszej pracy, zaczęliśmy bardziej cenić:
Ludzi i interakcje od procesów i narzędzi
Działające oprogramowanie od szczegółowej dokumentacji
Współpracę z klientem od negocjacji umów
Reagowanie na zmiany od realizacji założonego planu.
Oznacza to, że elementy wypisane po prawej są wartościowe, ale większą wartość mają dla nas te, które wypisano po lewej.