#Niezbędnik Juniora. Scrum

By 3 October 2015Niezbędnik Juniora

O Scru­mie na 90% słysza­łaś, ale praw­dopodob­nie spotkałaś się też z jego niepraw­idłowym uży­ciem. Dzisi­aj przyjrzymy się bliżej tej metodyce. Być może nawet uda Ci się usprawnić pracę Two­jego zespołu!

Wstęp

Zaczniemy od odrobiny teorii i kilku pojęć.

Czym jest Scrum?

Zadal­iśmy pod­sta­wowe pytanie, stanow­iące punkt wyjś­ciowy  sze­rok­iego tem­atu. Scrum to frame­work sposobu pra­cy zespołu oraz, pośred­nio, szkielet zarządza­nia pro­jek­tem. Należy do tzw. metodyk zwin­nych, czyli takich, które odd­a­ją idee man­i­fes­tu Agile. Scrum zakła­da pro­ces iter­a­cyjny, w którym pro­dukt jest ‘dzi­ała­ją­cy’ (choć niekoniecznie funkcjon­al­ny) już na bard­zo wczes­nych eta­pach. Później sukcesy­wnie uspraw­nia się wdrożone czyn­noś­ci. Dzię­ki temu scrum stosowany jest częs­to w pro­jek­tach innowa­cyjnych, przy współpra­cy zespołu posi­ada­jącego kom­pe­tenc­je tech­niczne z klien­tem (potenc­jal­nym użytkown­ikiem pro­duk­tu) Sprawdza się również w sytu­ac­jach, gdy wykon­aw­ca zna potrze­bę danej oso­by, a niekoniecznie ma szczegółową specy­fikację samego pro­jek­tu.

Podstawowe pojęcia

Scrum jest zbu­dowany wokół kilku kon­cep­tów, które trze­ba poz­nać ‘ogól­nie’, abyśmy mogli prze­jść do szczegółów.

Back­log.  Ist­nieją dwa back­lo­gi: pro­duk­tu i sprintu. Back­log pro­duk­tu to lista user sto­ries, które zamierza­my dostar­czyć w ramach pro­duk­tu. Back­log sprintu zaw­iera user sto­ries, które planu­je­my dostar­czyć w ramach sprintu, z podzi­ałem na poszczególne tas­ki.

Intere­sar­iusz. Oso­ba lub gru­pa, która będzie uczest­niczyła w cyk­lu życia pro­duk­tu (np. spon­sor, użytkown­i­cy — oper­a­torzy, klien­ci itp.)

Prod­uct own­er . Nazy­wany też głównym użytkown­ikiem. Jest to przed­staw­iciel użytkown­i­ka (lub grupy użytkown­ików), który bierze udzi­ał w proce­sach planowa­nia i pri­o­ry­te­tyza­cji zadań, a także uczest­niczy w demo.

Scrum board. Tabli­ca, na której widoczny jest progress sprintu. Powin­na być dostęp­na dla wszys­t­kich intere­sar­iuszy (może być fizy­cz­na lub online)

Scrum mas­ter. Członek zespołu, który dba o trzy­manie się najlep­szych prak­tyk w pro­ce­sie Scru­mowym i ciągłe uspraw­ni­an­ie pro­ce­su, nie jest to project man­ag­er!

Sprint. Krót­ki (zwyk­le tydzień lub dwa) okres cza­su, pod­czas którego dostar­cza­my wybraną funkcjon­al­ność (lub funkcjon­al­noś­ci) — user sto­ry

Sprint review (nie do koń­ca poprawnie nazy­wany też sprint demo) Spotkanie, pod­czas którego prezen­towane są osiąg­nię­cia ostat­niego sprintu, omaw­iana jest jego zgod­ność z założe­ni­a­mi oraz sposób na usprawnie­nie.

User sto­ry. His­to­ria użytkown­i­ka, czyli funkcjon­al­ność z punk­tu widzenia użytkown­i­ka pro­jek­tu, opisana w określony sposób (kto-co-dlaczego-jak — zobacz sekcję o pisa­niu user sto­ries)

Scrum, a ‘tradycyjne’ podejście do organizacji projektów

Poprzez poję­cie “trady­cyjne” rozu­miemy tutaj metodykę tzw. Water­fall , czyli taką, w której pro­jekt jest szczegółowo planowany na początku oraz doku­men­towany w naj­drob­niejszych szczegółach. Dopiero po tej fazie następu­je rozpoczę­cie real­iza­cji. Wery­fikac­ja następu­je po real­iza­cji całego pro­duk­tu, a zmi­any są wdrażane poprzez kole­jne mini-pro­jek­ty.

Najwięk­szą różnicą pomiędzy takim pode­jś­ciem, a Scrumem jest relac­ja z klien­tem. Stan­dar­d­owe pode­jś­cie nastaw­ione jest na relację zamaw­ia­ją­cy-wykon­aw­ca, w której wartoś­cią dla zamaw­ia­jącego jest pro­dukt, a dla wykon­aw­cy wyna­grodze­nie zań otrzy­mane. Scrum nie tylko nie dzieli pro­jek­tu i celu na dwie strony, ale wręcz wskazu­je klien­ta jako part­nera zespołu devel­op­er­skiego. Ma miejsce swoista koop­er­ac­ja na rzecz uzyska­nia najlep­szych efek­tów koń­cowych (w rozu­mie­niu funkcjon­al­nego pro­duk­tu)

Takie pode­jś­cie wyglą­da bard­zo kuszą­co, ale niesie za sobą pewne zagroże­nia. Przede wszys­tkim Scrum utrud­nia (choć w żad­nym wypad­ku nie uniemożli­wia!) kosz­to­rysowanie pro­jek­tu w długim ter­minie. Z drugiej strony pozwala na dopra­cow­anie pro­duk­tu, także poprzez iden­ty­fikowanie tych potrzeb klien­ta, których nie był świadomy oraz zna­jdy­wanie opty­mal­nych rozwiązań. Prak­ty­ka pokazu­je jed­nak, że pro­jek­ty real­i­zowane w Scru­mie kończą się szy­b­ciej, przy mniejszym budże­cie oraz z więk­szą satys­fakcją dla klien­ta, niż real­i­zowane w kon­wencjon­al­ny sposób. Wyni­ka to z fak­tu, że mając wspól­ny cel, zespół nie traci cza­su i energii na ‘walkę’ z klien­tem, a korzys­ta z syn­ergii swo­jego potenc­jału tech­nicznego i domenowej wiedzy klien­ta.

Trze­ba również powiedzieć, że bard­zo wiele zależy od samego zespołu. Scrum prowad­zony w niewłaś­ci­wy sposób może pogorszyć sytu­ację, zami­ast ją popraw­ić i z pewnoś­cią nie jest panaceum na wszys­tkie prob­le­my.

Kwes­t­ia wyboru sposobu real­iza­cji pro­jek­tu powin­na być ostate­cznie pod­ję­ta w orga­ni­za­cji. Nie jest błę­dem nie korzys­tanie ze Scru­ma, ale na pewno niewłaś­ci­wym pode­jś­ciem jest nie branie go pod uwagę przy planowa­niu nowego pro­jek­tu.

Realizacja projektu wg Scrum

Scrum daje kil­ka narzędzi, które mogą usprawnić pracę Two­jego zespołu. W tej sekcji omówimy najważniejsze z nich.

Backlog produktu

Back­log pro­duk­tu to spis his­torii użytkown­i­ka, które składa­ją się na kom­plet­ny pro­dukt koń­cowy. Powyższa lista nie jest zamknię­ta. Może być mody­fikowana w trak­cie real­iza­cji pro­jek­tu, w miarę iden­ty­fikowa­nia nowych potrzeb oraz zmi­any pri­o­ry­tetów.

Nie ma określonej formy prowadzenia back­logu — więk­szość narzędzi pozwala po pros­tu grupować his­to­rie real­iza­cji wg pro­jek­tów, pozwala­jąc na ich przenosze­nie do sprint­ów w przyszłoś­ci. W prak­tyce może to być nawet notes, czy kop­er­ta z karteczka­mi (czego jed­nak nie pole­camy, z uwa­gi na prob­le­my z zarządzaniem takim zbiorem ;) ).

His­to­rie użytkown­ików w konkret­nym back­logu mogą (nie jest to niezbędne) być osza­cow­ane pod wzglę­dem cza­sowym. Muszą określać pri­o­ry­tet (z punk­tu widzenia klien­ta). Powin­ny zaw­ier­ać kry­te­ria akcep­tacji (choć i one są opcjon­alne). Back­log pro­duk­tu jest pod­stawą do dal­szego planowa­nia, a jed­nym z ważniejszych pro­cesów z nim związanym jest back­log groom­ing.

Backlog grooming

W nazwie pro­ce­su ukry­ta jest jego isto­ta. “Groom­ing” to z języ­ka ang­iel­skiego dbać, wręcz ‘dopieszczać’, porząd­kować. Chodzi o to, aby prze­jrzeć back­log pro­duk­tu pod określonym kątem. Usunąć z niego nieak­tu­alne his­to­rie użytkown­i­ka, jak i popraw­ić esty­mac­je. Jeśli mamy nowe infor­ma­c­je, uzu­pełnić o dodatkowo odkryte ścież­ki, zwery­fikować pri­o­ry­te­ty oraz podzielić zbyt duże his­to­rie na mniejsze. Pro­ces ten powinien być wykony­wany cyk­licznie, względ­nie częs­to i oczy­wiś­cie z udzi­ałem klien­ta.

Sprinty

Sprint to pod­sta­wowa jed­nos­t­ka cza­su uży­wana w planowa­niu. Głównym założe­niem pro­jek­tu jest to, by efek­tem jed­nego sprintu (iter­acji) był przy­rost pro­duk­tu. Oznacza to w prak­tyce, że po zakończe­niu sprintu, pro­dukt powinien zyskać nową funkcjon­al­ność lub cechę, którą moż­na zademon­strować klien­towi. Nie musi to być skońc­zona funkcjon­al­ność (o ile oczy­wiś­cie przyjmiemy odpowied­nie kry­te­ria akcep­tacji).

Pod­czas sprintu real­izu­je­my his­to­rie użytkown­i­ka, rozbite na bardziej szczegółowe zada­nia. His­to­rie powin­ny być real­i­zowane w całoś­ci, w ramach jed­nego sprintu — przenosze­nie his­torii pomiędzy sprint­a­mi powin­no być ogranic­zone do min­i­mum, ponieważ utrud­nia wycią­ganie wniosków o postępie i szy­bkoś­ci osiąg­niętej przez zespół.

Zakres prac real­i­zowany w ramach sprintu jest określany przed każdym sprint­em osob­no, w pro­ce­sie planowa­nia sprintu.

Planowanie sprintów

Przy­go­towanie sprintu pole­ga na tym, że z back­logu pro­duk­tu przenosimy his­to­rie do back­logu sprintu, uprzed­nio sza­cu­jąc nasze możli­woś­ci. Następ­nie rozbi­jamy his­to­rie na bardziej pre­cyzyjne zada­nia z dokład­niejszą wyceną.

Pro­ces wyboru his­torii do sprintu powinien odby­wać się z uwzględ­nie­niem pri­o­ry­tetów , określonych we współpra­cy z klien­tem. Każdą his­torię prze­nie­sioną do sprintu dzie­limy na zada­nia, które następ­nie sza­cu­je­my w pro­ce­sie zwanym Plan­ning pok­er.

His­to­rie dobier­amy do momen­tu, w którym mamy jeszcze możli­woś­ci pra­cy, tzw. capac­i­ty.  Określamy je na pod­staw­ie doty­chcza­sowych doświad­czeń. Szerzej o tym zagad­nie­niu napisze­my w sekcji szybkość/velocity.

Planning poker

Plan­ning pok­er to bard­zo waż­na część Scru­ma, która zapew­nia efek­ty­wne sza­cow­anie oraz powszechne rozu­mie­nie zakre­su zadań. Zan­im jed­nak prze­jdziemy do właś­ci­wego pro­ce­su, kil­ka słów o jed­nos­tkach.

Scrum nie narzu­ca jed­nos­t­ki planowa­nia. Powin­na być ona dopa­sowana do zespołu i pro­jek­tu oraz odzwier­cied­lać realne potrze­by. Jed­nos­t­ki cza­su bywa­ją zbyt pre­cyzyjne (np. godziny) lub zbyt sze­rok­ie (dni). Częs­to wygod­nym rozwiązaniem jest przyję­cie abstrak­cyjnych jed­nos­tek planowa­nia — przyj­mu­jąc przykład­owo, że pełny tydzień pra­cy to 15 jed­nos­tek. Ponieważ przyj­mowanie podzi­ałów cza­sowych stanowi indy­wid­u­alne ustal­e­nie zespołu, w dal­szej częś­ci będziemy mówić po pros­tu o jed­nos­tkach. Jak sama się przekonasz, określe­nie ile cza­su zaj­mu­je dokład­nie jed­na jed­nos­t­ka, nie ma znaczenia.

Plan­ning pok­er zaczy­namy od wyboru zada­nia, które będzie odniesie­niem. Może to być pro­jekt z przeszłoś­ci, który każdy z członków zespołu dobrze zna. Co za tym idzie,  może­my ocenić jego złożoność i osza­cow­ać czas na wyko­nanie określonej licz­by podob­nych zadań. “Podob­nych” jest tutaj słowem-kluczem, ponieważ planowanie pole­ga nie na oce­nie czasochłon­noś­ci real­iza­cji przyszłego zada­nia, ale na porów­na­niu jego złożonoś­ci do punk­tu odniesienia — wybranego wcześniej pro­jek­tu.

Do pok­era najwygod­niej uży­wać kart, ale moż­na też sko­rzys­tać z aplikacji mobil­nej, czy po pros­tu pokazać konkret­ną wartość na pal­cach lub napisać ją na kartce. Ist­nieją dwa najpop­u­larniejsze zestawy (oczy­wiś­cie w zes­pole może­cie przyjąć swój włas­ny) Ciąg Fibonac­ciego oraz kwadraty kole­jnych liczb. Idea jest taka, że złożoność zadań nie rośnie lin­iowo. Zadanie dwa razy bardziej złożone od ‘odniesienia’ praw­dopodob­nie będzie wyma­gało więcej niż dwa razy więcej cza­su na real­iza­cję. Użyjmy kart z ciągiem Fibonac­ciego. Jeśli zadanie-odniesie­nie jest wyce­nione na dwie jed­nos­t­ki cza­su i aktu­al­nie sza­cu­jesz dwukrot­nie bardziej złożony pro­jekt,  najbliższym odpowied­nikiem na kar­cie jest licz­ba 5. Taki czas trwa­nia zada­nia powinien zostać przyję­ty. W pok­erze, po opisa­niu zada­nia czy his­torii przez jed­ną z osób, każdy sam dokonu­je porów­na­nia z zadaniem odniesienia. Po tym wszyscy jed­nocześnie pokazu­ją swo­je sza­cun­ki. Następ­nym krok­iem, o ile są różnice w oce­nie, jest omówie­nie przez każdego pod­staw swo­jej decyzji. Ponowne głosowanie ma miejsce do chwili, kiedy wszyscy będą jed­no­myśl­ni lub zgodzą się na określoną ‘wycenę’. Powyższe pode­jś­cie adresu­je kil­ka kwestii:

  • członkowie zespołu mogą mieć różne poję­cie zakre­su zada­nia — pod­czas omaw­ia­nia pod­staw do sza­cunków różnice powin­ny się ujawnić, dzię­ki czemu moż­na ustal­ić wspólne rozu­mie­nie
  • członkowie zespołu mają różną wiedzę i doświad­czenia — np. jed­na oso­ba może wiedzieć, że pra­ca z daną częś­cią sys­te­mu, czy tech­nologią, wyma­ga więcej wysiłku i cza­su, więc pod­czas omaw­ia­nia różnic, może się podzielić taką infor­ma­cją
  • członkowie zespołu mają różne tem­po pra­cy i są na różnych eta­pach roz­wo­ju zawodowego — każdy sprint ma określoną pojem­ność (capac­i­ty), która nie jest wyrażona w cza­sie, ale w jed­nos­tkach pra­cy; każdy devel­op­er pomi­mo pra­cy na pełny etat może mieć inną ‘zdol­ność’, pojem­ność sprintu jest sumą dla wszys­t­kich członków zespołu, a nie iloczynem jed­nej wartoś­ci i iloś­ci osób

Początkowo taki sposób planowa­nia zaj­mu­je sto­sunkowo dużo cza­su (kil­ka godzin w ciągu Sprintu) Jest to jed­nak czas, który bard­zo szy­bko odzyskamy, dzię­ki lep­szej orga­ni­za­cji pra­cy i więk­sze­mu przepły­wowi infor­ma­cji na etapie początkowym.

W internecie moż­na pobrać lub kupić kar­ty do planowa­nia. Dar­mowy zestaw do wydrukowa­nia dostęp­ny jest np. tutaj.

Scrum board

Scrum board to tabli­ca, na której są przed­staw­ione postępy danego sprintu. Może ona mieć for­mę fizy­czną lub elek­tron­iczną, częstą prak­tyką jest prowadze­nie jej w obu for­mat­ach.

Tabli­ca ta jest macierzą, gdzie wier­sze to his­to­rie użytkown­i­ka real­i­zowane w konkret­nym sprin­cie, a kolum­ny to ‘etapy’ real­iza­cji (np. ‘back­log’, ‘w trak­cie real­iza­cji’, ‘w trak­cie przeglą­du’, ‘wdrażane’, ‘gotowe’) Każdy zespół może dos­tosować etapy do włas­nego sty­lu pra­cy i pro­jek­tu. Poszczególne zada­nia są reprezen­towane przez pos­ti­ty lub inne ele­men­ty, które po zmi­an­ie sta­tusu zada­nia powin­ny być prze­nie­sione w aktu­alne miejsce.

Scrum board jest świet­nym narzędziem, które daje zarówno zespołowi, jak i innym intere­sar­ius­zom wgląd w postępy real­iza­cji oraz oso­by odpowiedzialne za dany ele­ment.

Codzienne spotkania zespołu

Znane bardziej pod nazwą stand-upy, są jed­ną z możli­wych form prowadzenia pro­jek­tu. Ich celem jest poin­for­mowanie całego zespołu o sta­tusie aktu­al­nie real­i­zowanych zadań, prob­lemach napotkanych od ostat­niego spotka­nia i ewen­tu­al­nych blok­er­ach. Nie jest to moment odpowied­ni na długie dyskus­je tech­niczne, z założe­nia spotkanie powin­no być krótkim sta­tus update. W jego trak­cie każdy w kilku zda­ni­ach odpowia­da na pyta­nia: co zro­bił od ostat­niego razu, jakie napotkał prob­le­my / czy jest zablokowany z jakiegoś powodu oraz co planu­je robić danego dnia.

Stand-upy pole­ga­ją na tym, że zespół — na sto­ją­co, aby niepotrzeb­nie nie przedłużać cza­su, spo­ty­ka się i każdy po kolei odpowia­da na kluc­zowe pyta­nia przy­toc­zone powyżej. To nie jest jedy­na opc­ja. Spotka­nia te moż­na prowadz­ić przez tele­fon, siedząc przy biurkach, przy lunchu, czy w dowol­nej innej formie, real­izu­jącej powyższe założe­nia.

Sprint review (wraz z demo)

Częsty błąd pole­ga na utożsami­a­n­iu Sprint review z demo, pod­czas gdy jest to tylko jeden z  ele­men­tów spotka­nia. Ma ono na celu nie tylko zaprezen­towanie wyników ostat­niego sprintu. Równie waż­na jest dyskus­ja nad real­iza­cją założonych kry­ter­iów, spełnie­niem potrzeb klien­tów oraz ewen­tu­al­nym umieszcze­niem nowo ziden­ty­fikowanych his­torii w back­logu pro­duk­tu. Pojaw­ia się także reflek­s­ja nad tym, co moż­na było usprawnić. Demo samo w sobie, bez dyskusji, nie niesie dużej dodanej wartoś­ci.

Szybkość (velocity) i diagram burn-down

Wspom­i­nal­iśmy już o ciągłym uspraw­ni­a­n­iu pro­ce­su, ale kluc­zowe do jego uspraw­ni­a­nia jest mierze­nie efek­ty­wnoś­ci. W Scru­mie służy do tego tzw. Veloc­i­ty — inny­mi słowy tem­po pra­cy. Idea jest pros­ta, i pole­ga na zlicze­niu iloś­ci zre­al­i­zowanych jed­nos­tek pra­cy w sprin­cie. Przy czym pomi­aru dokonu­je­my z punk­tu widzenia zespołu, a nie indy­wid­u­al­nych jego członków. Więk­szość dostęp­nych narzędzi mierzy veloc­i­ty za nas, ale ręczne policze­nie także nie powin­no spraw­iać prob­lemów.

Narzędziem pomoc­niczym są tutaj dia­gramy — w tym najpop­u­larniejszy burn-down. Dia­gram burn­down pokazu­je dwie lin­ie — jed­na to ide­al­ny postęp sprintu wyrażony w pozostałych do real­iza­c­ja jed­nos­tkach pra­cy danego dnia (założe­niem jest wykony­wanie takiej samej iloś­ci pra­cy każdego dnia roboczego), dru­ga to rzeczy­wista wartość wyko­nanych jed­nos­tek pra­cy od początku sprintu do tego dnia włącznie. Obie lin­ie powin­ny się pokry­wać — zarówno sytu­ac­ja, w której ‘rzeczy­wis­tość’ jest nad ‘ide­al­nym’ (oznacza, że niedosza­cowu­je­my zadań), jak i sytu­ac­ja odwrot­na (oznacza­ją­ca przesza­cow­anie) są syg­nała­mi do usprawnienia pro­ce­su. Drugim w kole­jnoś­ci jeśli chodzi o pop­u­larność jest dia­gram burn-up — idea jest iden­ty­cz­na, z tym że obra­zowana jest wyko­nana pra­ca, a nie pozostała. W obu przy­pad­kach chodzi jed­nak o ciągłą infor­ma­c­je ‘gdzie’ w sprin­cie jesteśmy, jaka jest nasza sytu­ac­ja.

Ciągłe doskonalenie i retrospektywy

W tym miejcu wiesz już, jak wyglą­da Sprint, znasz też narzędzia do bada­nia jego efek­ty­wnoś­ci. Po każdym sprin­cie (lub np. co dru­gi sprint) razem z zespołem zas­tanów się co poszło pozy­ty­wnie w sprin­cie, co się nie udało i co może­cie jako zespół popraw­ić. Te spotka­nia mogą być częś­cią sprint review, mogą być zaraz po nim lub mogą być zupełnie osob­ne. Różni­ca pomiędzy nimi jest sub­tel­na, ale bard­zo waż­na — o ile sprint review sku­pia się na pro­duk­cie i pra­cy, ret­ro­spek­ty­wa powin­na sku­pi­ać się na pro­ce­sie i jego real­iza­cji. Jest to więc miejsce na dyskus­je o wszel­kich przeszko­dach for­mal­nych, pomi­ja­niu ważnych ele­men­tów z jakiegoś powodu, pomysłach na usprawnie­nie, narzędzi­ach pra­cy itp.

Obowiązki Scrum Mastera

Scrum Mas­ter pełni spec­jal­ną rolę w Scru­mie, nie mającą odpowied­ników w innych pop­u­larnych pode­jś­ci­ach do real­iza­cji pro­jek­tów. Zadaniem Scrum Mas­tera nie jest prowadze­nie pro­jek­tu — zde­cy­dowanie nie ma on obow­iązków Project Man­agera. Oso­ba na tym stanowisku powin­na dbać o to, aby pro­cesy Scru­mowe były poprawnie (czyli w sposób dopa­sowany i przynoszą­cy efek­ty, a nie książkowy!) wdrażane w zes­pole oraz cią­gle uspraw­ni­ać zarówno pro­cesy jak i sam zespół.

Scrum Mas­ter nie jest zatem rolą porząd­kową. Czyn­noś­ci takie jak: inicjowanie dzi­en­nych spotkań, prowadze­nie Scrum boar­du czy spotkań plan­ningowych nie wchodzą w zakres jego codzi­en­nych obow­iązków. Powinien za to dbać o poprawne wdrażanie założeń pro­jek­tu, choć niekoniecznie musi być samodziel­nie inic­ja­torem i lid­erem. Za powyższe dzi­ała­nia odpowiedzial­ny jest cały zespół.

W przy­pad­ku tej roli częstą prak­tyką jest też rotac­ja oso­by ją pełniącej. O ile nie jest to zjawisko negaty­wne samo w sobie, należy zawsze mieć na uwadze efek­ty­wność w uspraw­ni­a­n­iu pro­cesów, która prze­cież przy­chodzi z cza­sem.

Historie użytkowników — kto, co, dlaczego i jak

His­to­rie użytkown­i­ka i ich zas­tosowanie  to jeden z powodów, dla których Scrum pozwala dostar­czać pro­duk­ty dopa­sowane do potrzeb użytkown­ików. To nic innego jak for­ma zapisu wyma­gań w sposób, który pozwala uch­wycić nie tylko cel, ale także kon­tekst. Dzię­ki temu na pod­staw­ie sto­sunkowo krótkiej infor­ma­cji , zespół może wywnioskować wiele rzeczy i wybrać najlep­sze rozwiązanie. His­to­ria może wyglą­dać następu­ją­co:

Jako użytkown­ik aplikacji, chcę dodawać nowe zada­nia z poziomu ekranu głównego.  Częs­to są one efek­tem planowa­nia i doda­ję je ‘seryjnie’.

To, co odróż­nia Scrum od innych metod, to uznanie takich właśnie his­torii jako pod­sta­wowej jed­nos­t­ki pra­cy. Dzię­ki temu pro­jek­ty są sku­pi­one na wyma­gani­ach użytkown­ików i znacznie lep­iej dopa­sowane do ich potrzeb.

Kto jest aktorem historii

Mówiąc najproś­ciej, aktorem his­torii może być dowol­ny intere­sar­iusz. Nie musi to być klient, czy użytkown­ik koń­cowy — user sto­ry. Ten opisu­je wyma­gania z punk­tu widzenia oso­by, która będzie w przyszłoś­ci utrzymy­wała, czy rozwi­jała sys­tem. Rozwiązanie jak najbardziej ok (oczy­wiś­cie pod warunk­iem, że spon­sorzy pro­jek­tu je akcep­tu­ją). Przykład­owo user sto­ry może się zaczy­nać:

Jako użytkown­ik sys­te­mu, …
Jako oper­a­tor sys­te­mu, …
Jako admin­is­tra­tor sys­te­mu, …
Jako oso­ba wdraża­ją­ca sys­tem u klien­ta, …
Jako wspar­cie klien­ta, …
Jako spon­sor pro­jek­tu, …

Określe­nie klien­ta jest pomoc­ne przy real­iza­cji, ponieważ infor­mu­je o tym, kto będzie korzys­tał z tej funkcjon­al­noś­ci, a przez to także nada jej kon­tekst. Ułatwia też znalezie­nie oso­by, u której moż­na szukać bardziej szczegółowych infor­ma­cji.

Co jest przedmiotem historii

Przed­miotem his­torii użytkown­i­ka może być dowol­na funkcjon­al­ność, pro­ces lub czyn­ność, którą aktor his­torii chce real­i­zować. Przed­miot powinien być zwięzły i jas­ny. Odpowia­da on na pytanie ‘Co, jako aktor his­torii, chcę, aby moż­na było osiągnąć za pomocą produktu’(w ‘kilku słowach’ należy zawrzeć mer­i­tum lub podzielić je na kil­ka mniejszych his­torii).

Przykłada­mi przed­miotów w his­torii użytkown­i­ka mogą być:

… , chci­ałbym zmienić język inter­fe­j­su na każdej pod­stron­ie, …
… , chci­ałbym dodać przed­miot na pod­staw­ie już ist­niejącego, …
… , chci­ałbym wygen­erować plik PDF z pod­sumowaniem zamówień, …

Przed­miot his­torii jest bard­zo ważny, ponieważ mówi nam, co dany użytkown­ik chce osiągnąć i jaki ma być tego efekt. Jest to więc najbliższy odpowied­nik wyma­gań funkcjon­al­nych, w trady­cyjnym pode­jś­ciu do zarządza­nia pro­jek­ta­mi.

Dlaczego historia jest ważna, czyli uzasadnienie

Odpowiedź na pytanie ‘Dlaczego użytkown­ik chce mieć taką możli­wość’ jest kluc­zowa, aby zrozu­mieć czego naprawdę potrze­bu­je klient. Pozwala też deweloper­om zapro­ponować lep­sze rozwiązanie, jeśli takie zna­ją. Przykłada­mi uza­sad­nień his­torii są np:

… , ponieważ oper­a­torzy nie dys­ponu­ją w tym momen­cie pełnym zestawem danych.
… , ponieważ obiek­ty dodawane są najczęś­ciej w dużych par­ti­ach.

Uza­sad­nie­nie poma­ga też pri­o­ry­te­ty­zować zada­nia i określać ich kole­jność oraz szczegóły imple­men­tacji.

Jak zostanie ona wykonana — kryteria akceptacji

To ele­ment nie­jako opcjon­al­ny — jeśli wys­tępu­je, to najczęś­ciej w postaci osob­nej listy punk­tów czy kry­ter­iów. Nie ma też stan­dar­d­owej formy opisu takich kry­ter­iów. Kry­te­ria akcep­tacji to nic innego jak dopre­cy­zowanie, co zaw­iera się w danym przy­pad­ku uży­cia, a co jest z niego wyk­luc­zone. Inny­mi słowy — jaki stan rzeczy poz­woli uznać, że his­to­ria została zre­al­i­zowana i spowodu­je akcep­tację klien­ta. Jest to o tyle ważne, że niekiedy peł­na his­to­ria użytkown­i­ka jest zbyt złożona lub nawet niemożli­wa do real­iza­cji (z powodu zależnoś­ci i innych mod­ułów). Weźmy na przykład poniższą his­torię:

Jako użytkown­ik por­talu XYZ, chci­ałbym wysłać wiado­mość do innych użytkown­ików z załącznika­mi. Robię to w celu wymi­any plików z dodatkową infor­ma­cją i opisem, która powin­na być archi­wiz­owana.

Kry­te­ria akcep­tacji mogą wyglą­dać następu­ją­co:

  • Funkcjon­al­ność poz­woli załączać dowol­ny typ pliku
  • Rozmi­ar pliku nie może przekraczać 5MB
  • Wyświ­et­lana będzie jedynie nazwa przesłanego pliku
  • Pli­ki nie będą wery­fikowane pod kątem poprawnoś­ci czy innych reguł
  • Plików nie będzie moż­na pobier­ać

Kry­te­ria te mogą wynikać z najróżniejszych okolicznoś­ci i mogą mieć różną for­mę. W tym miejs­cu mieszczą się także maki­ety, szkice, notat­ki ze spotkań, odniesienia do funkcjon­al­noś­ci w ist­nieją­cych sys­temach itp.

Ta sekc­ja jest kry­ty­cz­na, w kwestii komu­nikacji z klien­tem, ponieważ częs­to wyobraże­nie o danej funkcjon­al­noś­ci jest inne z per­spek­ty­wy devel­opera i klien­ta. Dla devel­opera pod­kreślanie słów kluc­zowych w treś­ci może być ‘głupotą, którą doda się w 5 min­ut w ostate­cznej wer­sji UI’, pod­czas gdy dla klien­ta może to być kluc­zowy ele­ment tej funkcjon­al­noś­ci. Kry­te­ria te pozwala­ją także uniknąć dyskusji o treś­ci ‘a ja myślałem, że…‘O ile his­to­ria użytkown­i­ka pozostaw­ia spore pole do inter­pre­tacji, kry­te­ria powin­ny pre­cyzyjnie określać zakres prac real­i­zowanych w jej ramach.

Dostosowanie Scrum’a oraz antywzorce

Jed­nym z głównych założeń Scru­ma jest jego dopa­sowanie do potrzeb orga­ni­za­cji i zespołu. Każ­da fir­ma jest inna, podob­nie jak pro­jek­ty, które są real­i­zowane. Założe­nie, że moż­na  prowadz­ić różnorodne prace tak samo jest bard­zo ryzykowne i — najczęś­ciej — nieprawdzi­we. Dlat­ego Scrum nie narzu­ca żad­nego ele­men­tu, a jedynie ofer­u­je zestaw prak­tyk i narzędzi, które są pomoc­ne. Jed­nocześnie jed­nak są od siebie nieza­leżne. Wiele orga­ni­za­cji z sukce­sem wdraża tylko część pro­cesów, obser­wu­jąc poprawę efek­ty­wnoś­ci, a jed­nocześnie zachowu­jąc inne dzi­ała­nia czy narzędzia, dos­tosowane do ich pro­filu dzi­ałal­noś­ci.

Nieste­ty, niek­tórzy pro­jek­tan­ci, z niewiedzy lub lenist­wa, nie poświę­ca­ją wystar­cza­ją­co uwa­gi na poprawne wdroże­nie Scru­ma lub dos­tosowanie jego ele­men­tów. Prowadzi to do różnych anty­w­zor­ców, które omówimy dalej.

Antywzorzec: PM = SM

Zadzi­wia­ją­co częstą prak­tyką jest utożsami­an­ie roli Project Man­agera z rolą Scrum Mas­tera, pod­czas gdy są to zupełnie różne role i nie powin­ny być łąc­zone! Rolą PMa jest zapewnie­nie orga­ni­za­cyjnego zaplecza pro­jek­tu, środ­ków na jego real­iza­cję oraz pil­nowanie har­mono­gra­mu i celów. SM z kolei jest odpowiedzial­ny za pro­cesy Scru­mowe w zes­pole i ciągłe ich uspraw­ni­an­ie!

Trochę inną, choć mniej destruk­cyjną, for­mą tego anty­w­zor­ca jest prak­ty­ka w zes­pole, że SM inicju­je i prze­wodzi np. dzi­en­nym spotkan­iom. To może wynikać z niezrozu­mienia idei, ponieważ o ile SM może być inic­ja­torem i ‘kierown­ikiem’ takich spotkań, o tyle robi to jako członek zespołu. Jako SM jego rolą jest zapew­ni­an­ie, że te spotka­nia się odby­wa­ją, dają efekt i prowadzą do poprawy efek­ty­wnoś­ci, ale nie oznacza to, że musi nimi kierować.

Antywzorzec: Planowanie ‘osobowe’

Ta prak­ty­ka jest chy­ba najczęś­ciej popeł­ni­anym ‘przestępst­wem’ w ramach Scru­ma, i pole­ga ona na tym, że członkowie zespołu ‘rez­er­wu­ją’ pewne obszary sys­te­mu, sku­pi­a­jąc się tylko na nich i przy­dziela­ją sobie wszys­tkie związane z tym zada­nia i his­to­rie już na początku Sprintu. To oczy­wiś­cie upraszcza prace — pozwala skupić się tylko na wycinku — ale zaprzecza idei, która pole­ga na samoor­ga­ni­za­cji zespołu oraz wymi­an­ie wiedzy. Każ­da oso­ba w zes­pole powin­na być w stanie zająć się dowol­nym zadaniem z back­logu w dowol­nym momen­cie sprintu — opisana wyżej sytu­ac­ja częs­to prowadzi do sytu­acji w których obciąże­nie pracą w zes­pole jest nierównomierne, a wiedza sku­pi­ona w osobach zami­ast rozpros­zona w całym zes­pole.

Łat­wo też przewidzieć skut­ki nagłej nieobec­noś­ci człon­ka zespołu — czy to przez chorobę czy też z racji zmi­any pra­cy.

Najczęst­szym objawem takiego sposobu planowa­nia jest sytu­ac­ja, w której lin­ie poziome na tabl­i­cy sprintu są opisane osoba­mi (członka­mi zespołu), a nie his­to­ri­a­mi użytkown­i­ka.

Antywzorzec: Planowanie zadaniami

Pisanie his­torii użytkown­i­ka nie jest łatwe, ale jest kluc­zowe — tylko w ten sposób może­my opisać nie tylko funkcjon­al­ność, ale i kon­tekst oraz zakres określonej funkcjon­al­noś­ci.

Nieste­ty, ponieważ jest to czasochłon­ny i angażu­ją­cy pro­ces, dość łat­wo wpaść w pułap­kę planowa­nia zada­ni­a­mi — zami­ast pisa­nia his­torii użytkown­i­ka, pisa­nia zadań do real­iza­cji.

W określonych sytu­ac­jach posi­adanie konkret­nych zadań w back­logu może nie być prob­le­mem (np. zada­nia związane z kon­fig­u­racją środowiska czy rzecza­mi for­mal­ny­mi — choć częs­to moż­na je też zapisać w formie his­torii użytkown­i­ka), ale są to wyjąt­ki. Niemal zawsze, a już szczegól­nie w kon­tekś­cie funkcjon­al­noś­ci, his­to­rie użytkown­i­ka powin­ny być pod­sta­wową jed­nos­tką planowa­nia.

Dla przykładu porów­na­jmy dwa zapisy: “Jako księ­gowy firmy, chce osob­no zapisane poszczególne staw­ki VAT dla fak­tur, ponieważ w bilan­sie muszę je sumować odd­ziel­nie” oraz “Umożli­wić odd­zielne zapisy­wanie stawek VAT dla fak­tur”.

W pier­wszym przy­pad­ku jest jas­ny cel — jeśli uży­wana jest baza rela­cyj­na, nie zmieni to za bard­zo mod­elu danych, ale w przy­pad­ku prze­chowywa­nia danych w rozwiąza­ni­ach NoSQL infor­ma­c­ja, że celem jest ich sumowanie może znaczą­co wpłynąć na imple­men­tac­je. Dru­gi zapis z kolei moż­na zrozu­mieć jako osob­ne pole przy infor­ma­cji o fak­turze lub osob­ny widok do wprowadza­nia fak­tur i osob­ny do wprowadza­nia stawek VAT. Niby efekt ten sam, ale które rozwiązanie spowodu­je, że klient będzie korzys­tał z pro­duk­tu i przyniesie mu on wartość?

Antywzorzec: Pomijanie demo, sprinty bez wartości dodanej

Kole­jnym częstym błę­dem jest trak­towanie Sprint­ów jako abstrak­cyjnej jed­nos­t­ki cza­su, bez więk­szego znaczenia. Prowadzi to do sytu­acji, w której real­izu­je­my zada­nia niemożli­we do prezen­tacji klien­towi, a przez to niemożli­we do wery­fikacji. Aby zobra­zować prob­lem, przed­stawmy jak­iś wycinek sys­te­mu w postaci poniższego dia­gra­mu:

kontrolery

W myśl założeń Scrum’a, prace powin­niśmy podzielić ‘pio­nowo’ — tzn. w pier­wszym sprin­cie zre­al­i­zować widok 1, ser­wis 1 (lub jego część) i bazę danych 1 (lub jej część). W prak­tyce ode­jś­cie od reg­u­larnego Sprint review z udzi­ałem klien­ta prowadzi do dzie­le­nia pra­cy ‘poziomo’ — najpierw wszys­tkie ‘najniższe’ ele­men­ty, potem te o jeden krok wyżej, a na końcu wszys­tkie wido­ki. Tak, jest to łatwiejsze dla devel­opera, ale niesie za sobą znaczące prob­le­my:

  • błędy w ‘dol­nych’ ele­men­tach wykry­je­my dopiero po 3 iter­ac­jach, a koszt ich poprawy rośnie wykład­nic­zo z cza­sem
  • przez dwie iter­ac­je nie będziemy mieli kon­tak­tu z klien­tem, po czym zarzucimy go trze­ma funkcjon­al­noś­ci­a­mi, utrud­ni­a­jąc skupi­e­nie się na dopra­cow­a­niu każdej z nich

W efek­cie ryzyku­je­my poniesie­nie więk­szych nakładów pra­cy i dostar­cze­nie funkcjon­al­noś­ci, która nie odpowia­da potrze­bom klien­ta.

Antywzorzec: Częsta rotacja Scrum Mastera

Wiele zespołów rotu­je Scrum Mas­tera — wymieni­a­jąc ku temu różne powody. Samo w sobie nie jest to błę­dem czy prob­le­mem, ale takim się sta­je, jeśli rotac­ja następu­je zbyt częs­to. Pamię­ta­jmy, że rolą Scrum Mas­tera jest dban­ie o pro­cesy i ciągłe ich uspraw­ni­an­ie — zmi­ana oso­by odpowiedzial­nej może przeszkadzać we wdraża­niu zmi­an i pode­j­mowa­niu więk­szych inic­jatyw.

Co znaczy zbyt częs­to? To zależy m.in. od dłu­goś­ci sprint­ów, zgra­nia zespołu, czy pro­jek­tów — nie ma jed­noz­nacznej odpowiedzi na to pytanie. Warto jed­nak zas­tanow­ić się, co możesz zro­bić w okre­sie, kiedy jesteś SM oraz czego zro­bić się nie da — być może warto wydłużyć ten okres w Twoim zes­pole?

Antywzorzec: Scrum Scrum, i tylko Scrum

Skra­jnoś­ci są złe zawsze, i ma to miejsce także w przy­pad­ku Scru­ma — pamię­taj, że to tylko narzędzie, a nie panaceum na wszys­tkie prob­le­my. Cza­sem Scrum nie jest właś­ci­wym pode­jś­ciem, cza­sem nie wszys­tkie jego ele­men­ty pomogą w real­iza­cji celu, a przede wszys­tkim — zawsze jest to tylko środek, a nie cel sam w sobie.

Wdraża­jąc prak­ty­ki Scru­ma należy zawsze zapy­tać siebie i zespołu jak przełoży się to na sukces pro­jek­tu, w jaki sposób mu pomoże — wdrażanie prak­tyk Scru­ma dla samego fak­tu ich wdraża­nia jest w najlep­szym przy­pad­ku bezcelowe, a może wręcz zaszkodz­ić.

Więcej informacji, szkolenia i certyfikacje

Po więcej infor­ma­cji odsyłamy przede wszys­tkim do źródła — czyli orga­ni­za­cji Scrum Aliance i pub­likowanych przez nią mate­ri­ałów: http://scrum.org .

Orga­ni­za­c­ja ta prowadzi też cer­ty­fikację w różnych rolach (od członków zespołu, właś­ci­cieli pro­duk­tów aż po Scrum mas­terów: https://www.scrum.org/Assessments .

Scrum naw­iązu­je do zwin­nego sposobu real­iza­cji pro­jek­tów, dlat­ego niewąt­pli­wie warto zapoz­nać się z Man­i­festem Agile, który daje pod­waliny takiemu pode­jś­ciu.

Niedłu­go opub­liku­je­my także recen­zję książ­ki o Scru­mie, która mamy nadzieję nieco przy­bliży Ci ideę tej tech­ni­ki.

Podsumowanie

Jak widzisz, Scrum to nie tylko ‘stand-upy’ i sprinty, to filo­zofia real­iza­cji pro­jek­tów poprzez zmi­anę sposobu myśle­nia o relacji pomiędzy odbior­cą koń­cowym a zespołem. Z pewnoś­cią nie jest to rozwiązanie dla każdego, nie jest to też panaceum na wszys­tkie bolącz­ki pro­jek­tów, ale jest to warta rozważe­nia alter­naty­wa i potężne narzędzie dla każdego zespołu. Jeśli Twój zespół pracu­je w Scru­mie, zas­tanów się, czy fak­ty­cznie korzysta­cie ze wszys­t­kich jego dobrodziejstw, a jeśli nie — co zro­bić, żeby to zmienić.

  •  
  •  
  •  
  •  
  •