Luboš Račanský
17.5.2011

Jaké problémy vyřeší Scrum



Jako konzultant mám tu výhodu, že se můžu poučit nejen z chyb svých ale i cizích. Na následujících řádcích bych chtěl ukázat problémy a chyby, se kterými jsem se setkal a které by vyřešil Scrum a agilní metodiky obecně. Co je Scrum se dočtete na wiki, ale pro pochopení tohoto článku o Scrumu vlastně nepotřebujete téměř nic vědět.

Závazek týmu

Ve Scrumu se za výsledky práce zavazuje tým (v anglické literatuře commitment). Pokud vám někdo zadá práci, určí nerealistický termín a trvá na něm, co se stane? Rezignujete na výsledek. Ve Scrumu odhady tvoří tým a jako tým jdete s kůží na trh. (Tedy vlastně se šunkou podle bajky The Chicken and the Pig)

Decentralizace

Překvapuje mě, že v době distribuovaných systému je projektové řízení stále spíše centralizované. Formální hierarchie je důležitá, ale nesmí být na obtíž. Můžete se inspirovat tím, jak to dělají mariňáci viz kniha Corps Business: The 30 Management Principles of the U.S. Marines, které se možná budu podrobněji věnovat v některém z dalším příspěvků. Poměrně často vídám tým-leadera zavaleného dotazováním, co má ten či onen právě teď dělat. Nejednou končí ve spirále micromanagementu. Scrum tým žádného dispečera nepotřebuje.

Levá ruka ví co dělá pravá

Obzvláště v korporátních firmách, ale nejen tam, váznou informace o tom, co kdo dělá (propracovanému systémy reportování navzdory). Navíc se můžete setkat s lidmi, kteří nic nedělají, ale přesto působí důležitě, zaneprázdněně a nepostradatelně (šašky si z toho tropí kniha Lenosti, buď pozdravena!) Scrum předepisuje tzv. Stand-up meeting (česky jsem to ještě neslyšel, ale snad schůzka na stojáka). Jedná se o pravidelné jednodenní schůzky nikoliv mítinky. Trvají nanejvýš 15 minut a stojí se při nich (zabraňuje to rozkecávání). Každý řekne, co dělal včera, jestli má nějaký problém a co bude dělat dnes. Nezachází se při tom do detailů. To ovšem neznamená, že se problémy zametají pod koberec. Jen se nastolená témata následně probírají pouze s těmi, kteří si na stand-upu uvědomili, že se jich týkají.

Osobní jednání

Agilní metodiky nenabádají k anarchii a k pálení dokumentace. Nicméně dostali jste někdy desítky stran dlouhou analýzu s ač možná nevyřčeným sdělením: „Programuj a neobtěžuj mě s otázkami!“? Než se tým zaváže k práci, musí rozumět tomu, co je její náplní. Včetně toho, kdy bude výsledek považován za hotový (v anglické literatuře level of done).

Už to skoro bude

Zajímá vašeho projektového manažera, na kolik procent je úkol splněn? A všimli jste si, že posledních 20% funkcionality trvá 80% procent času (syndrom už to skoro bude)? Ve Scrumu je důležité, zda je user story hotová, ne na kolik procent. Scrum dodává jen plně funkční, otestované a akceptované řešení (nikoliv polovičatě zpracované user story).

Časový rámec

Scrum časově ohraničuje (v anglické literatuře timeboxing) jednotlivé cykly vývoje (sprinty, iterace) na přibližně jeden až čtyři týdny. Žádné několikaměsíční rozplizlé období. Na průšvihy se musí přijít včas a ne je tutlat (v anlické literaře je pro to pěkný termín fail early). Pevně daný rozsah práce v iteraci je rovněž účinné nárazníkové pásmo již zmiňovaného micromanagementu.

Zpětná vazba

Kdekdo se zaklíná zpětnou vazbou, ale praktické využití obvykle vázne. V armádě je briefing a debriefing běžnou záležitostí. Softwarové inženýrství je mladý obor a tak znovuobjevuje kolo. Scrum zpětnou vazbu systematicky zařazuje do procesu jako Sprint Review a Sprint Retrospective.

Závěr

Scrum není zázračné, bezstarostné a bezúdržbové řešení pro každou situaci, firmu a projekt. Nicméně nabízí recept k léčbě bolestí, které byly v článku zmíněny. Podělte se v komentářích o své zkušenosti se Scrumem a dalšími agilními metodikami. Všem, kteří se Scrumem začínají ale i těm kteří ho již používají, držím palce!

Vaše emailová adresa nebude zveřejněna

Komentáře

Děkujeme za váš komentář
Další
  • Martin

    Troska vlastnych skusenosti z aktualneho integracneho projektu pre jednu svajciarsku banku, kde su agilnymi metodikami posadnuti - je to dobry pristup, a kazdy tim/firma by ho mala aspon vyskusat. Akurat by som nemal obrovske ocakavania, je to nastroj a jeho uzitok zavisi na sposobe pouzitia. Rozhodne by som nesiel pristupom "kod je najlepsia dokumentacia", hlavne v pripade, ked sa ten kod vytvara. Malo by byt jedno centralne miesto, ktore by malo obsahovat vsetky business pravidla, ciele apod. Na forme az tak nezalezi. Bol by som opatrny s iteraciami, musia byt navrhnute zmysluplne, ked su prilis kratke a tym nenapreduje tak rychlo, tak to akurat zbytocne zdrzuje. Celkovo by som nezahadzoval stare postupy, ak funguju ale s citom ich obohatil. Su ludia, ktorych by takyto prechod slusne frustroval, a kludne by kvoli tomu vymenili zamestnavatela. A bez ludi IT firma je len prazdne logo.

  • Mates Rak

    Nejvetsi vyhodou SCRUMu, ktera dodava tak casto pomijeny prvek kontroly preteceni trojkombinace scope/cas/penize, je podle me predevsim institut Product Ownera, ktery se primo podili pred kazdym sprintem (iteraci) na sestave polozek v planu. Prave angazovanost Product ownera (=klienta) na vyvoji, je vec, ktera u SCRUMu nese nejvetsi dil na tom, ze je tahle metodologie tak chvalena.

  • U nás říkáme stand-up meetingům "kolečko".

  • Lukáš Matějka

    Souhlasím s myšlenkou, že je IT mladý obor a že se někdy snaží znovuobjevit kolo. Mám občas pocit, že Scrum je brán jako něco co vše zachrání, zvláště pak když nefungují klasické přístupy projektového managementu. V mnoha případech se vezme Scrum pouze jako nástroj, který se použije a ono to ne vždy úplně dobře funguje. Dle mého názoru je to hodně postaveno na soft-skillových dovednostech zejména pak na vedení týmu.

  • YF

    fascinuje me to neustale prirovnavani k armade - nejsem zadnej zelenomozek a jejich prirucky me fakt nezajimaj - jestli nekoho fascinuje bejt robot tak at je - pokud mam rad svou praci a sem schopnej premyslet - tak nepotrebuju zadnej scrum ani nic jinyho a domluvu proste nenahradite diktatem - byla by moje nocni mura mit firmu plnou takovychdle robotu a uz vubec by me nebavilo v ni pracovat

  • Luboš Račanský

    To YF: Ani mně by se nelíbilo pracovat v utopistické společnosti, kterou jste vylíčil. Člověk by měl hodně číst, hlavně to, s čím nesouhlasí. Právě ti mariňáci jsou totiž cvičení k tomu, aby se obešli v případě potřeby i bez velení. A ano, komunikace je důležitá a Scrum (jedna z mnoha možností) jí dává rámec. Jaký je Váš způsob projektového vedení, můžete se podělit o své zkušenosti? Dost by mě to zajímalo.

  • BorecNakonec

    Dřív jsem metodiky typu XP, Scrum atd. hltal a docela jsem tím byl nadšený a chtěl jsem v takto řízených týmech pracovat, protože jako student jsem při sbírání praxe narážel ve firmách na typickej bordel a neschopnost (který dost často padal na hlavy nebohýho studenta). Pak jsem zase zažil druhý extrém a to buzeraci RUPem v Unicornu a teď po pár letech praxe v IT jsem došel k názoru, že ideální je tým schopných pohodářů. Jakmile vyvstane potřeba zavádět něco jako denní schůzování a neustálé kontroly a to podle nějaké metodiky, tak je to jen důkaz předchozího selhání a amatérského vedení projektu. Smyslem zavádění těchto formalit je totiž především neschopnost team-leaderů, manažerů a to třeba skrz několik úrovní. Čili je lepší dosazovat schopné motivované lidi, kteří si umí pohlídat selským rozumem ty pod sebou. Tím ale neříkám, že ty metodiky jsou špatný. Člověk tam najde dost inspirace, vyzobe si něco tu a něco tam a obohatí se a namixuje to přesně podle potřeb projektu, členů týmu atd. Nenazývá to vznešeným jménem pouze DOBŘE VEDE tým a obklopuje se dobře pracujícími lidmi, které ocení a těch špatných se pokud možno zbavuje.

  • Pavel

    Zdravím všechny! Možná pro některé IT firmy může být systém scrum zajímavý, ale já jsem se s ním seznámil co by klient a vůbec spokojený nejsem. Vadí mi, že nevím, jaká bude konečná cena webu, práce je pomalá a komunikace s firmou špatná. Vadí mi, že absolutně nemůžu napřímo komunikovat s grafikem, ale musím mluvit s člověkem, který je určený pro komunikaci - ten pak info předá jakémusi šéfovi a teprve ten to postoupí grafikovi. Celý proces je zdlouhavý a dochází k informačním šumům. Někdy se mi stane, že požadavek musím opakovat víckrát. Sprint trvá 3 týdny, během procesu nesmím do práce zasahovat (je naplánovaná dopředu) a výsledek jejich práce dostanu 1 den před osobní schůzkou s týmem IT firmy. Takže musím být den před schůzkou k dispozici na netu a pokud najdu chyby v jejich práci, tak už většinou nemají čas to hned opravit, proto se oprava přesouvá do dalšího sprintu. Na mé maily během sprintu odpovídají minimálně nebo vůbec. Takže pro mě zlatá klasika, kde jsem mohl komunikovat přímo s člověkem, který mi udělal celý web. Bylo to levnější, rychlejší a komunikace efektivnější.

  • Luboš Račanský

    @Pavel Je mi líto, že máte se Scrumem špatnou zkušenost, ale podle mého názoru jste spíš než na špatnou metodiku narazil na špatnou firmu, které Scrum používá spíš jako zaklínadlo. Souhlasím, že zákazník potřebuje vědět rámcovou cenu. My mu ovšem se Scrumem dáváme možnost skončit dříve, odložit některá rozhodnutí na později... Grafik je analytik designu, takže je chyba, že jste s ním nemohl jednat osobně. Onen „šéf“ je určen pro centrální sběr požadavků, aby Vás odstínil od jednotlivých programátorů a onen šum odstranil. Úlohy Vám měli dávat ke schválení už během sprintu, aby mohli na demu (sprint review) prezentovat funkční aplikaci bez chyb. Pokud Vám sprinty připadaly dlouhé, trval bych na jejich zkrácení. Přeji Vám, ať se příští výběr dodavatele povede lépe.

  • Pavel

    Luboši, dík za radu. Já jsem s grafikem osobně mluvil 3x na krátké schůzce, která je každé 3 týdny, ale nemohl jsem se ním zkontaktovat během jeho tvorby grafiky a loga. Připomínky jsem musel napsat komunikátorovi, ten to probral s týmem a řekl grafikovi. Předložili mi 1 grafický návrh v jedné barvě. Když jsem chtěl pozměnit barvy, tak se cítili se dotčeně, že tohle je nejlepší barevná kombinace. Nakonec grafik vymyslel ještě jiné barvy, které jsem odsouhlasil. Logo mi poslali jen jedno, to jsem také odsouhlasil, ale když jsem jim sdělil, že ho budu potřebovat i na vizitky a plakáty, tak byli zaskočení, že ho mají jen na web, že nevěděli, že ho chci pro tisk. Že pokud budu chtít i logo v křivkách, tak musím připlatit (částka: logo pouze na webu 7.500 Kč a pokud chci logo v křivkách, tak příplatek dalších 7.500,-). Příplatek jsem odmítnul, takže logo mám jen na webu. A chyby ve spritech oni řeší tím, že tvrdí, že to je normální, že chyby prostě jsou a budou a že se odstraní v dalším sprintu. Takže si připadám, že platím v dalším sprintu to, co se opravuje z předchozího sprintu a co už jsem platil. Hezké svátky!