Nasza wersja Agile nie działa. Porady

Pracuję w małym zespole złożonym z 4 programistów. Wdrażamy wersję Agile, która wydaje się stale dostarczać nam te same trudności, tydzień po tygodniu, i szukam sugestii, które mogą pomóc nam ulepszyć nasz proces.

Tło:

Zazwyczaj wykonujemy 2-tygodniowe sprinty i każdy sprint ma tendencję do niedoceniania naszej pracy i mamy kłopoty z naszym menedżerem, ponieważ jesteśmy opóźnieni.

Każdy sprint rozpoczynamy od zadania historii, które tworzy dla nas nasz menedżer. Czasami też rzuca zadania i my je oceniamy. Nie używamy punktów fabularnych. Korzystamy z oprogramowania Urban Turtle, aby „zarządzać naszymi sprintami”, które są w zasadzie tylko historiami i zadaniami oraz związanym z tym spaleniem. Nie planujemy wydania na koniec sprintu.

Najczęstszym problemem jest to, że planujemy zadanie na początku sprintu, aby odkryć, że ma ono znacznie większy zakres, ale nadal ma wysoki priorytet, więc musimy nad tym popracować dodatkowe godziny. Drugim najczęstszym problemem jest to, że jeden z nas napotyka problem techniczny, który spowalnia spalone godziny, powodując blokadę drogi.

Jedyną zaproponowaną nam sugestią jest bardziej proaktywne dostosowanie naszych szacunków i dostarczanie aktualizacji podczas porannych przygotowań, abyśmy mogli dostosować się do potrzebnego dodatkowego czasu.

Wydaje się jednak, że jest coś zasadniczo złego w sposobie, w jaki robimy różne rzeczy. Być może istnieje rozdźwięk między oczekiwaniami kierownika na poziomie projektu a oczekiwaniami na poziomie sprintu. Ponieważ wykonujemy te iteracje sprintu zgodnie z planem projektu, a zatem przedłużenie sprintu lub odroczenie elementów psuje plan projektu. Dlatego jako programiści jesteśmy zachęcani do wykonywania Agile poprzez zwiększanie szacunków w razie potrzeby, ale także kończenie sprintu na czas, co jest mylące.

To nie może być rzadki problem, więc mam nadzieję, że ci mądrzejsi ode mnie mają jakieś sugestie, w jaki sposób możemy przestać napotykać ten sam problem przy każdym sprincie. To frustrujące.

ponieważ opóźniamy się

Ten rodzaj myślenia jest twoim problemem. Nie spóźniłeś się z harmonogramem, harmonogram jest zbyt napięty. Powinieneś zacząć szacować historie w punktach abstrakcyjnych zamiast godzin, a następnie w ciągu 2-3 iteracji obliczyć swoją prędkość. Twoja prędkość określa, ile punktów zwykle wykonujesz podczas każdej iteracji, a nie ile punktów Twój menedżer chce zmieścić.

Po tym nie ma znaczenia, czy konsekwentnie nie doceniasz zadań - twoja prędkość już to uwzględnia.

Oczywiście nie jest to możliwe, jeśli użyjesz godzin zamiast punktów.

Wygląda na to, że problemami jest niezdolność twojego zespołu do dokładnego oszacowania i niemożność przewidzenia problemów, które powstają nieuchronnie.

Małe zadania są znacznie łatwiejsze do dokładnego oszacowania niż duże zadania, więc spróbuj podzielić swoje zadania na znacznie mniejsze części.

Nie pozwól, aby ktokolwiek dokonał oszacowania dla dowolnego zadania, chyba że dokładnie wie, jak to zrobić. W przypadku każdego zadania, które deweloper nie wie, co należy wykonać, poświęć trochę czasu na ten harmonogram sprintu, aby deweloper mógł przeprowadzić dochodzenie i zaprojektować, a także przedstawić dokładne oszacowanie. Nigdy nie mniej niż pół dnia. Ale przenieś zadanie na NEXT sprint. Następnie, kiedy dojdziesz do planowania następnego sprintu, będziesz miał dobre oszacowanie. Pamiętaj, że ten dodatkowy czas nie jest marnowany, ponieważ nadszedł czas, aby deweloper i tak wydałby.

I nie bój się wracać do kierownika projektu i mówić mu, że będziesz potrzebować więcej sprintów, aby przejść przez listę zadań. Lepiej to zrobić, niż zaangażować się w niemożliwe cele.

Czy próbujesz przeznaczyć 100% swojego czasu? Jeśli tak, przestań to robić. Zacznij od zsumowania wszystkich godzin, które Twój zespół musi poświęcić podczas sprintu. Zrób to, zakładając, że każdy pracownik poświęci co najmniej 6 godzin dziennie na realizację projektu. Jest to uważane za „idealny dzień”. Te pozostałe dwie godziny? Zaspokojeni spotkaniami, przerwami, zadaniami administracyjnymi, tym razem rano, kiedy czytasz e-maile i planujesz dzień itp. To nie jest „zabezpieczanie zakładów” ani „worki z piaskiem”, to jest realistyczne.

Po drugie, pomnóż to 6 godzin dziennie przez 80% . Czemu? Ponieważ jako ludzie jesteśmy do bani przewidywania, ile czasu zajmie zadanie. To wyjaśnia błędy w naszym osądzie. Znowu, nie worek z piaskiem, jest realistyczny.

Teraz masz liczbę reprezentującą realistyczną liczbę godzin, którą spodziewasz się zastosować bezpośrednio do swoich zadań. Podczas szacowania przestań dodawać historie, gdy kolejna opowieść Cię przewróci.

Wreszcie, nie pozwól właścicielowi produktu dodawać zadań. Planowanie Scrum jest dla zespołu , organizacja producentów nie jest częścią zespołu wykonującego pracę. Oczywiście w prawdziwym świecie, jeśli PO ma większą wiedzę niż ktokolwiek w zespole, jej wkład może być bardzo przydatny. Mimo to, jeśli zespół bierze upał za pozostawanie w tyle, musi wziąć odpowiedzialność za dokładnie to, co zrobi. Twoim celem jest spełnienie kryteriów akceptacji; jeśli zadanie nie prowadzi bezpośrednio do tego, nie rób tego.

Pamiętaj, że Scrum nie polega na zwiększeniu produktywności. Chodzi o bycie bardziej otwartym i komunikatywnym. Praca zajmie wszystko, co trzeba, aby wykonać. Scrum ma na celu ułatwić oszacowanie, łatwiej komunikować się z interesariuszami i ułatwić zespołowi zaangażowanie.

Kryteria akceptacji źle zdefiniowane na początku sprintu?

Wstępne szacunki są często zbyt niskie, ponieważ karty opowieści mają słabe kryteria akceptacji (jeśli istnieją), gdy są szacowane. Co powiesz na przejście na rozwój oparty na testach akceptacyjnych (ATDD), czyli opowiadanie historii, aby pomóc zespołowi naprawdę jasno określić, na czym polega karta?

Historie za duże?

Innym powodem, dla którego dowiadujesz się w połowie sprintu, że twoje historie trwają dłużej niż oczekiwano, może być to, że są zbyt duże. Czy widziałeś zwinnego w talii kart Flash ? Mają fiszkę o nazwie „Zmniejsz historie XL, aby dopasować”. Daje strategie dzielenia historii, takie jak odroczenie przypadkowych przypadków, skutki uboczne, niefunkcjonalne aspekty lub obsługa błędów w późniejszych historiach.

Nie możesz oszacować, ponieważ nie masz wystarczających informacji?

@sleske przedstawia dobrą sugestię dotyczącą skoków . Spróbuj zidentyfikować techniczne niewiadome w czasie szacowania. Jeśli takie istnieją, sprawdź, czy możesz odłożyć historię na późniejszy sprint, a zamiast tego wykonaj śledztwo czasowe (skok) tego sprintu, aby spróbować dowiedzieć się, co trzeba oszacować. Nie daj się ponieść emocjom i rozwiązuj oryginalną historię - skok jest wykonywany, gdy wiesz wystarczająco dużo, aby ocenić historię.

Zawieść szybciej

Zgadzam się z @Patrick Hughes - rozważ przejście na tygodniowe sprinty, aby szybciej zobaczyć problemy.

Oprócz dobrych sugestii @Kevin i @Patrick ...

Podejścia zwinne nie są „uniwersalne”, ale ten komentarz zwrócił moją uwagę:

Wdrażamy wersję Agile, która wydaje się stale dostarczać nam te same trudności

Lepiej zacznij od metodologii „według książki” (wydaje się, że Scrum jest obecnie dominujący) - i rób DOKŁADNIE to, co zrobił inny udany zespół… Zrób to przez kilka sprintów… I dopiero wtedy zacznij rozważać zmiany potrzebne do optymalizacji pod kątem warunków lokalnych.

Wynajęcie doświadczonego autokaru Scrum (na kilka iteracji) może być prawdziwą różnicą. Uzyskiwanie zwinności jest subtelne.

Najpierw polecam następującą książkę scrum-xp-from-the-okopy . Spójrz na stronę 26 na temat obliczeń prędkości. Chodzi o to, aby zdefiniować czynnik skupienia i powiedzieć, że w następnym Sprint:

dostępny osobodni * współczynnik ostrości = szacunkowa prędkość

Szacowana prędkość to suma oszacowań opowieści, które planujesz wdrożyć podczas następnego sprintu.

A po jednym Sprincie obliczasz ostatni współczynnik skupienia Sprint jako:

współczynnik ostrości = rzeczywista prędkość / dostępne osobodni

gdzie rzeczywista prędkość jest sumą oszacowań historii, które zrealizowałeś podczas sprintu.

Następnie ponownie użyjesz tego faktycznego współczynnika skupienia do następnego Sprintu, a po kilku Sprintach będziesz w stanie precyzyjniej określić, ile naprawdę możesz osiągnąć podczas Sprint ...

Dopóki nie otrzymasz szacunków, aby skrócić sprint do jednego tygodnia, w ten sposób szybciej rozpoznasz nadwyżkę i będziesz mógł reagować w mniejszych odstępach.

Poświęć więcej czasu z góry, projektując zadania, aby uzyskać trochę oddechu, aby rozpoznać skutki uboczne, które prawdopodobnie powodują krwawienie z lunety. Może się również zdarzyć, że same zadania są zbyt długie, aby można było je odpowiednio oszacować, aby sprawdzić, czy zadania można podzielić na krótsze etapy, które łatwiej będzie przełknąć.

Zapewnij wszystkim wygodę wysyłania czerwonej flagi, gdy tylko wpadną w kłopoty, zamiast utknąć na problem przez kilka godzin. Spróbuj odłączyć ego i winy od tego procesu, dla niektórych jest to łatwiejsze niż dla innych =)

I tak jak wychował @Kevin, tak naprawdę nigdy nie planujesz w 100% bezpośrednio do zadań, ponieważ zawsze są narzuty takie jak spotkania i tak dalej, że możesz nie rozpoznać jako zjadaczy czasu.

Kiedy wszystko będzie fajne na początku planowania, a następnie wróć do dwóch tygodni, zaczniesz w magiczny sposób poświęcać trochę czasu z mniejszej liczby spotkań.