napisane przez Michał Wolski | w kategorii agile, metodyki, zarządzanie wymaganiami
wtorek 28 lip 2009
Obecnie znajdujemy się w dziwnej sytuacji – są user stores (zwane w języku polskim historyjkami użytkownika) i scenariusze przypadków użycia z czego te ostatnie można podzielić na przypadki użycia formalne i nieformalne a także streszczenia przypadków użycia. Czym one się różnią, a w czym są takie same?
Przypadki użycia, scenariusze przypadków użycia i user stories dokumentują opis tego jak produkt ma być używany. Różnią się one, w kontinuum, pod względem ilości dodatkowych danych wymaganych dla stworzenia każdego z nich.
- Formalne przypadki użycia wymagają najwięcej wysiłku. Panuje w nich przepych i wiele się w nich dzieje, ale opisują wszelkie kombinacje tego, jak różne osoby wykonują tą samą czynność (lub jej odmianę).
- Nieformalne przypadki użycia są mniej więcej takie same- tyle tylko, że są mniej formalne. Wyzwaniem jest dostarczenie odpowiedniego poziomu szczegółowości, bez elementów prowadzących formalnych przypadków użycia, które mają służyć jako przypomnienie.
- Streszczenia przypadków użycia niemalże nie mają dodatkowych danych, ale zawierają takie sama wyzwania “na ile jest to jest wystarczająco” co nieformalne przypadki użycia, tyle że w większym stopniu.
- User stories mają najmniej dodatkowych danych i dostarczają najmniejszy kontekst.
Scenariusze przypadków użycia to nieco inny przypadek. Podobnie jak user story, scenariusz przypadku użycia opisuje jedną ścieżkę przez wielościeżkowy przypadek użycia. Warto więc połączyć słabość przypadku użycia (wysoka ilość danych dodatkowych) ze słabością user story (ograniczony kontekst) co w konsekwencji da dość spójny i zwinny oraz pomocny artefakt.
napisane przez Michał Wolski | w kategorii szkolenia
poniedziałek 27 lip 2009
Największym kapitałem każdej organizacji są zachodzące w niej procesy. Aby procesy te mogły być efektywnie doskonalone należy je w odpowiedni sposób odwzorować w systemie informatycznym. Zanim przystąpi się do budowy systemu informatycznego warto dobrze poznać te procesy budując ich modele. Dziś przyszłość stanowią metodyki zwinne (Agile) w tym także te, które wykorzystują modele. Właśnie tej tematyce – zwinnemu modelowaniu procesów biznesowych poświęcone było dwudniowe szkolenie, jakie miałem przyjemność poprowadzić 23-24 lipca w Warszawie.
Jedna z warszawskich firm w tym nurcie będzie modelować procesy biznesowe celem dostarczania klientom dedykowanych rozwiązań, które opierają się na otwartym kodzie tworzonej aplikacji. Pozwala to by aplikacja ta była w przyszłości rozwijana i modyfikowana przez dowolny podmiot, nie wyłączając oczywiście samego użytkownika.
Szkolenie przebiegło w bardzo dobrej, twórczej atmosferze. Otrzymałem tylko dobre i bardzo dobre noty a w komentarzach w pozycji Co najbardziej podobało Ci się na szkoleniu można przeczytać między innymi: “skupienie się prowadzącego na sednie sprawy”, “praktyczne przedstawienie złożonego tematu…”. Dziękuję 
napisane przez Michał Wolski | w kategorii SCRUM, agile, zwinne modelowanie
czwartek 9 lip 2009
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.
napisane przez Michał Wolski | w kategorii agile, o inżynierii oprogramowania, zwinne modelowanie
wtorek 7 lip 2009
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:
- odkrycie wymogów, które w przeciwnym przypadku pozostałyby nieodkryte
- wyłapanie prawidłowych wymogów
- efektywne przekazywanie informacji dotyczące wymogów
- wyznaczenie priorytetowych wymogów
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.
napisane przez Michał Wolski | w kategorii ogólne
czwartek 2 lip 2009
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, zwinne modelowanie
czwartek 2 lip 2009
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:
- planować iteracje
- szacować złożoność projektu
- komunikować się z klientem
- weryfikować wymagania klienta
- planować testy
- lepiej integrować systemy
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.
napisane przez Michał Wolski | w kategorii SCRUM, agile, metodyki, zwinne modelowanie
poniedziałek 22 cze 2009
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.
przeczytaj pozostałą część »
napisane przez Michał Wolski | w kategorii SCRUM, agile, ogólne, zwinne modelowanie
niedziela 21 cze 2009
Zasadnicze cechy SCRUM, w bardzo dużym uproszczeniu, to:
- iteracyjnie przyrosty wartości
- samoorganizujące się zespoły
- klient, bądź Właściciel Produktu, który dostarcza zespołowi listę pożądanych cech
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ść.
Spis treści
Role:
Czynności:
Artefakty:
napisane przez Michał Wolski | w kategorii SCRUM, agile, ogólne, zwinne modelowanie
niedziela 21 cze 2009
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:
- Określa cechy produktu;
- Podejmuje decyzje co do daty i zawartości;
- Jest odpowiedzialny za rentowność produktu (ROI);
- Ustala hierarchię cech wg wartości rynkowej;
- Koryguje cechy i priorytety co 30 dni, jeśli to konieczne;
- Akceptuje lub odrzuca efekty pracy.
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.
Modelowanie:
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.
Spis treści
Role:
Czynności:
Artefakty:
napisane przez Michał Wolski | w kategorii SCRUM, agile, ogólne, zwinne modelowanie
niedziela 21 cze 2009
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:
- Reprezentuje zarządzanie nad projektem (współdziałanie);
- Jest odpowiedzialny za wprowadzanie w życie wartości i praktyk Scrum;
- Prowadzi spotkania Codziennego Scruma;
- Usuwa utrudnienia;
- Chroni zespół przed zewnętrznymi zakłóceniami;
- Zapewnia, że zespół jest w pełni funkcjonalny i produktywny;
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ół).
Modelowanie:
Mistrz Scrum w zwinnym modelowaniu to kierownik projektu, który poza nadzorowaniem prac nad modelem może zajmować się szacowaniem ryzyka przedsięwzięcia.
Spis treści
Role:
Czynności:
Artefakty:
napisane przez Michał Wolski | w kategorii SCRUM, agile, ogólne, zwinne modelowanie
niedziela 21 cze 2009
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:
- Jest międzyfunkcyjny, z mniej więcej siedmioma członkami;
- Wybiera cel Sprintu i określa efekty pracy;
- Ma prawo do zrobienia wszystkiego w granicach wytycznych projektu, aby osiągnąć cel Sprintu;
- Sam organizuje siebie i swoją pracę;
- Demonstruje efekty pracy Właścicielowi Produktu.
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.
Modelowanie:
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.
Spis treści
Role:
Czynności:
Artefakty:
napisane przez Michał Wolski | w kategorii SCRUM, agile, ogólne, zwinne modelowanie
niedziela 21 cze 2009
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.
Modelowanie:
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.
Spis treści
Role:
Czynności:
Artefakty:
