Jestem właścicielem produktu w zwinnym zespole. Kiedy robię testy akceptacji PO, zwykle robię notatki, aby wypróbować niektóre przypadki krawędzi. Często zdarza się, że coś odkrywam, a potem oddaję to twórcom. Dostaję odpowiedź od jednego z programistów, gdy odrzucam jego historie. Mówi, że to niesprawiedliwe, ponieważ nie określam przypadków skrajnych i tego, jak program powinien reagować w kryteriach akceptacji, ponieważ zwykle koduje tylko to, co opisuję w tej historii. Zachęciłem go, by zapytał mnie, gdy wpada na jakieś przypadkowe przypadki podczas kodowania, ale uważa, że nie jego zadaniem jest zastanawianie się nad przypadkowymi przypadkami, jego kopalnią i powinienem napisać nowe historie na następny sprint.
W mojej obronie nie znam jego projektu do czasu, gdy go zaimplementuje, więc trudno jest iterować przez wszystkie możliwości (czy konfiguracja będzie w pliku DB lub właściwości?). Dla uproszczenia załóżmy, że mamy historię dodawania podziału do aplikacji kalkulatora. Czy w idealnym świecie SCRUM obowiązkiem byłoby dodać do kryteriów akceptacji „scenariusz dzielenia przez zero”, czy powinien on pracować nad tymi przypadkami, gdy się rozwija, aby aplikacja nie implodowała na 5/0? Żeby było jasne, w tym przypadku nie zaakceptowałbym, gdyby aplikacja mocno się zawiesiła na 5/0, ale przekazałbym, jeśli loguje się, drukuje DIV0 lub w jakikolwiek inny sposób poradzić sobie z błędem ... tak długo jak nie rozbić się.
Odpowiedzi:
Myślę, że odpowiedź brzmi: oboje powinniście myśleć o swoim własnym zestawie przypadków. Jako, że deweloper powinien obsługiwać przypadki brzegowe, które są specyficzne dla danych, takie jak awaria aplikacji z dowolnego wejścia użytkownika, 5/0 z pewnością należy do tej części spektrum. Twórca powinien zapytać o ciebie, co Twoim zdaniem byłby odpowiednim komunikatem o błędzie, gdy dane wejściowe podane w ramach interakcji użytkownika prowadzą do czegoś nieprawidłowego.
Twoja część spektrum to biznesowa strona rzeczy. Jak powinien zachowywać się kalkulator, jeśli konto użytkownika nie może używać przycisku podziału? Jak powinno się to zachowywać, gdy konto może korzystać z operacji Mod, ale nie ma dostępu do funkcji podziału?
Ważną wiadomością, którą moim zdaniem należy przekazać i uzyskać akceptację wszystkich członków zespołu, jest to, że wszyscy jesteście w tym samym zespole. Jeśli produkt nie jest kompletny, produkt nie jest kompletny, a zespół ponosi winę, a nie dany członek.
źródło
Zespół musi współpracować, a nie mieć postawę / mantrę typu „Nie moja praca, nie moja odpowiedzialność”.
Kryteria akceptacji mają postać:
Zazwyczaj akceptacja firmy zazwyczaj odpowiada na pytanie:
Ta funkcja będzie miała szereg wymagań, które są zorientowane na biznes, na przykład jeśli kliknę ten przycisk, spodziewam się, że to nastąpi. Wymienione zostaną spodziewane scenariusze biznesowe i oczekiwane zachowanie, ale nie obejmie wszystkich możliwych przypadków.
Oczekuje się, że wymagania biznesowe powinny być zdefiniowane przed iteracją, aby w ramach zapewniania jakości można było opracować wszelkie wymagania techniczne dotyczące wymagań innych niż biznesowe. W ramach zapewniania jakości należy opracowywać przypadki niszczące, a także w razie potrzeby przypadki skrajne.
Oba zestawy wymagań powinny zostać przejrzane przed rozpoczęciem pracy nad historią, aby możliwe było formalne oszacowanie i zaangażowanie jednostki pracy. Po wykonaniu tej czynności można opracować funkcję / historie. W tym momencie wszyscy mają jasność co do tego, co ma zostać dostarczone zarówno z biznesowego, jak i technicznego punktu widzenia.
Fabuła osiąga ostateczną akceptację, gdy członkowie zespołu ds. Biznesu i zapewnienia jakości podpiszą ją. Powinno to nastąpić podczas iteracji zarówno akceptacji biznesowej, jak i akceptacji zapewnienia jakości. Jest to definicja gotowej (DoD), która sygnalizuje, że można rozpocząć dodatkowe prace nad historią.
Wszelkie nowe ustalenia mogą być rejestrowane jako wady lub dodatkowe skoki historii. W idealnym świecie nigdy by się to nie zdarzyło, ale w rzeczywistości zwykle występuje pewne „odkrycie”, które ma miejsce podczas pracy nad fabułą / historią. To jest naturalne.
Zespół powinien współpracować (biznes, QA, deweloper) do mieszania z każdym chaotyczny typu odkrycie wymagań. Jeśli jest to sprawne, wszyscy powinni siedzieć przy tym samym stole, aby wspierać komunikację i szybkie rozwiązywanie wszelkich pojawiających się pytań. Powinien wyglądać mniej więcej tak:
QA:
DEV:
BIZNES:
DEV:
Lub jeśli jest to dużo pracy, nowa historia jest dodawana do zaległości. Zespół nadal może zaakceptować oryginalną historię, ponieważ spełnia ona wszystkie pierwotne wymagania, a następnie podnieść historię szczytów w następnej iteracji.
źródło
Pisanie oprogramowania, które zachowuje się w solidny sposób w obliczu niepoprawnych lub niejednoznacznych danych wejściowych, jest istotną częścią pracy programisty.
Jeśli programiści nie widzą tego w ten sposób, dołącz dodatkowe wymagania niefunkcjonalne do specyfikacji wymagań, które wyraźnie określają to wymaganie, i przekaż programistom przykład procesu testowania, aby mogli sami zastosować ten proces przed przesłaniem ostatecznej wersji kod do recenzji.
Testy akceptacyjne powinny być istotną częścią każdego dokumentu wymagań. Jeśli wymaganie nie określa również kryteriów akceptacji, tak naprawdę nie jest to wymaganie; to życzenie.
źródło
Stało się tutaj, że odkryłeś wartość . Wartość wejściowa nie była brana pod uwagę przy pisaniu historii (i kryteriach akceptacji) ani przy pisaniu kodu. Jeśli nie jest to część kryteriów akceptacji, tak naprawdę nie masz podstaw do odrzucenia historii.
To, co moglibyśmy zrobić w moim zespole, to:
Korzyścią tutaj jest to, że musisz rozważyć, czy naprawienie tego błędu jest kolejną najważniejszą rzeczą do zrobienia. To może być lub nie być wystarczająco ważne, aby to naprawić, ale ważne jest, aby wziąć pod uwagę jego wartość.
Oczywiście nadal musisz znaleźć sposób, aby zachęcić programistów (i siebie) do zbadania tych przypadków z góry. Jeśli Twój zespół programistów nie spędza czasu na dzieleniu się historiami, zachęć ich do szczegółowej sesji planowania przed rozpoczęciem pracy nad nimi.
źródło
Niektóre spostrzeżenia:
Nie znam twojej kultury pracy ani procesu, ale dla mnie odrzucenie historii jest poważnym krokiem. Gdybym był deweloperem, generowałbym również push, ponieważ jest to nagrana akcja, która źle odbija się na mnie i zespole.
To niesprawiedliwe, że spodziewa się, że znasz wszystkie skrajne sprawy. Ale jednocześnie niesprawiedliwie jest oczekiwać od niego tego. Każda zmiana wiąże się z ryzykiem, a po wykryciu problemów musisz współpracować jako zespół, aby je rozwiązać.
Nie powinieneś znać projektu. Pomocna może być znajomość projektu, aby wstępnie zgadnąć, które historie są łatwiejsze lub trudniejsze do zarządzania zaległościami. Ale unikaj uwięzienia programisty w swoim projekcie podczas pisania opowiadań. Wysysa całą zabawę, gdy jesteś po prostu klawiaturą aktywowaną głosem dla PO.
Wygląda na to, że powinniście popracować nad usprawnieniem procesu i budować zespół. Niektóre rzeczy, które mogę zasugerować dla procesu:
źródło
Wymagania powinny być jasne i zwięzłe. Jeśli nie są, to dzieje się dokładnie to, co się z tobą stało. To twoja wina, a najgorsze, co możesz zrobić, określając wymagania, to zakładać różne rzeczy.
Podałeś konkretny przykład dotyczący dzielenia przez zero. Jeśli nie określiłeś, że chcesz zarejestrować błąd, nie narzekaj, jeśli programista wydrukuje 100 jako wynik.
Ale w takich przypadkach uzupełniałem brakujące luki i przekazywałem je deweloperowi. W końcu zdarzają się błędy w wymaganiach.
źródło