2007. július 21., szombat

Agile-scrum, vagy amit akartok.

A címhez kiegészítésképpen - ahogyan mi akarjuk!
Nos itt többféle dolgot fogok érintőlegesen megfogalmazni, meg várhatóan összekeveredni. Egyelőre nem kerestem a témába vágó magyar szakirodalmat, így elképzelhető, hogy bizonyos dolgokat "félrefordítok".

Amikor még kissrác voltam és iskolában tanultam dolgokat - tudom nem vittem túlzásba, nade - na azokból a vízesés modell meg a spirálos diagramra emlékszem (ez a kettő nagyjából egybevág) ami nagyjából hasonló az összes többi mérnöki iparágban alkalmazott "fejlesztési" módszerhez: 1. a pénzesek kitalálnak valamit amit meg szeretnének csináltatni, hogy még több pénzhez jussanak 2. az elemzők kitalálják, dokumentálják a követelményeket 3. a tervezők megtervezik a felépítést lerjazolják, dokumentálják 4. a fejlesztől elkészítik a terméket 5. a tesztelők letesztelik az egészet és ha minden szép és minden jó akkor 6. a felhasználók elkezdik használni és fizetni a termékért: na innentől fogva folyik a pénz feltéve, hogy a termék jó. (vagy a marketing :)
Ez a folyamat a legapróbb dolgok esetén is sok időbe telik. Fontos szempont, hogy az egyes lépések között csak közvetlen, minimális visszacsatolás van, a fejlesztő tulajdonképpen nem beszél az elemzőkkel, csak a tervezővel és tőle is csak kérdez. Ha bárkinek gondja van az előző lépés kimenetével: vissza kell lépni arra a szintre, ahol a hiba-probléma felmerült és módosítani annak a lépésnek végdokumentumát.
Ezzel a módszertannal több probléma van, legalábbis szerintem (mások szerint is, de ezeket ragadtam ki):
Elsősorban az, hogy nem mindenki egy csodálatos elme, tehát biztos hogy legalább egy-két visszalépés lesz a folyamatban (minden lépcsőnél) Rengeteg idő megy el újrakitalálással, újraelemzéssel, újratervezéssel, újrakivitelezéssel. (mellékszálként jegyzem meg, hogy a pénzesek is szeretnek változtatni az ötleteiken) ((általában a projekt vége felé ennek a valószínűsége növekszik))
Másodsorban az információ lefelé folyik (vízesés), egyrészt nehéz másrészt drága felkiabálni, másrészt az egyes dokumentumok szentírásként vannak kezelve, és ennek tetejébe még amolyan hosszúpasszal kerül a kerítés túloldalára (amolyan nesze itt az SFS, dolgozz!)
Harmadsorban, és ez a legfontosabb szempont (legalábbis üzleti értelemben, az "életben ván még több móka") a pénz csak az ötödik lépésben kezd el folyni, feltéve, hogy: a pénzember ötlete jó volt, az elemző jól elemzett, a tervező jól tervezett, a kivitelező jól kivitelezett (na meg keveset tömegközlekedett) és végül a felhasználó elégedett (plusz hajlandó fizetni) Van még egy még ennél is fontosabb kritérium: a piac közben nem ment el más irányba. Ez mondjuk szoftverfejlesztésnél a legjellemzőbb, tessék csak Moore törvényére gondolni, vagy, hogy a tavalyi gépeden hogy futnak az idei programok (nem jól)
Mi a megoldás?
forrás: http://www.codeproject.com/KB/architecture/scrum.aspx
Nem spanyol-viasz, ráadásul már jópár éve létezika gyógyír a fenti problémákra, őgy hívják Agile. A legalapvetőbb tulajdonsága, hogy a fenti lépcsőkből a középső részt összevonja, és olyan csapatot alkot, ahol az elemző(k) (Business Analyst) a tervező(k) (Architect) a fejlesztő(k) (Developer) és a tesztelő(k) (QA) együtt dolgoznak. Ez így önmagában még nem ér semmit. Nemcsak hogy együtt dolgoznak, de amennyire lehet, egyszerre kezdenek el dolgozni a terméken (ez így persze nem teljesen igaz, később kiderül miért). De nemcsak, hogy együtt dolgoznak, de csapatként felelősek a végtermékért. Mielőtt rátérnék erre a végtermékre: az egész folyamat, az eddig megszokott projektek terjedelméhez képest rövidebb ún. sprintekre van osztva ami általában 30 nap hosszú. A sprint 3 szakaszból áll:
A) Sprint Team megalakulása és a végtermék meghatározása.
B) 30 nap megszakítás nélküli munka
C) Sprint bemutató, majd elemzés
Az A lépés talán a legfontosabb, ez a lépés kb 1-2 nap. Bemenete a pénzes ember prioritizált (de szép magyar szó) kívánságlistája , összefésülve kiegészülve a technika fejlesztések listájával. Ez a Product Backlog. Ez a lista új fícsöröket, hibákat (hibajegyeket) tartalmaz. A sprint tervező "értekezlet" célja, hogy a csapat ebből a listából a fontossági sorrend alapján, kiválasztja, hogy mit fog megoldani a sprint ideje alatt. Amennyiben egyes fejlesztések túl nagyok, a pénzes emberrel együtt kisebb fejlesztésekre bontja és azok közül válogat. A 30 nap az eddigi tapasztalatok alapján ideális. Elegendő idő ahhoz, hogy új értéket adjon az üzletmenethez (illetve a szoftverhez) A tervezés végén kialakul egy közös megegyezéssel lebontott feladatlista, amit a C) lépésben prezentálnia kell a csapatnak. Ez a feladatlista a Sprint Backlog, ami már részletesen lebontott akciótervet tartalmaz, időbecslésekkel. A feladatok legfeljebb 2 nap hosszúak lehetnek - szerintem inkább 4-8 órás becslések az ideálisak, ha valami nagyobb, meg kell próbálni lebontani.
Következik a B) szakasz ami pontosan 30 munkanap. A csapat "magára marad", és egyetln célja van: a 30 nap után bemutassa az elkészült, hibamentes, használható fejlesztéseket-újításokat. Ekkor kezdődik az igazi munka és a csapat tagjai nekilátnak dolgozni. Magukhoz rendelnek a sprint backlogból egy feladatot és azon dolgoznak, amíg nincs kész. Haladásukat naponta a Scrum meetingen ismertetik maguk között. Melynek hossza 15 perc. Bárki részt vehet rajta, de csak a csapat tagjai szólalhatnak meg. Mindenki a következő 3 kérdésre válaszol, amit a Scrum Master tesz fel:
1) mit csináltál az előző scrum óta?
2) mi akadályozott a munkavégzésedben?
3) mit fogsz csinálni a következő scrum-ig?
Minden ettől eltérő téma, illetve a felmerülő kérdések megvitatása nem a scrum körébe tartozik, és későbbi megbeszéléseken kell tisztázni. Ennek betartatása a ScrumMaster feladata. A ScrumMaster további feladatai közé tartozik, hogy a második kérdésre adott válaszokban említett akadályokat megszüntesse. (pl. az egyik csapattag folyamatosan sprinten kívüli projektekbe kell besegítsen - a ScrumMaster dolga, hogy a cégnél elérje, hogy a tagot kevésbé, vagy egyáltalán ne zaklassák mással)
Optimális esetben a Sprint Team egy nagyobb közös térben dolgozik, a minél hatékonyabb kommunikáció érdekében. Néhány alapvetés: a fejlesztések eredménye folyamatosan követhetőnek kell lennie bárki számára, folyamatos és teljes regression testtel biztosítani kell, hogy az alkalmazás nem romlik el a fejlesztések hatására (continous integration). A fejlesztésnek tesztvezéreltnek kell lennie, minden új funkcióhoz a lehető legteljesebb tesztelést kell lehetőleg automatizálni, ami bekerül a regressioni tesztbe, (Test driven development) ez azt is jelenti, hogy a teszt készül el először, ami értelemszerúen failed, amígnem a hozzá tartozó fejlesztés elkészül. A tesztelő és a fejlesztő "közösen" dolgozik, hogy a teszt minél pontosabb és teljesebb legyen.
A fentiek alapján a pénzes ember folyamatosan látja a fejlődő terméket - illetve a scrumon keresztül informálódik a haladás mértékéről.
A Scrum Backlogot az egyes csapattagok folyamatosan frissítik, illetve feljegyzik, ha egy feladat kész. Ebből a státusz információból, és az időbecslésekből készül a burndown diagram:

Ezen folyamatosan látszik a csapat sebessége, és időben jelzi, ha a dolgok nem jól haladnak. Alapvető elv, hogy a csapat önmagán szervezi. EZ a diagram a most befejezett sprintünket mutatja, ami nem volt ugyan teljesen igazi sprint, de látszik, amikor néhány időbecslés illetve újabb feladat a sprint backlogra került. Illetve az is majdnem látszik hogy majdnem időben végeztünk :)
A C) szakasz egy demonstrációval kezdődik, ahol a pénzember eldönti, hogy tetszik-e neki a fejlesztés és az használható-e az éles rendszerben. Egy sprint feladata nem feltétlenül kerül egyből az éles rendszerbe, de alapvetően a cél az, hgoy a leszállított értéknövelt alkalmazás már a 30-ik nap után a felhasználókhoz kerüljön, hogy termelje a pénzt. Vannak esetek, amikor ez nem megvalósítható, de a lényeg, hogy 30-60 nap után kiderül, hogy helyes-e az irány, és időben abba lehet hagyni, vagy változtatni lehet. Ebben a szakaszban zajlik egy postMortem és egy RetroSpective, amikor a csapat kielemzi saját magát, teljesítményét, és levonja a maga kis következtetéseit a jövő sprintjei számára (Lessons Learned)

Ezek a 30 napos ún Product Increment-ek segítik elő, hogy egy-egy nagyobb lélegzetű fejlesztést kis lépésekben kínáljuk a felhasználóknak ezáltal korábban kezdődik a tényleges bevételt hozó szakasz. A csapat közös elhastározása és a majdnem csoportos munkavégzés megszünteti a kommunikációs szakadékokat, az elemző a tervezővel a fejlszetővel és a tesztelővel közösen dolgozza ki, hogy a lehető legjobb minőségű legyen a a megoldás. Sokkal kevesebb a meglepetés, és tulajdonképpen megszűnnek a "nadehát én egyáltalán nem így gondoltam" típusú megjegyzések.

Ezeket az információkat sikerült fejből leírnom, biztos hogy nem teljes, azonban remélem segít megérteni, hogy mi merre hány méter Agile ügyben. A fent elhangzottak jópár angol nyelvű cikkből került a fejembe, plusz jártunk az Agile Vancouver termékmenedzserek számára tartott bemutatóján, a Sophos vancouveri főhadiszállásán tanulmányúton, illetve végigcsináltunk egy teljes sprintet (nem volt teljesen igazi, de legalább sikeres volt)

6 megjegyzés:

Carlos írta...

Szia!

Tetszett a leírás - látszik, hogy valóban alkalmazod is a módszertant. Utólagos engedelmeddel belinkeltem hasonló témájú cikkembe honlapomon: http://nkari.uw.hu

Üdv,
Károly

Névtelen írta...

Szia!

Újra én vagyok. Kösz, hogy regisztráltál, láttam akartál küldeni hozzászólást is (végül nem jött össze?).
Javítottam a linket, elsőre nem igazán jött össze... ;-)


Üdv,
Károly

gerzson írta...

Szia!

Érdekel, h milyen szakterületen illetve szűkebb iparági szegmensben dolgozol, h a SOPHOS-nál jártatok pont scrum-ot látni és az is, h pont "odacsöppentettek"?

Czimi írta...

Szia!

Piackutatást segítő szoftvereket fejlesztünk. A Sophos itt Vancouverben fejleszti a víruskeresőjét, és tartottak egy nyílt napot még tavaly nyáron.

üdv,
Czimi

gerzson írta...

Szia, bocs, h ilyen későn reagálok.

Érdekes lett volna szakmabeliként a SOPHPS-nál járnom, ezért kérdeztem rá. :)

Mennyire hasznos 1 nyílt nap?
Gondolok itt pl arra elsősorban, h ezen a nyílt napon ugyanazt csinálják, mint a többi napon? Kvázi mintha valódi munka közben látnád őket, hogyan scrummolnak? Készülnek ilyenkor a vendéglátók valami mások számára is könnyen befogadható problémával, vagy ugyanolyan feladatokat csinálnak ilyenkor is mint máskor?

Czimi írta...

Nem volt teljes nyílt nap, kora fdélután mentünk, tartottak egy előadást, hogy hogyan adaptálták a scrum-ot, aztán megmutatták az irodát és szabadon lehetett beszélni bárkivel.