“Zadanie zostało wykonane”, powiedział Zleceniobiorca. “Ale przecież mi chodziło o coś zupełnie innego!” odpowiedział Zleceniodawca. “A były kryteria akceptacji?”
Brzmi znajomo?

Jestem przekonany, że każdy z nas przynajmniej raz znalazł się w sytuacji kiedy odbierał zlecone wcześniej komuś zadanie i był negatywnie zaskoczony jego efektem. Co więcej, niektórych to spotyka codziennie. Jak sobie z tym poradzić? Przede wszystkim definiując kryteria akceptacji do każdego zleconego przez nas zadania.

Zacznijmy od praktycznego i “prostego” przykładu

Przeanalizujmy prosty jak wydawać by się mogło przykład podstawowej funkcjonalności większości systemów IT – logowania. “Jako klient chciałbym móc zalogować się do systemu, żeby móc korzystać z jego wszystkich ukrytych funkcjonalności” brzmiałaby podstawowa Historia użycia zgodnie ze zwinnym podejściem do wytwarzania oprogramowania. 

Jak określić kryteria akceptacji?

Kiedy zatem możemy uznać, że Dostawca oprogramowania dostarczył poprawnie działającą funkcjonalność logowania? W teorii wydaje się, że wystarczy móc zalogować się do systemu. W praktyce tutaj pojawiają się pytania.

  • Zalogowanie za pomocą loginu czy e-mail? 
  • A może system powinien móc rozróżnić te pola? 
  • A hasło podajemy na tym samym ekranie gdzie login, czy może na kolejnym? 
  • A czy samo logowanie nie wymaga dwu lub trzy stopniowej autoryzacji? 
  • A jeżeli już się zalogujemy, to mamy być przeniesieni w jakieś konkretne miejsce systemu?
  • A możemy się logować za pomocą SSO, np. kontem Google?
  • A jeżeli nie uda nam się zalogować, to system mówi wprost, że podaliśmy złe hasło, czy ogólnie o niepoprawnych danych?
  • A czy system ma podpowiadać możliwość zapamiętać danych w pamięci przeglądarki by nie trzeba się było ponownie logować?

Będąc bardzo dokładnym, a tego w końcu oczekuje od Software House każdy Zleceniodawca, można listę powyższych pytań rozwijać bardzo długo. I dokładnie na tym powinna polegać praca Product Ownera definiującego wymagania biznesowe przed ich zleceniem dalej. PO musi być świadomy, że pomijając ten krok, lub realizując go nie wystarczająco szczegółowo, nie może oczekiwać, że zespół deweloperski wyczyta z jego myśli wszystkie niespisane założenia i dostarczy Historię użycia w wymarzonej postaci.

Nie ma rzeczy oczywistych

Podstawowym założeniem, jakie stawiamy przed każdy projektem, sprintem, historyjką lub zadaniem jest “nie ma rzeczy oczywistych”. Wymaga to niestety więcej pracy na etapie projektowania i definiowania założeń, ale odpłaca się kilkukrotnie mniejszą ilością nieporozumień i czasu oraz budżetu przeznaczonego na ich prostowanie w późniejszym cyklu życia projektu.

Ustaliliśmy już dlaczego Kryteria akceptacji są niezbędnym elementem każdego zleconego dalej zadania oraz przeanalizowaliśmy przykładową funkcjonalność logowania. Tylko jak wykorzystać tę wiedzę w przypadku nowo definiowanych założeń? Czy istnieje jakaś gotowa checklista, po przejściu której możemy mieć pewność posiadania dobrych kryteriów akceptacji projektu?

Kreując kryteria akceptacji projektu zawsze posługujemy się takimi pytaniami jak:

  • W jakich warunkach funkcjonalność spełnia oczekiwania biznesowe?
  • W jakich warunkach funkcjonalność nie spełnia oczekiwań biznesowych?
  • Jakie elementy ma zawierać funkcjonalność?
  • Jaki jest pozytywny koniec ścieżki?
  • Jaki jest negatywny koniec ścieżki?
  • Ile różnych ścieżek (negatywnych i pozytywnych) może mieć funkcjonalność?
  • Jaki powinna dawać output funkcjonalności?
  • Jaki user powinien mieć input do funkcjonalności (czyli jakie dane powinien zapewnić)?
  • Czy funkcjonalność powinna być zależna od innej funkcjonalności albo od zewnętrznego systemu? W jakim stopniu?
  • Jak funkcjonalność powinna wyglądać (UI Design)?

Głównym kryterium tworzenia kryteriów jest doświadczenie

Niemniej najważniejsze przy spisywaniu kryteriów akceptacji jest doświadczenie. Doświadczenie co w przeszłości w podobnych sytuacjach poszło nie tak, jakie wnioski zostały wyciągnięte i jak możemy na ich podstawie zabezpieczyć projekt i Klienta przed potencjalnymi nieporozumieniami. My jako Globe Group zbieramy to doświadczenie już od 2008 roku, współpracując z małymi i średnimi przedsiębiorstwami, a także start-upami czy międzynarodowymi korporacjami. 

Potrzebujesz konsultacji w zakresie kryteriów akceptacji, backlogu projektu czy nawet wyceny?

Odezwij się do nas!

Dodaj komentarz