napisane przez Michał Wolski | w kategorii teksty, zarządzanie wymaganiami
piątek 26 cze 2009
Jakiś czas temu na stronie Pana Kowalczykiewicza http://www.cs.put.poznan.pl/kkowalczykiewicz/ był ciekawy tekst na temat dobrych praktyk w inżynierii wymagań. Obecnie ta strona jest wyłączona. Z tego też powodu pozwalam sobie na publikację tego tekstu, który (co mnie zadziwia) miałem w swoim archiwum. Tekst ten został odrobinę przeformatowany.
Ian Sommerville i Pete Sawyer zaproponowali ciekawą metodę oceny i doskonalenia procesów inżynierii wymagań. Opiera się ona na wyodrębnieniu dobrych praktyk, czyli czynności będących pożądanymi elementami wzorcowego procesu inżynierii wymagań. Autorzy starali się przy tym objąć całość problematyki inżynierii wymagań. Dobre praktyki reprezentują więc następujące obszary działalności:
- dokument specyfikacji wymagań,
- pozyskiwanie wymagań,
- analiza i negocjacja wymagań,
- opisywanie wymagań,
- modelowanie systemu,
- weryfikacja wymagań,
- zarządzanie wymaganiami,
- systemy krytyczne.
Biorąc pod uwagę te kryteria wyodrębniony został podział praktyk na trzy grupy wg zaawansowania powiązanego z tymi kosztami i poziomem skomplikowania:
Dobre praktyki stanowią podstawę do oceny poziomu dojrzałości procesów inżynierii wymagań w organizacji. Zakres wspomnianych dobrych praktyk opisałem w poniższych punktach:
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:
napisane przez Michał Wolski | w kategorii SCRUM, agile, ogólne, zwinne modelowanie
niedziela 21 cze 2009
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.
Modelowanie:
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.
Spis treści
Role:
Czynności:
Artefakty:
napisane przez Michał Wolski | w kategorii SCRUM, agile, ogólne, zwinne modelowanie
niedziela 21 cze 2009
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.
Modelowanie:
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.
Spis treści
Role:
Czynności:
Artefakty:
napisane przez Michał Wolski | w kategorii SCRUM, agile, ogólne, zwinne modelowanie
niedziela 21 cze 2009
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.
Modelowanie:
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).
Spis treści
Role:
Czynności:
Artefakty:
napisane przez Michał Wolski | w kategorii SCRUM, agile, ogólne, zwinne modelowanie
niedziela 21 cze 2009
Tablica Zadań (ang. Task Board) pokazuje całość pracy wykonywanej przez zespół podczas sprintu.
Tablica Zadań pokazuje całość pracy wykonywanej przez zespół podczas sprintu. Jest ona stale aktualizowana w trakcie sprintu- jeżeli ktoś myśli o nowym zadaniu, pisze nową kartę i umieszcza ją na tablicy. W trakcie lub przed Codziennym Scrumem, zmienia się szacunki (w górę lub w dół) i przemieszcza się karty na tablicy.
Tablica zadań może wyglądać tak:
Każdy rząd tablicy zadań to pozycja Produkt Backloga (w tym poszczególne przykładowe historyjki). Podczas spotkania dot. planowania sprintu zespół wybiera pozycję Produkt Backloga, które może wykonać podczas zbliżającego się sprintu. Każda pozycja Product Backloga zamienia się w wiele pozycji Sprint Backloga. Każdą z nich przedstawia jedna karta zadań, która jest umieszczona na tablicy zadań. Każda karta zadań jest najpierw na tablicy zadań w kolumnie “Do zrobienia”. Kolumny to:
- Historyjka (Story)– Opis historyjki (“Jako użytkownik chcę …”) pokazany na tym wierszu.
- Do zrobienia (To Do)– Obejmuje całość kart, które nie są zakończone lub w trakcie wykonywania.
- Praca w trakcie wykonywania (In Process)– Karty, nad którymi trwa praca. Programista, który decyduje się nad nią pracować, przesuwa ją, kiedy jest gotowy do rozpoczęcia zadania. Często dzieje się tak podczas Codziennego Scruma, kiedy ktoś mówi, “Zamierzam dziś pracować nad interfejsem logowania”
- Do sprawdzenia (To Verify)– Bardzo dużo zadań ma odpowiadające im karty testowania zadań. Dlatego też, jeżeli istnieje karta pt. “Kod klasy interfejs logowania”, występują też prawdopodobnie jedna lub więcej kart zadań związanych z testowaniem: “Przetestuj interfejs logowania”, “Napisz testy FitNesse dla interfejsu logowania”, “Napisz przymocowanie FitNesse dla interfejsu logowania”, itd. Niektóre karty zadań często nie uzyskują odpowiadających im kart testowania (“Zamocuj Bug 321 w Bugzilla”), tak więc są one umieszczone w kolumnie “Do sprawdzenia”.
- Zrobione (Done) – Tam umieszczane są karty po ich wykonaniu. Są one usuwane na zakończenie sprintu.
Istnieje wiele różnych sposobów realizacji tablicy zadań. Zespoły pracujące blisko siebie mogą korzystać ze ściany. Zespoły rozproszone będą stosować narzędzia informatyczne.
Modelowanie:
W zwinnym modelowaniu Tablica Zadań pokazuje całość pracy na d modelami i dokumentacją projektową wykonywaną przez zespół podczas sprintu.
Do realizacji Tablicy Zadań świetnie nadają się odpowiednio skonfigurowane macierze z przypadkami użycia. Taką funkcjonalność zapewnia wiele narzędzi CASE w tym Enterprise Architect.
Spis treści
Role:
Czynności:
Artefakty:
napisane przez Michał Wolski | w kategorii SCRUM, agile, ogólne, zwinne modelowanie
niedziela 21 cze 2009
Na Spotkaniu dot. Planowania Sprintu (ang. Sprint Planning Meeting) Zespół Scrum oraz Właściciel Produktu określają, które cechy i zadania będą poddane próbie wykonania w nadchodzącym sprincie.
Na Spotkaniu dot. Planowania Sprintu obecny jest Właściciel Produktu, Mistrz Scrum, cały Zespół Scrum oraz zainteresowani i odpowiedni przedstawiciele kierownictwa lub klienta. Podczas spotkania dot. planowania sprintu Właściciel Produktu opisuje zespołowi cechy o najwyższym priorytecie. W trakcie spotkania zespół zadaje dostatecznie dużo pytań tak, aby móc kontynuować po spotkaniu i określić, które zadania zostaną przesunięte z Product Backloga do Sprint Backloga. Łącznie, Zespół Scrum oraz Właściciela Produktu określają cel sprintu, który jest krótkim opisem tego, co postara się osiągnąć sprint. Powodzenie sprintu zostanie następnie ocenione podczas Spotkania Przeglądowego Sprintu względem celu sprintu, a nie każdej specyficznej pozycji wybranej z Product Backloga. Po Spotkaniu dot. Planowania Sprintu, Zespół Scrum spotyka się oddzielnie, aby omówić to, co usłyszał i podejmuje decyzje odnośnie zaangażowania w zbliżającym się sprincie. W niektórych przypadkach mogą wystąpić negocjacje z Właścicielem Produktu, ale to zawsze zespół będzie decydował o tym, w jaki sposób zobowiąże się do wykonania.
Właściciel Produktu nie musi opisywać każdej pozycji śledzonej w Product Backlogu. W zależności od wielkości Backloga i szybkości zespołu, może wystarczyć opisanie jedynie pozycji o wysokim priorytecie, zostawiając omówienie pozycji o niższym priorytecie na kolejne Spotkanie dot. Planowania Sprintu. Na ogół, Zespół Scrum poda wytyczne, gdy lepiej zapozna się z listą Backloga, aniżeli gdyby miał polegać na tym, co ma być wykonane w następnym sprincie.
Modelowanie:
W modelowaniu w Scrum Zespół Scrum oraz Właściciel Produktu określają, które cechy i jaki zakres funkcjonalności będą modelowane i projektowane w nadchodzącym sprincie.
Spis treści
Role:
Czynności:
Artefakty:
