Pisząc jakąkolwiek specyfikację wymagań a rejestr produktu i rejestr sprintu są taką specyfikację należy uwzględnić wymagania niefunkcjonalne.
O ile sama historyjka użytkownika zazwyczaj reprezentuje wymagania funkcjonalne to, w moim odczuciu, drobny problem jest z wymaganiami niefunkcjonalnymi, które reprezentują oczekiwania na poziomie systemu. Brak wymagań niefunkcjonalnych lub ich niedostateczna ilość są często źródłem problemów z programowaniem a także z testowaniem.
„Dobre zarządzanie oczekiwaniami jest niezmiernie ważne — szczególnie dlatego, że wiele osób nadal ma błędne wyobrażenie zasad, możliwości i granic zwinnych sposobów postępowania. Tylko wtedy, gdy oczekiwania są znane, można je okiełznać i powiązać z wymaganiami.”[3].
Osobiście uważam, że należy stosować takie narzędzia, które pozwolą na mapowanie wymagań niefunkcjonalnych na historyjki użytkownika. Enterprise Architect 13 jest dla mnie oczywistym rozwiązaniem.
„Właściciel produktu jest odpowiedzialny za definiowanie kryteriów akceptacji dla każdego elementu rejestru produktu. Są to warunki konieczne, które muszą być spełnione, aby właściciel produktu mógł z satysfakcją przyznać, że wszelkie funkcjonalne i niefunkcjonalne wymagania zostały zrealizowane. Właściciel produktu w oparciu o kryteria akceptacji może również pisać testy akceptacyjne lub werbować w tym celu ekspertów z danej dziedziny lub samych członków zespołu deweloperskiego. Niezależnie od przyjętego podejścia właściciel produktu powinien upewnić się, iż kryteria akceptacji (a często również specyficzne testy akceptacyjne) zostały stworzone, zanim element trafi pod obrady w trakcie planowania sprintu. Bez nich zespół nie będzie w pełni rozumiał danego elementu i nie będzie mógł przyjąć go do realizacji w sprincie. Z tego względu wiele zespołów scrumowych dołącza istnienie jasnych kryteriów akceptacji do swojej listy kontrolnej definicji gotowości„[1].
Wymagania dotyczące user experience najłatwiej zapisuje się w postaci szkiców, scenopisów, diagramów nawigacyjnych interfejsu użytkownika i prototypów. Moje doświadczenie sugeruje, że zespoły wolą tego rodzaju artefakty niż wytyczne dotyczące interfejsu użytkownika przedstawione w formie graficznej.
„W trakcie zarządzania wymaganiami niefunkcjonalnymi najlepiej jest wprowadzić rozróżnienie na wymagania globalne i lokalne. Te pierwsze zwykle odnoszą się do wszystkich wymagań funkcjonalnych i tworzą małą grupę. Przykładem może być ograniczenie wydajnościowe (…). Globalne wymagania niefunkcjonalne powinny być jak najwcześniej szczegółowo opisane — w trakcie tworzenia wizji lub dodawania nowych elementów do rejestru produktu„.[2]
Na koniec należy pamiętać iż „Scrum zrywa z dotychczasowym modelem, który zakładał, że w momencie uruchamiania projektu klient dokładnie zna swoje potrzeby. Wystarczy je tylko udokumentować i po sprawie. Scrum mówi zupełnie coś innego. Zamiast tracić czas na opisywanie czegoś, co i tak w trakcie kolejnych etapów pracy może się zmienić, rozmawiaj, pytaj, wyjaśniaj wątpliwości, nie bój się swoich pomysłów„[4].
Zapisanie wymagań niefunkcjonalnych już na poziomie epik pozwala na ich doprecyzowanie na poziomie poszczególnych sprintów. Co więcej Scrum zakłada dialog co oznacza, że nierealne (czyt. bardzo kosztowne w produkcji a mało użyteczne) wymagania funkcjonalne i niefunkcjonalne zostaną doprecyzowane w taki sposób, że osiągnięty zostanie konsensus pomiędzy celami i oczekiwaniami Właściciela Produktu a możliwościami technicznymi i umiejętnościami zespołu deweloperskiego.
Pisząc ten wpis korzystałem oraz umieściłem cytaty z następujących pozycji:
[1] „Scrum. Praktyczny przewodnik po najpopularniejszej metodyce agile” – Kenneth S. Rubin
[2] „Zarządzanie projektami ze SCRUM. Twórz produkty, które pokochają klienci” – Roman Pichler
[3] „Zwinne projekty w klasycznej organizacji” – Henning Wolf
[4] „Scrum. O zwinnym zarządzaniu projektami. Wydanie II rozszerzone” – Mariusz Chrapko
Szczególnie polecam pozycje 1 i 4, które to moim zdaniem są bardzo dobrą literaturą. Podane linki są linkami afiliacyjnymi.
Reklama
Globalne wymagania niefunkcjonalne można zapisać jako punkty DoD zespołu w danym projekcie. Dzięki temu przy każdej historyjce będziemy o nich pamiętać.