Agilný projekt = Tehly a piesok

Produkty sú pri klasickom projektovom riadení pripravené na začiatku veľmi podrobne. Projektový manažér plánuje projekt od začiatku tak, aby v ňom boli všetky úlohy, často až do najmenších detailov. A aj vrátane “bezpečnostnej vaty 10-15%”. Robí to v dobrej viere, že projekt je naplánovaný, odhadnuteľný a realizovateľný. Detailné plánovanie sa však v praxi zrúti ako domček z kariet v momente keď sa požiadavky zmenia. A to znamená “čoskoro a vždy“.

Agilný projekt má samozrejme tie isté úskalia. No agilita dovoľuje flexibilitu rozsahu požiadaviek, čo by produktový vlastník mal využiť. Využiť aj tým, že backlog bude obsahovať vlastnosti rôznej náročnosti (veľkosti).

Prediktívny aj agilný plán majú tie isté východiská, no agilný projekt je  realizovaný odlišným spôsobom:

  • Agilný projekt má síce dohodnuté dátumy dodania, no obsah dodávky je možné zmeniť. V tradičnom projekte sú väčšinou pevne dohodnuté dátumy, rozsah a často aj rozpočet. To znemožňuje pružne reagovať na zmeny.
  • Plán vždy obsahuje veľké požiadavky, tzv. eposy (v anglickej literatúre sa používa slovo epics). Produktového vlastníka zaujímajú práve eposy vytvárané na základe vízie produktu. Príklad: Správa zákazníkov, Správa produktov, Prehľady.
  • Plán obsahuje niekoľko malých, no konkrétnych požiadaviek, ktoré sa majú dokončiť v jednej alebo dvoch nasledujúcich iteráciách. Nie pre celý plán, len pre niekoľko iterácií! Tieto menšie požiadavky, stories, vznikajú iteratívnym a/alebo inkrementálnym rozdelením eposu. Príklad: Pridanie nového zákazníka, Pridanie kontroly údajov do formulára, Mesačný výkaz účtu

Agilný plán by mal obsahovať  “tehly aj piesok”. Eposy (tehly), ktoré tvoria základ aplikácie a stories (piesok), ktoré tvoria detaily.

Produktový vlastník tak má čas pripravovať eposy dopredu, zatiaľ čo tím má čas konkrétne požiadavky (stories) implementovať a dodávať.

Toto je základ dobrého agilného projektového plánu. Ako ale určíme, ktoré eposy potrebujeme skonkretizovať na stories a kedy?

Čo majú spoločné agilné metódy a kuchynský budík?

pomodoro.techniqueMožno ste už mali tú príležitosť zažiť naozaj funkčný Scrum. Prechádzate sa po miestnosti, kde sedí tím a vidíte, že jeho práca je ako dobre namazaný stroj. Na burndown charte je jasne vidieť, že to ide so sprintom dole z kopca, vývojári komunikujú, zákazník spolupracuje. Proste paráda. A potom si sadnete za svoj stôl a pozriete sa na tú hromadu práce, ktorú vám treba robiť. Dokumenty, ktoré treba spripomienkovať, články, ktoré ste chceli preštudovať a dopísať ten mail, ku ktorému sa neviete prinútiť. Možno si v takú chvíľu pomyslíte, aké by to bolo super, keby ste aj pracovali tak plynulo a efektívne. Aké by to bolo super, keby existoval Scrum pre jedného človeka. No. On možno aj naozaj existuje. Hovoria mu Pomodoro Technique.

Pomodoro je technika, ktorú pravdepodobne vymyslel Francessco Cirillo a jej hlavným účelom bolo udržať vaše sústredenie na to, čo práve robíte. Už to samo o sebe je dostatočný krok vpred, ale technika bola ďalej vylepšovaná, až sa z nej stal systém na riadenie času (time-management). Pomodoro technika má mechanické srdce, ktoré udiera v intervale presne jednej sekundy. Je to totiž kuchynský budík v tvare paradajky, ktorý odmeriava váš čas, počas ktoré sa máte sústrediť. Po 25 minútach si môžete dopriať 5 minútovú prestávku (dôležité je robiť čokoľvek iné, čo nesúvisí s predtým vykonávanou prácou) a potom si dať ďalšie pomodoro. Po štyroch pomodorách máte nárok na polhodinovú prestávku. Ak počas pomodora dokončíte úlohu zo zoznamu, škrtnete ju a ďalšie pomodoro venujete ďalšej položke. Podstatné je, že počas pomodora robíte len jednu vec, pre ktorú bolo pomodoro vyhradené a vyrušenie eliminujete podľa možnosti na čo najmenšiu mieru.

Možno zatiaľ nie je jasné, čo má pomodoro s agilnými metódami. Tak poďme ďalej. Zoznam úloh, ktoré pomocou pomodora máte spracovať (tzv. Today List), si plánujete každé ráno z takzvaného Activity List, kde máte všetky potenciálne úlohy. Čokoľvek, čo vás cez deň vyruší, si zapíšete do jedného z tých zoznamov podľa toho, aké je to súrne. A teraz tá zaujímavejšia časť. Pri plánovaní zoznamu pre daný deň odhadujete koľko pomodor vám daná činnosť zaberie a zo štatistík, ktoré si evidujete, viete koľko pomodor za deň približne stihnete, takže viete čo si pre daný deň máte naplánovať. Na konci každého dňa okrem toho robíte retrospektívu o tom, ako presne sa vám podarilo úlohy odhadnúť, koľko ste toho stihli, koľko ste mali vyrušení a podobne. Ok. A teraz poďme prekladať do reči Scrumu.

Každé ráno si z backlogu vyberiem do releasu úlohy, ktoré by som mal v tento deň stihnúť. Urobím to na základe odhadu, koľko sprintov mi bude trvať vykonanie úlohy a koľko sprintov priemerne stihnem za deň. Následne spustím sériu sprintov. Počas sprintov nemením na čom pracujem. Keď sprint skončí, oddýchnem, prehodnotím, čo by som mal robiť ďalší sprint a spustím ho. Na konci releasu robím retrospektívu, aby som vyhodnotil svoju úspešnosť v odhadoch aj samotnej práci. Rozdiel medzi pomodorom a Scrumom je často krát len v použitom slovníku.

Tie metódy sú si tak podobné, že si viem predstaviť, že pomodoro je metóda, ku ktorej by sa dospelo používaním Scrumu na riadenie práce jedného človeka a jeho postupným prispôsobovaním. Z tejto podobnosti vyplývajú 2 zásadné výhody. Prvá výhoda je, že ak poznáte jednu z týchto dvoch metód, tú druhú pochopíte veľmi rýchlo. Druhá výhoda je, že rôzne techniky, postupy a vylepšenia pre jednu môžu byť aplikovateľné pre druhú.

Myšlienka o tejto podobnosti nie je tak úplne moja. Vysvetlenie pomodora s občasnými odkazmi na Scrum môžete nájsť v knihe Pomodoro Technique Illustrated od Steffana Nöteberga. Je to jedna z kníh o pomodore a podľa môjho názoru jedna z tých lepších. Ak by sa vám dostala do ruky, tak sa neľakajte obrázkov, ktoré vyzerajú, že ich kreslil žiak základnej školy (v skutočnosti to bol autor). Cieľom obrázkov je sprostredkovať ideu (jeden obrázok = jedna idea) a to sa podľa mňa darí. Autor vás postupne prevedie od dôvodov, prečo sa vôbec pomodorom zaoberať, cez jeho princípy, až po rôzne špeciálne vylepšenia a prípady použitia.

Scrum a pomodoro sú len iné obaly pre tie isté princípy. Každopádne nemusí byť pomodoro to jediné, čo sa vie vykľuť zo stretu sveta agilného riadenia a time managementu. Ak máte vlastné skúsenosti s používaním agilných metód na riadenie vlastnej práce, podeľte sa o ne…

Agile@Slovakia meetup v Bratislave

Pozývame do Bratislavy všetkých, ktorí  praktizujú Agile, aby ho vysvetlili tým, ktorí ho praktizovať chcú. Všetkých, ktorí sa chcú o Agile porozprávať a spoznať aj ďalších.

Kedy: Pondelok 21.11.2011, 18:00
Kde: Kafe Nervosa, Zámocka 30, Bratislava, Mapa
Registrácia: Email:  dusankocurek@hotmail.com
Facebook: http://www.facebook.com/event.php?eid=297934896902236
LinkedIn: http://events.linkedin.com/Agile-Slovakia-Meetup/pub/843842

Viac informácii ako to prebiehalo

Témy

Na našich meetupoch môže hovoriť každý. Privítame prezentáciu Vašich skúsenosti a vedomostí. Téma prezentácie môže byť akákoľvek týkajúca sa agilných postupov, nových postupov v projektovom manažmente, samoorganizácii tímu alebo  iba jednoducho Vašej histórie adaptácie Agile.

Michal Truban, WebSupport.sk

Scrum vo WebSupport.sk

Eva Kišoňová, Siemens

Agilný set-up agilného projektu

Roman Pieron, InterWay s.r.o.

Feature team vs. Support team

majky tkacik Marián Tkáčik, ScrumDesk s.r.o.

Getting Things Done a-alebo Scrum

LadislavGazo Ladislav Gazo, Seges s.r.o.

Ako sme zistili, že asi robíme Scrum

Prezentácia by mala byť v rozsahu 15 minút. Nevyžaduje si veľkú prípravu, stačí niekoľko stránok.

Registrácia prezentujúceho

Tému Vašej  prezentácie spolu s fotografiou, menom spoločnosti a krátkou biografiou na dusankocurek@hotmail.com.

REGISTRÁCIA JE UZAVRETÁ.

Ďakujeme za Vašu pdoporu.

P.S.

Ďakujeme Igorovi (@ipavelek) za pomoc s organizáciou meetupu.

Ružové Prekvapenie o Motivácii

Daniel H. Pink – Drive, The Surprising Truth About What Motivates Us

pinkDrive

Už dlhšiu dobu sa zaoberám otázkou, ktorá by sa dala v krátkosti zhrnúť do vety “Ako správne motivovať agílny tím ?”. Dosť dlho som hľadal odpoveď hlavne na finančnú stránku motivovania ‘dospelého ‘ tímu, myslím bonusy a iné finančné nástroje. Naposledy som sa ju pokúšal hľadať medzi účastníkmi konferencie ALE2011 v Berlíne, kde som od viacerých ľudí počul ako odpoveď : “Dan Pink – Drive“. Konečne som sa k tej knihe dostal a tu sú moje postrehy bezprostredne po dočítaní.
Pre tých, čo by hľadali odpoveď na otázku okolo používania finančných nástrojov vopred avizujem, že Dan Pink má v tom jasno : Plať toľko aby otázka peňazí nebola na stole.

Ale aj tak je kniha skvelá.

Kniha samotná sa skaldá z troch častí. Jej nosnou myšlienkou je rozdiel medzi tým, čo veda pozná a business prostredie robí.

1. Nový operačný systém
Úvodná časť začína opisom rôznych experimentov (už z rokov 1949 a 1960 ), ktorých účel bol detekovať účinok vonkajšej motivácie na sledovaných jedincov. Ako inak s prekvapivým výsledkom.
Pink veľmi zaujímavo opisuje sociálne prostredie ako operačný systém, v ktorom právo a ekonomika je akoby interface vrstvou nad  sadou protokolov, inštrukcií a predpokladov toho, ako svet funguje. A ako každý operačný systém, aj ten náš má verzie, v čase sa, ako všetci veríme, vylepšujúce. Vrátane problémov so inkompatibilitou. Náš názor na to, ako veci fungujú potrebuje čas od času upgrade. A ten čas je tu.
Veľmi podnetnou kapitolou je Sedem dôvodov, prečo cukor a bič nefunguje. Jednoduchá motivačná metóda vychádzajúca z predpokladu že je potrebné odmeňovať správne chovanie a trestať nesprávne v mnohých prípadoch vedie k tomu, že vo výsledku často dostávame menej toho čo chceme, viac toho čo nechceme a ako bonus neetické chovanie a potlačenú kreativitu. Zároveň  ale vysvetľuje, kedy takáto priamočiara motivácia (ak-potom) môže prinášať výsledky.

V závere prvej časti autor definuje dva typy  správania: a)Typ X – správanie podmienené hlavne vonkajšími faktormi a odmenami ku ktorým vedie aktivita. Oproti tomu b) Typ I – správanie reagujúce viac na vnútorné uspokojenie z aktivity samotnej.  A áno, b) je správne.  Pozitívny záver je, že Typom I sa nerodíme, ale sa ním stávame.

2. Tri elementy
V druhej, kľúčovej časti knihy  sú rozobraté 3 hlavné motivátory. Autonómia, Majstrovstvo a Účel.
Autonómia riadiť si veci po svojom, zdokonaľovanie a snaha byť v niečom naozaj dobrý a v neposlednom rade robiť niečo čo má  (vyšší/širší) zmysel je pre väčšinu ľudí viac ako tie veci, za ktoré si “štestí nekoupíš”.

3. Toolkit pre subjekty Typu I
Tretia časť knihy, predstavuje návod pre jednotlivcov, rodičov ale aj organizácie ako prebudiť vlastnú motiváciu a ako motivovať iných. Nie je to teória, je to konkrétny zoznam užitočných praktík. Za všetky mňa zaujali – predtým kým pôjdete spať si položte otázku : Bol som dnes (v čomkoľvek) aspoň o trochu lepší ako včera ? , alebo – zostavte a udržujte zoznam vecí, činností, ktoré NEbudete robiť.
Pre organizácie sa vyzdvihuje potreba vyčleniť čas na aktivity ‘mimo oficiálny plán’.

Kniha v závere obsahuje veľmi užitočný abstract, takže pre tých, čo sa im nechce čítať, alebo si len chcú pripomenúť dôležité myšlienky, stačí prečítať tých 6 strán. Ale pre serióznych záujemcov o myšlienky z tejto knihy, ktorí si ťažko nájdu čas na prečítanie radšej odporúčam pozrieť toto krátke video

http://www.youtube.com/watch?v=u6XAPnuFjJc (10min).

K dispozícii už je aj slovenský preklad “Čo nás poháňa, Prekvapivá pravda o tom čo nás motivuje a ženie vpred”
alebo český preklad  s názvom “Pohon”

O vlastnosti, ktorú nikto nepotrebuje

Produkovať a pridávať vlastnosti nie je len slovenské…

Produkty boli dlho tvorené s dôrazom na pridávanie novej funkčnosti tak, aby spoločnosť poskytla užívateľom v nových verziách viac a viac. Tento prístup trval pomerne dlho, no začiatkom 21. storočia sa situácia mení.

Používatelia si najviac vážia čas. Potrebujú jednoduché aplikácie, ktoré poskytujú funkčnosť priamo pod prst. Kontextovo. A s príchodom mobilných zariadení sa takýmto aplikáciám darí viac a viac. Doba, kedy panel nástrojov v aplikácii bol prepchaný je dávno preč. Dnes sú v móde veľké ikony, dobrý dizajn aplikácie a hlavne prehľadnosť.

Mimochodom, skúste odpovedať na otázku:

Predstavte si aplikáciu, ktorú používate denne.

Koľko percent vlastností v nej obsiahnutej NEpoužívate?

Odpoveď na túto otázku sa snažil pred niekoľkými rokmi nájsť Scott Ambler zo spoločnosti IBM.

A výsledok? Veľmi pravdepodobne taký ako ste odpovedali aj Vy sami. Tak ako väčšina ľudí na našich školeniach.

Tento výsledok je mrazivý ak si uvedomíte čo všetko vývoj nepoužívaných vlastností znamená. Koľko ľudskej energie sa v podstate vyhodí von oknom. Resp. uloží na disk :).

V tomto obrázku je skrytá odpoveď na komentáre k predchádzajúcim článkom série prečo treba papierik s požiadavkou roztrhať.

Pretože práve v tých 80% vlastností, ktoré nie sú používané, sa skrýva úspora času, úsilia ľudí a samozrejme peňazí.

Tento princíp je známy aj pod anglickou skratkou YAGNI – (you ain’t gonna need it). Nebudete to potrebovať.

Otázkou je ale KTO určí vlastnosti z množiny 20%? A tu nastupuje do procesu vývoja Zákazník. Zákazník, ktorý vie prečo vlastnosť potrebuje, kedy ju potrebuje a vie, nakoľko si vlastnosť cení.

Pretože hodnota vlastnosti je v Agile hlavným atribútom pre určenie priority, poradia:

  • Pretože najviac cenené vlastnosti dodané na trh skôr ako konkurencia znamenajú pre spoločnosť návrat investícií a skorý zisk.
  • Pretože v tom tkvie umenie produktového vlastníka, ktorý zákazníkovi pomôže určiť hodnoty a priority. Pomôže formulovať požiadavky pre vývojový tím.

Pred pár dňami som sa zúčastnil StartUp Campu v Košiciach. Pre mňa najzaujímavejšie zistenie bolo, ako málo sa slovenské spoločnosti a startupy venujú tomu, pre koho tvoria aplikácie, čo je potenciálnym trhom a čo ten trh skutočne chce. Naopak, venujú sa technológiám a nadšene rozprávajú o HTML5, serveroch, službách.

Nevieme kto bude aplikáciu používať, no chceme robiť radšej marketing pre podporu predaja. Hmmm, predaj, ale KOMU?

Konferencia LESS2011

LESSS je sieťou ľudí, ktorý pravidelne organizujú konferenice o Lean a Agilnom produktovom vývoji. Tento rok má LESS2011 za jasný cieľ zameranie sa na manažment inovácií a transformáciu organizácií.

Hlavné prezentácie prednesú Lean špecialisti ako Peter Middleton a Jams Sutton, ale aj propagátor radikálneho manažmentu Steven Denning a reprezentant najslubnejšieho prístupu k financovaniu projektov a stratégii: Bjarte Bogsnes.

Agile@Slovakia sa po dohode  s organizátormi LESS podarilo získať zľavu 100 Euro  na vstupom s použitím  zľavového kódu.

Kedy: 30.10. – 2.11.2011

Kde: Clarion Hotel, Štokholm, Švédsko

Program: http://less2011.leanssc.org/wp-content/uploads/2011/08/less-2011-conference-schedule.pdf

Registrácia:  http://less2011.leanssc.org/register/

Kód:  AGILESLOVAKIACOMMUNITY


Agile@Slovakia Meetup v Žiline!

Organizácia

Ďalšie mesto, do ktorého prinesieme agile, je Žilina.

Pozývame všetkých, ktorí Agile praktizujú, aby ho vysvetlili tým, ktorí ho praktizovať chcú.  Viac informácii ako to prebiehalo v máji na Meetupe v Košiciach je na http://agile.sk/?p=514http://agile.sk/?p=520.

Kedy: Pondelok 17.10.2011, 18:00

Miesto: Pizzeria Campari, http://www.camparipizza.sk/kontakt/, mapa
Registrácia: Pošlite email na dusankocurek@hotmail.com.

Témy meetupu

Jiri DubskyJiří Dubský, COOPEX Soft, Považská Bystrica

Kritické miesta pri zavádzaní Scrumu v praxi (historky starého zbrojnoša)

Radacovsky_TiborTibor Radačovský, Ness KDC, Košice

Team.changeDevProcess(flow = “waterfall2agile”, environment = “distributed”)

Kocurek_Dusan Dušan Kocúrek

Ako nezbabrať agilný projekt

Príbehy používateľov v praxi

user.story.appliedObčas sa vyskytne kniha, ktorá mi nedá pokoj, kým si ju neprečítam. Jednu chvíľu o nej niekto hovorí na konferencii, potom na ňu nájdem odkaz v inej knihe alebo sa objaví v nejakom TOP rebríčku. Jednoducho si začnem hovoriť, že to všetko nemôže byť náhoda, a rozhodnem si tú knihu prečítať. Podobné to bolo aj s knihou User Story Applied od Mike Cohn-a. Keď sa mi dostala do rúk, všimol som si, že je zo série kníh „A Kent Beck Signature Book“. Hlavou mi preletelo: “Hm. Keď Kent Beck podpíše Mike Cohn-a, tak to som vážne zvedavý, čo to bude.“

User Story Applied neostáva nič dlžná svojmu názvu, pretože teóriu okolo techniky používania User Story rozoberá pomerne podrobne. Nie je to kniha pre ľudí, ktorí nepoznajú agilné metódy, pretože aj keď obsahuje dodatok popisujúci extrémne programovanie, nie je jej cieľom vysvetľovať základné princípy. Všetko sa krúti okolo User Story a práce s nimi.

Hneď v prvej časti je rozoberaná zaujímavá myšlienka. User Story nie je len tá kartička s popisom, ktorú máte zavesenú niekde na stene alebo uloženú v elektronickej podobne. Mike tvrdí, že User Story sa skladá z troch časti:

1.       krátkeho popisu (to je tá už spomínaná kartička),

2.       konverzácií počas vývoja,

3.       akceptačných kritérií.

Čiže rozhovory medzi zákazníkom a vývojárom sú neoddeliteľnou súčasťou User Story.  Čo inak znamená, že kým nie je hotová úloha, nie je hotová ani User Story – porovnajte to s klasickým postupom, kde zber požiadaviek musí byť ukončený pred ďalšími fázami vývoja. V tomto prípade kartička doslova vystupuje len ako pripomienka toho, že sa o tom ešte treba rozprávať. V prvej kapitole knihy sú ďalej rozoberané príbuzné témy ako vlastnosti správnej User Story, techniky na modelovanie User Roles, ako správne písať akceptačné testy alebo rôzne typy User proxies (nič sa nevyrovná skutočnému zákazníkovi).

Nasledujúca kapitola je o odhadoch a plánovaní. To, že sú v knihe zahrnuté aj tieto témy, je logické. Čo mi však vadilo, je rozsah tejto kapitoly, ktorý predstavuje približne tretinu knihy. Hlavne ak uvážim, že od rovnakého autora existuje kniha Agile Estimation and Planning ktorá sa tomu plne venuje (a v oboch knihách sú prezentované rovnaké princípy). Kapitola obsahuje rôzne postupy a techniky na odhadovanie User Story v Story points, a tiež návody ako plánovať release a iteráciu.

Po odbočke k plánovaniu sa v poslednej kapitole vracia Mike späť k samotným User Story a preberá rôzne špecifické témy ako: „smrad“ zlej User Story, prečo User Story nie je Use Case a v čom je rozdiel alebo ako sa pri plánovaní vysporiadať s nefunkcionálnymi požiadavkami a chybami. Zaujímavé je, že User Story môže pokaziť aj vývojár. Napríklad takým zlatokovaním  – Goldplating (zlatokovanie je, ak vývojár svojvoľne pridáva rôzne super cool vylepšenia, ktoré ale zákazník nikdy nechcel – viac: wikipedia ). To len potvrdzuje to, že User Story je v tejto knihe chápaná nie len ako dokumentácia, ale aj ako časť procesu vývoja. V zostávajúcej časti kapitoly sa Mike ešte dotkne obľúbenej dilemy: je lepší softvér alebo papier (jedna z otázok, na ktorú asi nikdy nebude existovať jednoduchá odpoveď) a v jej úplnom závere sa dá nájsť 40 stranový príklad vytvorenia User Roles, User Stories a naplánovania Releas-u.

Na otázku, či sa oplatí túto knihu čítať, by som odpovedal protiotázkou: „Je váš zákazník spoluhráč, alebo protihráč?“. Ak váš zákazník patrí do skupiny, s ktorým sa ťažko spolupracuje, mohlo by sa stať, že keď sa po prečítaní tejto knihy pozriete do backlogu, tak zistíte, že veľa z tých požiadaviek vlastne nie sú User Story. Prípadne po prečítaní kapitoly o „smradoch“ zistíte, že tie vaše majú vážne pachové nedostatky. V takom prípade čítanie knihy môže byť frustrujúce. Ak však máte zákazníka, ktorý na túto hru pristúpil, potom si túto knihu kúpte alebo požičajte a prečítajte. Ak už máte používať User Story, je dobré im rozumieť.

Webinar Základy Scrumu, Mike Vizdos už zajtra

SNAG-0016

Už zajtra,  29. Septembra, bude Mike Vizdos vysvetľovať základy Scrumu prostredníctvom webinára. Okrem základov sa veľká časť webinára bude venovať otázkam. Školenie bude v anglickom jazyku.

Nenechajte si ujsť túto príležitosť opýtať sa na Vaše problémy jedného z najlepších trénerov Agile.

Webinár je sponzorovaný spoločnosťou ScrumDesk. Vás tak bude  stáť iba hodinu Vášho času.

Registrácia: https://www1.gotomeeting.com/register/844020585