Inżynieria
programowania
Wstęp do Scrum
Giovanni Asproni
crum jest jedną z najbardziej znanych meto- system norm i wartości ustanowionych przez Manifest
dologii agile. Została opracowana przez Ke- Agile (patrz ramka). Najważniejszą cechą tych metodo-
Sna Schwabera i Jeffa Sutherlanda około ro- logii jest skupianie się na ludziach: na pracy zespołowej,
ku 1993 (data pierwszego Scrum opisanego przez Jef- komunikacji bezpośredniej i szybkiej wymiany informacji,
fa Sutherlanda w  Agile Development: Lessons Lear- w odróżnieniu od bardziej tradycyjnych, które  dla od-
ned from the First Scrum  patrz sekcja resources na miany  skupiają się na procesie, na kolejności wykony-
stronie ScrumAlliance [11]). Scrum przynosi wiele korzy- wanych czynności i stosowanych narzędziach [2].
ści klientom  ludziom lub organizacjom, które są zało- Najważniejszym celem metodologii agile jest do-
życielami projektu  oraz użytkownikom. Iteracyjna i in- starczenie korzyści wszystkim uczestnikom, włącz-
krementalna natura tej metodologii, połączona z zarzą- nie z programistami. Korzyści dla klienta zdają się być
dzaniem priorytetami wymagań, pozwala na wczesne oczywiste: oprogramowanie, które spełnia przyjęte za-
uzyskanie istotnych elementów, przy czym najważniej- łożenia, jest zrobione na czas i mieści się w przewidzia-
sze z nich  po pierwszej iteracji. Co więcej, Scrum po- nym budżecie. Korzyść dla programistów jest znacz-
zwala klientom i użytkownikom uzyskać całkowitą kon- nie mniej oczywista: motywacja i satysfakcja z wykona-
trolę nad kierunkiem i zakresem prac projektu. Na koń- nej pracy. Faktem jest, że stosowanie metodologii agile
cu każdej iteracji mogą zdecydować o kontynuacji pro- może wiele pomóc w motywowaniu programistów [2],
jektu  poprzez dodanie lub modyfikację funkcjonalno- co jest najważniejszym czynnikiem wpływającym na
ści  albo o zakończeniu projektu, jeśli jest zadowalają- ich produktywność [6], a to z kolei bezpośrednio wpły-
cej jakości, bądz
nie jest już im potrzebny. Scrum przy- wa na korzyści dla klientów. Jak zostanie pokazane
nosi korzyści menedżerowi projektu dostarczając na- w dalszej części artykułu, Scrum stosuje się do wszel-
rzędzia  wykres malejący (j.ang. burn-down chart), wy- kich norm i wartości ustanowionych w Manifeście Agile.
kaz prac produktu (j.ang. product backlog), wykaz prac
sprintu (j.ang. sprint backlog)  oraz techniki  codzien- Podstawowe założenia Scrum
ne zebrania, spotkanie planowania sprintu (j.ang. sprint Proces Scrum, jak inne metodologie agile, jest iteracyj-
planning meeting), spotkanie przeglądu sprintu (j.ang. ny  produkt jest wytwarzany w następstwie realiza-
sprint review meeting)  ukierunkowane na zwiększe- cji kolejnych mini-przedsięwzięć zwanych iteracjami 
nie możliwości obserwacji każdego aspektu projektu. oraz inkrementalny  funkcjonalność produktu rośnie
Pozwala to na większą kontrolę nad projektem i wcze- poprzez nowe właściwości, dodawane kolejno pod-
śniejsze wykrywanie problemów, które mogą się zda- czas każdej iteracji. Posiada też własną terminologię,
rzyć podczas trwania projektu. Wreszcie, Scrum zarów- zarówno dla ról zaangażowanych osób, jak i dla niektó-
no dobrze się sprawdza w małych zespołach  siedem rych czynności procesowych. Przedstawię je wstępnie
plus-minus dwóch programistów [15]  jak i dobrze się w następnych dwóch sekcjach. Szybki przegląd proce-
skaluje na większe projekty. Zresztą ta technologia była su przedstawia Rysunek 1.
stosowana w projektach angażujących nawet do kilku-
set programistów [14]. Jej implementacja czasem jed- Role
nak może być trudna  Scrum, jak pozostałe metodolo- W procesie Scrum określa się jedynie trzy role, jakie ma-
gie agile, silnie bazuje na pracy zespołowej, komunika- ją otrzymywać uczestnicy projektu: właściciel produktu,
cji, zaufaniu oraz przydzielaniu odpowiedzialności i wła- szef scruma, oraz członek zespołu. Właściciel produktu
dzy. Te wszystkie sprawy wymagają poważnych zmian jest odpowiedzialny za decyzje w sprawie cech funkcjo-
w przyzwyczajeniach, szczególnie dla organizacji, które nalnych produktu oraz zarządzanie priorytetami w ich
nasiąkły bardziej tradycyjnymi metodami. Pełna akcep- implementacji. Reprezentuje on interesy wszystkich lu-
tacja tych zmian wymaga czasu i ciężkiej pracy. W tym dzi zaangażowanych w projekt i finalny produkt  klien-
artykule  po wprowadzeniu do podstaw tej metodolo- tów, użytkowników itd. Często tę rolę otrzymuje ktoś
gii  przedyskutuję niektóre z tych problemów, włącznie z zespołu marketingu, albo kluczowy użytkownik. Ta ro-
z paroma sugestiami na ich rozwiązanie. la jest podobna do roli klienta w Manifeście Agile.
Szef scrum jest odpowiedzialny za egzekwowa-
Manifest Agile nie praktyk i zasad Scrum, reprezentowanie zarząd-
Termin Agile Software Development to worek, do które- ców wobec projektu,  ekranowanie zespołu i usuwa-
go można wrzucić wszystkie metodologie spełniające nie przeszkód  upewnianie się, między innymi, że
każdy członek zespołu posiada odpowiednie zaso-
by sprzętu i oprogramowania, stanowisko pracy itp.
Kontakt z autorem: [e-mail]
Często ta rola jest przydzielona kierownikowi tech-
64
www.sdjournal.org
Software Developer s Journal 6/2006
Wstęp do Scrum
ganizacji. Moim ulubionym podejściem jest posiadanie w zespo-
Manifest Agile
le członków  pełnoetatowych plus  w razie potrzeby  zewnętrz-
nych dla zespołu specjalistów  częściowo-etatowych , dostępnych
Manifest Agile został zaczerpnięty z [5] Manifestu Agile Software
jako pomoc ekspercka. Zaleca się zawsze wszystkim zaangażo-
Development.
wanym w projekt Scrumowy, aby nie podejmowali się więcej, niż
Odkrywamy lepsze sposoby na tworzenie oprogramowania
jednej roli jednocześnie. Powód jest taki, że każda z ról ma przy-
poprzez robienie tego i pomaganie w tym innym. Poprzez tę pracę
pisany inny zestaw odpowiedzialności, przez co może nie współ-
osiągnęliśmy korzyści:
grać z inną rolą. Na przykład, właściciel produktu mógłby próbo-
" Ludzie i współpraca ponad proces i narzędzia;
wać wymusić na zespole programistów pracę w nadgodzinach,
" Działające oprogramowanie ponad wyczerpującą dokumentacją;
żeby spełnić niemożliwy deadline, w którym to przypadku szef
" Współpraca z klientem ponad negocjacją kontraktu;
Scruma powinien poczuć się częścią zespołu i bronić go przed ta-
" Reagowanie na zmiany ponad trzymaniem się planu.
kim nadużyciem. Jednak takie rozdzielenie nie zawsze jest możli-
we. W tym przypadku radzenie sobie z potencjalnymi konfliktami
Czyli, choć elementy po prawej mają swoją wartość, cenimy bar-
pozostawia się zdrowemu rozsądkowi zaangażowanych osób.
dziej elementy po lewej.
Czynności procesowe i narzędzia
nicznemu zespołu lub kierownikowi projektu, a czasem wła- W tym rozdziale objaśnię terminologię dotyczącą elemen-
ścicielowi produktu. tów procesu Scrum. Pierwszym ważnym terminem jest sprint,
Członkiem zespołu jest każdy, kto należy do zespołu wy- który jest tylko innym określeniem iteracji. Sugerowany czas
konującego czynności związane bezpośrednio z wytwarzaniem trwania sprintu jest trzynaście dni kalendarzowych, niemniej
oprogramowania. Członkowie zespołu pełnią różnorakie funk- zwykle można znalez
ć zespoły pracujące z iteracjami jedno-
cje  w przypadku aplikacji webowych mogą do niego należeć lub dwutygodniowymi. Ważne jest, żeby raz ustalony czas
projektanci stron, programiści, testerzy, administratorzy baz da- trwania pierwszego sprintu był następnie taki sam dla pozo-
nych, administratorzy systemu, projektanci techniczni itd. Ze- stałych sprintów, co nada zespołowi odpowiedni rytm i uprości
spół ten jest zespołem samoorganizującym się  jego członko- zarówno zarządzanie, jak i śledzenie czynności procesowych.
wie sami decydują o postępach prac nad dostarczeniem pro- Na początku każdego sprintu organizowane jest spotkanie
duktu bez ingerencji z zewnątrz. Członkowie zespołu, w ideal- planowania sprintu, które jest zajęciem jednodniowym, podzie-
nym przypadku, nie mają przydzielonych tytułów (takich jak ar- lonym na dwie części. Pierwsza część to czterogodzinna sesja
chitekt, kierownik techniczny itd.); zamiast tego współpracują planowania, na której właściciel produktu tworzy tzw. wykaz prac
na równych zasadach. Każdy może być zaangażowany w do- sprintu (zestaw czynności do wykonania w bieżącej iteracji). Jest
wolną z czynności  projektowanie, programowanie, tworzenie to lista czynności najwyższego priorytetu w ilości takiej, jaką ze-
dokumentacji itd.  niezależnie od swojego zakresu ekspertyzy. spół może wykonać w bieżącym sprincie. Czynności te wybiera-
Członkostwo w zespole powinno angażować na cały czas. ne są z wykazu prac produktu, czyli listy wszystkich czynności,
Co jednak nie zawsze jest możliwe, szczególnie przy takich ro- które należy wykonać w celu wytworzenia produktu. Wykaz prac
lach, jak administrator systemu, czy baz danych, które są zazwy- produktu może się zmieniać w czasie (i zwykle się zmienia), kie-
czaj dzielone pomiędzy poszczególnymi zespołami wewnątrz or- dy dochodzą nowe wymagania, bądz
też modyfikuje się lub usu-
Scrum
24 godziny
Powszedni
30 dni
Zadania z wykazu prac
Wersja produktu zdatna
Wykaz prac Sprintu opracowane przez zespół
do wypuszczenia
Wykaz prac produktu według uszeregowania
zarz dzonego przez właściciela produktu
Rysunek 1. Cykl Scrum
Software Developer s Journal 6/2006 www.sdjournal.org
65
Inżynieria
programowania
wa istniejące.Po utworzeniu wykazu prac sprintu, właściciel pro-
duktu i zespół określają tzw. cel sprintu (j.ang. sprint goal), czyli
Zasady rządzące Manifestem Agile
biznesową korzyść, jaką zmiany w produkcie muszą dostarczyć,
Priorytetową sprawą jest osiągnięcie zadowolenia klienta poprzez
niezależnie od implementowanej funkcjonalności. Jego przezna-
wczesne i nieprzerwane dostarczanie mu oprogramowania wysokiej
czeniem jest określić, na czym programiści winni się skupić oraz
jakości. Nie ma się co sprzeciwiać częstym zmianom wymagań, na-
jakie możliwości wybierać w przypadku problemów lub niepew-
wet na póz
niejszym etapie. W procesie agile restrykcyjność zmienia
ności. Cel sprintu powinien być mierzalny, dzięki czemu moż-
się na korzyść klienta. Należy dostarczać działające oprogramowa-
na łatwo określić, kiedy został osiągnięty. Na przykład, celem
nie często, od kilku tygodni do kilku miesięcy, z tendencją raczej do
dla aplikacji webowej dla danego sprintu może być  Obsługiwać
krótszych okresów czasu. Ludzie interesu i programiści muszą pra-
dwukrotnie więcej połączeń, niż w wersji 2.0 .
cować razem codziennie w całym projekcie. Projekt winien być opar-
W drugiej części, zespół dzieli wykaz prac sprintu na poszcze- ty o umotywowanych ludzi. Należy dostarczyć im środowisko pracy
gólne zadania  jednostki pracy szacowane na cztery do sześciu i wszelkie wsparcie oraz zaufać im, że wykonają swoją pracę.
Najbardziej skuteczną i wydajną metodą dostarczania i wy-
godzin  do wykonania w celu dostarczenia wymaganej funkcjo-
miany informacji w zespole programistycznym jest bezpośrednia
nalności. Lista tych zadań niekoniecznie musi być kompletna, bo
rozmowa. Działające oprogramowanie jest głównym miernikiem
wiele zadań może pojawić się gdy sprint już się zaczął. Właściciel
postępu. Ludzie finansujący projekt, programiści oraz użytkowni-
produktu nie uczestniczy w tym spotkaniu, ale musi być dostępny,
cy powinni móc śledzić postęp stale i bez ograniczeń. Ciągłe sku-
żeby odpowiadać na ewentualne pytania zespołu.
pianie się na jakości technik i ulepszaniu projektu zwiększa jego
Spotkanie planowania sprintu jest ograniczone czasowo do
zwinność (j.ang. agility).
ośmiu godzin, a pierwsza część jest ograniczona do czterech go-
Upraszczanie, jako sztuka maksymalizacji ilości nie wykonanej
dzin. W tym miejscu nie od rzeczy jest wspomnieć, że Scrum jest
pracy, jest sprawą zasadniczą. Najlepsze architektury, wymagania
bardzo ścisły pod względem ograniczeń czasowych. Jeśli upłynął
i projekty powstają w samoorganizujących się zespołach. W regu-
czas przeznaczony dla danej czynności, to musi ona zostać za- larnych odstępach czasu zespół winien rozważać, jak zwiększyć
kończona  cztery godziny to dokładnie dwieście czterdzieści mi- swoją wydajność i zgodnie z tym zmieniać swoje metody pracy.
nut i ani minuty dłużej. Powód tego jest taki, że ludzie mają się sku-
pić na tym, co jest ważne, i nie marnować czasu na sprawy drugo-
rzędne. Codziennie o tej samej porze, w tym samym miejscu, oraz Zaraz po spotkaniu przeglądu sprintu organizuje się spotka-
najlepiej jeszcze przed rozpoczęciem pracy, zespół powinien zro- nie retrospektywne sprintu (j.ang. sprint retrospective meeting),
bić sobie spotkanie na dzień dobry (j.ang. stand-up meeting; zwa- trwające trzy godziny, na którym zespół i szef scruma rozma-
ny inaczej scrumem powszednim) trwające co najwyżej pięćdzie- wiają o tym, które zadania i czynności zostały wykonane należy-
siąt minut  niezależnie od wielkości zespołu  na którym każdy cie podczas ostatniego sprintu i jak można usprawnić następny.
członek zespołu odpowiada na trzy pytania: Co robiłeś wczoraj?; Właściciel produktu nie uczestniczy w tym spotkaniu.
Co będziesz robić dzisiaj?; Co ci stoi na przeszkodzie? Z kolei, jeśli podczas sprintu okazuje się, że występu-
Spotkanie służy jedynie synchronizowaniu (nie rozwiązywa- ją szczególnie uciążliwe problemy z realizacją postawionych
niu problemów). Wszelkie ważne sprawy są rozpatrywane po za- zadań lub też cel sprintu okazał się już nieistotny, szef scru-
kończeniu spotkania. Uczestnictwo w tym spotkaniu jest otwar- ma lub właściciel produktu ma prawo zarządzić nadzwyczajne
te dla każdego, kto jest zainteresowany projektem. Uczestnicy zakończenie sprintu. Innymi słowy, Sprint zostaje przerwany
są podzieleni na dwie grupy. Pierwsza, czyli świnki, to ludzie na- (j.ang. aborted) oraz zostaje podjęta akcja naprawienia pro-
leżący do zespołu programistów, a reszta stanowi drugą grupę, blemu, po czym organizuje się nowy sprint, najpewniej z no-
czyli kurczaki [14]. Podczas spotkania tylko świnki mówią, pod- wym wykazem prac (j.ang. backlog) i nowym celem.
czas gdy kurczaki mogą jedynie po cichu obserwować. Zasto-
sowanie tej reguły powoduje, że spotkanie jest krótkie, ludzie są Wprowadzanie do Scrum
skupieni na istotnych sprawach, a uczestnicy projektu są doinfor- Na początku jest projekt, właściciel produktu, szef scruma
mowani na temat postępu prac i napotkanych problemów. i zespół  z technicznego punktu widzenia to wygląda prosto:
Dla członków zespołu uczestnictwo w tym spotkaniu jest
obowiązkowe. Jeśli któryś z członków nie może w nim z jakichś " Właściciel produktu określa początkowy wykaz prac pro-
powodów uczestniczyć, inny członek zespołu powinien zdać za duktu, plan edycji produktu, budżet itd.;
niego sprawozdanie. W czasie trwania sprintu, na koniec każ- " Zespół, wraz z szefem scrum i właścicielem produktu, de-
dego dnia pracy, każdy członek zespołu aktualizuje tzw. wy- cydują o czasie trwania iteracji (i tego się trzymają);
kres malejący (j.ang. burn-down chart)  wykres przedstawiają- " Planowana jest pierwsza iteracja: określa się wykaz prac
cy ilość pracy do wykonania w bieżącym sprincie (patrz Rysunek sprintu, cel sprintu, zadania  po czym każdy udaje się do
2.)  wraz z szacowaną ilością pracy pozostałej do wykonania swoich zadań.
w zadaniach, nad którymi pracował w ciągu dnia. W ten sposób
łatwo będzie zobaczyć, czy sprint idzie pomyślnie, czy też wystą- Tego typu plany nie zawsze są łatwe do zrealizowania w prak-
piły jakieś opóz
nienia wymagające korekty planów. tyce, szczególnie gdy uczestniczą w tym ludzie.
Na koniec sprintu organizuje się spotkanie przeglądu Przede wszystkim, w zespole zakładanym od zera dopie-
sprintu (j.ang. sprint review meeting), na którym zespół przed- ro po jakimś czasie zostanie osiągnięta równowaga. Nim to na-
stawia właścicielowi produktu, co osiągnięto w ostatniej itera- stąpi, członkowie zespołu będą się starali zaznaczyć swoją wagę
cji. Potem właściciel produktu określa, czy cel sprintu został wobec całego zespołu, powodując tym problemy we współpracy.
osiągnięty. Czas trwania tego spotkania jest ustalony na czte- Jest to normalne i właściciel produktu oraz szef zespołu powin-
ry godziny. ni pohamować swoje zapędy do interwencji porządkowych, a tak-
66
www.sdjournal.org
Software Developer s Journal 6/2006
Inżynieria
programowania
że odmówić tego w razie próśb. Zespół powinien sam wypraco-
Odnośniki
wać sobie równowagę bez wpływów z zewnątrz. W gruncie rze-
czy bowiem każda zewnętrzna pomoc jedynie utrudnia zespołowi
" [1] Asproni, G., An Experience Report on Implementing a Cu-
samoorganizowanie się. Innym problemem, jakże powszechnym
stom Agile Methodology on a C++/Python Project, Overload 64,
w wielu organizacjach, jest oporność na zmiany. Jeśli się chce
2004, http://www.giovanniasproni.com/articles
wprowadzić Scrum w organizacji, która stosuje już inną metodykę,
" [2] Asproni, G., Motivation, Teamwork, and Agile Development,
lub nie stosuje żadnej, można z dużą dozą prawdopodobieństwa
Agile Times Vol. 4, 2004, http://www.giovanniasproni.com/articles
napotkać sprzeciw tych, którzy czują się przez jej wprowadzenie
" [3] Asproni, G., How to Shoot Yourself in the foot. In an Agile Way,
zagrożeni. W tym wypadku, dobrze jest rzucić okiem na [8], w któ- Overload 71, 2006, http://www.giovanniasproni.com/articles
" [4] Beck, K., Andres, C., Extreme Programming Explained:
rym autorzy prezentują wzorowy język do wprowadzania nowych
Embrace Change, 2nd ed., Addison Wesley, 2004
idei o organizacji. Udało mi się zastosować niektóre z technik opi-
" [5] Beck, K., et al., The Agile Manifesto, http://
sanych w tej książce, nim poznałem je jako wzór [1]. Na domiar po-
www.agilemanifesto.org
wyższych problemów, każda rola ma też swoje wyzwania.
" [6] Boehm, B. W., Software Engineering Economics, Prentice
Szef Scrum powinien pohamować swe zapędy do rządze-
Hall, 1981
nia zespołem, nawet jeśli, co się niekiedy zdarza, członkowie ze-
" [7] Cockburn, A., Agile Software Development, A. Wesley, 2002
społu tego sobie życzą  czasem żądają jego interwencji w spra-
" [8] Manns, M. L., Rising, L., Fearless Change: patterns for in-
wach, w których powinni sobie radzić sami. Właściciel produktu,
troducing new ideas, Addison Wesley, 2004
tak jak i szef Scrum, winien trzymać na wodzy pokusę rządzenia
" [9] N.A., Scrum Development Group, http://
zespołem, który może organizować się zupełnie inaczej, niż by on
groups.yahoo.com/group/scrumdevelopmen [10] N.A., XP @
oczekiwał, oraz pokusę dodawania  ważniejszych spraw do wy- Scrum, http://www.controlchaos.com/about/xp.php
" [10] N.A., ScrumAlliance, http://www.scrumalliance.org/
kazu prac sprintu, gdy sprint już wystartował. Jeśli próbuje to ro-
" [11] N.A., Agile Project Management Group, http://
bić, szef scruma i zespół winni się mu postawić. Jeśli nowe cechy
finance.groups.yahoo.com/group/agileprojectmanagement/
są tak ważne, że dodanie ich jest nieodzowne, właściciel produk-
" [12] N.A., AgileAlliance, http://www.agilealliance.org
tu zawsze może zarządzić nadzwyczajne zakończenie sprintu.
" [13] Schwaber, K., Agile Project Management with Scrum, Mi-
Innym wielkim wyzwaniem dla właściciela produktu jest ra-
crosoft Press, 2004
dzenie sobie z organizacją priorytetów poszczególnych prac
" [14] Schwaber, K., Beedle, M., Agile Software Development
z wykazu. Faktem jest bowiem, że decydowanie o tym, co ma
with Scrum, Prentice Hall, 2002
wejść do sprintu i z jakim priorytetem, to ogromna odpowie-
dzialność. Szczególnie dla kogoś, kto jest nowy w Scrumie, lub
w ogóle pierwszy raz ma do czynienia z procesem iteracyjno-in- rzy programiści czują się też jedynymi właścicielami swojego ko-
krementalnym, może to być stresujące. Przecież w końcu  jak du i nie lubią, gdy ktoś ten kod modyfikuje lub choćby ogląda. To,
głosi pewien schemat myślowy  wszystkie wymagania mają co się zwykle powinno osiągnąć to przekonać wątpiących tak,
najwyższy priorytet i wszystkie muszą być spełnione w produk- aby zrozumieli istotę potencjalnych problemów, jakie widzą oni
cie końcowym. W takim przypadku zespół i szef Scruma powin- w tej metodologii, pokazywać im, jak mogą być one rozwiązane
ni udzielić mu pomocy w określaniu poprawnych priorytetów po- i przedstawić im w Scrum te sprawy, które mogą być dla nich oso-
przez zadawanie pytań, tak żeby właściciel mógł spokojnie prze- biście użyteczne [8]. W przypadku programistów, uświadomienie
myśleć, które z tych bardzo ważnych wymagań mają być speł- im perspektywy nauczenia się nowych technologii i technik zwy-
nione w pierwszej kolejności. Ta sprawa może być trudna, ale po kle jest metodą na zwalczenie tego zagrożenia. W przypadku nie-
kilku sprintach, jeśli zespół będzie w stanie dostarczyć jakąś ko- których ludzi może się zdarzyć, że nie przekonają się oni nawet
rzyść na koniec każdego z nich, właściciel produktu będzie bar- do wypróbowania tej metodologii i wtedy najlepiej będzie ich usu-
dziej zadowolony i sprawa stanie się prosta. W pozycji [1], nawet nąć z zespołu  jak dotąd, nie zetknąłem się z taką sytuacją.
jeśli nie jest ona akurat o Scrumie, można poczytać, jak mój ze- Wreszcie, mogą się pojawić problemy spowodowane
spół i ja radziliśmy sobie z tego typu problemami w rzeczywistym przez pomyłki, wynikające z braku doświadczenia we wpro-
projekcie, w którym uczestniczyłem. wadzaniu nowej metodologii w organizacji. Kilka najbardziej
Generalnie zresztą dla człowieka na stanowisku menedżer- niebezpiecznych, na jakie się natknąłem w praktyce, to: Od-
skim  kierownika projektu, kierownika technicznego itd.  jed- górne zarządzenie wprowadzenia metodyki; Przywiązywanie
ną z największych barier do pokonania w przypadku wdrażania zbyt dużej wagi do procesu i zbyt małej do produktu.
Scruma może być odczuwalny brak kontroli nad projektem. Dla Zostały one przedyskutowane w [3]. Tu zamieszczę jedy-
wielu ludzi przekazywanie władzy i ufanie innym jest naprawdę nie krótkie podsumowanie wyjaśniające, dlaczego mogą one
wyzwaniem z uwagi na obawy przed utratą możliwości wglądu, przysparzać problemów. Pierwszy z nich może się zdarzyć,
kontroli, oraz czasami osobistej siły. Okiełznanie tych obaw nig- jeśli kierownik projektu decyduje, że lubi Scrum i wymusza go
dy nie jest łatwe; zwykle wymaga ciężkiej pracy i czasu, a tak- na programistach (niekiedy na właścicielu produktu również).
że nie ma w tej kwestii żadnych murowanych recept na sukces. Problem w takim podejściu polega na tym, że wymuszanie
Książka Mary Lynn Manns i Lindy Rising może dostarczyć nie- bardzo rzadko służy programistom. Zatem próba wymuszania
co dobrych pomysłów na radzenie sobie z tym problemem [8]. na nich nowej metodologii może w efekcie przynieść efekt od-
Co do członków zespołu, należy też uwzględnić fakt, że nie każ- wrotny do zamierzonego.
dy się do Scrum nadaje; ludzie często nie lubią być pozbawia- Drugie z kolei jest typowe dla zespołu, który używa te-
ni swoich tytułów i zaliczani do szeregowych członków zespołu. go szczególnego procesu po raz pierwszy. W pewnej mie-
U najbardziej introwertycznych programistów konieczność tak rze jest to normalne: w końcu jeśli się ktoś uczy czegoś nowe-
ścisłej współpracy może wywołać poczucie dyskomfortu. Niektó- go, to trzeba się na tym skupić, żeby się dowiedzieć, czy robi
68
www.sdjournal.org
Software Developer s Journal 6/2006
Wstęp do Scrum
się dobrze, czy z
le. Jednak gdy zespół zaczyna spędzać wię- Podsumowanie
cej czasu na procesie, niż na produkcie, powinien to być znak, W tym artykule przedstawiłem podstawy Scrum, korzyści z je-
że chyba nie wszystko jest w porządku. Podsumowując, pra- go zastosowania i niektóre z problemów  wraz z możliwymi
ca w dobrze zorganizowanym projekcie Scrumowym może być rozwiązaniami  które mogą się pojawić podczas wdrażania.
bardzo korzystnym doświadczeniem dla wszystkich uczestni- Jeśli ktoś chce nauczyć się więcej, w sekcji odnośników znaj-
ków: właściciel produktu dostaje lepszy produkt wcześniej, pro- dzie mnóstwo zasobów do obejrzenia, wiele z nich jest do-
gramiści mają większą satysfakcję ze swojej pracy i większe stępnych za darmo w Internecie. Dobrym punktem startu są
możliwości uczenia się nowych rzeczy dzięki przeplatającym się strony ScrumAlliance [11] oraz AgileAlliance [13], na których
funkcjom zespołu i uczestnictwie w każdym aspekcie projektu, można znalez
ć kilka darmowych artykułów o  Agile Deve-
a kierownik projektu ma większą kontrolę nad projektem i lepszy lopment  w ogólności i Scrum w szczególności. ScrumAllian-
wgląd w to, co się w nim dzieje. ce zawiera też parę odniesień do darmowych narzędzi, które
mogą być użyteczne, gdyby się ktoś decydował na zastoso-
Scrum i programowanie ekstremalne wanie Scrum w swojej organizacji.
Po co ten akapit? Przecież metody agile są różne, więc po co po- Inne zasoby na sieci zawierają też dwie interesujące grupy
równywać Scrum z programowaniem ekstremalnym (j.ang. extre- Yahoo otwarte dla wszystkich: Scrum Development [9] i Agile
me programming, XP) [4]? Powód prosty: XP jest prawdopodob- Project Management [12], z których można skorzystać poprzez
nie najbardziej znaną metodą agile i pierwszą rzeczą, jaką ludzie zadawanie pytań ekspertom programowania metodami agile
chcą się dowiedzieć, gdy przedstawia się inną z nich, jest jak się oraz uczestnictwo w różnych, często gorących dyskusjach.
one do siebie mają. Niestety mają się one do siebie mniej więcej Zanim ktoś spróbuje zastosować Scrum swoim projekcie,
jak jabłka do pomarańczy. Nawet założywszy, że obie spełniają oprócz podparcia się darmowymi zasobami opisanymi wyżej,
Manifest Agile, dotyczą różnych spraw. Scrum dotyczy strony za- sugeruję przeczytać  co najmniej  książkę Alistaira Cock-
rządzającej, pozostawiając inżynierskie sprawy  projektowanie, burna o agile software development w ogólności [7] i dwie
kodowanie, zarządzanie konfiguracją, testowanie itd.  samoor- książki o Scrumie Kena Schwabera [14].
ganizującemu się zespołowi, podczas gdy XP dotyczy właśnie in- Jeśli zdecydujesz, że naprawdę lubisz Scrum  i masz tro-
żynierskich spraw i nie dostarcza żadnych specyficznych narzę- chę zbędnych pieniędzy  możesz zostać Certyfikowanym
dzi do zarządzania projektem. W praktyce często stosuje się je Szefem Scrum po odbyciu dwudniowego szkolenia. Możesz
razem, a także istnieją metodologie oparte na połączonych tych znalez
ć więcej szczegółów na ten temat na stronie ScrumAl-
dwóch metodach. Przykłady można obejrzeć w [10]. liance [11]. n
Księgozbiór
Microsoft Windows Internals, 4th Edition: Microsoft
Windows Server 2003, Windows XP, and Windows 2000
Autorzy: Mark E. Russinovich, David A. Solomon
Wydawnictwo: Microsoft Press 12/2004
ISBN: 0-7356-1917-4
Ocena: 5-
Podczas gdy od kilku już lat trwa nieustająca kampania promocyjna środowiska programi-
stycznego firmy Microsoft  platformy .NET, a serwisy internetowe huczą od plotek na temat
wciąż odwlekanej premiery najnowszego dziecka korporacji  systemu Windows Vista, w tle
tysiące programistów wciąż wspiera, rozwija, a i także tworzy oprogramowanie systemowe.
Specyfika tego typu aplikacji wymaga wiedzy niemal tajemnej o wnętrznościach i mechani-
zmach funkcjonujących u podstaw systemów Windows XP, Windows Server 2003 i Windows
2000. Wiedzę tę niewątpliwie posiadają autorzy: M. Russinovich i D. Solomon. Niestety nie
mogę napisać, iż mimo niemal tysiąca stron druku, dzięki tej książce dowiemy się wszystkiego - każdego szczegółu na temat tego, co
wiedzieć powinniśmy o rodzinie systemów Windows NT. Nie istnieje jednak na rynku lepsza pozycja, równie kompleksowo omawiają-
ca aspekty związane z wnętrznościami tego systemu. Otrzymujemy, bowiem bogaty zestaw informacji referencyjnych dotyczących:
jądra i architektury systemu, zarządzania procesami, wątkami, pamięcią, konfiguracją systemu, a także opis mechanizmów działa-
nia systemu plików, wejścia  wyjścia, operacji sieciowych, bezpieczeństwa, czy nawet elementów takich jak uruchamianie, zamy-
kanie oraz analiza błędów napotkanych w czasie działania systemu. Dostrzeżone minusy to brak wersji elektronicznej lub nawet CD
z zamieszczonymi aplikacjami wykorzystanymi w książce. Zbyt krótki, ale za to bardzo ciekawy, rozdział o analizowaniu błędów wy-
stępujących podczas awarii systemu oraz dość znaczna liczba dostrzeżonych błędów. Sądzę, iż każdy programista poważnie traktu-
jący tworzenie aplikacji na platformie Windows, powinien zastanowić się nad zakupem tej niezbyt taniej pozycji.
Zrecenzował: Stefan Turalski
http://www.promise.pl
Software Developer s Journal 6/2006 www.sdjournal.org
69