Grupa posiada swoją stronę na Google Groups pod adresem:

http://groups.google.com/group/agile-warsaw?hl=pl&pli=1 .

Charakter grupy jest otwarty. Spotkania odbywają się w wybrane poniedziałki. Do tej pory miały miejsce dwa, a kolejne już dziś.

Tematy z pierwszych spotkań i prezentacje:

Marek Kirejczyk – ‘From Scrum to Kanban‘, czyli jak być jeszcze bardziej Agile, przejść od Scruma do Kanabana, zmniejszając Time To Market, poprawiając jakość, synchronizując projekty między sobą i poprawiając komunikacje. (prezentacja)

Mateusz Srebrny – ‘Spikes‘ – o tym jak planować research i analizę w metodykach agile. (Prezentacja)

Najprostszym sposobem szacowania zadań jest oczywiście przypisanie im określonej wartości liczbowej, wyrażającą liczbę godzin potrzebną do wykonania zadania.  Ważne, jest aby zadanie którego określam czas było odpowiednio małe. (Więcej na temat dzielenia projektu na zadania znajdowało się w części 2).

Taki sposób szacowań jest dalece nieidealny. Powodując wiele problemów, a przede wszystkim błędów. Dlatego wymyślono kilka metod, które mogą pomóc.

Szacowanie ważone (trójpunktowe)

Technika szacowania trójpunktowego, pochodzi z Metody PERT.  Zdecydowanie jest jedną z najchętniej przeze mnie wykorzystywanych.  Polega na wyliczeniu wartości czasu wykonania zadania na podstawie 3 pośrednich wartości:

• Szacunek  optymistyczny (To)
• Szacunek realistyczny (Tr)
• Szacunek Pesymistyczny (Tp)

Wartość czasu oblicza się ze wzoru na średnią ważona z następującymi wagami:

T = (To + 4*Tr + Tp) / 6.

Z mojego doświadczenia wartości wag, powinny być jednak różnicowane w zależności od wykonawcy zadania. Na przykład niedoświadczony, początkujący programista, ma zwykle tendencję do podawania znacznie bardziej optymistycznych wartości, niż jego doświadczony kolega. Dla takich osób możemy przyjąć na przykład następujące wagi:

T = (To + 3*Tr+2*Tp) / 6

Szacowanie trójpunktowe jest niezwykle efektywne ponieważ zmusza do zastanowienia się chwilę dłużej za nim podamy prognozowane przez Nas wartości. Poza tym mamy większą świadomość co oznaczają zapisane liczby. W przypadku gdy mamy tylko jedną wartość, to tak naprawdę nie wiemy czy ktoś napisał swoją wersję pesymistyczną, czy może optymistyczną.

Szacowanie względne

Technika ta, o ile dobrze pamiętam, popularyzowana jest w metodykach zwinnych. Pomysł polega na tym, aby wybrać sobie jedno zadanie, które będzie nam łatwo oszacować  i każde inne zadanie porównywać i zapisywać jako wielokrotność tego pierwszego.

Wybrane przez Nas zadanie jako wzorcowe powinno być dość małe. Gdybyśmy wskazali duże zadanie (np. 20h), to zapewne w projekcie znalazłoby się sporo prac, które musiałyby być jakimiś wartościami ułamkowymi. O ile stosowanie jeszcze miar na poziomie 0,5 jest w porządku, to już rozdrabnianie się na ułamki typu 1/4, 1/5 itp. wprowadzałoby tylko niepotrzebnie wiele bałaganu.

Metoda ta posiada jeszcze drugi problem. W projekcie, nawet w części programistycznej wiele zadań jest drastycznie różnych od siebie i ciężko jest je porównywać. Weźmy na przykład zadanie zmiany układu wyświetlania strony, a zintegrowanie portalu z systemem płatności. Jakby nie patrzeć, to że przebudowanie widoku zajmuje mi 4h, jakoś nie rozjaśnia sprawy ile czasu potrzeba na integrację z zewnętrznym systemem.

Dlatego moim zdaniem warto korzystać z metody szacowania względnego jako uzupełnienia, a nie samodzielnej techniki.

Do rzeczy, jak ułatwić szacowanie czasu trwania projektu?

Do szacowania całkowitego czasu wykonywania projektów można podejść na kilka sposobów. Poniżej lista podstawowych metod.

Szacowanie Oddolne (Wstępujące)

Jest to jedna z najbardziej pracochłonnych metod szacowania, dzięki czemu jest zdecydowanie najdokładniejsza.

Szacowanie oddolne polega na podzieleniu całego projektu na jak najmniejsze zadania, dla których oszacowania czasu wykonania może być dość dokładne.

Dzieląc projekt na zadania, powinniśmy dokonywać ich podziału do momentu w którym dane zadanie nie będzie przekraczać kilku dni roboczych. Jako optimum przyjmowane są różne wartości, osobiście jako maksimum polecam 40h (1 tydzień roboczy), ale ideałem są zadanie w zakresie od 4-16h.Przykładem podziałów zadań do wykonywania takiego szacowania są listy zadań WBS (WorkBench Structure).

Metoda szacowania oddolnego jest najbardziej przydatna w momencie planowania całego projektu, kiedy podjęliśmy już decyzję odnośnie sposobu realizacji i znamy zasoby jakimi dysponujemy oraz dokładnie stawiane nam wymagania.

Ciężko stosować ta metodą w pełnym zakresie do przygotowywania wstępnych szacunków projektu na etapie jego definiowania, kiedy niespisane są jeszcze wymagania projektu. Choć już wtedy warto podzielić projekt na mniejsze części.

Szacowanie Odgórne (Historyczne / Zstępujące ).

Jest to jedna z lepszych metod, która w połączeniu z szacowaniem oddolnym daje doskonałe rezultaty. Metoda szacowania odgórnego polega na wykorzystaniu danych z wcześniej realizowanych projektów.

No i tu właśnie mamy problem, bo jeśli nie mamy doświadczenia z poprzednich, podobnych projektów, to niestety nie możemy skorzystać z tej techniki. Drugi problem, to nawet jeśli realizowaliśmy wcześniej zbliżone projekty, to nie zawsze dysponujemy danymi historycznymi odnośnie rzeczywistych czasów wykonywania zadań.

Dlatego tak ważne jest, aby już od swojego pierwszego projektu archwizować dane zawierające nasze poprzednie szacunki wraz z realnie uzyskanymi wartościami.

Metodę szacowania odgórnego możemy oczywiście stosować również do pewnych, wybranych części danego projektu. Ponieważ, często się zdarza, że realizujemy projekt podobny, ale z jakimiś dodatkowymi funkcjami. Możemy, więc skorzystać z tej metody do oszacowania wykonania wspólnej części obu projektów. Metodę szacowania odgórnego najczęściej wykorzystuje się na etapie definiowania projektu, kiedy znamy jego ogólne założenia. (Np. przygotowywanie oferty dla klienta).

Szacowanie Parametryczne

Kolejna metoda jest nieco zbliżona do szacowania odgórnego, ponieważ korzysta również z danych historycznych. Szacowanie parametryczne polega na zastosowaniu modelu matematycznego.

Na przykład możemy korzystając z danych historycznych określić, że poszczególne fazy projektu Planowanie, realizacja, wdrożenie trwały odpowiednie 20, 40, 20 procent całkowitego czasu projektu. Więc możemy dokonać założenia, że teraz będzie podobnie.

Można również próbować szacować wielkość projektu, przeliczać to na linie kodu, a te na ilość pracy. Istnieją tablice definiujące ilość linii kodu na dzień roboczy dla wybranych języków programowania. Technika ta jest podstawą metody COCOMO (którą opiszę w części trzeciej – szacowanie zadań). Osobiście nigdy nie przekonałem się do tego typu szacowania i traktuje je bardziej jako ciekawostkę. Choć metoda ta była kiedyś stosowana dość szeroko.

O czym warto pamiętać szacując?

Stosowanie Buforów (rezerw) czasowych

Szacując całkowity czas trwania projektu należy koniecznie wziąć pod uwagę bufor czasowy.

Ważne jest, aby doliczać rezerwę do całkowitego czasu trwania projektu, a nie jak często się to zdarza do poszczególnych zadań. W drugim przypadku mamy mocno zaciemniony obraz tego ile naprawdę doliczyliśmy czasu do całego projektu, co znacznie utrudnia nam kontrolę.

Jeśli szacujemy na przykład, że czas realizacji projektu to 10 tygodni i doliczamy bufor 10%. To wiemy, że mamy 1 tydzień zapasu i w każdym momencie trwania projektu jesteśmy w stanie określić, jak wiele czas

u z rezerwy wykorzystaliśmy.Poza tym przeszacowywanie każdego zadanie wpływa często również na obniżenie naszej wydajności, bo skoro widzimy, że mamy czas, często spowalniamy naszą pracę, mniej koncentrując się na wykonaniu zadań.

Wielkość buforu zależy bardzo mocno od złożoności projektu i naszego doświadczenia. Jeżeli robiliśmy podobny projekt, dysponujemy danymi archiwalnymi, to możemy założyć bufor na około 10% czasu trwania. Jeśli jednak brakuje nam doświadczenia, a projekt jest bardzo złożony to bufor czasowy może wynieść nawet około 50%+.

Aktualizaca Szacunków

W zasadzie z wcześniejszymi szacunkami, można zrobić dwie rzeczy, albo wywalić do koszta, albo zaktualizować. Pozostawienie ich gdzieś w obiegu to jak zakładanie sobie pętli na szyję. Zawsze po pewnym czasie pracy, niektóre nasze szacunki będą się okazywały trafne inne nie. Możemy, więc albo wykonać nowe oszacowanie, albo zaktualizować istniejące. Jeżeli, wybierzemy drugą opcję, którą polecam, bardzo dobry przykład opisywania zadań zaproponował Joel Spolsky. Propozycję tę przedstawię w kolejnej części.

Jeśli robimy coś po raz pierwszy

Koniecznie trzeba uważać jeśli robimy coś po raz pierwszy. Zawsze potrzebujemy na to zdecydowanie więcej czasu, niż gdy dana czynność wykonywana jest ponownie.

Mimo, że na przykład wykonywaliśmy już integracje z system płatności, to wykonanie integracji z podobnym system innego dostawcy zajmie nam jednak więcej czasu. Zawsze musimy uwzględnić czas na naukę.

Zbieraj dane, zapisuje czasy realizacji, szacuj i jeszcze raz szacuj!

Podsumowując, szacowanie jest bardzo trudnym zadaniem, szczególnie jeśli brak nam doświadczenia. Dlatego ważne jest, aby ćwiczyć się w szacowaniu i już od pierwszych swoich projektów próbować estymować.

Koniecznie należy archiwizować otrzymywane czasy i w trakcie wykonywania zadań zapisywać rzeczywiście otrzymane wartości. Te informację mogą się okazać ( i z pewnością się okażą) prawdziwym błogosławieństwem w przyszłości. Do zbierania danych nie potrzeba super narzędzi, wystarczy zwykły arkusz kalkulacyjny (np. Google Docs, który sprawdzi się również w pracy grupowej). Można również korzystać z dedykowanych rozwiązań, bardzo ciekawą darmową pozycją jest Feng Office.

W trzeciej części postaram opisać się sposoby radzenia z szacowaniem poszczególnych zadań w projekcie.

Większość z Nas szczególnie, ta mniej doświadczona zwykle bardzo nie lubi dokonywać oszacowania. Nic dziwnego skoro często zadania to przypomina chodzenie po omacku.  Dlatego postaram się tutaj jak najszerzej omówić dostępne metody i narzędzia.

Zacznę od kwestii o których powinniśmy pamiętać wykonując wszelkie oszacowania, później przejdę do sposobów na szacowanie całych projektów, w części trzeciej opiszę metody szacowania czasu trwania poszczególnych zadań, a na koniec wspomnę trochę o dostępnych narzędziach.

Zaczynamy – czyli jak zabierać się do szacowania czasu?

Oszacowanie czasu trwania całego projektu, to zadanie naprawdę trudne. Szczególnie na początku projektu w fazie przygotowawczej, kiedy tak na prawdę nie do końca wiemy jeszcze co trzeba w projekcie zrobić. Ale za nim powiem, jak można sobie pomóc, to ustalmy z czego powinno się składać takie formalne oszacowanie.

1. Założenia

Każde oszacowanie projektu powinno mieć pokrótce opisane założenia, dla których zostało dokonane. Czyli jakie rzeczy zostały uwzględnione, a co nawet ważniejsze, czego ewentualnie nie uwzględniono. Jakie było zakładane rozwiązanie i jakie zaplanowano zasoby. Generalnie wszystkie czynniki, które mogą znacząco wpłynąć na czas trwania projektu.

2.  Odchylenie , czyli dokładność oszacowania.

Powinniśmy sobie zdawać sprawę w jakim stopniu dokładny jest prognozowany czas. Czasem mamy naprawdę dużą pewność (np. robiliśmy już podobne projekty) i możemy sobie założyć, że oszacowanie może mieć odchylenie rzędu 10 – 20%.  Czasem jednak trafiamy do dzikiej nieznanej krainy i nasze szacunki mogą być naprawdę bardzo orientacyjne. W takim przypadku odchylenie, może sięgać do np. 100% czasu trwania. Jeśli chodzi o wyznaczanie wielkości odchylenia to osobiście przyjmuje pięciostopniową skalę (jak w większości ciężko mierzalnych metryk, taka ilość daje sporą elastyczność, a nie powoduje jeszcze bałaganu).

• Bardzo Niskie 0 – 10%
• Niskie  10 – 20%
• Średnie 20-40%
• Wysokie 40 – 70%
• Bardzo Wysokie 70%+

Warto zwrócić uwagę, że w tym przypadku im większy poziom odchylenia, tym szerszy jego przedział.

3.  Czas ważności Oszacowania

Zaleca się też, choć wszystko zależy od przeznaczenia oszacowania, aby określić jego czas ważności. Tzn na przykład, że oszacowanie aktualne jest do końca Marca. (bo wtedy będziemy mieli więcej szczegółów) Zabezpiecza Nas to na wypadek, gdyby ktoś później wyciągał nam takie archiwalne oszacowanie i dochodził jego wyegzekwowania.

Osobiście, niestety raczej rzadko zdarza mi się określać czas ważności oszacowania. Wykonywane oszacowania zwykle są po prostu aktualizowane w ramach napływających danych, czy wykonywania prac, występowania problemów itd.

4. Nakład pracy, a czas trwania

Bardzo ważna rzecz, której trzeba mieć świadomość, jak również zaznaczyć w opisie oszacowania. Pojęcia ‘nakładu pracy’ i ‘czasu trwania’ są często stosowane zamiennie, co jest wielkim nieporozumieniem i trzeba je twardo rozgraniczyć.

Nakład pracy, opisuje szacunek ile godzin roboczych należy poświęcić na zrealizowanie projektu/zadania. Zaś Czas trwania, musi do nakładu pracy doliczyć takie kwestie jak dostępność zasobów, dni wolne, realizację innych projektów i zobowiązań itp.

Koniecznie należy zaznaczyć w oszacowaniu, którą z tych wartości prognozujemy. Inaczej nieraz spotkałem się z nieporozumieniami. Programista mówi, że wykonanie jakieś funkcjonalności to 3 dni roboty, a klient rozumie,  że za 3 dni otrzyma gotowe rozwiązanie.

Podsumowanie

Stosowanie wszystkich tutaj wymienionych elementów oczywiście nie jest konieczne. Ale często zabezpiecza nad przed mogącymi wystąpić problemami. W kolejnej części opiszę zasady szacowania całych projektów, a później przejdę do szacowania zadań.

Zmiana ta będzie miała na razie niewielki wpływ na wyniku wyszukiwania, ale kto wie jak będzie w przyszłości?

Więcej informacji można znaleźć na blogu Google: http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html

• ScrumMaster
• Właściciel Produktu
• Zespół

Role te zaliczane są do tzw. grupy świń, czyli grupy zaangażowanej w proces tworzenia projektu. Dodatkowo, występuje jeszcze rola ‘udziałowca’. Mogą to być np. osoby finansujące projekt, zarząd, czy przyszli użytkownicy. Osoby z tej grupy nazywa się ‘kurczakami’. Są one zainteresowane realizacją projektu, ale  nie są bezpośrednio zaangażowane w jego tworzenie.

Zespół

Zwykle opisy ról w metodykach zarządzania projektami zaczyna się od kierowników. W przypadku Scrum zdecydowanie należy zacząć od zespołu, ponieważ to on jest najważniejszy w całym projekcie.

Zadaniem zespołu jest realizowanie projektu poprzez zamianę zaległości produktowych (product backlog) w funkcjonalności.  Bardzo ważne jest, że w Scrum zespół powinien mieć charakter interdyscyplinarny, czyli składać się ze specjalistów różnych dziedzin. Np. programiści, testerzy, architekt itp.

Główne założenie metodyki mówi, że zespół jest odpowiedzialny za zarządzanie samym sobą. Scrum jest pozbawiony typowego Project Managera. To zespół, który analizuje problem i listę funkcjonalności do zaimplementowania jest odpowiedzialny za zorganizowanie swojej pracy.

Za optymalną wielkość zespołu uznaję się grupę siedmiu osób (+- 2). Empirycznie stwierdzono, że dla takiej liczebności występuje maksymalna wielkość efektu synergii. Efekt ten opiera się na założeniu,  że dwie pracujące osoby mają lepszą wydajność pracy, niż to wynika z sumy wydajności każdej z nich z osobna.

Właściciel produktu

To osoba odpowiedzialna za zarządzanie wymaganiami projektu spisanych w postaci zaległości produktowych. Właściciel produktu jest przedstawicielem udziałowców. Do jego zadań należy właściwe dobieranie funkcjonalności w kolejnych iteracjach tak, aby zmaksymalizować zyski osiągane z realizacji projektu.

ScrumMaster

Jest to osoba odpowiedzialna za nadzorowanie procesu Scrum. Celem osoby w tej roli jest pomoc zespołowi, aby ten mógł pracować jak najefektywniej. Koniecznie należy zwrócić uwagę, że ScrumMaster nie ma kierować pracami zespołu. Rolą ScrumMaster jest bycie trenerem, wsparcie dla zespołu i usuwanie wszelkich przeszkód jakie się pojawiają.

Drugim zasadniczym obowiązkiem ScrumMaster’a jest nadzorowanie procesu Scrum. Musi on dopilnować, aby wszystkie pozostałe osoby stosowały się do zasad metodyki. Np. nie próbował zmieniać wymagań przypisanych do danego sprintu (iteracji) w trakcie jego trwania.

O ile zespół sam organizuje swoją pracę ScrumMaster powinien analizować jej wyniki i reagować w przypadku kiedy zauważa niebezpieczeństwo.

Nie pamiętam już kto, ale powiedział kiedyś, że tworzenie oprogramowania jest jedną z najbardziej skomplikowanych dziedzin inżynierskich. Stopień złożoności do jakiego dochodzą projekty jest wręcz niespotykany nigdzie indziej. Nic więc dziwnego, że już od dawna próbowano zapanować nad tym procesem. Od Lat 80-tych powstało wiele metodyk zarządzania projektami. Większość z nich była rozwijana lub bazowała na mechanizmach stworzonych w ramach projektów rządowych, które często wymagały bardzo obszernych dokumentacji i ścisłego procesu kontroli.

Do niedawna wydawał się, że bez tego żaden projekt, który ma osiągnąć sukces, nie może się obyć. Jednak mniej więcej w połowie lat 90-tych zaczęły się rozwijać metodyki/frameworki znacznie mniej restrykcyjne. Ich twórcy spotkali się w lutym 2001 roku w stanie Utah, na wspólną zabawę na nartach ( ), a przy okazji opracowali słynny już dokument: Manifest Agile. Dokument, zgodnie z duchem Agile jest krótki w formie, ale bogaty w przesłaniu, w tłumaczeniu na język Polski:

Poprzez wytwarzanie oprogramowania oraz pomaganie innym w tym zakresie odkrywamy lepsze sposoby realizowania tej pracy. W wyniku tych doświadczeń zaczęliśmy przedkładać:

• Ludzi i ich wzajemne interakcje (współdziałanie)ponad procedury i narzędzia.
• Działające oprogramowanie nad wyczerpującą dokumentację.
• Współpracę z klientem nad negocjację umów.
• Reagowanie na zmiany nad realizowanie planu.

Oznacza to, że wprawdzie doceniamy to co wymieniono po prawej stronie, to jednak bardziej cenimy to co wymieniono po lewej.

Manifest Agile – Tłumaczenie z Wikipedia.org

Problemy tradycyjnych metodyk

Manifest jest w zasadzie idealnym podsumowaniem problemów, z którymi spotykamy się przy zarządzaniu projektami poprzez tradycyjne, zwane również ‘ciężkimi’, metodyki.

1. Problemy z komunikacją.

Tutaj chyba już nie trzeba się rozpisywać. Bo najlepszym opisem tego jest już słynny komiks zamieszczony po prawej stronie. Brak umiejętności przekazywania naszych oczekiwań i problemy ze wzajemnym porozumieniem się miedzy ludźmi ze ‘świata biznesu’ i ‘świata technologii’. Jeżeli dorzucimy teraz do tego brak możliwości rewidowania przez klienta tego co dla niego tworzymy we wczesnych fazach projektu, otrzymujemy efekt jak na obrazku. Przekłada się to nie tylko na rozczarowanie klienta, ale również zespołu realizującego.

2. Zbyt scentralizowane podejmowanie decyzji.

W tradycyjnych metodykach zarządzania projektami najczęściej większość decyzji podejmuje kierownik projektu, w zależności od znaczenia tej decyzji, możliwe, że będzie musiał skonsultować się najpierw z Komitetem Sterującym. Taka pionowa struktura zarządzania bardzo wydłuża czas podejmowania decyzji. Druga sprawą jest fakt, że zwykle osoby pracujące bezpośrednio przy danym problemie mają znacznie lepsze możliwości podjęcia słusznej decyzji.

3. Brak wprowadzania zmian zgodnych z oczekiwaniami klienta.

Jest to problem nadal często spotykany, choć wiele klasycznych metodyk wprowadziło już mechanizmy zarządzania zmianami wymagań. A już zdecydowanie, żadne metodyka ‘nie przyznaje się’ do tworzenia projektów w sposób kaskadowy. Mimo to zespoły realizujące projekty, często nie wprowadzają mechanizmów zarządzania zmianami wymagań w praktyce. Wynika to często z niechęci i nieumiejętności dobrego prowadzenia projektu iteracyjnego. Ludzie przyzwyczajeni do starego podejścia niezbyt chętnie przenoszą się na nowe.

4. Zbyt wielkie przykładanie wagi do dokumentacji

Klasyczne metodyki zyskały przydomek ciężkich, z uwagi na fakt powstawania przy ich realizacji bardzo obszernych dokumentacji. Dokumentacja ta jest często tworzona na wyrost i w praktyce nigdy nie wykorzystywana. Szczególnie problematyczne jest to przy tworzeniu małych, krótkoterminowych projektów. Wtedy koszty wytworzenia dokumentacji mogą stanowić nawet większą część kosztów całego projektu. (Mowa tu nie o dokumentacji technicznej czy użytkownika, a przede wszystkim o dokumentacji projektowej: plany zarządzania projektem, specyfikacje wymagań itp, plany zasobów itp.)

Scrum – Historia Właściwa

Biorąc pod uwagę wszystkie te wady klasycznych metodyk stworzono wiele alternatyw. Jedną z nich jest właśnie Scrum.

Historia tej metodyki sięga roku 1986. W artykule “The New New Product Development Game”, które ukazał się w Harvard Business Review, Hirotaka Takeuchi i Ikujiro Nonaka przedstawili ogólne założenia metodyki. Szukali oni optymalnego sposobu zarządzania projektami innowacyjnymi o ciężkim do przewidzenia efekcie prac.

Następnie w roku 1995, Ken Schwaber jeden z największych autorytetów metodyki Scrum dokonał jej formalnego opisu. Na jego stronie, można znaleźć oryginał tego opracowania. Od tego czasu Scrum stawał się coraz popularniejszy.

Nazwa metodyki wywodzi się od rodzaju zagrywki w rugby, która nazywa się właśnie ’scrum’, co można na Polski tłumaczyć jako młyn. Co ciekawe wiele razy spotkałem się ze stwierdzeniem, że nazwa Scrum pochodzi od młyna takiego do mielenia mąki.

]]> http://www.mcwolf.net/article/scrum-historia/feed/ 0 http://www.mcwolf.net/article/scrum-metodyka/ http://www.mcwolf.net/article/scrum-metodyka/#comments Thu, 11 Mar 2010 19:31:27 +0000 Tomasz Wolfram http://mcwolf.net/?p=232 Metodyki zwinne – Agile

Co raz więcej ostatnio mówi się o tzw. metodykach zwinnych (Agile). Wszyscy zachwalają ich elastyczne podejście, możliwość łatwego dostosowania, brak potrzeby generowania niepotrzebnych ton śmieci, zwanych potocznie dokumentacją. W zasadzie zewsząd słychać ‘achy’, ‘ochy’, lub wręcz okrzyki uwielbienia. Stąd postaram się przybliżyć w kilku najbliższych postach metodykę Scrum i jej zasady, aby każdy mógł podejść do niej nieco bardziej świadomie i wyrobić swoje zdanie.

Dla wyjaśnienia dodam, że nie jestem zagorzałym zwolennikiem, czy przeciwnikiem tego sposobu zarządzania projektami. Uważam, że to doskonałe podejście w przypadku wielu firm i projektów. Na pewno można je też zastosować wręcz w większości przypadków osiągając dobre rezultaty, choć nie zawsze będzie to rozwiązanie optymalne.

Metodyka Scrum po koleji:

1. Scrum – Odrobina Historii.
2. Role w projekcie
3. Cykl życia projektu wg. Scrum (Sprinty, Spotkania Scrum, przeglądy i spotkania retrospektywne)
4. Planowanie i Zarządzanie wymaganiami
5. Scrum praktyczne przykłady zastosowania.
6. O czym się często zapomina wdrażając Scrum.

Dodatki:

A. Słownik Pojęć
B. Czy Scrum jest metodyką?

Mam nadzieję, że wszystkie tematy uda mi się szybko, ale jednocześnie wyczerpująco,  opisać.

Zacznijmy od tego, żeby poprawnie zrozumieć o czym właściwie mówimy. Na podstawie definicji ze słownika języka Polskiego PWN:

Metodologia

studium metod (nauka o metodach) – nauka o metodach badań naukowych, o skutecznych sposobach dociekania ich wartości poznawczej.

Słownik języka polskiego PWN

Metodyka

powiązane ze sobą metody, techniki, reguły i praktyki oraz wiedza jak je stosować. zbiór zasad dotyczących sposobów wykonywania jakiejś pracy lub trybu postępowania prowadzącego do określonego celu

Słownik języka polskiego PWN

Co wynika z poniższych definicji:

Po pierwsze w zarządzaniu projektami, metodologią w zasadzie nie zajmujemy się wcale. Zajmujemy się metodykami. Więc używanie słowa ‘metodologia’ jest w ogólnie nie poprawne. Skąd bład? Otóż, angielskie słowo ‘methodology’ w kontekście zarządzania projektami powinno być tłumaczone jako ‘metodyka‘, a często automatycznie zastępujemy je słowem metodologia.

A co do samego sporu z grupy na goldenline, to na poprawnie zadane pytanie “Czy Scrum jest metodyką?” Moja odpowiedź brzmi – TAK. Parafrazując definicje słowa metodyka. Scrum to zestaw powiązanych ze sobą metod, technik, reguł i praktyki, wraz z wiedzą jak je stosować.

Gdyby ktoś miał jeszcze wątpliwość, czy Scrum faktycznie dostarcza nam tej wiedzy to zauważę tylko:
- Narzędzie jakim jest Product backlog, scrum w zasadzie opisuje dość dokładnie jak go używać, kto powinien się nim zajmować i tak dalej. Czyli jest to wiedza jak z niego korzystać.
- Codziennie spotkanie Scrum, poza opisem co jest celem spotkania, scrum definiuje też kiedy przeprowadzać takie spotkania (codziennie, najlepiej o tej samej porze) i kto powinien się na nim pojawić, kto może zabierać głos itd.

Takich informacji w Scrum’ie jest sporo, więc uważam, że można z czystym sumieniem powiedzieć, że Scrum jest metodyką.

Na początek jednak, aby każdy mógł się łatwo odnaleźć w kolejnych postach, chcę opisać tutaj parę pojęć i definicji związanych z tą metodyką.

Scrum

Jest to nie tylko nazwa metodyki. Scrum jest to również nazwa codziennego spotkania zespołu. Spotkanie to jest codziennym przeglądem wykonanej i planowanej pracy. Scrum powinien być prowadzony przez ScrumMaster’a. Każdy z członków zespołu powinien odpowiedzieć na 3 pytania:

• 1. Co zrobiłeś od ostatniego Scrum?
• 2. Co planujesz wykonać do następnego Scrum’u?
• 3. Czy coś utrudnia Ci wykonywanie efektywnie swojej pracy?

Spotkanie takie powinno być bardzo zwięzłe, co zwykle oznacza czas trwania do 15 minut.

Sprint

Ograniczony standardowo do 30 dni okres czasu, w którym zespołu pracuje nad stworzeniem funkcjonalności z zaplanowanej listy zaległości produktowych sprintu . Sprint najłatwiej porównać jest do iteracji. Każdy sprint powinien być tak zaplanowany, aby stworzone funkcjonalności były w pełni działające i gotowe do wydania. Co oznacza, że w każdym sprincie muszą zostać wykonane następujące czynności:

1. 1. Analiza
2. 2. Projektowanie
3. 3. Kodowanie
4. 4. Testowanie
5. 5. Dokumentowanie

W praktyce sprinty trwają od 2 tygodni do 1 miesiąca, w zależności od projektu i organizacji.

Zaległości Produktowe (Product Backlog)

Lista wszystkich wymagań, zarówno funkcjonalnych jak i niefunkcjonalnych projektu. Każde wymaganie powinno mieć ustalony priorytet i oszacowanie czasowe potrzebne do zamiany każdego z wymagań w działającą funkcjonalność. Im większy priorytet elementu, tym dokładniejsze powinno być jego oszacowanie. Scrum jest procesem otwartym na zmiany wymagań w trakcie trwania projektu. Dlatego lista zaległości produktowych cały czas ewoluuje zarówno pod kątem znajdujących się elementów, jak też mieniających się priorytetów poszczególnych wymagań. Zamiast standardowych przypadków użycia, wymagania opisywane są zwykle przy wykorzystaniu User Stories.

Zaległości Sprintu (Sprint Backlog)

Lista wymagań danego sprintu wybrana wspólnie przez zespół i właściciela produktu. W przeciwieństwie do Zaległości produktowych całego projektu, Sprint backlog jest niezmienny. Czyli określamy go na początek danego sprintu i trzymamy się, aż do jego zakończenia. Jeśli w trakcie sprintu wynikną bardzo nieprzewidziane okoliczności mające duże znaczenie dla powodzenia projektu, w ostateczności Właściciel Produktu ma możliwość przerwania sprintu, ale nigdy zmiany jego zaległości.

ScrumMaster

Jedna z trzech ról w procesie Scrum. Nie wolno mylić jej z Project Managerem z klasycznych metodyk. Rolą ScrumMaster’a jest nadzorowania i kontrolowanie procesu scrum. Tak aby zmaksymalizować korzyści wynikające z jego stosowania. ScrumMaster powinien również pomagać zespołowi w przypadku pojawienia się problemów. Ale rolą ScrumMaster nie jest przydzielanie zadań członkom zespołu.

Właściciel Produktu

Druga z trzech ról w procesie Scrum. Też nie powinno się jej mylić z klasycznym Project Managerem, jednak jest to moim zdaniem rola bardziej zbliżona do PM’a niż ScrumMaster. Zadaniem właściciela produktu jest zarządzanie Zaległościami Produktu, tak aby zmaksymalizować zyski z projektu. Właściciel produktu wraz zespołem ustala listę zaległości sprintu.

Zespół

Ostatnia i najważniejsza rola w procesie Scrum. Zespół to grupa licząca zwykle od 5 do 9 osób (Za wartość optymalną uznaje się 7 osób). Zespół jest odpowiedzialny za realizację zaległości sprintu. Przy czym bardzo ważna jest kwestia odpowiedzialności, bowiem fundamentem metodyki scrum jest założenie, iż zespół powinien się sam organizować. Również z uwagi na założenia Scrum’u w skład zespołu powinny wchodzić osoby o różnych specjalizacjach: Analitycy, Architekci, Programiści, Testerzy.