Czy przy tworzeniu oszacowań czasu dla biletów należy uwzględnić szacunek czasu dla testerów (QA)? Wcześniej zawsze szacowaliśmy czas bez testerów, ale mówimy o tym, aby zawsze go uwzględniać. Ma to sens w naszym bieżącym sprincie, ostatnim przed premierą, ponieważ musimy wiedzieć, że całkowity czas biletów zajmie tydzień.

Zawsze rozumiałem, że oszacowanie dotyczyło tylko czasu programisty, ponieważ jest to zwykle ograniczenie zasobów w zespołach. Kolega mówi, że gdziekolwiek pracowali, zanim czas testera został uwzględniony.

Żeby było jasne, dotyczy to procesu, w którym programiści piszą testy jednostkowe, integracyjne i interfejsu użytkownika z dobrym zasięgiem.

Moja zalecenie: albo umieścisz czas testu na bilecie, albo dodasz bilet reprezentujący samo zadanie testowania. Każde inne podejście powoduje, że nie doceniasz prawdziwej potrzebnej pracy.

Podczas gdy czas programisty jest często wąskim gardłem, z mojego doświadczenia wynika, że ​​wiele zespołów jest testowanych. Zakładając, że ograniczającym zasobem jest jedno lub drugie bez dowodów, może cię ugryźć.

Jako twój kolega nie widziałem udanej organizacji, która nie bierze pod uwagę czasu testowania.

Dodatek do twoich wyjaśnień: Nawet jeśli deweloperzy piszą testy automatyczne, szczególnie testy jednostkowe (testy integracyjne działają lepiej), nie są wystarczające do prawidłowego przetestowania.

Jeśli zaangażowane są osoby odpowiedzialne za kontrolę jakości, ich czas należy oszacować w taki czy inny sposób. Tylko wtedy, gdy zdecydujesz się usunąć osoby odpowiedzialne za kontrolę jakości z listy płac, wtedy ich czas pracy faktycznie zniknął i możesz go usunąć z oszacowania. Miałoby to jednak skutki uboczne, które łatwo zignorować. Być może nadal brakuje testów wydajności, stresu, bezpieczeństwa i akceptacji.

Zdecydowanie tak

Testowanie jest częścią procesu rozwoju. Jeśli Twój zespół faktycznie spędza czas na testowaniu oprogramowania, czas spędzony na testowaniu musi być częścią szacunku.

Jeśli jest to zwinne, uwzględniłbym wysiłek testowy jako część wszystkich punktów fabularnych. Na przykład, wysiłek deweloperów może 1 dzień i testowanie 1 dnia, więc będzie to historia 2-punktowa.

To zależy od tego, jak twoja definicja jest zrobiona, ale zazwyczaj jej ukończenie, akceptacja biznesowa i testy podpisują się w iteracji. Jeśli DoD jest tylko akceptacją biznesową, wysiłek testowy nie musi być uwzględniony w punktach fabularnych, ale nadal należy go śledzić.

Kosztorys powinien uwzględniać wszystkie prace niezbędne do zrealizowania biletu. Jeśli testowanie jest wymaganą częścią biletu, należy je uwzględnić w kosztorysie. Jeśli testowanie jest osobnym biletem, to nie powinno.

To oczywiście może stać się niewyraźne, gdy zaczniesz używać punktów fabularnych, ponieważ różnica między 5 tylko dla deweloperów i 8 dla deweloperów będzie dość proporcjonalna do dev i QA 5 w porównaniu do dev i QA 8.

Widziałem czas pracy testera. Widziałem, jak działają osobne historie. Widziałem osobne zadania, z których każde oceniane przez grupę wykonującą je działa. Rób to, co ma dla ciebie sens, po tym wszystkim, aby cały proces służył ci, a nie odwrotnie.

Fakt, że nie możesz odpowiedzieć na to zdecydowanie sugeruje , że nie wiesz, dlaczego piszesz prognozy (a przynajmniej, że nie zgadzasz się z kolegą, dlaczego piszesz prognozy). Jest to większy problem niż to, czy szacunki powinny obejmować testy.

Dowiedz się lub osiągnij porozumienie, dlaczego piszesz prognozy. Jeśli ma przewidzieć, co konkretny zespół osiągnie w danym czasie, odpowiedź zależy po prostu od tego, czy zespół, dla którego się oceniasz, wykonuje testy, czy nie. Jeśli Twój zespół ds. Kontroli jakości jest osobny i ma własne harmonogramy, może być zainteresowany, aby dowiedzieć się, ile czasu testowego Twoim zdaniem (programistów) potrzeba od nich na danym bilecie. Mogą zignorować twoje liczby i wprowadzić własne. Tak czy inaczej, mogą śledzić to oddzielnie od szacunkowych czasów opracowywania.

Z drugiej strony, jeśli jeden zespół zajmuje się opracowywaniem, testowaniem i kontrolą jakości, a celem oszacowań czasowych jest przewidywanie i planowanie działań tego zespołu w określonych ramach czasowych, wówczas oczywiście szacunki czasowe muszą obejmować Kontrola jakości oraz wszelkie inne zadania, które zespół musi wykonać, aby osiągnąć wyznaczony cel. W tym przypadku, jeśli musisz mieć spotkanie rozpoczynające dla każdego biletu lub wypełnić trochę dokumentów po zakończeniu, to czas dla administratora musi gdzieś tam być . Nie możesz tego po prostu zignorować.

Jeśli to wszystko jeden zespół, ale z oddzielnymi rolami „programistów” i „testerów”, może to oznaczać, że masz wiele biletów, nad którymi może pracować tylko jedna strona podziału, a Twój (być może całkowicie hipotetyczny) wykres Gantta wygląda dokładnie tak, jak wyglądałaby tabela dla dwóch oddzielnych zespołów. Fakt ten zakłóci niektóre metodologie bardziej niż inne i być może lepiej byłoby podzielić plan z tego powodu, ale jeśli go nie podzielisz, musisz ustalić i oszacować wszystko, co zespół musi zrobić, lub twoje prognozy będą beznadziejne .

Jeśli celem tych szacunków jest coś innego niż przewidywanie i planowanie, na przykład „ponieważ bezmyślnie przestrzegamy pustego rytuału, który je obejmuje”, lub „ponieważ kierownictwo używa ich jako kija, aby nas pokonać, aby uzyskać nadgodziny”, lub „ponieważ musimy ustalić stałą cenę, a liczby idą w ogromną formułę” (dzięki John Wu), może być trudniej ustalić, co powinny zawierać ;-)

Zawsze oceniaj całą pracę, którą należy wykonać, aby historia użytkownika / funkcja / bilet naprawdę się wykonała. Nazywamy to Gotowe .

Skończyliśmy, gdy jesteśmy gotowi do produkcji .

Obejmuje to wszelkie testy ręczne i eksploracyjne, ale nawet testy akceptacyjne dla użytkownika.

Zespół zwinny powinien być w stanie wydać nową część ukończonej pracy w dowolnym momencie. Tak jak:

Działające oprogramowanie jest podstawową miarą postępu.

Skąd wiesz, czy to działa, jeśli go nie przetestowałeś? Teraz piszesz, że czas rozwoju jest wąskim gardłem twojego czasu. Jako inżynier ds. Kontroli jakości uważam, że większość zespołów ma wąskie gardło w zakresie zdolności testowych lub po prostu robi skróty.

Krótko mówiąc, oszacuj również wysiłek testowy. Pamiętaj, że może to wpłynąć na twoją prędkość . Jeśli dokonałeś względnych oszacowań w punktach fabularnych, testowanie może być już włączone do twojej średniej prędkości.

Oto coś bardzo ważnego: Wszystkim szacunkom powinny towarzyszyć założenia i wyłączenia .

Obejmuje to określenie, co jest uwzględnione: tylko programowanie, projektowanie i rozwój, testy programistyczne i jednostkowe, zakres testów akceptacyjnych, budowa infrastruktury itp.

Jeśli przekazujesz dokument szacunkowy kierownikowi projektu, zamieni on ten dokument w zlecenie pracy lub oświadczenie pracy dla klienta lub (jeśli jest to projekt wewnętrzny) dla PMO . Oni mogą mieć zestaw formuł za dodanie napowietrznych (na przykład, niektóre projekty mogą dodawać X% na pokrycie QA, a następnie dodać Y% do ładu pokrywy i zarządzania projektami), które są ustalane w drodze umowy lub zestawu przez doświadczenie. I nie chcesz się podwójnie liczyć. Z drugiej strony mogą nie dodawać ich automatycznie.

Praktyki różnią się. Ktokolwiek używa tych liczb, musi wiedzieć, co oznaczają liczby, i powinieneś wyraźnie powiedzieć, czy podałeś czas na test, czy nie.

Czas powinien być uwzględniony w oszacowaniu, ale nie należy szacować czasu testerów, zamiast tego testerzy powinni oszacować swój czas .

Nieuwzględnienie czasu testowania jest fałszywym oszacowaniem całkowitego czasu, jaki zajmie, ale czas programisty i czas testera nie są wymienne (zwłaszcza dlatego, że prawdopodobnie pracujesz równolegle, a testerzy mają opóźnienie), więc powinieneś oszacować je osobno. Co więcej, nie jesteś w stanie oszacować czasu, w którym testerzy będą musieli przetestować wszelkie zmiany, tylko ekipa testowa powinna to zrobić.

Kapsułkowanie

Podejdę do tego z punktu widzenia oprogramowania i języka.

• Jesteś małym trybikiem na dużej maszynie.
• Z zewnątrz twojego zespołu twój system biletowy działa jako interfejs / API dla twojego zespołu
• Użytkownicy biznesowi korzystający z systemu biletowego nie są programistami

Od dobrego projektowania oprogramowania powinieneś uprościć i jak najbardziej zawrzeć.

Aby spojrzeć na ten proces z punktu widzenia użytkowników biznesowych, naprawdę dbają tylko o 2 rzeczy.

1. Ile to będzie kosztować?
2. Czy już skończyliśmy?

Umożliwienie użytkownikowi biznesowemu poznania wewnętrznego procesu zespołu jest złym zarządzaniem; zbliżony do zapewnienia publicdostępu do stanu wewnętrznego.

Brak ochrony stanu wewnętrznego zespołu zachęca inne zespoły do ​​zarządzania zasobami i bałagania się stanem wewnętrznym.