Jak podajemy prawidłowe prognozy czasu podczas planowania sprintu, nie robiąc projektu „za dużo”?

9

Mój zespół nabiera rozpędu ze Scrumem, ale większość z nas jest bardziej zaznajomiona z metodami nie zwinnymi lub „pseudo-” zwinnymi. Część, która jest dla nas największą przeszkodą, to zorganizowanie efektywnego spotkania w sprawie planowania sprintu, w którym dzielimy elementy zaległości na zadania i szacujemy godziny. (Używam terminologii z szablonu Scrum VS2010; przepraszam, jeśli gdzieś użyję niewłaściwego słowa).

Kiedy próbujemy dowiedzieć się, ile czasu zajmie zadanie, często wpadamy w pułapkę zaprojektowania funkcji na poziomie kodu - układ tabeli, interfejsy itp. - w celu ustalenia, jak długo to zajmie. .

Jestem prawie pewien, że nie jest to odpowiednie miejsce do robienia tego rodzaju projektów. Powinniśmy planować zadania na te spotkania projektowe podczas sprintu. Mamy jednak problem z ustaleniem, jak inaczej wymyślić sensowne oszacowania zadań.

Czy są jakieś praktyczne nawyki / techniki / itp. za podjęcie decyzji o tym, jak długo zajmie funkcja, nie wiedząc, jak ją wdrożyć? Jeśli nasze szacunki czasowe zmienią się znacząco po zakończeniu projektu, jak możemy odpowiednio wcześniej zaliczyć budżet naszego zaległości Sprint?

EDYTOWAĆ:

Tylko dla wyjaśnienia, ponieważ niektóre komentarze / odpowiedzi są bardzo ważne, ale myślę, że odpowiadam na niewłaściwe pytanie.

Wiemy , że to, co robimy, jest niewłaściwe i że powinniśmy poświęcać czas na sprint dla tego projektu. Koncepcyjnie wszyscy programiści to rozumieją. Sprowadzamy również członka zespołu z doświadczeniem Scrum, aby śledzić nas, jeśli zaczniemy chodzić w chwasty.

Problem polega na tym, że bez przechodzenia przez ten proces projektowania trudno nam podać konkretne oszacowania czasowe dla czegokolwiek. Ciągle mówimy takie rzeczy jak „dobrze, jeśli zaprojektujemy to w ten sposób, może to potrwać 8 godzin, ale jeśli zamiast tego będziemy musieli zrobić to w inny sposób, zajmie to około 32, ale może nie być tak źle, gdy zaczniemy pisać ... ”.

Zakładam również, że proces ten poprawi się, gdy będziemy mieli pewną historyczną prędkość do pracy, ale wiele technologii i wzorów architektonicznych, które stosujemy, są dla nas nowe. Ale jeśli potencjalnie bardzo błędne szacunki są naturalną częścią dostosowania tego procesu, będziemy musieli się zregenerować, aby to zaakceptować :)

KutuluMike
źródło
Co rozumiesz przez „odpowiedni”?
Robert Harvey
Chodzi mi o to, że nie sądzę, że zespół powinien spędzać 25-30 minut na projektowaniu technicznym funkcji podczas planowania sprintu, ale to tylko moje przeczucie (że sprawia, że ​​nasze spotkania planistyczne
trwają
Masz rację Michael. Właśnie pomyślałem o czymś innym, co dodam do mojej odpowiedzi poniżej. Zasadniczo, jeśli planujesz sprint bez jakiegoś sponsora biznesowego, to tak naprawdę nie wiesz, co zrobić priorytetem. Więcej poniżej.
Ian
1
Masz dwie możliwości. Możesz przedłużyć fazę projektowania, aby uzyskać odpowiednie oszacowania, lub możesz żyć w narzuconym sobie ograniczeniu czasowym i akceptować dzikie domysły. Możesz także wbudować czas w sprinty do projektowania (co i tak będziesz musiał zrobić) i zmienić swoje prognozy pracy po zakończeniu fazy projektowania.
Robert Harvey
Wydaje mi się, że część „poprawianie szacunków pracy” jest dla nas walką; niektórzy członkowie zespołu nalegają bardziej niż inni, że nie podajemy szacunkowych godzin, jeśli nie wiemy, że mają rację. Mam również nadzieję i oczekuję, że z czasem poprawimy się, ale wyraźnie „wszystkim innym” udaje się to zrobić dobrze, więc mam wrażenie, że brakuje mi czegoś oczywistego.
KutuluMike,

Odpowiedzi:

14
  1. Zaplanuj cykliczne spotkanie „pielęgnacyjne”, podczas którego będziesz rozmawiać o projekcie. Zespół, w którym pracuję, ma je raz na sprint, na dzień przed planowaniem. Chodzi o to, aby projekt był wystarczająco przybity, aby zespół mógł uzgodnić prognozy czasu dla całej historii. Możesz rozważyć podział zadań na tym spotkaniu, aby planowanie stało się wyłącznie ćwiczeniem w podejmowaniu decyzji, ile wybrać. Innymi słowy, powinieneś projektować w sprintach PRZED rozpoczęciem rzeczywistej pracy.

  2. Rozważ użycie planowania pokera , tj. Punktów / jednostek „wysiłku” zamiast osobodni do oszacowania zadań. Spróbuj także rozbić historie na tyle, na ile możesz. Im dłuższa / bardziej złożona jest historia, tym mniej prawdopodobne jest, że twoje oszacowanie będzie dokładne.

  3. Podczas planowania mistrz scrum powinien kontynuować planowanie zgodnie z planem, zatrzymując wszelkie dyskusje, które zbyt daleko idą w „rozwiązywaniu”. W tym momencie członkowie zespołu muszą szybko dojść do porozumienia w sprawie oszacowania, zwykle podając górną granicę / najgorszy numer sprawy. Znacznie łatwiej jest podjąć więcej pracy, jeśli zadania stają się łatwiejsze niż planujesz, niż poradzić sobie z przesunięciami harmonogramów z powodu zadań trwających dłużej niż planowano i historii toczących się w wielu sprintach.

  4. Porozmawiaj o tym, jak szacunki potwierdziły się w retrospekcji pod koniec sprintu. Zwłaszcza, jeśli były jakieś bardzo odległe. Czy zespół nauczył się czegokolwiek z tego, jak przebiegła historia, i jak się spodziewali? Scrum Master powinien skupić się na zmianach, które można wprowadzić w procesie projektowania / szacowania.

mongiesama
źródło
Oznacziłem to jako odpowiedź, ponieważ wydaje się, że dochodzi do sedna naszego problemu: musimy zrobić więcej pracy z góry przed spotkaniem planistycznym, aby lepiej zrozumieć elementy zaległości i związane z nimi zadania, kiedy już tam dotrzemy.
KutuluMike,
10

Myślę, że problem polega na tym, że próbujesz oszacować czas. Nie rób

Oszacuj złożoność. Spójrz na wymaganie (mam nadzieję, że historia użytkownika) i oceń, jak skomplikowany będzie zespół, aby dowiedzieć się, jak go zbudować i przetestować, w porównaniu do tego, jak skomplikowane są inne wymagania lub historie użytkowników. Czasami się mylisz, ale często masz dobre pojęcie o tym, jak trudne będzie coś. Przekonasz się również, że przedmioty o podobnej złożoności wymagają tyle samo wysiłku, aby je ukończyć.

Tak więc rankingi złożoności stają się „punktami fabularnymi” powiązanymi z historiami użytkowników w zaległościach produktu. Po przejściu kilku sprintów dowiesz się, ile punktów historii możesz przejść w sprincie, i to jest twoja prędkość. W tym momencie będziesz miał znacznie lepszy pomysł na to, jak długo potrwa każdy przedmiot.

Bardzo polecam Zastosowane historie użytkowników Mike'a Cohna .

Matthew Flynn
źródło
To ma sens, ale staramy się postępować zgodnie z szablonem Scrum VS2010, zgodnie z teorią, że wymyśliło to wielu inteligentnych ludzi, którzy wiedzą, co robią. Jeśli nie szacujemy godzin, w jaki sposób możemy śledzić takie rzeczy, jak pozostanie pracy nad zadaniami lub tworzenie wykresu wypalenia?
KutuluMike,
Nie śledzisz pozostałej pracy nad zadaniami. Albo to jest zrobione, albo nie jest. Na początku sprintu zespół zobowiązuje się do wykonania pewnej liczby opowiadań, w oparciu o ich priorytet, stopień ich złożoności oraz najlepsze przypuszczenia zespołu, z jaką złożonością mogą sobie poradzić. Na spotkaniu dotyczącym planowania sprintu powinni zdecydować, jakie zadania są wymagane do ukończenia historii. Te zadania składają się na zaległości w sprincie - można powiedzieć, że są one o 1 punkt za sprint. Po zakończeniu każdego z nich można je sprawdzić jako gotowe.
Matthew Flynn
Nie ma żadnego związku między punktami złożoności w rejestrze produktu a punktami zadań w rejestrze Sprint. Codziennie aktualizujesz zaległości sprintu, sprawdzając zadania. Aktualizujesz backlog produktu pod koniec sprintu, gdy zademonstrowałeś, że ukończone są wszystkie historie.
Matthew Flynn
Hmm, to naprawdę robimy coś złego. Wiem, że istnieje więcej niż jeden sposób zrobienia Scruma, ale wykorzystujemy te wskazówki, które mówią, aby śledzić pozostałą pracę nad zadaniem: msdn.microsoft.com/en-us/library/ff731574.aspx . Czy to nie w porządku?
KutuluMike,
3
Ahhhh Widzę. Nie jest to złe jako takie, ale oczywiście nie jest dla ciebie szczególnie pomocne. Przewodnik Scrum mówi: „Gdy praca jest wykonywana lub zakończona, szacowana pozostała praca jest aktualizowana”, więc szablon MS ma sens. Jak już powiedziałem, nie jest to tak naprawdę użyteczna metryka - nikt nigdy nie wykonuje dobrej pracy, oceniając pozostałą pracę dla zadania, a Ty marnujesz czas, próbując to zrobić. Uczyń swoje zadania małymi i binarnymi (0 = zrobione lub 1 = nie), a będziesz mieć miarę tego, co zostało zrobione, a co pozostało, i nie musisz o tym myśleć.
Matthew Flynn
6

Wiem, że twoje pytanie dotyczy w szczególności unikania projektowania w planowaniu. Ale to jest rodzaj problemu XY .

Byłem tam, gdzie jesteś. Zamiast dać ci coś, co może zapewnić stopniową poprawę, chciałbym pomóc ci przeskoczyć niektóre z tych stanów pośrednich.

Oto trzy rzeczy, które nasz zespół robi w szczególności w związku z planowaniem i wykonywaniem pracy. Pomogły nam to uniknąć problemów z projektowaniem i uniknąć niedokładnych szacunków czasowych.

Automatyczne kryteria akceptacji

Na nasze historie wskazuje ich liczba automatycznych kryteriów akceptacji . Oznacza to, że gdybyśmy napisali zautomatyzowane testy w celu potwierdzenia, że ​​historia jest skończona, czym one byłyby?

Na przykład „Gdy użytkownik kliknie„ Odtwórz ”na iPadzie z systemem iOS 6+, odtwarzanie wideo rozpocznie się.” Zautomatyzowanie tego testu może być trudne, ale jest to kryterium akceptacji (AC) opowieści i ma jeden punkt.

Używamy skali Fibonacciego i zawsze zaokrąglamy w górę. Więc jeśli historia ma cztery automatyczne kryteria akceptacji, jest to historia pięciopunktowa.

Nasz maksymalny rozmiar punktu opowieści wynosi osiem punktów, ale rzadko je mamy. Jeśli historia ma więcej niż pięć automatycznych kryteriów akceptacji, znajdujemy sposób na ich podzielenie.

Wstępna pielęgnacja

Mamy spotkanie inauguracyjne w poniedziałek, ale nasze spotkania na temat pielęgnacji są miejscem, gdzie ma miejsce planowanie zespołu. Przed uwodzenia, członkowie zespołu będą wstępne oczyszczenie historię, opisując wyniki i biorąc ukłucie w zautomatyzować kryteriów akceptacji.

Pielęgnacja wnosi wiedzę zespołu do przygotowanych opowieści, wyszukując nieokreślone wymagania, dzieląc historie itp.

Czasami wymieniamy zadania oprócz kryteriów akceptacji, ale nie są one szacowane czasowo. Nigdy nie szacujemy czasu. Zadania to tylko deklaracje pracy, które należy wykonać w celu spełnienia kryteriów.

Ograniczanie produkcji w toku

Tradycyjny scrum próbuje ograniczyć czas pracy do czasu sprintu. Odkryliśmy, że to sztucznie zmusiło nas do pośpiechu, aby dotrzymać terminów sprintu, zabijając nasze weekendy, ponieważ sprint kończy się w piątek.

Innym podejściem jest ograniczenie bieżącej pracy w dowolnym momencie. Przeprowadziliśmy migrację do tej ostatniej i byliśmy znacznie szczęśliwsi z tego powodu.

Gdy historia przechodzi z zaległości do pracy w toku, charakteryzujemy ją jako jedną z kilku stanów:

  • Wstrzymanie - praca w zespole nie może się zdarzyć, ponieważ czekamy na dodatkowe działania w zespole
  • W rozwoju - praca nad osiągnięciem kryteriów akceptacji
  • Test potrzeb - wierzymy, że poznaliśmy AC, czekając na sprawdzenie przez kogoś innego
  • W teście - historia jest oceniana w stosunku do AC, usuwane są błędy
  • Gotowy do wdrożenia - przy następnej dostępnej okazji rozpocznie się

Następnie wykorzystujemy liczbę historii w każdym stanie, aby skupić uwagę zespołu. Na przykład może być dostępny programista, który może zająć się nową historią, ale jeśli mamy wiele historii w teście, lepiej jest, aby pomogli w opracowaniu istniejących historii.

jimbo
źródło
3

Po pierwsze, pamiętaj, że dokładne szacunki są niemożliwe w tych okolicznościach. Nie stresuj się, jeśli pomylisz się. Jednak nadal potrzebujesz surowego pomysłu, aby zaplanować, a naprawdę jedynym sposobem na wyjaśnienie całkowitej niepewności jest dodanie większej liczby punktów historii do oszacowania. Jeśli nie wiesz, czy to 5, czy 13, użyj 13.

Pomocne jest również dzielenie historii na możliwie małe. Często mamy historię badań / projektowania, której jedynym celem jest wykonanie wystarczającej ilości pracy, aby lepiej zrozumieć, jak wykonać tę funkcję, a następnie sama fabuła przechodzi do kolejnego sprintu. Zastanów się, dlaczego to działa. Nawet jeśli nie masz pojęcia, jak trudne będzie to zadanie, zazwyczaj dość dokładnie wiesz z wcześniejszych doświadczeń, ile czasu zajmie znalezienie.

Karl Bielefeldt
źródło
2

Możesz tutaj zrobić dwie rzeczy.

Najpierw poproś mistrza scrum, którego rolą jest monitorowanie dyskusji i powiedzenie „Hej, znów projektujesz”, kiedy jesteś. To trudniejsze niż się wydaje, obracaj w niego ludzi z dnia na dzień i początkowo spraw, by wszyscy byli mistrzami scrum, aby każdy mógł się popsuć.

Po drugie, jeśli projektujesz podczas planowania sprintu, musisz umieć rozróżnić między brakiem wystarczającej wiedzy, aby zadzwonić na czas trwania zadania, a tym, czy projektujesz, ponieważ jest to bardziej zabawne.

Znowu mistrz scrum powinien tu kopnąć i powiedzieć ci, żebyś odłożył przedmiot z powrotem, dopóki nie będziesz wystarczająco silny, aby go zaplanować, lub sprawi, że przestaniesz projektować i odpowiesz na oryginalne pytanie (ile to zajmie).

Więc jeśli planujesz sprint, warto mieć tam sponsora biznesowego, który omówi z tobą zaległości i uszereguje pod względem ważności rzeczy, które chcą zrobić jako pierwsze. Jeśli to zrobisz, okaże się, że trudniej jest zaprojektować podczas sesji, ponieważ będą niespokojni i ostatecznie nie będą chcieli przyjść.

Ian
źródło
W rzeczywistości dodajemy mistrza scrum (kogoś z doświadczeniem Scrum, zatrudnionego do wypełnienia tej roli za nas), więc mam nadzieję, że to pomoże; ale wszyscy zdajemy sobie sprawę, że jest to problem, z którym zmagam się, jak to zrobić lepiej .
KutuluMike,
Zidentyfikowałeś problem. Projektujesz na spotkaniu. Następne spotkanie, jeśli planujesz, przestań, powiedz „Nie wiemy wystarczająco dużo” lub „Wiemy wystarczająco dużo”. Jeśli nie masz wystarczającej wiedzy, odłóż ją, aż uzyskasz więcej informacji (sesja projektowa poza spotkaniem planistycznym). Jeśli masz wystarczająco dużo informacji, zaplanuj (lub nie) i przejdź dalej.
Ian
Jeszcze jeden komentarz, który powinienem dodać. Uważaj przy wynajmowaniu mistrza scrum. Przy wszystkich zwinnych metodach kluczem jest elastyczność. Przyjmij to, co działa, zmień to, co nie. To ogromna zmiana dla firm, które lubią dokumentować procedury i planować plany.
Ian
0

Działaliśmy w oparciu o oszacowanie historii „zimnej” podczas planowania sprintu z niewielką ilością dyskusji. Szacunki są naprawdę niedokładne, pomimo utworzenia zespołów z dość wąskim ukierunkowaniem ... głównie ze względu na istnienie wielu nieudokumentowanych, nieskomentowanych starszych kodów, które nie mają realnego pojęcia o tym, co się właściwie dzieje i personel, który znacznie się zmienił od czasu napisania oryginału.

Teraz staramy się poświęcić trochę czasu na zaplanowanie zbadania każdej historii - a tutaj tylko jeden twórca zbada jedną historię ... Mamy nadzieję, że będzie to oznaczać, że twórca, który zbadał, będzie w stanie udzielić pewnych wyjaśnień i wglądu pomóc w oszacowaniu. Do tej pory pomogło to przy niektórych próbach.

Nie jestem jeszcze przekonany, że dodatkowe dochodzenie naprawdę sprawia, że ​​szacunki są wystarczająco dokładne, aby uzasadnić koszt, ale spróbujemy to zrobić przez kilka sprintów, aby to zobaczyć.

Dave
źródło