Cześć! Tutaj Szymon z analizowac.pl W tym poście poruszę temat wyboru techniki zbierania wymagań biznesowych. Przez całą swoją karierę dobierałem techniki ekspercko z wykorzystaniem doświadczenia i tego jak zbieranie wymagań wygląda w danej organizacji.
Wiadomo, wykorzystywałem proste schematy typu:
- Interesariusz nie umie do końca opisać swojego procesu – obserwacje
- Duża grupa interesariuszy, mało czasu – ankiety
- Znany problem lub okazja, brak pomysłu jak go zrobić – burza mózgów
- Stary system do przepisania – archeologia systemu
- etc
Jednak nie miałem do tego żadnego ciekawego procesu który opisywał by jasno. Taka i taka sytuacja to taka i taka technika. Ostatnio zacząłem się zastanawiać nad tym jak u mnie wygląda proces doboru techniki zbierania wymagań biznesowych. I szukając też innych ludzi którzy dokonywali takich samych przemyśleń natknąłem się na fajną matrycę doboru technik wyboru techniki pozyskiwania wymagań biznesowych. Sposób doboru techniki wydawał mi się na tyle ciekawy że postanowiłem się nim podzielić na blogu.
Zbieranie wymagań – matryca
Cała matryca wyboru najlepiej jest do przedstawienia za pomocą schematu
Wybór naszej techniki zbierania wymagań jest podzielony na 3 filary wyboru które potem razem łączymy i na podstawie tych filarów wybieramy technikę. Te filary to
- Parametry projektu
- Interesariusze
- Jak wytwarzamy oprogramowanie
Przejdźmy przez każdy z tych filarów.
Parametry projektu
W filarze „Parametry projektu” definiujemy zakres parametrów które przypisujemy do projektu(piękne zdanie mi wyszło no ale czy tego chcę czy nie to właśnie to robimy w tym kroku). A jakie parametry mamy? Poniżej tabelka
| Parametr | Opis |
| Rozmiar projektu | Rozmiar projektu definiujemy po ilości wymagań które dany projekt dostarcza. Wyróżniamy trzy typy: – Mały (do 100 wymagań) – Średni (do 1000 wymagań) – Duży (powyżej 1000 wymagań) |
| Złożoność projektu | Złożoność definiujemy na podstawie takich czynników jak liczba modułów których zmiana dotyczy, liczba systemów z którymi trzeba się zintegrować, liczba technologii jakich trzeba użyć, zróżnicowanie obszarów z jakich pochodzą interesariusze, liczba ludzi decyzyjnych w projekcie. Dzielimy na 4 typy – Niska – Średnia – Wysoka – Bardzo wysoka |
| Zmienność wymagań | Czyli liczba wymagań które się zmieniają wraz z upływem czasu trwania projektu. Dzielimy na 3 typy – Mała – Średnia – Duża |
| Solidność | Czyli stopień jakości wymagań jaki jest potrzebny dla bezpieczeństwa wdrożenia projektu. Dzielimy na 4 typy – Niska – Średnia – Wysoka – Bardzo wysoka |
| Ograniczenie Czas/budżet | Czyli ile mamy czasu na wdrożenie projektu oraz jakim budżetem dysponujemy. Projekt może być rygorystyczny lub bardziej elastyczny. Dzielimy na 4 typy – Niski – Średni – Wysoki – Bardzo wysoki |
| Czy domena biznesowa istnieje? | W tym parametrze definiujemy czy proces który chcemy usprawnić oprogramowaniem istnieje czy nie. Projekt może być wymianą obecnego systemu lub wyrzuceniem obsługi procesu na Excelach a może być tworzeniem nowych procedur. Dzielimy na dwa typy – Istniejąca – Nowa |
| Dostępność interesariuszy | Czyli czas jaki interesariusze są w stanie nam poświęcić – Niska – Średnia – Wysoka |
| Zasięg projektu | Odpowiada na pytanie czy aplikacja będzie używana tylko przez ludzi w danej organizacji czyli aplikacja szyta na miarę(wewnętrzna) czy przez zewnętrznego klienta czyli aplikacja pudełkowa (zewnętrzna) – Wewnętrzna – Zewnętrzna |
| Wiedza domenowa | Czyli odpowiedź na pytanie jak bardzo znamy domenę biznesową projektu. Dzielimy na 3 typy – Mała – Średnia – Duża |
| Wielkość zespołu developerskiego | Czyli jak bardzo niezawodne musi być oprogramowanie. Wyróżniamy 3 typy – Mały (czyli prosty system biznesowy gdzie do obsługi wystarczy max kilku programistów którzy znają system od podszewki) np. system do zarządzania zadaniami – Średni (czyli system który wymaga większej ilości programistów i nie muszą oni znać wszystkiego) – Duży (czyli system który jest duży, nie może zawieść pod żadnym pozorem i wymaga dużej ilości programistów) np. system obsługi bankomatów lub kontroli lotów |
Identyfikacja charakterystyk ludzkich
Jak wszyscy dobrze wiemy, ludzie odgrywają największą rolę w przypadku każdej inicjatywy związanej z rozwojem informatycznym organizacji. Tak samo jak w procesie wytwórczym w przypadku wyboru techniki zbierania wymagań, charakterystyka interesariuszy odgrywa dużą rolę. Zachowanie interesariuszy ich wiedza, doświadczenie mają duży wpływ na to jak zbieranie wymagań biznesowych będzie wyglądać.
Dlatego jednym z filarów wyboru techniki zbierania wymagań jest identyfikacja z jakimi interesariuszami mamy do czynienia. Tutaj tak samo jak w przypadku parametrów projektowych przygotowano matrycę cech ludzkich.
W tej matrycy oceniamy Interesariusza ale i Analityka. W przypadku analityka określamy dwie cechy:
- Doświadczenie w inżynierii oprogramowania (Nowicjusz/Doświadczony/Ekspert)
- Doświadczenie w domenie biznesowej (Nowicjusz/Doświadczony/Ekspert)
W przypadku Interesariusza mamy dwie cechy
- Doświadczenie w domenie biznesowej (Nowicjusz/Doświadczony/Ekspert)
- Charakter (Cichy/Komunikatywny/Otwarty)
Proces wytwarzania oprogramowania
Tutaj to zwyczajnie wyróżniono najbardziej popularne metody wytwarzania oprogramowania i na nie nałożono dopasowanie do technik zbierania wymagań biznesowych. Wyróżniono następujące procesy:
- Waterfall
- Prototypowanie
- Model eksploracyjnego wytwarzania oprogramowania
- Model spiralny wytwarzania oprogramowania
- Model skupiony na reużywalności aplikacji
- Modele Agileowe
- Proces zunifikowany jak np. RUP
- Rapid application development (RAD)
Matryce wyboru techniki zbierania wymagań
Po zdefiniowaniu filarów do wyboru metody zbierania wymagań przyszedł najwyższy czas na to żeby dobrać do tego techniki. A jaka propozycja została tutaj przedstawiona? Jak zwykle najlepszym sposobem pokazania czegokolwiek to pismo obrazkowe więc dla odmiany przedstawiamy 3 matryce wyboru techniki zbierania wymagań.
Matryca parametrów projektu
Matryca charakterystyk ludzkich
Wartości w matrycy są T/N (Tak/Nie) w odpowiedzi na pytanie czy używać danej techniki. Tam gdzie jest kreska to dana technika nie dotyczy cech interesariusza.
Matryca procesu wytwarzania oprogramowania
W przypadku tej matrycy zalecane jest stosowanie prostej zasady która brzmi:
Jeśli dla danego procesu dana technika ma wartość >=0.5 to można tą technikę stosować.
Wydaje się proste.
Przykład
Jak już opisałem całe założenia z artykułu to teraz warto jest przerobić to jakoś przetestować.
Weźmy sobie prosty przykład i zobaczmy jak będzie wyglądać zbieranie wymagań dla niego. Załóżmy że jesteśmy w sytuacji gdzie mamy:
Osoby – Interesariusze
- Osoby które zjadły zęby na swoim biznesie
- Osoby które są otwarte
- Osoby które nie dysponują dużą ilością czasu
Osoby – Analityk
- Mamy dobry background techniczny
- Słabo jeszcze znamy dziedzinę biznesową
Proces wytwórczy
Proces wytwórczy niech będzie procesem Agileowym czyli np. najbardziej popularny Scrum
Rozmiar projektu
Rozmiar niech będzie średni. Kilkaset wymagań.
Złożoność i solidność
Powiedzmy że to prosta aplikacja więc niech będzie średnia
Zmienność wymagań
Niech będzie niska(czyli idealny świat dla każdego programisty co raczej się nie udaje)
Ograniczenia czas/budżet
Powiedzmy że tutaj zbyt dużego ciśnienia nie ma więc zróbmy niskie.
Domena biznesowa istnieje, projekt wewnętrzny i zespół developerski nie jest za duży.
Jak to nam się mapuje na techniki zbierania wymagań?
Patrząc po matrycy parametrów projektowych to szybko nam się lista technik zawęża. BA! nawet jedna technika nie jest w stanie w 100% się wpasować w nasz projekt. No ale nie załamujemy się. Najbardziej pasujące techniki które mają najwięcej podkreśleń(7 podkreśleń) to
- Grupy fokusowe
- Warsztaty
- Obserwacje
- Analiza protokołu
- Analiza dziedziny biznesowej/procesu biznesowego
- Introspekcja
Matryca ludzi też nie ma techniki w 100% pasującej więc wybierzmy te co mają najwięcej „okejek”:
- Burze mózgów
- Wywiady
- Grupy fokusowe
- Warsztaty
Techniki które w modelu Agile mają >=0.5 to
- Wywiady
- Grupy fokusowe
- Warsztaty
- Obserwacje
- Analiza kultury organizacji
- Prototypowanie
- Modelowanie
- Analiza dziedziny lub procesu
- Laddering
- Introspekcja
- Mapy myśli
- Analiza dokumentacji
No i mamy zwycięzców!! Możemy zaczynać zbieranie wymagań 😉
Wybierzmy laureatów naszego plebiscytu! Techniki dla których zbieranie wymagań najbardziej pasuje do danej sytuacji to(czyli techniki które są w trzech matrycach):
- Grupy fokusowe
- Warsztaty
Techniki które są w 2 matrycach
- Obserwacje
- Analiza dziedziny lub procesu biznesowego
- Introspekcja
Jestem zaskoczony. Byłem mocno sceptyczny do tego ale wyszło całkiem dobrze w mojej skromnej ocenie.
Podsumowanie
Podsumowując. Sposób jest… Ciekawy. Jednak wydaje się trochę zadaniem takim dla ludzi którzy lubią sobie pogrzebać i podumać w jakiś rzeczach które nie mają zbyt dużej wartości. Czyli dla ludzi takich jak ja którzy jak się czymś zainteresują to nie odpuszczają i grzebią do końca. Może w sumie by napisać taką apkę która wyliczy te techniki na podstawie wprowadzonych danych? W sumie w wolne jesienno-zimowe weekendy nie będzie co robić 🙂
Źródło
