Gdybym miała wybrać, z jakiego narzędzia najczęściej korzystam na pewno byłaby to CHEKCLISTA!
Więcej o checklistach możesz się dowiedzieć we wpisie: Organizacja dnia pracy Product Ownera
Tworzę listy dotyczące wielu aspektów mojej pracy PO — poczynając od zadań porannych po zamykanie projektu.
Mało tego, posiadanie checklist w moim przypadku nie ogranicza się tylko do zawodowego życia! Jeśli obserwujesz mój profil na social mediach, to pewnie już wiesz — w przestrzeni prywatnej też jestem od nich uzależniona!😁 Jednak to temat na inny artykuł… dzisiaj skupimy się na listach dotyczących pracy Product Ownera!
Checklista, która pomoże Ci zweryfikować, czy masz dobrze określone kryteria akceptacji zadań
Na początku chciałabym zwrócić Ci tylko jedną uwagę — pamiętaj, że moja checklista dotyczy stricte projektów, nad którymi pracowałam. Nie musisz więc dążyć do jej odwzorowania w swojej pracy i projekcie 1:1. Potraktuj ją jako luźną inspirację do skrojenia jej na miarę własnych (projektowych) potrzeb!
Checklista kryteriów akceptacji:
- Kryteria są napisane jako równoważniki zdań.
- Kryteria opisują rezultat nie proces.
- 1 kryterium = jeden podpunkt.
- W kryteriach użyłam zdań prostych (unikamy zdań złożonych).
- Uwzględniona została “happy path”.
- Uwzględnione zostały warunki brzegowe:
- Jakie błędy są wyświetlane?
- Tekst błędu jest zrozumiały dla użytkownika końcowego.
- Uwzględnione zostały aspekty CRUD:
-
- C – create – kto (lub co?) może wprowadzać (tworzyć) dane?
-
- R – read – kto (lub co?) może dane odczytać?
-
- U – update – kto (lub co?) może aktualizować dane?
-
- D – delete – kto (lub co?) może usuwać dane?
⚠️ Kryteria akceptacji mają być taką checklistą dla wszystkich stron. Dzięki niej:
- Biznes wie, jaki będzie rezultat implementacji.
- Developer wie, co i jak ma zakodować.
- Tester wie, jak ma testować.
Przykłady
Zobaczmy parę przykładów, które pomogą nam zrozumieć jak zastosować powyższe punkty:
- Kryteria opisują rezultat nie proces.
Zamiast pisać:
Gdy użytkownik kliknie w >>wyślij przelew<< dostaje powiadomienie na swoją aplikację, gdzie może przelew potwierdzić. Gdy to zrobi, zobaczy w aplikacji potwierdzenie wykonania przelewu
lepiej napisać:
– wysyłka przelewu musi być potwierdzone w aplikacji,
– po wykonanym przelewie wyświetlane jest potwierdzenie wykonania przelewu.
- 1 kryterium = jeden podpunkt.
Zamiast pisać:
Użytkownik, żeby się zarejestrować, musi podać email i hasło, a po zalogowaniu musi podać imię i nazwisko.
lepiej napisać:
– rejestracja użytkownika wymaga podania e-mail i hasła
– podczas pierwszego logowania użytkownik musi podać imię i nazwisko
- W kryteriach użyłam zdań prostych (unikamy zdań złożonych).
Zamiast pisać:
Użytkownik na widoku wszystkich umów może skorzystać z funkcji, dzięki której umowy zostaną przefiltrowane i wyświetlone ze względu na typ umowy.
lepiej napisać:
– umowy mogą być filtrowane po typie umowy
- Uwzględniona została “happy path”
W tym podpunkcie trzeba zadbać o uwzględnienie ścieżki, którą chcemy, żeby użytkownik przebył.
- Uwzględnione zostały warunki brzegowe:
W tym punkcie uwzględniamy ścieżki, które nie mieszczą się w “happy path” Np. co jeżeli klient chce dodać do koszyka więcej produktów niż mamy na stanie?
- Jakie błędy są wyświetlane?
Tutaj musimy rozważyć np. różne walidacje. Możemy np. informować użytkownika, że podany przez niego mail jest nieprawidłowy, bo nie zawiera ‘@’ i ‘.’ i wtedy nie jest możliwy zapis formularza.
Ale możemy również np. informować, że imię jest nieprawidłowe bo zawiera cyfrę, a mimo to pozwolić na zapisanie formularza. (Być może Elon Musk będzie jeszcze bardziej kreatywny przy wymyślaniu imienia swojego kolejnego dziecka i trend się poniesie?)
- Tekst błędu jest zrozumiały dla użytkownika końcowego.
Programiści “po swojemu” obsługują błędy, ale tekst “Http failure response for http://xyz-deployment-pdf.azurewebservices/abc/820e6a23-sjh5-72889-jekn-234n234u/abc/preview?culture=en: 500 OK” niewiele powie użytkownikowi końcowemu 🙂 Trzeba zadbać o zrozumiały test błędu Choćby “Coś poszlo nie tak, spróbuj ponownie”.
- Uwzględnione zostały aspekty CRUD:
-
- C – create – kto (lub co?) może wprowadzać (tworzyć) dane?
-
- R – read – kto (lub co?) może dane odczytać?
-
- U – update – kto (lub co?) może aktualizować dane?
-
- D – delete – kto (lub co?) może usuwać dane?
Tutaj chodzi o to, żeby rozważyć jak dane o których mowa jest w wymaganiu mogą być tworzone, odczytywane, aktualizowane i usuwane.
Np. jeżeli mamy sklep internetowy, to użyktownicy samodzielnie dodają się do bazy poprzez założenie konta. Mogą też odczytać i edytować swoje dane oraz usunąć konto.
Ale czy ktoś jeszcze może operować na tych danych?
Tak!
- administrator sklepu może odczytać i edytować dane klienta, jeżeli tan np. popełnił jakich błąd. Czy może usuwać? No właśnie – dobre pytanie.
- system/osoba/firma obsługująca wysyłkę zamówień może odczytać, ale nie może edytować czy usunąć takich danych
- podobnie księgowość, która wystawia paragony, czy faktury
Pamiętaj też, że kryteriów akceptacji nie tworzymy w oderwaniu od reszty interesariuszy! 😁
Powinny być one potwierdzone z biznesem i przegadane z zespołem developerskim. Nie bez przyczyny tworzone są interdyscyplinarne zespoły w IT. Wiele można wyciągnąć ze spotkań refinementowych, gdzie wspólnie obgadujemy wymagania, ich kryteria akceptacji i na bieżąco je modyfikujemy, tak aby zaadresować potrzeby pod wymagania.
Mam nadzieję, że moja checklista pomoże Ci w lepszym i efektywniejszym tworzeniu kryteriów akceptacji! Jeśli masz pytania — zadaj je w komentarzu, zawsze odpowiadam!
M.in. takich rzeczy możesz się ode mnie nauczyć w Szkole Prodcut Ownera. Zapisz się już dziś – masz czas tylko do 1 lutego do 20:00!!
