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

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ć :)

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.

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 .

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.

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.

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ść.

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ć.