Projektowy Młyn

Klasyczne, ''ciężkie'' metodyki zarządzania projektami, oparte na dokładnym planowaniu wszystkich działań, niezbyt przystają do projektów o wysokim stopniu niepewności, do których należą projekty programistyczne. Tutaj bardzo ciekawym rozwiązaniem jest metodyka Scrum.

Klasyczne, 'ciężkie' metodyki zarządzania projektami, oparte na dokładnym planowaniu wszystkich działań, niezbyt przystają do projektów o wysokim stopniu niepewności, do których należą projekty programistyczne. Tutaj bardzo ciekawym rozwiązaniem jest metodyka Scrum.

Zespoły zajmujące się wytwarzaniem oprogramowania już dawno przekonały się, jak ważne jest wczesne dostarczanie kolejnych wersji systemu - być może mocno okrojonego, ale mimo wszystko działającego (wówczas odbiorca może ocenić, czy prace postępują we właściwym kierunku). Dlatego powstały iteracyjne techniki produkcyjne, takie jak metoda spiralna, wczesne prototypowanie czy programowanie ekstremalne (extreme programming, XP). Metody te są jednak ściśle związane ze specyficzną dziedziną wytwarzania oprogramowania, a ponadto nie obejmują pełnego cyklu życia produktu.

Klasyczne sposoby zarządzania projektami są zbyt "kaskadowe" w przypadku przedsięwzięć o wysokim stopniu niepewności i innowacyjności, do jakich z natury rzeczy należą projekty programistyczne, toteż konieczne stało się opracowanie alternatywnych metodyk prowadzenia projektów, które byłyby bardziej odpowiednie dla tego typu przedsięwzięć.

W ten sposób narodził się Scrum, który jest jedną z "lekkich" (zwinnych) metodyk zarządzania projektami, realizowaną zgodnie z zasadami The Agile Manifesto. Jest stosowany z powodzeniem od połowy lat 90. przez różne firmy zajmujące się wytwarzaniem oprogramowania, w tym przez Microsoft.

Sam termin "scrum" wywodzi się z gry w rugby i oznacza młyn, czyli rodzaj rzutu wolnego, w którym dwie splecione ze sobą drużyny przepychają się nad leżącą na murawie piłką. Jak przystało na metodykę lekką, Scrum koncentruje się na dostarczaniu wyników projektu metodą kolejnych przybliżeń, bezpośrednim zaangażowaniu przyszłego użytkownika w proces wytwórczy oraz na samoorganizacji zespołu projektowego.

Zespół projektowy w Młynie

Projektowy Młyn

Motto: "Czy czujesz się na tyle lekki i zwinny, aby zagrać w rugby?"

Ścisły zespół Młyna liczy zwykle od 5 do 9 osób (magiczne 7±2) i ma zwykle charakter interdyscyplinarny, to znaczy poza programistami może w nim uczestniczyć również kontroler jakości, dokumentalista, grafik, a także specjalista biznesowy lub psycholog. Wszyscy członkowie zespołu są zaangażowani w stu procentach i nie mogą uczestniczyć w żadnych innych pracach. Jedynym wyjątkiem mogą być pracownicy usługowi, np. administrator zajmujący się obsługą komputerów członków zespołu, który jest wzywany w miarę potrzeb. Co ciekawe, struktura taka odpowiada dokładnie "zespołowi chirurgicznemu", postulowanemu ponad 30 lat temu przez Freda Brooksa w jego znanym "Mitycznym osobo-miesiącu".

Rolę kierownika projektu pełni Mistrz Młyna (Scrum Master), którego zadaniem nie jest jednak ani planowanie, ani przydzielanie, ani kontrolowanie wykonania zadań, lecz przede wszystkim usuwanie wszelkich przeszkód w pracy zespołu, a także zapewnianie zgodności wyników prac z celami biznesowymi sponsora projektu. Mistrz pilnuje również przestrzegania obowiązujących reguł gry (np. dba o samoorganizację zespołu, ale zwalcza kliki) oraz reprezentuje zespół na zewnątrz.

Ważną rolę pełni odbiorca aplikacji, zwany też właścicielem produktu. W przypadku projektu realizowanego na zamówienie zewnętrzne będzie nim reprezentant klienta, natomiast w przypadku wewnętrznego projektu mającego na celu wytworzenie nowego produktu na rynek masowy, właścicielem jest zwykle ktoś z działu marketingu.

Jednostką pracy zespołu projektowego jest przebieg (sprint), który trwa zwykle od 2 do 6 tygodni. Zaleca się jednak stosowanie przebiegów o stałym czasie trwania (np. 1 miesiąc), co pomaga zespołowi w wypracowaniu regularnego rytmu pracy. Naczelną zasadą pracy Młyna jest to, że każdy przebieg musi dostarczyć użytkownikowi kolejną działającą wersję produktu, którą byłby w stanie dotknąć i ocenić. Nie jest przy tym ważne, jak wiele nowych funkcji systemu zostanie dodanych w ciągu miesiąca. Liczy się to, że każde kolejne wydanie musi dodawać nową wartość, którą daje się zweryfikować w praktycznym użytkowaniu, nie zaś na papierze.

Do biegu...

Projektowy Młyn

Przykładowy wykres spalania

Każdy przebieg jest poprzedzony fazą przygotowawczą, w której uaktualniana jest lista wymagań użytkownika. Poprawniej byłoby zresztą mówić o liście życzeń, ponieważ wymagania gromadzone są w postaci "historyjek" (stories), mówiących o tym, jak właściciel wyobraża sobie swój przyszły produkt. Opowiadanie sensownych historyjek nie jest jednak wcale takie łatwe, w związku z czym wielu praktyków zaleca wcześniejsze szkolenie użytkowników w sztuce ciekawego opowiadania.

Historyjki muszą być krótkie i treściwe - najlepiej, aby z jednej historyjki wynikała wprost jedna cecha systemu. Pomysły użytkownika można gromadzić na zwykłych kartonikach albo wpisywać je do kolejnych wierszy arkusza kalkulacyjnego. Zanim zespół przystąpi do pracy, właściciel produktu proszony jest jeszcze o ustalenie priorytetów wymagań oraz o wyznaczenie głównego celu przebiegu.

Jeśli chodzi o priorytety, to nie muszą być one ułożone według bardzo wyrafinowanej skali. W wielu przypadkach wystarczy wskazanie tych cech, bez których realizacja systemu w ogóle mija się z celem (must be), tych, których obecność bardzo ułatwiłaby pracę (should be) i wreszcie tych, których obecność sprawiłaby właścicielowi niekłamaną przyjemność (nice to have). Jak wiadomo, użytkownicy mają naturalną skłonność do początkowego zaliczania prawie wszystkich swoich pomysłów do najwyższej kategorii, w związku z czym tu także potrzebna jest odrobina treningu i negocjacji.

Lista czekających na spełnienie życzeń wraz z ustalonymi priorytetami tworzy rejestr wymagań na produkt (product backlog). Konieczność dodatkowego wyznaczenia głównego celu przebiegu wynika z tego, że mechaniczne wybranie cech o najwyższym priorytecie mogłoby prowadzić do realizacji słabo skorelowanych, czy nawet wzajemnie sobie przeszkadzających zadań. Podobnie jak wymagania cząstkowe, główny cel przebiegu musi być krótki i jasny. Przykładowo, w dziedzinie usług finansowych mogłoby to być hasło "zapewnić dostęp do bieżących notowań giełdowych w czasie poniżej 1 minuty", w dziedzinie badań psychologicznych - "stworzyć koncepcję badania samooceny działającego na telefonie komórkowym", czy też po prostu - "przenieść centralną bazę danych z platformy MS SQL Server na platformę Oracle". Jak widać, niektóre cele mogą mieć charakter czysto techniczny, wynikający z bieżącego stanu rozwoju systemu, są więc wówczas proponowane przez sam zespół wykonawczy.

Cel przebiegu zaakceptowany wspólnie przez właściciela produktu i przez zespół powinien zostać wypisany dużymi literami i przymocowany na ścianie pokoju Młyna.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200