Niefunkcjonalne wymagania jako User Stories
W Product Backlogu zapisywane są wymagania dotyczące produktu. Jeśli chcemy je sformułować z perspektywy użytkownika, często stosuje się format User Story. W sposób jasny i konkretny ujmowane są tutaj funkcjonalne wymagania dotyczące produktu. Ale co z wymaganiami niefunkcjonalnymi? One również powinny znaleźć się w Product Backlogu. Dowiedz się tutaj, dlaczego wymagania niefunkcjonalne są ważne i jak najlepiej można je zintegrować z Product Backlogiem, np. przy użyciu szablonu User Story.
Różnice między wymaganiami funkcjonalnymi i niefunkcjonalnymi
Od dawna w zarządzaniu produktem rozróżnia się wymagania funkcjonalne i niefunkcjonalne. Oba pojęcia są rozgraniczane również w zwinnym zarządzaniu wymaganiami. Poniżej krótko przedstawiamy różnice.
Wymagania funkcjonalne
Te wymagania opisują konkretne funkcje i specyfikacje produktu. Jako User Story wymagania są wymienione możliwie precyzyjnie i kompletnie — takie, które są ważne dla użytkownika. Są to wymagania specyficzne dla produktu, które zazwyczaj nie mogą być przeniesione na dowolny inny produkt. Oto typowe przykłady wymagań funkcjonalnych:
Jako użytkownik programu do edycji tekstu chcę móc wstawiać tabelę.
Program musi być w stanie obliczyć kaloryczność menu na podstawie formuły.
Wymagania niefunkcjonalne
Wymagania niefunkcjonalne są mniej specyficzne. Opisują na przykład jakość, warunek lub właściwość produktu. Te wymagania niekoniecznie są specyficzne dla produktu. Mogą mieć ogólne zastosowanie do wielu produktów, a nawet do całego projektu lub architektury oprogramowania:
Przyjazny dla użytkownika interfejs
Szybki czas reakcji
Ze względu na swój niespecyficzny charakter istnieje ryzyko, że te wymagania zostaną potraktowane po macoszemu podczas tworzenia Product Backlogu. Jednak powinny one być w nim uwzględnione, ponieważ są dla użytkownika bardzo istotne. Jeśli jakość, niezawodność czy szybkość nie są dostosowane do potrzeb klientów, produkt z dużym prawdopodobieństwem nie będzie używany — sama funkcjonalność nie wystarczy, by zadowolić użytkowników. Dlatego pojawia się pytanie, jak włączyć wymagania niefunkcjonalne do rozwoju produktu. Sformułowanie ich jako User Story jest pomocne, aby nadać priorytety temu rodzajowi wymagań.
Jak opisywać wymagania niefunkcjonalne w Scrum jako User Stories
- Wymagania niefunkcjonalne powinny być opisane w sposób mierzalny
- Patrzeć na wymagania niefunkcjonalne z perspektywy klienta
- Czy wymaganie niefunkcjonalne może lepiej znaleźć się w „Definition of Done"?
Wymagania niefunkcjonalne powinny być opisane w sposób mierzalny
Stwierdzenie, że Twoja strona powinna mieć możliwie szybki czas reakcji, jest dla zespołu deweloperskiego zbyt nieprecyzyjne. Nie opisuje mierzalnych wymagań. „Szybko" jest w tym przypadku nieprecyzyjnym stwierdzeniem, które praktycznie każdy deweloper definiuje inaczej.
Dla zespołu pomocne jest podanie dokładnych danych. Można je wypracować wspólnie. Jednym ze środków może być ograniczenie nałożone na wymaganie. Dzięki temu właściwości stają się bardziej uchwytne i można je bez problemu wdrożyć. Wymaganie może brzmieć na przykład tak:
Strona powinna ładować się w mniej niż x sekund.
Spalanie kalorii powinno być wyświetlone po kliknięciu w mniej niż 8 sekund.
Patrzeć na wymagania niefunkcjonalne z perspektywy klienta
Podczas tworzenia User Stories uczestnicy powinni wejść w perspektywę klienta. Przy tworzeniu User Story przydatne może być konkretne wyobrażenie produktu przy użyciu formatu:
„Jako <użytkownik> chcę <cel>, aby <powód>"
Ten prosty format może pomóc Tobie i Twojemu zespołowi pytać o powód wymagania. Dlaczego może być ważne dla użytkownika, aby spalanie kalorii menu było wyświetlone w mniej niż 8 sekund? Ponieważ użytkownik dzięki temu szybko ma wartość porównawczą, która pozwala mu zaplanować własne menu w swoim harmonogramie. Należy jednak kwestionować wynik i traktować formułę jedynie jako „narzędzie do myślenia". Jeśli odpowiedź na pytanie „dlaczego?" jest zbyt skomplikowana lub myląca, powinieneś szukać bezpośredniej rozmowy z klientem lub użytkownikiem. Zapytaj ludzi, dlaczego ta właściwość jest dla nich osobiście ważna. Czasami okazuje się, że wymaganie niefunkcjonalne wcale nie jest tak niespecyficzne, lecz jedynie niedokładnie sformułowane.
Czy wymaganie niefunkcjonalne może lepiej znaleźć się w „Definition of Done"?
Czy chodzi o kwestie przekrojowe, takie jak na przykład czasy reakcji programu? Wtedy może mieć sens umieszczenie ich w „Definition of Done". Wspólnie z zespołem i ewentualnie interesariuszami możecie rozważyć, czy szybki czas reakcji nie powinien być zasadniczo kryterium dla całego systemu.
Włączenie wymagania niefunkcjonalnego do Definition of Done oznacza, że każdy element musi je spełniać. Jest to korzystne, gdy chodzi na przykład o projekt graficzny i jego zgodność z identyfikacją wizualną firmy itp.
Przekształcanie wymagań niefunkcjonalnych w wymagania funkcjonalne
Wymagania niefunkcjonalne mogą być sformułowane jako User Story tak samo jak wymagania funkcjonalne. I powinny, aby nie zostały przeoczone lub zaniedbane. Ważne jest, aby były sformułowane w sposób mierzalny i w jakiś sposób ograniczone. Jeśli sam nie możesz wprowadzić ograniczenia, pomocna jest przedstawiona powyżej formuła. Pyta o „dlaczego?" i może służyć jako wsparcie dla Twoich przemyśleń. W przeciwnym razie pomaga bezpośrednia rozmowa z zespołem, użytkownikami lub interesariuszami.
Pierwsze informacje na temat Scrum i User Stories znajdziesz na naszej stronie. Chcesz zdobyć głębszą wiedzę o Scrum? Zarejestruj się na szkolenie Scrum i naucz się podstaw pracy zwinnej!
