Modelowanie zakresu jest jedną z ważniejszych czynności która jest do zrobienia w przypadku gdy mamy projekt do którego zgłasza się w trakcie gdy został wykonany development(i jesteśmy w trakcie testów) dodatkowe wymagania. W takim przypadku zespół developerski zamiast zajmować się poprawianiem błędów i dopieszczaniu wersji oprogramowania zajmuje się tym aby wykonać dodatkowy development.
Taki projekt lub zmiana prowadzi do tego że:
– nie wiemy czy cel został osiągnięty bo ciągle zmienia się zakres który musimy zrobić,
– nie wiemy czy wartość biznesowa została dostarczona bo czy zmiana zakresu nie sprawia że wartość uległa zmianie,
– tracimy czas na testy i termin wdrożenia zaczyna nas gonić(uciekamy od harmonogramu).
Co możemy zrobić w zaistniałej sytuacji?
Możemy jasno określić zakres projektu i na jego podstawie określać czy odpowiednie zmiany zostały wykonane czy nie i mieć zdefiniowane cele wg. przez wszystkich lubianej zasady SMART.
Jak tego dokonać?
Modelowanie zakresu jest rekomendowane do wykonywania na wiele sposobów. Według mnie najlepszymi technikami jest stosowanie poniższych technik:
– Modelowanie procesu biznesowego
Proces w jasny sposób pokazuje co jest w danym procesie biznesowym wykorzystywane a co nie i jakie czynności wspiera system w danym momencie procesu. Dzięki czemu w bardzo prosty sposób można wskazać co dany system robi a czego nie.
– Diagram przypadków użycia
Diagram przypadków użycia pokazuje co wykonuje dany system i w bardzo prosty sposób prezentuje granicę systemu. Dzięki tej granicy systemu bardzo łatwo można powiedzieć co wchodzi w zakres projektu a co nie.
– Lista funkcji systemu
Zanim napiszę cokolwiek o funkcjach systemu to zaznaczam jedno. Funkcje systemu to nie funkcjonalność. Funkcje to lista rzeczy które system wykonuje. Czyli np. generuje wydruk oferty. Do systemu generującego wydruk oferty nie dodamy nagle systemu dodawania zadań z klientem i zarządzania relacją z nim.
– backlog projektu
Backlog to spriorytetyzowana lista zadań które mamy wykonać w ramach projektu. Backlog jest uzgadniany z interesariuszami dzięki temu interesariusze w prosty sposób poznają system i jego granicę. Dzięki backlogowi w prosty sposób przedstawiamy zakres systemu poprzez edukację.
