Költözés

Az oldal címe megváltozott. Kérek mindenkit, hogy mihamarabb írja át a címet kedvenc RSS-olvasójában:

• RSS-feed címe: http://feeds.feedburner.com/infokukac (Kommentek: http://feeds.feedburner.com/infokukaccomments )
• Az oldal címe: http://infokukac.com

Mindig van idő

Aki egyetemre, főiskolára járt, annak biztosan ismerős az a helyzet, amikor az ember ismeri a vizsga időpontját, és szépen kiszámolja, hogy naponta hány tételt kell megtanulni ahhoz, hogy a vizsgáig az összes sorra kerüljön. 

Igazából a tanulás elmarad, szépen telnek a napok, az ember pedig azzal nyugtatgatja magát: "nem baj, nem maradtam le még semmiről, a tervezett napi 2 helyett majd 3 tételt tanulok meg". Aztán pár nap múlva már 4-5-nél járunk, a vizsga előtt 2 nappal pedig tényleg rászánjuk magunkat, és elolvassuk együltő helyünkben az összes tételt. Jó esetben a vizsga sikerülni is szokott.

Valami hasonló a helyzet a projekt határidőkkel. Az elején még kényelmesen dolgozgatnak az emberek, aztán a határidő előtt megkezdődik a hajtás, felpörögnek az események. A végeredmény (jó esetben) pedig átadás lesz. 

Miben lenne más, ha pár nappal korábban lenne a határidő? Semmiben. Ugyanúgy elkészülne a feladat.

Ezt az elvet egy Parkinson nevű angol közgazdász is felismerte, és azóta Parkinson törvényének hívják (1955). Nevezetesen: "A munka addig terjeszkedik, hogy kitöltse a teljesítéséhez rendelkezésre álló időt."

Ha le akarunk fejleszteni egy adott funkcióhalmazt, és meghatározunk egy határidőt, akkor Parkinson törvénye - saját meglátásom szerint - azért működik, mert ahogy a határidő egyre közeledik, annál inkább kapnak szerepet a valódi prioritások. A valódi prioritások határozzák meg a tényleges értékeket, amelyektől sikeresek lehetünk. Még ha egy prioritásos feladaton dolgozunk is, annak az implementálását is sokféleképpen lehet elvégezni. A prioritásokat az implementáció közben is figyelembe lehet (kell) venni.

Rövid határidők

Nem véletlen, hogy krízishelyzet esetén, amikor a projektmenedzsmentet komolyabban is veszik, rövid határidőket szabnak. A rövid határidők segítenek abban, hogy egy-egy feladaton fókuszáltan dolgozhassunk. Nem "folyik szét" a munka a kezeink között.

A Scrum fix hosszúságú (1-4 hetes) sprintjei is azt garantálják, hogy rövid idő alatt a prioritásos feladatokon érjen el eredményeket a csapat.

Automatizált tesztek, refaktorálás

Mi szokott lenni az első számú ellenérv, kétely a unit-tesztekkel, integrációs tesztekkel, ill. a refaktorálással szemben? Az, hogy nincs idő rá. Ha valaki ilyet állít, az csak olyan lehet, akinek fogalma sincs arról, hogy mit jelentenek ezek a fogalmak a valóságban.

Itt van az ellenérvem velük szemben: ha a Parkinson törvénye működik, és kevesebb idő is elég ahhoz, hogy egy munkát megcsináljunk, akkor miért nem építjük be a szoftverfejlesztési folyamatunkba az automatizált tesztek írását? Ha gány a kód, miért nem szánunk arra időt, hogy rendbe rakjuk, hogy refaktoráljunk? Úgyis kész leszünk határidőre, és így legalább olyan lesz a kódunk, hogy:

• mások is megértik, 
• bármikor lehet benne változtatni, mert nem bonyolult,
• bármikor lehet benne változtatni, mert a tesztek mutatják, ha elrontottunk valamit.
  

...és ezzel összességében még több időt nyerünk.

Sok mindent lehet az időre és a határidőre fogni. A valóság viszont az, hogy pontosan arra van időnk, amire időt szánunk.

Mindig van idő.

Agilitás, prezentáció

Szombaton informatikatanároknak tartottam egy előadást a szoftverfejlesztésről. A célom az volt, hogy megismertessem őket azokkal a módszerekkel, amelyeket az iparban alkalmazunk, és felhívjam a figyelmet az agilis szoftverfejlesztésre. A prezentáció kb. 45p-ig tartott, érkezett jó pár kérdés is a végén. Úgy érzem, jól sikerült.

Ezúton osztom meg a prezentációt, hátha valaki még hasznát veszi. Természetesen szóban sokkal több minden elhangzott, mint ami az írásban található.

A mennyiség mindig üti a minőséget

Korábban már barátaim körében közzétettem Jeff Atwood-nak a Coding Horror c. blogjáról ezt a nagyszerű írást. Íme magyarul. Kicsit még tömörítettem rajta.

Jeff Atwood a cikkében egy könyvre hivatkozik. A könyvet David Bayles és Ted Orland írta, a címe: Art & Fear, Observations On The Perils (and Rewards) of Artmaking.

A könyv arról szól, hogy hogyan lehet a művészetet "megcsinálni". Mik az okai annak, ha sokszor nem jön össze, és milyen természetűek azok a felmerülő nehézségek, amelyek sok művészt megakadályoznak abban, hogy a művészetteremtés rögös útján célba érjen. Ebből a könyvből származik a következő történet:

A kerámiatanár egy nap bejelenti az osztálynak, hogy két csoportra osztja őket. A bal oldalon ülőket - mondja - csupán az alapján fogom osztályozni, hogy hány darabot dolgoznak ki, míg a jobb oldalon ülőket tisztán az alapján, hogy milyen az elkészített darab minősége. Az osztályozás módszere egyszerű: az utolsó órán a tanár behozza a fürdőszobamérlegét, és megméri a "mennyiségi" csoport által készített edényeket. Minden 20kg-os edény 5-öst kap, a 18kg-osok már csak 4-est s.í.t. A "minőségi" csoporttal szembeni elvárás az, hogy egyetlen edényt hozzanak, annak viszont tökéletesnek kell lennie ahhoz, hogy megkapják az 5-öst. 

Eljött az osztályozás ideje, és az eredmény meglepő lett: a legjobb minőségű munkákat mind az a csoport készítette, amelyet a mennyiségért osztályoztak. Az jött ki a dologból, hogy mialatt a "mennyiségi" csoport lázasan égette ki egymás után a különböző munkákat, és eközben tanult a hibáiból, a "minőségi" csoport leült, és a tökéletességről filozofálgatott, a végén pedig nem tudott többet felmutatni, mint a grandiózus elméleteit és egy darab élettelen agyagot.

A dolog tanulsága:

1. Fejezd be a filozofálgatást!

2. Írj sok szoftvert!

3. Tanulj a hibáidból! 

Ha nem írunk szoftvert, nem is tudunk belőle tanulni. Ahelyett, hogy azon agonizálunk, vajon a jó dolgot alkotjuk-e, helyette egyszerűen alkossuk meg! Ha nem működne a dolog, akkor folytassuk addig, amíg meg nem találjuk a megfelelő megoldást.

Certified ScrumMaster tréning beszámoló

2010. január 21-22-én ScrumMaster tréningen vettem részt. A tréninget Michael Vizdos tartotta, akitől megtudtuk, hogy az Agilis kiáltvány eredeti aláíróinak mindegyikével dolgozott már. Évek óta alkalmazza a Scrum-ot, az ő tréneri felkészítését Jeff Sutherland végezte, aki a Scrum kitalálója.

Résztvevők, helyszín, szervezők

A tréninget Kóspallagon, a Szent Orbán Hotelben tartották. Pontosabban Kóspallag közelében, ugyanis a hotel nem is lakott területen belül található, hanem a Duna-Ipoly nemzeti park erdejének egy olyan részén, ahová elvileg csak az erdészek és a hotel lakói hajthatnak be.

A tréninget az Agilis Szoftverfejlesztők Egyesületéből megismert Zsuffa Zsolt IT Kódex nevű cége szervezte. A tréning kb. 1000 EUR volt (+ szállás). 

Összesen 12 résztvevő jött el, ebből ketten voltunk, akiknek már volt tapasztalata a Scrum-mal. A többség a Scrum körüli hype következtében jött el abban a reményben, hogy a tréning után forradalmi változásokat fog tudni elérni saját cégénél és ügyfeleinél.

Mike amerikai, ezért az egész tréning (jórészt) angolul ment. Nem mondom, hogy nem voltak kisebb nyelvi problémák, de azért az egész hallgatói csapat jól alkalmazkodott ehhez a kényszerhez, és egy interaktív tréning valósulhatott meg. (Felüdülésképpen a tréningen néha egy-egy részt - magyarul - a Sprint Consulting cég vezetője, Bodó Árpád Zsolt is tartott.)

Az első nap

Mike rövid bemutatkozása után nekünk kellett a mellettünk ülőt bemutatni: hogy hívják, milyen cégtől jött, és milyen céllal jött el a tréningre. Én egyike voltam azon keveseknek, aki egyedül érkezett, úgyhogy rögtön össze is ismerkedtem a mellettem ülővel.

Az én érdeklődésem középpontjában az állt, hogy két év Scrum után rendszerezhessem saját ismereteimet. Mindenki egy kicsit a saját íze szerint értelmezi a Scrum-ot, ez alól én sem voltam kivétel. Kíváncsi voltam, mik azok, amik "rárakódtak" nálam az eredeti módszerre, és mi is valójában a vegytiszta Scrum. 

Az első nap első fele nem is a Scrum-ról szólt, hanem általában az agilitásról. Úgy gondolom, hogy ez egy kiváló ötlet, hiszen a Scrum lényege nem is a módszereinek összességében rejlik, hanem magának az agilitásnak a gyökereiben keresendő. A résztvevők kicsit kiszakadhattak a követelményelemzés - tervezés - implementálás - tesztelés vízesés modelljéből. Volt pl. egy olyan feladat, ahol Mike-ot, egy képzeletbeli IT vállalat vezetőjét kellett meggyőzni arról, hogy a 3 hónapos késésben lévő szoftverfejlesztési projektet, amely épp a követelményfelmérési fázison esett túl, át kell állítani agilis projektre :) Elég jól játszotta a szerepét, nem is sikerült :) ("Dehát itt vannak a dokumentációk! - és rámutatott egy tonna dokumentációra. - Ezt kell megcsinálni. Minden egyformán fontos és kritikus!")

Szó esett a projektmenedzsment bűvös háromszögéről, amelynek lényege, hogy egy projekt kényszerei a határidő, a szkóp és a költségek. Ha ezek mind fixek, ne is vergődjünk az agilitással. 

Volt egy jó kis játék. 12-en voltunk, ebből 6-nak főnököt, 6-nak beosztottat kellett játszania. Egy pár négyzetméteres részbe voltunk összeterelve, a főnökök a terület szélén álltak, a beosztottak valahol középen. Minden főnöknek a saját beosztottját kellett irányítania az előre, jobbra, balra parancsokkal úgy, hogy a beosztott mihamarabb megtegyen 60 lépést. Elég döcögősen ment a dolog, mert a beosztottak állandóan összeütköztek, és a főnökök nem voltak képesek elég hatékonyan irányítani őket. Ezzel szemben, amikor a játék második részében kizártuk a főnököket, és mindenki beosztott lett, és saját maga döntött, merre haladjon, elég hamar kialakult egy kör, ami mentén a teljes csapat együtt haladt egy irányban. A játék az önszerveződést szemléltette, ami az agilitásnak, ezen belül a Scrum-nak is az alapja. (A játék még tovább nehezedett. Lettek vakok a csapatban (ők jelentették a juniorokat), ill. időnként Mike is beállt középre, hogy akadályt képezzen.)

A lean is említésre került. Mintha egy kis élcet éreztem volna Mike hangjában: "a lean-esek általában elméletiesek". (Jól érzem, hogy az agilisok és lean-esek titkon egymásnak estek a világban?)

A nap második fele már a Scrum-ról szólt. Megismerhettük a teljes életciklust, a főbb fogalmakat és a ScrumMaster szerepét. 

A nap végén egy képzeletbeli történetet adott elő Mike. Te egy kiszolgáló vagy egy Mekiben. Este 11:55 perc van, éjfélkor zárás. Nincs vásárló, de valaki mégis betér az üzletbe, és kér egy BigMac menüt, Super Size menüben, egy ketchupot és egy fagyit. Az egész 2000 forintba kerül. Miközben fizetne az illető, kiderül, hogy csak 500 forint van nála. A főnök arra utasított korábban, hogy senki nem mehet el úgy, hogy ne vásároljon valamit. A vásárló viszont a teljes megrendelést akarja. Mit teszel? A megoldás az, hogy nincs megoldás. A történet tanulsága, hogy ne vállaljuk be a projekteket, ha reménytelen, annak ellenére sem, hogy a főnökeink, tulajdonosaink azt akarják. (Azért valljuk be, alkamazottként ezt kicsit nehéz megtenni. Mindenesetre tiltakozhatunk.)

A második nap

Tovább tisztázódtak a felelősségek a Scrum-on belül, miért felelős a csapat, miért felelős a Scrummaster és miért a Product Owner. Rengeteg szimulációs játékot és gyakorlatot tartottunk.

Volt pl. egy játék, ahol sprinttervezéseket és sprinteket kellett tartani. Mindezt rövid idő alatt (pl. 6-7 perc jutott egy-egy tervezésre, ill. sprintre). Nagyon érdekesek voltak a teljesítendő sztorik, mert abszolut nem a szoftverfejlesztéshez kötődtek. Például ilyen és ehhez hasonló sztorik szerepeltek a product backlog-ban:

• 10 papírhajó hajtogatása,
• négyemeletes ház építése kártyából,
• dobjunk annyiszor két kockával, hogy végül három alkalommal legyen párunk,
• megtalálni egy kártyapakliban a hiányzó kártyát,
• rajzoljunk Miki egeret,
• stb.

Több tanulsága is volt a játéknak:

• a szoftverfejlesztés során se tudjuk megmondani, hogy az egyes feladatok mennyi ráfordítást igényelnek, de egymáshoz képest viszonylag jól tudjuk viszonyítani őket (relatív pontozás),
• ahogy telnek a sprintek, a csapat összeszokik, és hatékonyabban végzi el a munkát (tervezés, végrehajtás),
• mivel egyszer váratlanul felcseréltek csapatok között csapattagokat, ezért egy pillanatra a csapatok teljesítménye megtorpant (nem érdemes/szabad ezt csinálni a gyakorlatban),
• product owner-eket is kicseréték egyszer: ekkor is összeomlott a csapat, mert a korábbihoz volt hozzászokva, és mert az új product owner sem ismerte még az új csapatot.

Tanulságok

A tréningen elég sok közös feladatot kellett csinálnunk. Egy csapatépítővel is felért ez a két nap :) Ez mindenképpen jót tett a hangulatnak, és egy kicsit mindenki megnyílhatott.

Látszik, hogy Mike nem kezdő a szakmában. Elég sok blogot olvasok az agilitásról, Scrum-ról, a kritikus énem minden nem odaillő szóra felfigyel. Mike esetében nem érzékeltem ehhez hasonlót, ennek egy példája pl., hogy a Scrum-ot soha nem hívta módszertannak a kétnapos tréning során, helyette a keretrendszer (framework) szót alkalmazta. 

Azt is megemlítette, hogy valószínűleg a legtöbben nem fogják alkalmazni a Scrum-ot, vagy bele buknak. A Scrum nem alkalmazható a megfelelő szoftverfejlesztési (elsősorban eXtreme Programming) technikák nélkül sem.

Sok minden átjött az ilyen kis apróságokban is, ha az ember figyelt. Valószínűleg a hallgatóság zöme ezt nem is érzékelte.

A magam részéről úgy gondolom, megérte elmenni. (Igaz, a munkáltatóm fizette a részvételi díjat.) Megismerhettem, hogy pontosan mik a Scrum-beli szereplők elvi felelősségei (mi, ugye, a saját környezetünkhöz adaptáltuk), és láthattam, hogy egyes dolgokban (pl. mi szerepeljen a product backlog-ban, milyen hosszú legyen egy sprint stb.) hogyan vélekednek mások. Az is kiderült számomra következményként, hogy a Scrum-on belül is vannak "ellentmondások", egy kicsit mindenki a saját szája íze szerint értelmezi a szabályokat. Végülis a Scrum tényleg egy keretrendszer, mindenkinek magának kell testreszabnia azt (a projektre, ügyfélre, vállalatra, csapatra).

Az ehhez hasonló tréningeket végülis a nemzetközi ScrumAlliance szervezet intézi. Mint megtudtuk, mindenki, aki a kétnapos tréningen részt vett, egy teszt kitöltése után - az eredménytől függetlenül - automatikusan megkapja a Certified Scrummaster jogosítványt. Ennek tanulsága számomra az, hogy ne higgyünk feltétlenül annak, aki egy ilyen papírt lobogtat. (Azért ha megkapom a tanúsítványt, én is kirakom a logót a blogomra :D)

Kemény pénzekért, valós tapasztalatokért további minősítések érhetőek el a ScrumAlliance-nál. (Egy év tapasztalat után elvileg már pályázható a Certified Scrum Practitioner cím, ha korábban résztvettünk egy Certified ScrumMaster vagy Certified Product Owner tréningen.)

Sokat lehet elmélkedni a Scrum-ról, agilitásról. Nem baj, ha ilyen tanfolyamon veszünk részt. Megfelelő irodalmat és blogokat is olvasnunk kell. Sokkal fontosabb azonban annak a felismerése, hogy ezen eszközök csupán támogatást nyújtanak, eredményeket csak akkor érhetünk el, ha saját magunk próbálkozunk, és élesben nézzük meg, valójában mire is vagyunk képesek. 

Próbálkozz - figyelj - tanulj!

Fluent interface

Kb. 2 éve olvastam először a fluent interface-ekről. Akkor nagyon megtetszett, és azóta is folyamatosan alkalmazom a módszert. Nem is gondoltam akkor, hogy Java-ban (vagy C#-ban) a legalapvetőbb nyelvi eszközökkel ilyen kifejező kódot lehet írni.

Az alapprobléma

Az eredeti probléma abban áll, hogy hogyan valósítsuk meg viszonylag sok paraméter átadását a kódban. A legalapvetőbb megoldás a standard módszer:

void doRegistration(String firstName, 

                    String lastName, 

                    String email, 

                    String password, 

                    String country, 

                    String city, 

                    String streetAddress1, 

                    String streetAddress2, 

                    String postalCode, 

                    boolean male, 

                    int age, 

                    boolean wantsNews) {

// ...

}

Jelen esetben 12 paraméter átadásáról van szó. Mondanom sem kell, hogy kínszevedés kliensként az ilyen metódust hívni, hiszen ahhoz, hogy tudjam, mit kell éppen átadni, az IDE-t kell segítségül hívnom. Ráadásul a keletkező kódot ilyen esetben borzasztó utólag is olvasni, hiszen nem rí le róla, hogy a híváskor milyen paraméterket, milyen sorrendben is adok át.

Martin Fowler Refactoring c. könyvében az Introduce Parameter Object c. minta próbál egyszerűsíteni a problémán, és azt javasolja, hogy rakjuk egy objektumba (osztályba) ezeket a paramétereket, majd ezt az objektumot adjuk át.

void doRegistration(RegistrationData data) {

// ...

}

Sajnos, a gond még mindig ugyanaz, hiszen magát a RegistrationData típusú objektumot is fel kell töltenünk ugyanezekkel a paraméterekkel. Megoldás lenne a setter-ek alkalmazása, de őszintén szólva, ha ilyet meglátok a kódban, egy kisebb agyvérzést kapok. Mivel mások által sem javasolt az objektumok kívülről történő piszkálása (sérti az egységbezárás elvét), célszerű más megoldást keresni, és itt jönnek a fluent interface-ek a képbe.

A megoldás

Kliens oldalon a következő a használandó kód (pl. egy tesztben):

RegistrationData registrationData = new RegistrationData()

    .withName("Béla", "Kovács")

    .withAccount("bela.kovacs@gmail.com", "pass1234")

    .withCountry("Hungary")

    .withCity("Budapest")

    .withAddress("Kossuth Lajos utca 13.", ""),

    .withPostalCode("1234"),

    .withMale(true)

    .withAge(20)

    .withWantsNews(false);

doRegistration(registrationData);

A RegistrationData osztály implementációja a következő:

public class RegistrationData {

    private String firstName;

    private String lastName;

    // további mezők

    RegistrationData() {

    }

    

    RegistrationData withName(String firstName, String lastName) {

        this.firstName = firstName;

        this.lastName = lastName;

        return this;

    }

    // további with-ek

    String getFirstName() {

        return firstName;

    }

    // további getter-ek (ha szükségesek egyáltalán)

}

A módszer előnye az, hogy amikor olvassuk a kódot, látszik, hogy a hívás pillanatában milyen paraméterek kapják a megfelelő értékeket. Ezért is kapta a fluent nevet a minta, hiszen folyamatosan, gondolkozás nélkül olvashatjuk a kódot, "folyékonyan", mintha természetes nyelven lenne írva. 

Látható az is, hogy nem muszáj egy az egyben átkonvertálni minden paramétert egy with... hívássá, azok csoportosíthatóak nagyobb, jól nevesíthető tömbökbe. Például a firstName-et és lastName-et együtt a withName... metódussal olvassuk be. (Viszont egy ilyen with... hívásba sem szabad sok paramétert bezsúfolni, mert akkor ugyanott tartunk, ahonnan elindultunk.)

A módszer egyetlen hátránya, hogy - a standard, sokparaméteres átadással szemben - nem kényszeríti ki az összes paraméter átadását. Az eredeti példa pl. nem fordul addig, amíg át nem adunk 12 akármilyen paramétert (a típusoknak azért egyezniük kell). Ezt azzal szokták orvosolni, hogy a paraméterek átadása után hívnak egy validate(), void visszatérési értékű metódust, amely elszáll, ha valamilyen paraméter nem lett kitöltve. Másik módszer a probléma megoldására, ha teszteket írunk. Amúgy - megsúgom - ha kihagyunk véletlenül egy paramétert, azt rövid időn belül úgyis észrevesszük, és korrigálhatunk, tehát nem célszerű emiatt túlságosan aggódni. Amit viszont cserébe kapunk, az a nagyfokú olvashatóság.

A sprinttervezés (Scrum-sorozat 3/2. rész)

Az előző post kicsit hosszúra sikeredett, viszont megismerhettük a tervezés legfontosabb eszközeit: az előkészítést, a sztoripont fogalmát, a fókuszfaktort, a kapacitástervezést és a Planning Poker-t. Minden együtt van ahhoz, hogy a tervezés teljes forgatókönyvével tisztában lehessünk. 

A tervezés forgatókönyve 

0. Készüljünk elő: aktualizáljuk a Product Backlog-ot, készüljünk fel a sztorikból! 

1. Tervezzük meg a csapat kapacitását: határozzuk meg, hogy az elkövetkezendő sprint alatt hány sztoripontot tudunk teljesíteni! (Ld. kapacitástervezés) 

2. Vegyük a legfontosabb sztorit! 

3. Bontsuk le közösen feladatokra! 

4. Becsüljük meg az egyes feladatok méretét! 

5. Menjünk vissza a 2. lépésre, amíg tudunk újabb sztorit választani, ami még befér a sprintbe. 

A tervezést rendszerint a Scrummaster moderálja. (Nálunk a meeting request-eket is ő küldi ki a tervezésre.) 

Előfeltétel, hogy a Product Owner priorizálja a Product Backlog-ot a tervezésre. A csapat ezt ne bírálja felül, fogadja el, hogy ez a prioritás. A csapat meg azt állapítja meg, hogy a rögzített hosszúságú sprintben mennyi sztorit tud elkészíteni. 

Feladatokra bontás 

A Product Backlog-ból a sztorikat prioritás szerint vesszük elő. 

Először mindenkinek meg kell értenie, hogy miről szól a sztori. (A mi esetünkben ennek lehetőségét a korábban elkészített rövid, érthető dokumentáció, és az üzleti szakértő (Albert) jelenléte biztosítja.) Ha ez megvan, akkor a csapat közösen lebontja a sztorit kisebb feladatokra. 

Pár dolog: 

• A kártyákkal történő becslést (Planning Poker) akkor célszerű elvégezni, amikor az aktuális sztori feladatokra bontásán túl vagyunk (mindenki egyszerre emeli a kártyát!). 
• Magukat a feladatokat becsüljük, nem a teljes sztorit. 
• Nagyon fontos, hogy akkor vegyünk véglegesnek egy becslést, ha abban a csapat közösen egyetért. Ha véleménykülönbségek vannak, akkor azokat ütköztetni kell (Scrummaster feladata), meg kell vitatni, és konszenzusra kell jutni. 

A feladatokra bontás több eredménnyel is jár: 

• a csapat végiggondolja a sztori megvalósításának menetét, 
• ezáltal még jobban megismeri a problémát (esetleg újabb kérdések is felszínre kerülnek), 
• a kisebb méretű feladatokkal történő becslés pontosabbá teheti a teljes sztori becslését, 
• ha kisebb méretűek az elvégzendő feladatok, akkor jobban követhetővé válik sprint közben a haladás. (Megszűnik a napokig, hetekig tartó "80-90%-ban kész vagyok, már csak..." probléma.) 

Az alábbiakban összefoglalom azokat a tapasztalatokat, amiket a feladatokra bontásnál szedtünk össze. Figyelem, ezek nem Scrum-szabályok, hanem a saját megfigyeléseink és gyakorlatunk! 

Ne válasszuk szét a munkafázisokat! 

Példa: ha a sztori egy webshop alkalmazásnál a "Regisztráció", akkor ne legyen két külön feladat az, hogy "Regisztráció fejlesztése" és "Regisztráció unit test írás", hanem állapodjon meg a csapat, hogy egy sztori/feladat elvégzéséhez a unit-test-ek megírása is szükséges.

Mivel kisméretű a csapat (max. 7-9 fő), ezért nem szükséges a munkafázisok szerinti szájbarágos feladatrészletezés. Mindenki tudja, hogy mi a feladata. Ha mégis így teszünk, rengeteg függőséget viszünk be a feladatokba, ráadásul drasztikusan megemelkedik a feladatok száma, ami Micro Management-et eredményez. 

Sok kicsi sokra megy! 

Ha túl sok az apró feladat, akkor torzíthatják a becslést. 

Ha túl sok a 0-s sztoripontú feladat, akkor ezek összege is 0. A valóságban ezek valószínűleg a 0-nál sokkal több idő alatt fognak elkészülni. 

A másik eset, hogy ha a sok apró feladatot 0.5 sztoripontra túlbecsüljük (ez kb. fél-1 napos időtávot jelent a biorobot pontrendszerben), akkor a sok ilyen apró feladat együttesen tetemes ráfordítást jelent, pedig valójában lehet, hogy csak 1 nap kellene a fejlesztésükhöz.

Nem baj, ha egy feladat nem egységnyi ideig tart 

Ugye milyen jó lenne, ha egységnyi idejű feladataink lennének (mondjuk, amik egy napig tartanak)? Ha valaki egy nap elkezd egy feladatot, a következő napra be is fejezné. Nagyon könnyen követhető lenne a haladás sprint közben. Ez sajnos a valóságtól elrugaszkodott feltételezés, nem árt azzal tisztában lennünk, hogy ez nem fog menni. Nem lehet úgy megerőszakolni a feladatokra bontást, hogy ez teljesüljön, és ezzel ráadásul elősegítjük a Micro Management-et. 

Törekedni azonban lehet arra, hogy a feladatokra bontás során egy-egy feladat rövid idő alatt teljesíthető legyen (1-2 nap).

Felejtsük el az alkalmazás rétegeit! 

Egy sztorit ne az alapján bontsuk feladatokra, hogy az alkalmazásban milyen rétegek vannak. 

Pl. egyik feladat az X funkcióhoz felhasználói felület készítés, a másik ennek szerveroldalának elkészítése! 

Itt már át is megyünk Micro Management-be. Kétszer annyi kártyánk lenne sprint közben a falon (ha még több rétegre bontanánk, akkor még több), amitől nehézkesebbé válik a haladás áttekintése, és előtérbe kerülhetnek a 0-0.5 sztoripontos feladatok (ld. fenn). 

Azért nem kell a rétegekkel foglalkoznunk, mert legtöbbször az egyes rétegeket nem lehet függetlenül fejleszteni, közös munkára van szükség. Pl. a felhasználó felület helyességét nehéz tesztelni a meglévő szerver oldal nélkül, és a kettő közötti interfészt is közösen kell kialakítani. 

Ne adott emberhez tervezzük a feladatokat! 

Úgy gondolkozzunk, hogy nem tudjuk még, ki fogja csinálni a feladatot! (Merthogy sprint közben fog kiderülni.) Mivel elviekben keresztfunkcionális a csapatunk, és nem rétegek szerint vágjuk a feladatokat, ez teljesíthető.

Ne foglalkozzunk a függőségekkel! 

Nem kell a feladatok közötti függőséggel törődni. Miért? Mert kevesen vagyunk a csapatban, egy sprint rövid ideig tart. Talán a csapat a sprint közben is el tudja dönteni, hogy milyen sorrendben célszerű haladni. (Micro Management, ismerős?)

Nem baj, ha egy feladatot nem egy ember végez 

Az lenne az ideális, ha a sprint közben számonkérhetőek lennének az egyes emberek, hogy hogyan állnak a saját választott feladatukkal. Ha ketten dolgoznak egy feladaton, akkor már nem egyértelmű, hogy ki az, aki miatt nem halad a feladat elvégzése. 

Az, hogy egy feladaton egyszerre csak egy ember dolgozhat, sajnos, ismételten Micro Management-hez vezet, mert a legtöbbször rétegek vagy munkafázisok szerint szerveznénk a feladatokat. Ezért célszerű belenyugodni abba, hogy nincs azzal baj, ha egy feladaton többen is dolgoznak. 

How-to-demo írása 

A Scrum egyik szabálya, hogy az elkészített feladatokat mindenki saját maga demózza az ügyfélnek (vagy a Product Owner-nek). Ezért - annak ellenére, hogy a csapat közösen tervez, fejleszt stb. -, minden fejlesztőn ott a személyes felelősség. Ha nem veszi komolyan a munkát, akkor beég az ügyfél előtt a demón. 

Ahhoz, hogy ne csússzanak félre a dolgok (egyértelmű legyen, hogy mi a fejlesztendő funkció, valamint hogy hogyan lehet azt bemutatni az ügyfél előtt), meg kell határozni, hogy hogyan demózható egy-egy elkészítendő feladat. Ezt nevezik "How-to-demo"-nak. 

Valakik azt javasolják, hogy tervezés közben határozzuk meg, hogy az egyes sztorikat (esetleg feladatokat) hogyan lehet majd demózni. Ez egyfajta specifikáció a fejlesztőnek a sprint idejére, másrészről pedig elfogadási kritérium (Acceptance Criteria). Mi nem ezt a módszert alkalmazzuk, több okból is. 

• A mi esetünkben nagyon sok ideig tartana, ha egy-egy forgatókönyvet megírnánk, és a tervezés akár több napig is eltartana (annyira komplexek a sztorik). 
• Megadjuk a lehetőséget arra, hogy ha az implementáció során a modellben valamilyen problémával szembesülünk, akkor korrigálhassuk a forgatókönyvet. Úgy gondoljuk, hogy nem érdemes túlságosan korán specifikálni a feladatot (még a sprint előtti tervezés is több esetben korainak bizonyult!). Helyette hagyjuk, hogy a fejlesztő sprint közben írja meg a forgatókönyvet. Miután elkezdi "felszívni", beleásni magát a sztoriba, sokkal jobban átlátja a lehetőségeket, a lehetséges ellentmondásokat, és így jobb forgatókönyv tud készülni. 

A How-to-demo-t egyébként egy rövid leírásnak kell elképzelni, amit a csapat tagjai megértenek. Nem kell olyan részletekig kidolgozni, hogy az az ügyfél számára is átadható legyen (nekik ott van a demó). 

Egy How-to-demo, amit mi írtunk éles projektben. Egy teljes iratkezelési folyamatot mutat be. A TEST előtag jelzi, hogy az adott ponton ellenőrizhető a meglévő eredmény.  How-to-demo: Visszavárt irat érkeztése ügyvitelre leadott ügyiratba  szaboz új iratot készít (1 irattári, 1 tartalék példány), új ügybe  szaboz a tartalékpéldányt visszavárólag elküldi  szaboz az ügyiratot leadja ügyviteli irodára  TEST irodavezetőnél le lehet szűrni az ügyviteli irodán lévő ügyiratokra, a leadott ügyirat megjelenik.  irodavezető visszavártan érkezteti az elküldött iratot.  TEST az irat az ügyvitelen marad  irodavezető kiadja az ügyiratot az ügyviteli irodáról szaboa-nak  TEST szaboa tud iratot készíteni az ügyiratba

Sprint Backlog 

A Product Backlog tartalmazza az összes hátralévő sztorit. A Sprint Backlog ehhez képest azon sztorikat tartalmazza, amik beférnek az aktuális sprintbe. Nem csupán a sztorik neve, hanem a lebontott feladatok és azok becslései is szerepelnek benne. 

A táblázatban a következő adatok találhatók:

• A oszlop: sztori azonosítója, 
• B oszlop: sztori megnevezése, 
• C oszlop: a lebontott feladat neve, 
• D oszlop: prioritás (a sztorié a product backlog alapján, az összes feladat ezt örökli), 
• E oszlop: a feladatra becsült sztoripontok száma, 
• F oszlop: a taszk egyedi azonosítója a sprinten belül,
• 1. sor: hányadik sprintnél járunk, mikor van a demó,
• 2. sor: a sprint célja - mindig kitaláljuk, hogy miért is van ez a sprint. Pár szóban megfogalmazzuk a célját. Elvégre nem árt, ha tudja az egész csapat, hogy mi is a célja az aktuális munkának. 

Timeboxing 

A Scrum egyik alapvetése, hogy szigorú időkereteket (timebox) alkalmaz. A legalapvetőbb időkeret magának a sprintnek az időtartamára vonatkozik: ha egy sprint kéthetes, akkor egy nappal sem tart tovább. A timeboxing-ot lehet alkalmazni magára a tervezésre is: ha a Scrummaster 2 órát szán a tervezésre, akkor az egy perccel se lehet hosszabb. A csapatnak meg kell tanulnia, hogy hogyan tervezzen hatékonyan, mint ahogy azt is meg kell tanulnia, hogy hogyan szállítsa a sprintre betervezett sztorikat. 

Habár az irodalomban szerepel a timeboxing alkalmazása a tervezésre, bevallom, mi ezt a szabályt nem alkalmaztuk. Nekünk nem voltak terjengősek a tervezések, ha a 2 óra után még kellett fél óra, akkor fél órával tovább tartottuk. A tervezés szigorú timeboxing-ja csupán egy módszer: ha a csapat nem képes megfelelően működni, akkor korlátok közé szorítjuk. Ezáltal megtanulhatja hatékonyan felhasználni a rendelkezésre álló időt. 

Végezetül jöjjön egy képzeletbeli sprinttervezés párbeszéd részlete. 

A fiktív sprinttervezés résztvevői az előző részben említett csapat tagjai: Albert (az üzleti szakértő), Jónás (junior fejlesztő), Döme (junior fejlesztő), Iván (senior fejlesztő), Zalán (senior fejlesztő), Csubi (Scrummaster). [A fejlesztendő termék egy banki webes rendszer. Éppen megtörtént a kapacitástervezés az aktuális sprintre.] Csubi: Az első sztori a product backlog-ból az "Átutalás". Albert, mesélnél róla egy kicsit? Albert: Ezt valószínűleg mindannyian ismeritek már. Egyszerűen arról van szó, hogy egy ügyfél egy meghatározott összeget átutal a saját bankszámlájáról egy másik bankszámlára. Miután bevitte az adatokat, kellene egy ellenőrző képernyő, ahol lecsekkolhatja a bevitt adatokat. Az egészet majd később lehessen időzíteni is, de az egy másik sztori. [Itt Albert arra utal, hogy ez is egy lefejlesztendő funkció, és benne is van a Product Backlog-ban, de kisebb prioritással, és majd egyszer meg kell azt is csinálni.] Csubi: Elég ennyi infó a feladatokra bontáshoz?  Csubi körbenéz. Mindenki bólint. Csubi: Rendben. Érdemes szétbontani feladatokra? Döme [junior fejlesztő, nemrég érkezett a projektbe]: Lehetne az első az, hogy a funkció kiválasztása a főképernyőről. [Zalánnak felcsillan a szeme, már várta ezt a magas labdát.] Zalán: Ezt mindig úgy csináljuk, hogy beleértjük a feladatba. Tehát magától értetődik, hogy ahhoz, hogy egy funkció működjön, ahhoz kell lenni valahol egy linknek vagy gombnak, amivel a funkció elindítható. Ha valaki csinálja az átutalás felhasználói felületét, akkor felrakja ezt a gombot a főképernyőre. [Döme elbizonytalanodik.] Döme: Ja, bocs, nem tudtam. Csubi: Semmi gond. Akkor mi legyen az első feladat? Jónás: Szerintem legyen az adatok bevitele, utána jöhetne az átutalás. Iván: Várj, az ellenőrzés ne maradjon ki. Csubi: Tehát akkor: adatok megadása, ellenőrzés, átutalás. Jó így? [Senki nem válaszol, mindenki üveges csirkeszemekkel néz maga elé.] Csubi: Na, mi az? Nem túl fitt a csapat így kora reggel! Döme: Tegnap volt egy kis pókerparty, a végére kicsit sok lett a vodka. [Mindenki röhög egyet magában. Csubi is elmosolyodik.] Csubi: Ja, értem már. Na, jó, akkor úgy veszem, hogy mindenki igent mondott. Be is írom az Excelbe. [Egyetért a csapat. Csubi kezeli az Excelt: beírja a Sprint backlog-ba az első három feladatot.] Csubi: Rendben. Becsülhetünk? Az első feladat az adatok megadása. Ki mennyit becsül? [A kártyák a kezek ügyébe kerülnek, és elindul a gondolkozás. Valaki a kezében tartja az egész paklit. Az első kártyát hátra teszi, majd a következőt megint, és addig folytatja, amíg meg nem találja a kívánt pontszámú lapot. Iván mindig fejjel lefelé tartja őket az asztalon: bal oldalon a 0-ás kártya, utána következik jobbra növekvő sorrendben a többi: 0.5, 1, 2, 3, 5. A többi kártyát nem is rakja maga elé, mert olyan nagyságú feladat még sosem volt, és valószínűleg nem is lesz. Különben az már több sztorivá vagy még kisebb feladattá lenne bontható. Mindenki a kezébe fog egy kártyát, és közben a többieket figyeli, hogy vergődnek-e még a kártya kiválasztásán. Döme, akinek ez az első sprintje, meglehetősen hamar kiválasztotta a saját kártyáját, és mosolyog magában.] Csubi: Ok. Kérem a téteket! [Két 2-es, egy 1-es, és egy ?-t mutatnak fel a csapattagok. A ?-et Döme mutatja fel, nem igazán tudja még, hogy hány sztoripontot érhet a feladat.] Csubi: Na, látom, nincs egyetértés. Jónás! Te miért mutatsz 1-et? Jónás: Szerintem nem nehéz a feladat, felrakjuk a főképernyőre az új linket, aztán megjelenik egy sima űrlap, viszonylag kevés adattal. Zalán: Hát, azért szerintem kell a 2 nap. Meg kell írni a unit- és integrációs teszteket is. Jónás: Ó tényleg, mindig elfelejtem! Csubi: Rendben. Akkor lehet 2?  [Mindenki bólint. Döme elfogadja a csapat döntését, és arra gondol, vajon mikor jut el ő is oda, hogy képes legyen jól becsülni. A csapat folytatja a következő feladattal.]