Kolejne pytanie, które pojawiło się na „Liście 99” to:
Jak
zbiera Pani wymagania?
Na to pytanie odpowiem posługując się radami, zawartymi w
książce „Oprogramowanie szyte na miarę” M. Bartyzela, informacjami z kursu „Specjalistów analizy” oraz wskazówkami
z bloga analiza it
Zbieranie wymagań można podzielić na 3 podstawowe kategorie
: Współpracę, Badania i Eksperymenty.
Do etapu współpracy
zaliczymy m.in. wywiady, warsztaty ( o tym jak poprowadzić dobre warsztaty można
dowiedzieć się z piętnastej lekcji kursu Specjalistów analizy ).
Do rozmowy (wywiadu), pierwsze co należy zrobić to PRZYGOTOWAĆ SIĘ ! Sprawdź kim są Twoi przyszli klienci, czym się zajmują, jaką pełnią rolę w organizacji itp. Itd. To ułatwi Ci prowadzenie rozmowy i pozwoli na połamanie pierwszych lodów.
Do rozmowy (wywiadu), pierwsze co należy zrobić to PRZYGOTOWAĆ SIĘ ! Sprawdź kim są Twoi przyszli klienci, czym się zajmują, jaką pełnią rolę w organizacji itp. Itd. To ułatwi Ci prowadzenie rozmowy i pozwoli na połamanie pierwszych lodów.
Badania to między
innymi Analiza: dokumentów, materiałów z etapu sprzedażowego, specyfikacji procesów
biznesowych, regulacji, możliwych rozwiązań.
Eksperymenty to np.:
tworzenie makiet i prototypów.
Ważnym aspektem jest zidentyfikowanie interfejsów nie tylko tych związanych z
integracją pomiędzy systemami uczestniczącymi w procesie, ale także (a może
przede wszystkim ) tych ludzkich, wymiana informacji między systemami/zespołami, analiza tej komunikacji to podstawa poprawnie zebranych wymagań.
Jeśli prowadzimy
rozwój systemu, czyli nie musimy zaczynać wszystkiego od zera, to dobrze jest
zapoznać się z procesami w firmie (jeśli
jest coś takiego jak księga procesów, to cudnie, ale najczęściej procesy
zagnieżdżone są w dokumentach typu PT, lub różnego rodzaju Specyfikacjach).
Jeśli zależy nam na zebraniu dużej ilości informacji w
krótkim czasie, warto w procesie zbierania wymagań posiłkować się dobrymi ankietami i kwestionariuszami, które dadzą nam statystyczny ogląd na problemy
, które chcemy rozwiązać.
Kolejnymi metodami są
Burze mózgów, należy
zorganizować spotkanie, podać na nim temat i pozwolić uczestnikom na
wypowiadanie najbardziej abstrakcyjnych pomysłów, takich, które mogą wydawać
się irracjonalne a w efekcie mogą dawać spektakularne rezultaty!
Stymulowanie innego
punktu widzenia – należy postawić
się w roli potencjalnego użytkownika i jego oczami spojrzeć na potencjalny
produkt. Metoda ta może okazać się zbawienna i rzuci nam nowe światło na
zbieranie wymagań do naszego projektu.
Obserwacje polowe – polegają na obserwacji użytkowników w trakcie ich pracy,
może wydawać się to na pierwszy rzut oka dość dziwne, no bo jak to tak,
jedziemy do kogoś i gapimy mu się na ręce ? no niestety trochę tak, ale trzeba
pamiętać, że warto wyjść zza biurka, zobaczyć jak wyglądają procesy od początku
do końca. Niestety minusem tego sposobu zbierania wymagań jest możliwość
pominięcia sytuacji wyjątkowych, bo np.: jesteśmy u naszego klienta przez 7
dni, wyjeżdżamy do swojego biura, mamy w głowie cudowny plan a tu JEB! 8 dnia 3
fuckupy, tysiąc błędów a my tego nie obserwowaliśmy i prawdopodobnie nie uwzględnimy
w procesach i wymaganiach, które będziemy opisywać.
Warsztaty – mają na celu zebranie
w przysłowiowej kupie osób z różnych działów, najlepiej z różnym punktem
widzenia na dany problem, które wspólnie dochodzą do wniosków, dających ogromną
wartość dodaną do procesu zbierania wymagań. Warsztaty są jedną z kluczowych praktyk
zwinnych, ponieważ angażują kluczowych interesariuszy to tworzenia backlogu. Jedynym
minusem warsztatów jest ich czasochłonność i trudność w wykorzystaniu dla
zespołów rozproszonych geograficznie.
Przypadki użycia –
pomagają spojrzeć na system oczami użytkownika, ważną zaletą przypadków użycia
jest wyznaczenie dzięki nim granic systemu i powiązania aktorów z poszczególnymi
funkcjonalnościami. Wadami przypadków użycia może być ich niemożliwość dostosowania
do systemów bez interfejsu użytkownika lub dla samych wymagań jakościowych
Wg
Inżynierii Wymagań, typowa struktura wymagania biznesowego powinna
obejmować
następujące aspekty:
- Użytkownik – dla kogo przeznaczone jest to wymaganie?
- Wynik – jakiego wyniku oczekują interesariusze?
- Przedmiot – co jest przedmiotem wymagania?
- Kwalifikator – jaki jest mierzalny kwalifikator?
Metod zbierania wymagań jest oczywiście o wiele
więcej, niemniej te wydają mi się najbardziej praktyczne i najczęściej
stosowane. Jeśli uważasz, że ta odpowiedź powinna wyglądać inaczej, napisz w
komentarzu. 😊
Komentarze
Prześlij komentarz