Z racji tego, że publikacja odnośnie zwinnego podejścia w zakresie modelowania procesów biznesowych (WMB) –pisałem o tym kilka dni temu w tekście pt “Krajowa Konferencja Inżynierii Oprogramowania“- ukazała się w limitowanej edycji 150 egzemplarzy pozwalam sobie na publikację skanu tego tekstu.
User story to opis celów zorientowanych na użytkownika, jakie jedna lub więcej osób osiągnie za pomocą Twojego produktu. User stories używa się do osiągnięcia celu zawsze wtedy, kiedy jest osoba obsługująca interfejs . User story pisze się w formacie
Jako [osoba odgrywająca daną rolę] chcę [wykonać jakąś czynność] aby [osiągnąć jakiś cel].
W ten sam sposób można pisać scenariusze przypadków użycia, przy których należy uwzględnić, że scenariusz może obejmować kilka user story. Takie podejście pozwala także na zastosowanie modelowania w języku UML w SCRUM i tym samym wpisuje sie w nurt agile modeling – zwinnego modelowania.
Długość iteracji i jej wielkości pod względem zasobów musi być skorelowana z celami i pracą, które ma być wykonana. Moje wytyczne:
Wielkość zespołu – większe zespoły wprowadzają większe koszty stałe i tym samym prowadzą do dłuższej iteracji. Następujące wytyczne zapewniają przydatny punkt wyjścia:
Cele iteracji – niektóre cele wymagają więcej czasu na ukończenie niż inne
Wielkość kosztów stałych – im więcej sprawozdawczości oraz innych przeciążeń administracyjnych, które są nakładane na zespół, tym dłuższe będą musiały być iteracje
Podział zespołu – im bardziej podzielony zespół, tym trudniejsza komunikacja oraz tym więcej czasu zajmie uzgodnienie decyzji prowadzących do zwiększonego poziomu planowania i dokumentowania oraz dłuższych iteracji
Dostępność zasobów – Im mniej czasu, który członkowie zespołu mają przeznaczyć na projekt, tym więcej czasu upłynie na iteracje
Formalność projektu – niektóre projekty mają bardziej surowe wymogi odnośnie przeglądów formalnych i dokumentacji projektowej, wymagając więcej czasu na te czynności
W trakcie szkicowania procesów biznesowych należy zdefiniować wspólne słownictwo, przy użyciu najpopularniejszych terminów i wyrażeń w zakresie problemu. Następnie należy konsekwentnie wykorzystywać wspólne słownictwo we wszystkich tekstowych opisach biznesu. W ten sposób, utrzymują Państwo spójne opisy tekstowe i unika się nieporozumień wśród członków projektu dot. stosowania i znaczenia terminów. Słownictwo powinno mieć formę słownika.
Aby znaleźć wspólne terminy w zakresie problemu, należy uwzględnić terminy stosowane w trakcie rozmowy, o co chodzi w biznesie. Warto skupić się na terminach opisujących następujące koncepcje:
Każdym termin jest na ogół opisywany jako rzeczownik wraz z definicją. Terminy powinny być podane w liczbie pojedynczej, "zamówienie" oraz "zadanie", a nie "zamówienia" czy "zadania".
I na koniec oczywiste i najważniejsze: wszystkie zainteresowane strony powinny porozumieć się co do zdefiniowania terminów.
Aby przewidzieć wymogi dla aplikacji biznesowej można rozważyć stworzenie następujących modeli:
Podane punkty stanowią składową wielu aplikacji biznesowych, ale w zależności od specyfiki biznesu i procesu niektóre z nich mogą być opcjonalne.
Moim zdaniem wszystkie metodyki zwinne mają tą zaletę, że są tańsze od tradycyjnego “ciężkiego” podejścia choćby dlatego, że nie traci się czasu na modelowanie. Jest tylko jedno ale. A mianowicie klient musi dokładnie wiedzieć czego chce. Co w sytuacji gdy klient jest grymaśny, zmienia wymagania lub tylko je odrobinę modyfikuje bo jak widzi gotowy produkt to zaczyna rozumieć błędy w swoich wymaganiach, zaczyna rozumieć swój biznes? W takiej sytuacji modelowanie staje się nieodzowne. Budując model klient może zrozumieć i zobaczyć jak będzie działał system i zweryfikować czy jest to to o co dokładnie mu chodziło. Co więcej mając model wytwórcy także lepiej go rozumieją. Pozostaje pytanie: Co z kosztami?
Wbrew pozorom koszty modelowania nie są wysokie i zwracają się z nawiązką.
Skąd te wyniki wyjaśnia to poniższa tabela, w której cyfry stanowią jednostki czasu, którym możemy przypisać dowolną wartość: tydzień, miesiąc.
|
Działanie |
SCRUM z modelowaniem |
SCRUM |
|
Wymagania |
1 |
1 |
|
Modelowanie |
3 |
0 |
|
Kodowanie |
9 |
10 |
|
Poprawianie kodu |
1 |
6 |
|
Testowanie |
1 |
3 |
|
Suma |
15 |
20 |
Otóż ponosi się co prawda koszty modelowania, ale w związku z tym, że zatwierdzony model pomaga lepiej zrozumieć projektowany system i klientowi, i wykonawcy systemu to jest mniej poprawek kodu i mniej testowania bo testy mogą być wcześniej zaplanowane. Natomiast permanentne zmiany w aplikacji celem dostosowania ich do wymagań klienta, w sytuacji gdy gotowy produkt rozmija się mniej lub bardziej z rzeczywistymi potrzebami klienta to dodatkowe koszty. Ponadto gdy nie ma modelu programista musi wszystko wymyślić sam a tym samym może się okazać, że gdy popełni błąd w rozumowaniu to prawienie błędu pociąga za sobą dodatkowe koszty. Mając model można błędy wychwycić wcześniej.
Szacuję, że przy większych projektach oszczędności czasu a tym samym pieniędzy, z tytułu modelowania, sięgają od 20 do 30 procent.
Na koniec należy pamiętać, że podane cyfry to tylko przykład i w każdym projekcie poszczególne fazy mogą wyglądać inaczej a co za tym idzie oszczędności mogą być mniejsze lub większe.
Budowanie modeli ma ogromną wartość. Zastanawia mnie dlaczego budując dom wymagana jest dokumentacja projektowa a do budowy systemu informatycznego to sprawa opcjonalna. Dokumentacja nie zawsze jest wykonywana a jej potrzeba wynika bardziej ze świadomości zamawiającego produkt niż z wymogów prawa. Ciekawe jest to, że koszt budowy domu jest wielokrotnie niższy niż niejednego systemu informatycznego. Co więcej gdy chcemy coś dobudować do naszego domku musimy mieć gotowy plan rozbudowy i kilka zezwoleń od władz. W systemach informatycznych niejednokrotnie zmiany są nanoszone ad hoc – zwłaszcza w metodykach Agile. A przecież budowa zwinnego modelu nie jest droga a daje sporo korzyści bo pozwala na lepsze zdefiniowanie wymagań. Budowa modeli pozwala na:
Innymi słowy niezależnie od tego czy budujemy nowy system czy też rozbudowujemy stary mając model jesteśmy wstanie lepiej zarządzać wymaganiami a tym samym całym przedsięwzięciem, gdyż unikamy większej ilości przypadkowych czynności, które mogłyby doprowadzić do porażki.
Zwinne modelowanie polega miedzy innymi na tym, że budowana dokumentacja do projektu nie jest nadwymiarowa. Innymi słowy jest jej tyle ile potrzeba i nie mniej ani nie więcej. Jak na tym zapanować. Ja osobiście lubię stosować scenariusze (w SCRUM opowiadania klienta), które pozwalają mi na zbudowanie zwinnych przypadków użycia. Natomiast przypadki użycia pomagają mi efektywnie:
Czym jest więc przypadek użycia? W moim rozumieniu przypadek użycia to agregat scenariuszy dostarczający konkretnych wartości. Dlatego też w moich modelach scenariusze odgrywają ważną rolę, a modele opierają się o przypadki użycia.
Scrum to jedna ze zwinnych metodyk w nurcie Agile, stosowaną w procesie wytwórczym oprogramowania. SCRUM jest ukierunkowany na budowę gotowego kodu. Powstaje jednak pytanie co zrobić, gdy potrzebny jest model, lub specyfikacja projektu?
Jest na to sposób. Można budować modele zgodnie z metodyką SCRUM. Na stronie: Modelowanie w SCRUM opisałem zarys SCRUM wraz z kilkoma wskazówkami wykorzystania języka UML w tej metodyce.
Zasadnicze cechy SCRUM, w bardzo dużym uproszczeniu, to:
W przypadku Scrum projekt postępuje seriami miesięcznych iteracji, które zwane są sprintami.
Scrum pasuje idealnie do projektów z szybko zmieniającymi się lub pojawiającymi się wymogami Praca, która ma być wykonana w projekcie Scrum, jest wymieniona w Product Backlog, stanowiącym listę wszystkich pożądanych zmian w produkcie. Na początku każdego sprintu odbywa się Spotkanie dot. Planowania Sprintu, podczas którego Właściciel Produktu ustala hierarchię Product Backloga a Zespół Scrum wybiera zadania, które może wykonać podczas nadchodzącego Sprintu. Te zadania są następnie przenoszone z Product Backloga do Sprint Backloga.
Każdego dnia sprintu odbywają się krótkie spotkania zwane Codziennymi Scrumami, które pomagają zespołowi terminowo wykonać pracę.
Na końcu każdego sprintu, podczas Spotkania Przeglądowego Sprintu, Zespół przedstawia dokonaną funkcjonalność.
Role:
Czynności:
Artefakty:
Właściciel Produktu (ang. Product Owner) reprezentuje interesy wszystkich interesariuszy, określa cechy produktu i ustala hierarchię Product Backloga – zaległości produktu.
Właściciel Produktu ma następujące obowiązki:
Właściciel Produktu jest odpowiedzialny za pierwszy z trzech rytuałów Scrum: Planowanie Sprintu
Zespół Scrum przygląda sie zhierarchizowanemu Product Backlogowi, oddziela pozycje o największym priorytecie i zobowiązuje się je wykonać podczas sprintu. Pozycje te stają się Sprint Backlogiem.
W zamian za zobowiązanie Zespołu Scrum do wykonania wybranych zadań, Właściciel Produktu zobowiązuje się, że nie będzie obarczać zespołu nowymi wymogami w trakcie sprintu. Wymogi mogą być zmienione, ale tylko poza sprintem. Po tym jak zespół rozpocznie sprint, będzie ona maniakalnie skoncentrowana na celu sprintu.
W zwinnym modelowaniu Właściciel Produktu to osoba, która przekazuje wymagania do zamodelowania, odbiera modele – klient, lub osoba z danej organizacji, która zamawia dany produkt.
Role:
Czynności:
Artefakty:
Mistrz Scrum (ang. Scrum Master) odpowiada za zapewnienie tego, aby Zespół Scrum żył wartościami i praktykami Scrum czyli innymi słowy on nadzoruje sposób wykorzystania metodyki. Mistrz Scrum chroni zespół poprzez zapewnienie tego, że nie podejmą oni zbyt wielkich zobowiązań w stosunku do tego, co mogą osiągnąć podczas sprintu. Mistrz Scrum ułatwia Codzienny Scrum i staje się odpowiedzialny za usuwanie przeszkód, o których to informuje zespół w trakcie tych spotkań.
Mistrz Scrum:
Ponadto Mistrz Scrum nie jest kierownikiem projektu, ale mediującym liderem zespołu i kierownikiem procesu Scrum. Jego głównym zadaniem jest monitorowanie zadań sprintu, aby zapewnić jego powodzenie. W tym celu musi regularnie fizycznie spotykać się z pozostałymi członkami zespołu. Należy pamiętać, że Mistrz Scrum nie tworzy/przypisuje zadań dla zespołu (robi to sam zespół).
Mistrz Scrum w zwinnym modelowaniu to kierownik projektu, który poza nadzorowaniem prac nad modelem może zajmować się szacowaniem ryzyka przedsięwzięcia.
Role:
Czynności:
Artefakty:
Wszystkie prawa zastrzeżone 
modesto group All rights reserved
