Agile regulázott környezetben

Most már az FDA, az amerikai élelmiszeri és gyógyszer hivatal is - aki az orvosimûszer-gyártó cégek mûködését felügyeli - elfogadja az agile fejlesztési módszertant. A dolog érdekessége, hogy az orvosi berendezés gyártás erõsen szabályozott, erõsen processzezett és dokumentált, az agile meg épp a processzek ellen lázadt fel, úgy 15 évvel ezelõtt. Változnak az idõk, de azért szerencsére elég lassan...

Lean vagy agile?

Már rég írtam szakmait, most itt az ihlet megint. Nyomatják ezerrel az IT cégnél a Lean filozófiát és ugyanakkor az Agile bevezetését. Jó ott lenni és látni, hogy mennyit megbotlanak. Mert az újnak az érvényességét nem validálták, mindenkire rá akarják adni a fûzõt, arra is, akire nem kellene, meg akire nem lehet. Egyszerûen van, ahol nincs értelme.

A másik gond az, hogy a lean-t (folyamat-optimalizálás, alkalmazási terület: gyártósor, tömegtermelés) és az agile-t (nóvum elõállítás, alkalmazási terület: mûhely) egyidõben akarják bevezetni ugyanott. Nem olvassák el a könyveket és tanulmányokat - a karcsúsításban nem jut rá idõ. Hol vannak ilyenkor a tanácsadók?

Ime egy 2000-es tanulmány (Bruce, Daly, Towers: Lean or Agile, Manchester Business School), ami rávilágít arra, hogy a két dolog tök más célra való:

Szívesen.

PO diktátor

In agile there is no democracy: PO tells what to do, and what to do first. PO is like a commander.

---

Az agile nem demokrácia, a product owner mondja meg mit kell csinálni, és milyen sorrendben, mint a hadseregben. Balra át?

Excel backlog plugin

A cím furcsa, de a lényeg: rájöttem, hogy lehet Excelben backogot vezetni. Most minden és mindenhol agile, a feladatokat szépen sárga lapra rajzoljuk, és tologatjuk az ajtón balról jobbra, aztán ha leesett, megpróbáljuk kitalálni, honnan.

Ez nem scrum, hanem Kanban, potyogós

Kellett egy privát agile tool, hogy a saját feladataimat kövessem. Elõbb az outlook kalendárt használtam, színes bejegyzések voltak a feldatok, piros, ha fontos, narancssárga, ha ráér, és ha valamit elkezdtem, átszineztem sárgára, ha kész lett, zöldre. Tökéletesen mûködik, még a feladat hossza is beállítható, 10 perc, fél óra, 2 óra, és mivel a naptáramban van, le is foglalja az idõt. Ha nem sikerül megcsinálni, át lehet dobni a következõ napra. A probléma csak az, ha nem készül el egy feladat, egy idõ után könnyen 30-40 is, és 5 percenként ugrál fel a figyelmeztetõ, mint motivátor (projekt manager), hogy az ember kikapcsolja a figyelmeztetést, és onnantól fogva minden csúszik. Na meg az is probléma, hogy az üres idõt elfoglalja, ha valaki keres, azt hiszi, megbeszélésen vagyok, elérhetetlenné teszem magam.


Ennél egy jobb módszer volt Excel táblába tenni a feladatokat: 3 oszlok (backlog, started, done), de lehetetlen megcsinálni, hogy csak annyi munkát kezdjek el, amennyit belátható idõn belül be tudok fejezni (1 nap túl rövid, a 2 hét túl hosszú, és a hirtelen beesõ sürgõs feladatokra nincs már szabad kapacitásom, a terv borul). A gond ezzel, hogy excelben elég nehéz mezõket mozgatni, kopipasztázni kell, és aztán az elmozgatott tiket alattiakat újrarendezni, újraformázni, újraszínezni.

Backlog Excelben - állandó újraformázás

Az ultimate megoldás végül az lett, hogy felírtam a feladatokat egymás alá egy listára, felvettem mellé egy oszlopot (státusz), és ebbe a következõ értékeket engedem meg:
- backlog
- selected
- work in progress
- completed

Automatikus szinezést állítottam be, a státusz mezõ színe jelzi, mi van folyamatban. Lehet filterezni, amikor csak azt látom, mi van hátra, lehet sorba rendezni, nem kell állandóan vacakolni a formázással és a keretekkel. A fontosakat lehet elõre venni, lehet mellé kommentet írni (az exceles backlogban ez eléggé problémás volt). Hurrá, van egy jó feladatkezelõm.

Az ultimate Excel backlog tool

Ha jobban megnézem, 15 évvel ezelõtt is valami hasonlót használtunk, szóval az evolúcióval felfedeztem a spanyolviaszt. De legalább mûködik.

Exploratory testing

Ma Michael Bolton, az exploratory testing (sw tesztelési módszer) egyik guruja tarott előadást a Helsinki Műszaki Egyetemen, ami Espooban van. Csak átruccan Európába, és az itteni szoftver tesztelők társasága szervezett egy kis műsort, nekünk szakembereknek. Érdekes volt viszont látni korábbi munkaadómat, egyébként csak 3-4 arcot ismertem korábbról.

A fazon arról beszélt, hogy lehet tesztelni részletes teszt terv nélkül. (Scenario based testing.) Mikor az előző cégemnél teszteltem, ezt a módszert használtam, anélkül, hogy tudtam volna róla. Érdekes téma, ha nagyobb lenne a szakmai érdeklődés, megmutathatnám, hogy csináltam, excel táblával, spontán, de pontosan felírva, mit csinálok, és mit tapasztalok. Egy ideje tudom, hogy ennek neve is van, és most érdeklődve figyeltem, mit csinálhattam volna jobban. Na meg arra is rájöttem, miért nem tudom rendesen dokumentálni azt a tesztelést, ami most az egyik projektemben folyik, hát azért, mert explanatory (felfedező) tesztelést csinálnak: csinálnak egy durva ellenőrzést, és csak ott mennek bele a részletekbe, ahol valami gányt találnak. Meg előre eltervezetten megnéznek egy-egy területet alaposan is.

Lelkendezve jöttem el az előadásról, bár jobb lett volna egy sörözés keretében kérdezni Michaelt. Ehhez túl sokan maradtak az előadás után, inkább csendesen elosontunk.

Az egyik legérdekesebb része a QA-nak az volt, mikor a szoftver tesztelői tanusításról kérdezték. Mert ellene van. És mert azon gondolkoztam, beszerezzem-e a tanusítást (jogosítványt?), de azok után amit mondott, azt hiszem, felesleges.

A tesztelőt megeszik, ugye?

A projekt lassan kész, tesztelőt hívnak, hogy ugyan már valaki tesztelje le az alkalmazást, mielőtt kikerül a világba. A tesztelő hibákat talál, amit javítani kell (a program időnként lefagy), és olyan kérdéseket fogalmaz meg, amit az új felhasználók is feltennének. A fejlesztők és managerek már nem új felhasználók, ismerik a rendszert, nekik ezek a kérdések sokszor időpocsékoló apróságok.

Úgy néz ki, mindenki utálja a tesztelőt, mert megakasztja a fejlesztést. A termék átadásáig még 3 sprint van hátra. Érdekes módon pár alap funkciót a 3. sprintben terveztek implementálni, a tesztelő szerint ez kockázatos, nem lesz idő letesztelni és kijavítani, ha hiba adódna. Természetesen a fejlesztők tökéletesek, és nem hibáznak, mégis, a tesztelő már talált 3 kritikus hibát. És még csak alig mélyedt el a történetben.

A hivák javítása, a hibajelentések átnézése, megválaszolása, a döntés, hogy javítsuk-e és hogyan annyi időt elvesz, hogy beláthatatlan, mikorra készül el a termék. A tesztert jobb elhallgattatni, levadászni, hazavinni, megfőzni, és ebédre megenni, jobb felvenni a flastromragasztó szemüveget, amiben a hibák nem látszanak.

Éljen az agilitás!

Talán ezért volt (így hallottam) az Ericssonnál korábban külön maintenance csoport, akik a felfedezett hibákat (gépikód szinten!) javították, és nem hagyták, hogy a fejlesztők idejét vegye el a javítás. És talán ezért jó az open source fejlesztés, mert a más által megírt kódba utólag bárki belejavíthat, ha hibát talál, és nem kell schedulálni a javítást, és jóváhagyni a release-t.

A tesztelő tanácsa, a kivégzés előtti utolsó szó jogán: hagyjatok (tervezzetek) időt a tesztelésre is. Akármilyen ronda az a vízesés, a tesztelést nem lehet megúszni, mert ciki lesz, mikor a felhasználóitok bukkannak a szekrénybe rejtett csontvázakra.

Hétvége mint munkanap

Munkahelyen áttértünk a fizetõs ScrumWorks toolról az Agilefant-ra.

Jó és könnyen kezelhetõ programocska, webkettes felülettel, húzod és viszed a taskokat, jelented az órát, szinte mindent tud, amit ma tudni kell egy ilyen fehér táblát leváltani szándékozó toolnak. Van egy baja. Nem, kettõ. Az egyik az, hogy beta, de azért megy. A másik az, hogy finn egyetemisták fejlesztgetik. És elfelejtettek arra gondolni, hogy a hétvégén mi (ipar) nem dolgozunk. Nem lehet megadni neki, hogy a hétvégéket szedje ki a burndown chart-ból, és baromi érdekesen néz ki, amikor két napig "áll" a munka, vízszintes a görbe. Egy egyetemen egy ilyen követelmény valószínûleg értelmezhetetlen: ott hétvégén sem lehet letenni a könyveket, sõt, akkor van az embernek igazán ideje dolgozni és készülni a vizsgákra. Vagy fejleszteni az Agilefantot.

A kép felsõ szélén látható a finn zászló. Made in Suomi.

Agile korlátai és a keresés problémája

Azt monda a product owner: a sprint végére működjön az OTA konfiguráció. A sprint végén leült a csapat, demonstrálta, hogy az OTA konfiguráció működik. Elfogadva (= fejlesztő csapat szélnek eresztve). A felhasználók elégedetlenek, mert az OTA beállítások csak egy bizonyos operátor egy bizonyos márkájú telefonjaival működnek megbízhatóan, egy másikkal duplán érkeznek, az összes többi telefon pedig egyáltalán nem működik. A team azt mondja, hogy az OTA működik, a PO a haját tépi, hogy nem úgy, ahogy kéne.

A probléma: nem volt rendesen definiálva, mik is az elvárások. Mint ahogy Baracskai tanította a keresésről: nem elég azt mondani, hogy kék farmert akarok, azt is tudni kell mondani, hogy ne legyen teve a seggén. Agile-ben ugyanis nincs követelmény-elemzés. Vagy ha van is, nem alapos.

A mi PO-nk nem is gondolt arra, hogy a nadrágon tevék lehetnek.

Most magyarázom neki a farmeres és a kukázós keresést, nehezen fogja, hogy az agile olyan, mint a guberálás.

Agile rejtvényfejtés

Vannak ezek a rejtvényújságok, vagy füzetek, tele keresztrejtvénnyel, meg skandinávval, meg olasz módra. Van bennük egy fajta rejtvény, amit pillanatok alatt, a szavak beírása nélkül is meg tudok oldani. Nem tudom, mi a típus neve, mert ebben az ebugatta nevű újságban nincs fölé írva, de a lényeg az, hogy a rejtvény úgy néz ki mint egy keresztrejtvény, betűrendben felsorolták a beírandó szavakat, és azokat kell beírni a rejtvénybe. Egy szót könnyítésül előre beírtak, és a végén néhány szó kimarad. Ebből áll össze a megadott vicc poénja. És itt csapok a homlokomra, mert a rejtvényfajta neve: poénvadászat.

Szóval ezt a fajtát mindenféle fejtés nélkül fejtem: a szavak párosan fordulnak elő a rejtvényben, páros számú két, három, négy, öt stb. betűs szó megy bele (mert a pálya mindig szimmetrikus), így lehet látni, hogy hol maradnak felesleges szavak, vagyis a vicc poénjához tartozó szavakat pillanatok alatt meg lehet találni, és a rejtvény kész. Ezt hívom agile (gyors) rejtvényfejtésnek (ejtsd: edzsájl)

Aztán annak is van egy szépsége, mikor a folyamatot végig csinálod, keresgetve beírod a szavakat (egymás után, mint a waterfall), hogy a rejtvény teljesen ki legyen töltve, de erre jobb az olasz módra, annál nehezebb csalni, vagy a sudoku.

A poénvadászatnál, mint az agile-nál is, a végeredmény a fontos. A poén. Sokszor azon gondolkoztam, hogy ez csak nekem megy ilyen könnyen, vagy mindenki így csinálja? Talán a mensában...

Edző

A coach tippeket ad a vezetőnek a döntéshez. Az agile coach végrehajtja a vezető döntését, nem egyenrangú felek.

Megnéztem a Fehér tenyér c. művet, ebben is egy érdekes coaching technikát látni. A coach versenyez az ügyfelével. A végső pillanatban lemond a győzelemről, az ügyfél javára. Vajon itt egyenrangúak?

Szóbeszéd

Hallottam egyszer egy informatikai projektrõl, ahol nagyon lassan haladt a munka. Rájöttek, hogy a határidõre nem készülnek el, ezért a feladatot kiadták egy alvállalkozónak, aki örömmel nekiállt befejezni a weboldalt. A régi csapat embereit megtették managernek, ki a tervezésért, ki a programozásért, ki a tesztelésért, ki a dokumentálásért, megint más az új rendszer oktatásáért lett felelõs. Hasonló manager pozíciókat hoztak létre az alvállalkozónál is, és a két cég megfelelõ managerei egymással találkozva egyeztették a már elvégzett és elvégzendõ feladatokat. Szép tervek és prezentációk készültek. Amikor az eredeti határidõ eltelt, és a projektet újra kellett tervezni, minden nagyon szépen mutatott, volt velocity, lett új határidõ. Aztán lassan az új határidõk is leteltek, a megbízó cég kezdett idegeskedni. Felvett egy új alvállalkozót, annak kb 50 emberét, hogy teszteljék az elkészült rendszert, és auditálják az alvállalkozót, miért halad olyan lassan, miért csúsznak el minden korábban megegyezett határidõt. És hogy miért nem készültek el azok a tanulmányok és tanfolyam anyagok, amiket a megrendelõ megrendelõje elvárt. Mindkét cégnél dolgozott már 20-20 manager az ügyön, és mint kiderült, az alvállalkozó is alvállalkozót vont be a programozásra. Az auditoroknak mindenkivel le kellett ülniük és beszélniük, erre elment egy hónap, kettõ, és az auditorok szállították a válságtervet, ahogyan a probléma kezelhetõ lenne: a legszükségesebb tervek és anyagok listája, és a még hiányzó programok. Mikor ezt az alvállalkozónak átadták, egy ideig eltartott, mire megjött a dühös válasz az alvállalkozó alvállalkozójától: "Most akkor a dokumentumokat írjam, vagy a programot?" De mondhatta volna így is: valaki legyenszíves priorizálja a backlogom.

Ismerõs? Az egyetlen fojtogatható nyak...

Érdekes módon a projekt minden résztvevõje nagyon jól érezte magát, és váltig állították, hogy nincs itt probléma, mindenki pozitívan értékeli a projektet. Kivéve talán azt az egy csirkét.