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?
Odpowiedzi:
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ć.
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”.
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.
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
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.
DoneiUndone