Znalezienie usystematyzowanego sposobu pracy z wymaganiami może potrwać. Ja swój system cały czas doskonalę, ale mogę powiedzieć, że już działa nieźle.
Po pierwsze - zrozum potrzebę biznesową, jaką ma zaspokoić rozwiązanie.
Najlepiej to opisać i potwierdzić z klientem - zrozumienie problemu, jakiemu stawia czoło biznes i celu, jaki chcą osiągnąć realizując nowy projekt, jest podstawą w analizowaniu potencjalnego rozwiązania.
Po drugie - czym kierują się stakeholderzy?
Jeżeli biznes sam proponuje rozwiązanie, postaraj się zrozumieć, czym kierowali się Twoi stakeholderzy wybierając takie, a nie inne, rozwiązanie. Wielu z nas porusza się jedynie w swoich ramach poznawczych - wymyślamy rozwiązania w ramach tego, co znamy i rozumiemy.
Po trzecie - burza mózgów!
Angażowanie zespołu w analizę wymagań nie jest pójściem na skróty, ani wysługiwaniem się innymi. W różnorodności siła! Będąc analitykami patrzycie na nowe rozwiązania zupełnie inaczej niż testerzy, deweloperzy czy architekci. Każdy punkt widzenia jest cenny! Zwłaszcza, gdy zmiany, które mają być dokonane, są rozległe i dotykają wielu aspektów systemu. Jeżeli nie macie tyle przestrzeni, żeby zorganizować burzę mózgów całego zespołu, to może chociaż uda się zrobić spotkanie trójkowe? Jeszcze lepiej, gdy możecie włączyć w proces osoby ze strony klienta.
Po czwarte - struktura.
Przygotowując specyfikację korzystam z pewnego schematu, który ułatwia mi późniejszy podział na zadania dla zespołu i zapewnia, że nic mi nie umknie.
Kiedyś od razu tworzyłam epic/feature w narzędziach do zarządzania zadaniami i od razu tworzyłam do niego notki, które starałam się opisać. Taka chciałam być porządna 😉 Dziś już tego nie robię, ponieważ boleśnie przekonałam się, jak łatwo coś przeoczyć. Co więc robię? Tworzę sobie szablon, na którym bazuję przygotowując specyfikację, a który wygląda następująco:
| Potrzeba biznesowa:
…
Cel, jaki ma być osiągnięty: …
Wymagania: Wymaganie
Kryteria akceptacji
Notatki
Link
|
W momencie, gdy coś przyjdzie mi do głowy w międzyczasie - wpisuję to do kolumny z pytaniami (chyba, że nie ma to nic wspólnego z aktualnym tematem, wtedy ląduje na mojej liście todo ). Gdy coś nie jest jasne w momencie specyfikowania, zapisuję to również w kolumnie z pytaniami. Nie ma znaczenia, czy wątpliwości pojawiają się, gdy pracuję sama, rozmawiając z zespołem, czy z klientem. Wszystko musi być w jednym miejscu!
Gdzie trzymam tabelę?
To zależy od projektu, a przede wszystkim od moich najważniejszych stakeholderów. Jeżeli pracujemy z klientem, który nie zagląda do naszego narzędzia do zarządzania wymaganiami, używam wtedy łatwo dostępnego dla wszystkich miejsca, np. Confluence albo - wersja minimalistyczna - pliku tekstowego w chmurze. Podejmując taką decyzję należy wziąć pod uwagę również politykę Twojej firmy i firmy klienta, w zakresie przechowywania takich informacji. Jeżeli taka istnieje, to na pewno istnieje również miejsce, gdzie można bezpiecznie taką dokumentację przechowywać. Najważniejsze jest, aby była ona łatwo dostępna dla wszystkich stakeholderów. Pamiętajcie, aby linka do dokumentu dodawać w każdym mailu, czy zaproszeniu na spotkanie tak, aby maksymalnie ułatwić wszystkim zainteresowanym pracę.
Na koniec.
Dopiero w momencie, kiedy wszystko jest wyjaśnione, a wymagania są potwierdzone przez kluczowych stakeholderów, tworzę zadania dla zespołu. W ten sposób unikam wielokrotnego poprawiania notek, co przy dużej ich ilości może być uciążliwe, czasochłonne i niestety - błędogenne. Nie jestem też ograniczona wczesnym podziałem rozwiązania na zadania, łatwiej jest zachować spójność i wyłapać wymagania do ponownego użycia.
A Wy? Jak pracujecie? Z czym macie najwięcej problemów? Co się u Was sprawdza, a czego nigdy nie robicie?
__________________________
* W momencie, kiedy wymagania i kryteria akceptacji są zatwierdzone i przenoszę je do narzędzia do zarządzania wymaganiami (Jira, TFS, inne), wklejam link do tej notki, żeby być pewna gdzie i jakie wymaganie zostało zapisane, i upewniam się, że wszystkie wymagania zostały przeniesione (!)
