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)