Kilka dni temu w tekście: Zwinne modelowanie w Visual Studio 2010 pisałem o możliwości modelowanie za pomocą UML w VS 2010. Teraz czas na drugą z mojego punktu widzenia ważna zmianę. Otóż w MSF for Agile Software Development v5.0 jaki towarzyszy VS 2010 uwzględniono zwinne modele a proces wytwórczy kodu oparto o SCRUM. Więcej informacji pod adresem:
http://msdn.microsoft.com/en-us/library/dd380647.aspx
Szczególnie polecam rozdział 4.4 Use Models in Agile Development.
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.
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.
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:
Zespół Scrum (ang. Scrum Team) buduje produkt, który zostanie wykorzystany przez klienta: przykładowo, oprogramowanie lub witrynę. Zespół w Scrum jest „międzyfunkcyjny” – obejmuje całą wiedzę niezbędną dla dostarczenia w każdym Sprincie produktu będącego potencjalnym wynikiem sprintu – jest „samoorganizujący się” oraz posiada bardzo duży stopień autonomii i odpowiedzialności.
Zespół Scrum:
Zespół Scrum nie obejmuje żadnej tradycyjnej roli inżynierii oprogramowania, takiej jak programisty, projektanta, testera, bądź architekta. Wszyscy w projekcie pracują razem na rzecz wykonania zestawu prac, do którego wykonania w ramach sprintu się zobowiązali. Zespół Scrum wypracowuje głęboką formę koleżeństwa i poczucia, że „wszyscy razem w tym uczestniczymy”.
Zaleca się by członkowie powinni byli pełnoetatowymi pracownikami, ale mogą istnieć wyjątki (np. administrator baz danych) Członkowie powinni zmieniać się wyłącznie między sprintami.
W zwinnym modelowaniu w metodyce Scrum Zespół Produktu buduje modele. Ponadto Zespół Scrum obejmuje całą wiedzę niezbędną dla dostarczenia w każdym Sprincie modeli i dokumentacji będących potencjalnym wynikiem sprintu.
Role:
Czynności:
Artefakty:
Rezultatem każdego sprintu jest potencjalnie wykonalny przyrost produktu (ang. Potentially Shippable Product Incremement). Za wykonanie tego artefaktu odpowiada Zespół Scrum.
Dużo mówi się na temat różnicy między „potencjalnie wykonalnym (zrobionym)” oraz „wykonalnym”.
Mike Cohn stwiedza:
.. „potencjalnie wykonalne” oraz „wykonalne” to nie to samo. Niektóre duże lub złożone projekty będą wymagać zastosowania „sprintu hartującego” lub „sprint wzmacniającego” na końcu cyklu wypuszczenia (na przykład 6 dwutygodniowych sprintów a następnie dwutygodniowy sprint wypuszczenia). Sprint wypuszczenia nie stanowi ubijania podstawy dla byle jakiej pracy; jest to raczej miejsce, gdzie może odbywać się hartowanie systemu.
Jedna rzecz jest jasna: Zespół Scrum musi uzgodnić swoją definicję „potencjalnie wykonalnego” oraz „wykonalnego” i dojść do wspólnego rozumienia z Właścicielem Produktu.
W zwinnym modelowaniu w metodyce Scrum Potencjalnie Wykonalny Przyrost Produktu to nic innego jak modele i dokumentacja jaka ma powstać pod koniec każdego Sprintu.
Role:
Czynności:
Artefakty:
Zaległości produktu (ang. Product Backlog) to główny wykaz wszystkich funkcjonalności pożądanych w produkcie. Za dostarczenie zaległości produktu odpowiedzialny jest Właściciel Produktu.
Gdy projekt jest inicjowany nie ma wszechstronnego, czasochłonnego wysiłku, aby zapisać wszystkie dające się przewidzieć zadania lub wymogi. Zazwyczaj, projekt zapisuje to, co jest oczywiste, co niemal zawsze wystarcza do pierwszego sprintu. Product Backlog może następnie rozrastać się i o produkcie i jego klientach wiadomo więcej.
W trakcie Spotkania dot. Planowania Sprintu Właściciel Produktu ustala hierarchię pozycji w Product Backlog i opisuje je zespołowi. Następnie zespół określa, które pozycje może wykonać podczas nadchodzącego Sprintu. Następnie zespół przenosi pozycje z Product Backloga do Sprint Backloga. W trakcie tej czynności dzieli każdą pozycję Product Backloga na jedno lub kilka zadań Sprint Backloga tak, aby mógł skuteczniej dzielić pracę w trakcie Sprintu. Konceptualnie, zespół zaczyna od góry zhierarchizowanej listy Product Backloga i zaznacza linię po najniższych pozycjach o wysokim priorytecie, które może wykonać. W praktyce nie jest rzeczą wyjątkową, że zespół wybiera, na przykład, pięć górnych pozycji, a następnie dwie pozycje dolne na liście, ale takie, które mają związek z początkowymi pięcioma.
Pozycje Product Backloga mogą być zadaniami technicznymi („Modyfikacja klasy Login, która narzuca wyjątek”) lub bardziej skoncentrowane na użytkowniku („Umożliwienie wycofania ustawień ekranu”).
Product Backlog może być zachowany w arkuszu Excela. Arkusz Excela może pokazywać każdą pozycję Product Backloga i ogólny priorytet (bardzo wysoki, wysoki, itd.) nadany przez Właściciela Produktu. Szacunki zostały przygotowane przez twórców, ale jest zrozumiane, że są bardzo nieprecyzyjna oraz są przydatne tylko dla ogólnego przypisania zadań do różnych sprintów.
W zwinnym modelowaniu Zaległości Produktu to wymagania jakie są stawiane modelowanemu systemowi lub organizacji. Idealną techniką są tu przypadki użycia, które mogą być odpowiednikiem wspomnianych powyżej jednej lub kilku pozycji opisanych w arkuszu Excel.
Gdy w metodyce Scrum stosuje się modelowanie to wykonane modele i dokumentacja projektowa stają się Zaległościami produktowymi dla Zespołu Scrum, który będzie dokonywał implementacji rozwiązania.
Role:
Czynności:
Artefakty:
Wykres Wygaszania Wypuszczenia (ang. Release Burndown Chart) śledzi postęp drużyny pod względem planu wypuszczenia.
W projekcie Zespół Scrum śledzi swój postęp pod względem planu wypuszczenia, aktualizując Wykres Wygaszania Wypuszczenia na końcu każdego sprintu. Pozioma oś Wykresu Wygaszania Wypuszczenia pokazuje sprinty; oś pionowa pokazuje ilość pracy pozostającej na początku każdego sprintu. Praca pozostająca może być przedstawiona w dowolnej jednostce preferowanej przez zespół –punktach abstrakcji, dniach idealnych, itd.
Na tym Wykresie Wygaszania, drużyna rozpoczęła projekt, który został zaplanowany na jedenaście dwutygodniowych sprintów. Rozpoczęły się one z 200 punktami abstrakcyjnymi pracy. Pierwszy sprint przebiegł dobrze i z wykresu można wywnioskować, że po pierwszym sprincie praca pozostająca wyniosła 180 punktów abstrakcyjnych. Jednakże w trakcie drugiego sprintu oszacowana praca pozostająca faktycznie wygasła. Mogło tak być, ponieważ do projektu dodano pracę, albo zespół zmienił niektóre szacunki dot. pozostającej pracy. Od tego punktu projekt był dobrze kontynuowany. Postęp zwolnił podczas sprintu nr 7, ale następnie został szybko wznowiony.
Ten typ Wykresu Wygaszania Wypuszczenia bardzo dobrze sprawdza się w wielu sytuacjach oraz w wielu zespołach. Niemniej jednak, w przypadku projektów z mnóstwem zmieniających się wymogów, można spojrzeć na Alternatywny Wykres Wygaszania Wypuszczenia.
W zwinnym modelowaniu na Wykresie wygaszania Zespół Scrum śledzi swój postęp w modelowaniu i przygotowywaniu dokumentacji pod względem planu wypuszczenia, aktualizując Wykres Wygaszania Wypuszczenia na końcu każdego sprintu.
Role:
Czynności:
Artefakty:
Wykres Wygaszania Sprintu (ang. Sprint Burndown Chart) jest graficznym przedstawieniem pracy pozostającej do wykonania w trakcie trwania Sprintu.
Szacowana praca pozostająca w sprincie jest obliczana codziennie i przedstawiana w formie graficznej, czego efektem jest Wykres Wygaszania Sprintu Oś pionowa pokazuje pozostające w Sprincie godziny wysiłku. Oś pozioma przedstawia dni Sprintu. Wygaszanie ma zostać pokazane na linii spadku od startu Sprintu z godzinami startu, do końca Sprint przy braku pozostających godzin.
Zespół robi, co może, aby umieścić właściwą ilość pracy w sprincie, ale czasami podczas Spotkania dot. Planowania Sprintu umieszcza się zbyt dużo lub zbyt mało pracy. W takim przypadku drużyna musi dodawać lub usuwać zadania. W powyższym Wykresie Wygaszania Sprintu można zobaczyć, że zespół początkowo zaplanował zbyt dużo pracy i dnia 5/16/02 ciągle miał prawie 600 godzin do wypracowania. W takim przypadku skonsultowano się z Właścicielem Produktu i ustalono usunięcie części pracy ze sprintu, efektem czego był duży spadek na wykresie pomiędzy 5/16/02 (619 godzin) i 5/17/02. Od tego punktu zespół dokonywał stałego postępu i ukończył sprint z powodzeniem.
W zwinnym modelowaniu na Wykres Wygaszania Sprintu Zespół Scrum śledzi swój postęp w modelowaniu i przygotowywaniu dokumentacji pod względem planu iteracji (Sprintu).
Role:
Czynności:
Artefakty:
Wszystkie prawa zastrzeżone 
modesto group All rights reserved
