Kto w Scrumie weryfikuje „Gotowe”?

13

Jestem kierownikiem ds. Kontroli jakości / testów w mojej organizacji i do dziś zweryfikowałem jakość oprogramowania (testy napisane i wykonane oraz usunięte błędy). Kto to zweryfikuje w Scrumie? Skąd mam wiedzieć, że zespół napisał i wykonał wszystkie właściwe testy? Z drugiej strony obawiam się, że jeśli będę kontynuować weryfikację, zespół nie będzie miał wystarczających uprawnień. Ale potrzebuję trochę procesu weryfikacji, czy „Gotowe” to rzeczywiście „Gotowe”. Co sugerujesz?

Eugene
źródło

Odpowiedzi:

21

Jednym z głównych pomysłów w Scrum jest to, że zespół powinien uzgodnić „definicję ukończenia”. Idealnie jest to coś w rodzaju zestawu obiektywnych kryteriów, które każdy może zweryfikować, przeglądając listę kontrolną.

Ale aby zmniejszyć szansę na prześlizgnięcie się czegoś, to jest sensowne, aby mieć zasadę, że weryfikacja „zrobione” najczęściej jest wykonywana przez kogoś innego niż osoba, która wdrożyła przedmiot - lub wyznaczonego faceta do spraw jakości, takiego jak ty (ale ryzykuje to, że ty wąskie gardło).

W razie wątpliwości należy omówić z zespołem i mistrzem Scrum i wspólnie zdecydować.

Michael Borgwardt
źródło
+1, chociaż właściciel produktu zwykle nie jest uważany za część zespołu - zazwyczaj jest wylosowany poza kręgiem zespołu - ale ma (lub powinien mieć) głos w definicji „zrobione”. Jest to jedyny sposób, w jaki właściciel produktu może (wolno) wpływać na sposób działania zespołu.
Marjan Venema
1
@MarjanVenema Właściciel produktu jest bardzo uważany za część zespołu Scrum. W rzeczywistości bez właściciela produktu Scrum ma niewielkie szanse na odniesienie sukcesu.
Derek Davidson PST CST
1
@Derek: Myślę, że masz nieporozumienie oparte na niejasnej terminologii. Istnieje zarówno „Zespół Scrumowy”, jak i „Zespół programistów”, przy czym ten drugi jest częścią tego pierwszego, a także Właściciel produktu i Scrum Master.
Michael Borgwardt
2
@MichaelBorgwardt Właśnie dlatego tak jasno odpowiedziałem w odpowiedzi, że właściciel produktu jest częścią zespołu Scrum . Zgadzam się, że właściciel produktu nie jest częścią zespołu programistów, ale kontekst nie wyjaśnił tego. Miałem nadzieję, że rozwiążę zamieszanie. Wygląda na to, że mogłem przypadkowo coś stworzyć :)
Derek Davidson PST CST
6

Myślę, że w tym pytaniu jest ukryte założenie. Istnieje różnica między „zaakceptowanym”, gdy Właściciel Produktu oświadcza, że ​​element zaległości lub zadanie spełnia wymagania Właściciela Produktu, a „zakończone”, co oznacza, że ​​cała praca związana z tym elementem jest zakończona.

Jednak zadanie ma zwykle coś więcej niż zadanie widoczne dla właściciela produktu, zwykle w najlepszym razie pół-techniczne, w tym testy (automatyczne i ręczne), dokumentacja i przegląd. Właściciel produktu rzadko jest w stanie poznać aspekty techniczne, nie mówiąc już o ich zakończeniu.

Dlatego to ostatecznie do zespołu należy określenie, co oznacza „zrobione”. Organizacja może mieć standardy, a różni interesariusze będą mieli własne wymagania. Scrum master lub odpowiedni menadżerowie zwykle są odpowiedzialni za zestawianie i egzekwowanie listy.

W twoim przykładzie jako kierownik kontroli jakości / testów jesteś tym, który mówi, czy testy są zakończone. Jednak możesz nie być najlepszą osobą, która powie, czy kod został sprawdzony, wymagania bezpieczeństwa są spełnione, produkt jest umiędzynarodowiony, dokumentacja jest kompletna lub cokolwiek innego stanowi „zrobione”.

akton
źródło
4

Jedynym pojęciem „zrobione” jest to, czy historia jako całość jest ukończona. Zespół powinien stworzyć definicję czynności, która mówi, kiedy czują, że historia jest skończona, czy nie. Zazwyczaj obejmuje to takie rzeczy, jak „sprawdzono kod”, „przeprowadzono nocne testy”, „wszystkie kryteria akceptacji zostały spełnione” itp. Po osiągnięciu tych celów zespół może mieć pewność, że zrobił wszystko oczekiwałem od nich, że skończą historię.

Podczas sprintu, jeśli próbujesz ustalić, czy jeden z tych elementów w definicji skończonej został osiągnięty, po prostu zapytaj. W Scrumie i zwinności chodzi o otwartą komunikację. Jeśli należysz do zespołu, zapytaj kolegów z drużyny, czy ktoś napisał testy, czy je przeprowadził, czy stworzył pracę nocną itp. Jeśli jesteś interesariuszem, zapytaj mistrza scrum.

Jeśli siedzisz poza zespołem, ale nadal musisz sprawdzić testy, poproś zespół, aby dodał „testy muszą zostać sprawdzone przez użytkownika user3251930” jako część definicji „zrobione”. Jeśli tego wymaga opowieść, bądź szczery i włącz ją do procesu. Cały sens „definicji ukończenia” polega na tym, aby zespół mógł mieć pewność, że zrobił to, co jest wymagane do dostarczenia wysokiej jakości oprogramowania. Jeśli częścią tego jest przegląd zewnętrzny, niech tak będzie.

Ostatecznie to właściciel produktu podpisuje się na konkretnej historii, więc pod koniec dnia on lub ona podejmuje ostateczną decyzję, czy opowieść jako całość jest skończona, czy nie.

Bryan Oakley
źródło
Muszę przejrzeć testy, w przeciwnym razie nie wiedziałbym, czy zostały napisane prawidłowe testy. Definicja „Gotowe” nie obejmuje dokładnych testów, które należy napisać.
Eugene
@ user3251930: dlaczego musisz je przejrzeć? Nie ufasz swojemu zespołowi? Jeśli jednak naprawdę musisz je przejrzeć, uwzględnij definicję „być przetestowane przez użytkownika3251930”.
Bryan Oakley
Jeśli klienci otrzymają coś, co nie zostało całkowicie przetestowane, byłoby naprawdę bardzo źle. Może z czasem uda mi się zaufać zespołowi, mam taką nadzieję.
Eugene
1

Pierwsze pytanie, które powinieneś sobie zadać

Czy jesteś Scrum Master ? Jeśli tak.

W scrum procesy są kontrolowane i zarządzane przez Scrum Master.

Jak ty to robisz:

W fazie wymagań możesz użyć historii użytkowników dla każdego testu, który należy zweryfikować.

W każdym sprincie Elementy pracy są pobierane z rejestru produktów i kierowane przez właściciela produktu. Każdy z nich będzie również miał kryteria weryfikacji.

Teraz w wymaganiach Scruma nie zmieniaj się po rozpoczęciu sprintu. Pod koniec sprintu możesz przeanalizować weryfikację zgodnie z kryteriami dla każdego wykonanego przedmiotu.

Jeśli to zrobione, można znaleźć tylko na podstawie odpowiedzi właściciela produktu.

Pamiętaj, że w Agile „Obejmujesz zmianę” nawet w późnej fazie rozwoju

Neo
źródło
0

Zespół decyduje. Używam listy kontrolnej, która jest uważana za „Gotowe”. Co „zrobiono” na historię, na sprint, na wydanie.

Jak wspomnieli inni, ostatecznie decyzja należy do właściciela produktu.

Sherbert
źródło
czy to tylko Twoja osobista opinia, czy możesz jakoś to zrobić?
komara
-1

Zgadzam się, że jest to coś, co zespół programistów / testerów musi zdefiniować, w zależności od własnych praktyk. Niektóre projekty działają na tyle sprawnie, że zaryzykują opublikowanie błędów w swoim strumieniu alfa; niektórzy uważają, że każdy błąd, który wydostaje się poza grupę programistów, jest błędem procesu.

Projekt, nad którym pracuję, wymaga wzajemnej oceny zmian w kodzie i wymaga, aby każdy, kto napisał kod, dostarczył / zaktualizował testy regresji lub wyjaśnił, dlaczego nie jest to możliwe. (Oni i ich recenzenci muszą również poświadczyć, że sprawdzili znane złe praktyki. Na ogół jesteśmy znacznie bardziej szczęśliwi, jeśli mogą wykazać, że uruchomili pełny zestaw testów i uzyskali czysty wynik (lub znany czysty moduł) przynajmniej otwarte problemy) Kod musi następnie przetrwać intensywne zautomatyzowane testy jednostkowe i funkcjonalne na wielu platformach, aby wykazać, że nie powoduje żadnych regresji w stosunku do nich, i jest dodatkowo sprawdzany pod kątem typowych antypatternów przez automatyczny system analizy kodu. to czy akceptujemy go w głównym strumieniu programowania i oznaczamy element pracy jako ukończony.

To oczywiście nie gwarantuje, że nikt nie znajdzie nowego sposobu na porażkę, ale zmniejsza ryzyko do akceptowalnego poziomu bez znacznego ograniczenia szybkości rozwoju.

keshlam
źródło