Környezetemben sokak számára néha nehéz elmagyarázni mit is csinálunk pontosan, mit jelent az agilis munkamódszer, amiben dolgozunk a fejlesztő csapattal. Alább egy hétköznapi példával szemléltetném, nagyjából mi a munka folyamat egy ilyen környezetben.
A legidősebb fiam szeptemberben iskolába fog ment, így már kirajzolódott a nyári események egy része: iskolatáska, füzetek, íróasztal vásárlás. Ezek közül a legutóbbi volt az egyik legfontosabb és a legnagyobb körültekintéssel kiválasztott dolog, hiszen sokkal könnyebb megfelelő környezetben alkotni.
Persze ennek az asztalnak helyet is kell találni, ami a jelenlegi gyerekszobában nem volt. Ennek egyik oka, hogy a fekvőhely és a ruhás/játékos szekrény az előző lakhelyünkről lett áthozva és nem passzolt a tetőtéri kialakításhoz. Így adta magát a feladat: új bútor kell a gyerekszobába. Az ágyat megvettük az IKEA-ba, pipa. De tetőtéri bútort nem nagyon árulnak, így vagy egy asztalost kérek meg vagy magam készítem el. A második mellett döntöttem, hiszen nem áll távol tőlem a barkácsolás.
A folyamat során próbáltam az agilis módszertanról tanultakat alkalmazni, nem lövöm le a poént, lássuk hogy sikerült.
1. Követelmény elemzés
Felmértük a szoba adottságait, hogyan lehetne a legoptimálisabban kihasználni a teret. Egy külső tényező, a megvásárolt ágy, amely kihúzható, korlátozta a szabad hely forrást. A jövőbeni külső tényezők növekedésével is számolnunk kellett, az íróasztalnak is kellett helyet találni, lehetőleg úgy, hogy természetes fény érje. Így a tetőtér beépítése mellett döntöttünk a szoba teljes hosszában.
Felmértük, hogy milyen célt szolgálna az új bútor: ruhák tárolása, játékok tárolása. Mivel a már meglévő ágy, főleg kihúzva, korlátozza a hozzáférhetőséget a szekrényhez, így olyan tárgyak tárolását is számba vettük, amihez ritkán kell hozzányúlni: pl. téli/nyári ágynemű, téli ruhák.
2. Tervezés
A követelmény elemzésből kiesett funkcionalitásoknak megfelelően megterveztem 3D-ben a szekrényt. IKEA-s kihúzható kosár és tároló dobozok, mint külső tényezők, szintén befolyásolták ezt a szakaszt, így az egyes fakkok, polcok méreteit ezekhez igazítottam. Elkészült a terv az elsődleges mérések alapján, amit jóváhagyott a stakeholder (kedves Feleségem).
 |
| 3D model |
A belső határoló elemeket úgy kellett megtervezni, hogy a polcok nagy része hozzáférhető legyen az ágytól.
3. MVP
Ezután meg kellett nézni, hogy az elképzelés megvalósítható-e, érdemes-e nagyobb beruházást eszközölni. Jelen esetben az MVP célja az volt, hogy ellenőrizzem a mérések alapján megvalósult tervet. Erre főleg a tető hajlásszöge miatt volt szükség, illetve lássuk, hogy értelmesen használható felület marad-e a szekrény teteje és a tető között. Erre létrehoztam a tervek alapján meghatározott méretek szerinti egyszerű váz szerkezetet meglévő léc darabokból:
 |
| MVP |
Ezzel validáltam a tervet, hogy be fog férni a bútor a helyére, és a tetején is marad elegendő hely.
4. Becslés
A 3D-s modellből készítettem egy 2D-s tervet, abból pedig bútorlaponként egy-egy méretezett rajzot, darabszámmal. Ennek a költségét és az elkészítéséi idejét bebecsültettem a helyi lapszabászattal.
 |
| Terv |
A végleges ár túlmutatott az eredetileg erre szánt keret összegénél, mivel a vasalatok és a bútorlap költségét én kevesebbre becsültem. A scope-ból úgy tudtam vágni, hogy a hátsó takaró bútorlapot lehúztam a listáról, hiszen zárt állapotban nem látszik, nincs hozzáadott értéke és funkcionalitását átveszi a tető. A vasalatból nem szerettem volna minőségben lejjebb adni, illetve a tolóajtó mérete indokolta a több görgőt és így a magasabb összeget. Stakeholder jóváhagyta.
A költség további csökkentését és az MVP kihangsúlyozását eredményezte, hogy az IKEA-s kosarakat és dobozokat majd később fogjuk megvenni és beszerelni. Ezek nélkül is használható marad a bútor, és elkészültekor így is értéket fog teremteni az ügyfeleknek.
5. Összeszerelés (fejlesztés)
A bútorlapok legyártását követően jöhetett az összeszerelés a tervek szerint.
 |
| Fejlesztés |
Az első sprint után jött a demo: valóban a tervezettnek megfelelően fér el a bútor a tetőtérben? És vajon használható lesz kihúzható ágy mellett is a szekrény egyik fele?
 |
| Demo |
Igen! A demo sikeres volt, jöhetett a következő sprint. Elkészült a bútor másik oldala is és felszerelésre kerültek a felső lapok is. Itt dönteni kellett, hogy az összeillesztés rejtett lesz-e, vagy felülről csavarozva. Mivel időben nem szerettem volna többet rászánni, illetve hiba lehetőséget is tartalmazott volna a rejtett megoldás (fa tiplikkel), így a kevésbé esztétikus, de egyszerűbb és gyorsabb megoldást választottuk a stakeholder-rel egyeztetve. Ettől függetlenül ezt a részt még nagyobb odafigyeléssel végeztem el, hogy a végeredmény a lehetőségekhez képest esztétikus legyen.
A tolóajtók szerelése közben észrevettem, hogy túl sok az interrupt. A görgők esetében,a melyekből ajtónként 4 db kellett:
- be kellett jelölni a pontos helyüket
- majd apró mélyedést csinálni, hogy ne másszon el a csavarok helye
- aztán 3-as fúrófejjel előfúrni a csavarok helyét (görgőnként 4 darab)
- becsavarozni a facsavarokat
- felrögzíteni a tartóra a görgőket
 |
| Tolóajtó: interrupt hegyek |
Ennél a folyamatnál nagyon sokszor kellett szerszámot cserélni, és a fúróban fejet váltani. Így a második ajtónál már minden lépést az összes görgőnél végigcsináltam, nem pedig görgőnként váltogatva a taskokat, így sokkal kevesebb idő alatt elkészült a második ajtó.
6. Átadás, ügyfél elégedettség mérés
Végül elkészült a szekrény 2 nap alatt, az ügyfelek nagy megelégedettségére és azóta is szívesen használják.
7. Retrospective
Ha igazán MVP-t szerettem volna, akkor a tolóajtó is lehetett volna másidk körös fejlesztés, beruházás. Költség csökkentési lehetőség lett volna, ha a belső polcok nem közepes, hanem alacsonyabb minőségű bútorlapokból lett volna megrendelve és legyártatva.
 |
| Valódi MVP |
Remélem sikerült ezzel az egyszerű és hétköznapi példával érthetőbbé tenni az agilis működés egy szeletét. Vegyük sorra a lényeget, átültetve az IT iparba:
- követelményelemzés: a vevő igények felmérése, külső tényezők megismerése
- tervezés (story-k megírása)
- ötlet validálása (MVP)
- fejlesztési költségek (sprintek) becslése
- fejlesztés
- demozás ügyfeleknek
Fontos az ügyfelekkel való szoros együttműködés, változtatások, felmerült problémák kommunikációja és jóváhagyása. Lényeges, hogy próbáljunk a scope-on vágni, mérjük fel, hogy adott funkciókra valóban szükség van-e? A demo és a fejlesztési szakasz ciklikusan követik egymást, míg el nem készül a termék.
Cél, hogy fejlesztés közben minél kevesebb interrupt legyen, és nem szabad elhanyagolni a retrospective fontosságát, ahol fel kel mérni a hibákat és a pozitívumokat a fejlesztési szakaszokban, hogy tanuljunk belőlük és sprintről sprintre jobbak, hatékonyabbak legyünk.