Jak uzyskać wystarczającą ilość szczegółów w planowaniu i szacowaniu podczas korzystania z TDD?

Question

Planując 2-tygodniowy iteracji w przeszłości miały historię użytkownika:

• Story: Zmiana nazwy pliku

i połamane go do zadań, które zostały następnie szacowane w godzinach:

• Story: Zmiana nazwy pliku
  • Zadanie: Tworzenie polecenie Zmień nazwę (2H)
  • Zadanie: Utrzymanie listę wybranych plików (3h)
  • Zadanie: Hak do klawisza F2 (1h)
  • Zadanie: Dodaj opcję menu kontekstowego (1h)

bym wtedy wybierz zadanie do wykonania i śledź czas poświęcony na pracę nad nim. Chciałbym powtórzyć proces z innym zadaniem. Pod koniec iteracji mogłem spojrzeć na czas spędzony na każdym zadaniu, porównać go z oszacowaniem i wykorzystać te informacje do poprawy przyszłych oszacowań.

Podczas pracy wykonywanej wyłącznie przez testy, jedyną pracą, która jest jasno określona z wyprzedzeniem, są testy akceptacyjne, które rozpoczynają rozwój, a na podstawie historii użytkownika, która obejmuje dużą ilość pracy, zakres testu akceptacyjnego może być zbyt szerokie, aby dać dobrą ocenę.

Mogę zgadywać zadania, które zakończą się (jak poprzednio), ale czas spędzony nad nimi jest o wiele trudniejszy do śledzenia, ponieważ testy sprawiają, że pracujesz w małych pionowych wycinkach, często pracując nad trochę każdego zadania w tym samym czasie.

Czy są jakieś techniki, które mógłbym zastosować, aby dokładniej oszacować i dokładnie śledzić czas wykonywania TDD? Korzystam z usługi TargetProcess, która zachęca do dzielenia opowieści użytkowników na zadania opisane powyżej, więc zachowanie informacji w tym formacie byłoby pomocne.

Answer 1

W agile zarówno zadania, jak i dane szacunkowe są płynnymi rzeczami, które zmieniają się przez cały czas.

Więc może zacząć (pamiętać, że są to bardzo luźne przykłady):

• Story: Zmiana nazwy pliku
  • Zadanie: Zbadaj problem i rozbić (0d/5d)

Pierwszy wywoływacz/s odebrać to zadanie i rozbicie go jak idą:

• Story: Zmiana nazwy pliku
  • Zadanie: Zbadaj problem i rozbić (4h/kompletna)
  • Zadanie: 1 część (0d/2d)
  • Zadanie: 2nd część (0d/3D)

W miarę postępów te aktualizacje stają się bardziej dokładne. Nowe zadania dodawane i dzielone na miarę ich pojawiania się:

• Story: Zmiana nazwy pliku
  • Zadanie: Zbadaj problem i rozbić (4h/kompletna)
  • Zadanie: 1. część (4h/7h)
  • zadanie: 2nd część (1h/20h)
  • zadanie: nowe zadanie realizowane podczas pracy na X (0h/5h)

Nie ma znaczenia, czy używasz Scrum, Crystal, XP, TDD lub jakiejkolwiek innej wersji zwinnej - wszystkie opierają się na szacunkach płynu.

Faktem jest, że nigdy nie wiesz, ile czasu zajmie Ci coś - po prostu zrób to, co najlepsze, i zrewiduj to codziennie. Nigdy nie dostaniesz procesu, w którym nie ma niespodzianek, ale zręcznym zarządzaniem ich wpływem.

Na przykład coś Załóżmy bolesnego podchodzi:

• Story: Zmiana nazwy pliku
  • Zadanie: Zbadaj problem i rozbić (4h/kompletna)
  • Zadanie: 1. część (10h/kompletne)
  • Zadanie: druga część (10h/3h)
  • Zadanie: nowe zadanie zrealizowane podczas pracy na x (3h/1h)
  • Zadanie: rozwiązać bałagan problem znaleziony podczas pracy na y (0 godz/5d)

Historia jest teraz trwa dłużej niż oczekiwano, ale każdy o tym wie i nie wie, dlaczego i ty poradzę sobie z tym.

Twoje zadania i ich szacunki stale się zmieniają w miarę wykonywania pracy. Wykres wypłaty jest dobrym wskaźnikiem, ile pozostało do zrobienia w zespole. Nie zawracałbym sobie głowy prędkością, ale jeśli to robisz, porównuje "kwotę wykonaną" między różnymi iteracjami, dając ci pewien pomysł na rozpęd projektu. Prędkość działa tylko wtedy, gdy masz bardzo spójne długości iteracji, rozmiar zespołu i klasyfikację (rozmiar, trudność, złożoność itd.) Historii, więc zacznę od sprawdzenia poprawności każdej iteracji, a następnie przejdź do niej.

Answer 2

My w TargetProcess użyciu prostszych zadań dla kondygnacji:

Story: Zmiana nazwy pliku

• Zadanie: Specyfikacja (2h)
• Zadanie: Opracowanie (14h)
• Zadanie: Testowanie (6)
• Zadanie: Aktualizacja dokumentacji użytkownika (2h)

Jeśli zadanie deweloperskie trwa dłużej niż 16 godzin, jest to znak podziału na kilka mniejszych zadań. W rzeczywistości zazwyczaj nie tworzymy zadań trwających mniej niż 2-3 godziny.