Weblabor

Szükség van-e projektmenedzsmentre?

Profi az, aki tudja, mit csinál

Azt gondolom, profi az, aki tudja, mit csinál. Tudja nem csak akkor, amikor beír egy sor PHP-t, de akkor is, amikor rendszerbe szervezi a sorokat, tudja akkor, amikor ennek megjelenítést tervez, de tudja akkor is, amikor az egész készítés folyamatát kell megszerveznie, átlátnia.

És persze ha valamit nem csinál profin, igyekszik ezen változtatni.

De hogyan szervezünk projektet? Miért úgy?

Miért nem jók az ismert módszerek? Miért nem használjuk őket?

Everything is mandatory

Korán megtanultam: félmegoldások nem elfogadhatóak. Az ügyfelet tulajdonképpen nem érdekli a mockup, nem érdeklik a tervek, és főleg nem érdeklik a béták. Neki megoldást szállíts. Everything is mandatory, ahogy Hírbehozó státusza hirdette.

Különösen így van ez már meglévő rendszerek karbantartása esetén: hisz' csak egy sort kell átírni, hisz csak egy új mező, hisz' csak kis gyorsítás, hisz' csak feje tetejére kell állítani a számlázást, hisz' csak… nem érdekesek félmegoldások: ez „atomi”.

A programozási tevékenységek 80%-a karbantartás, és ez a jövőben valószínűleg csak romlani fog

A hagyományos módszerek azt tanítják: dolgozz iterációkban, fokozatosan bővitgesd a programot. Ez az inkrementális fejlesztési modell fellelhető mind a RUP-ban, mind a SCRUM-ban, de még az eXtreme Programmingban is.

De gondoljuk meg: elfogadható-e egy félig megjavított bug? Egy félig átírt adókezelés? Ugye nem. Márpedig a helyzetek sok esetben ilyenek. Nem tudunk mindent inkrementálisan megoldani: egész egyszerűen sokszor a teljes megoldásra van szükség, és bár szükségünk lesz menet közben információkra (pl. az új adószabályozás részleteire), nincs mit bemutatni közte.

De nem az egyetlen mítosz, amivel le kell számolni ilyenkor. Íme néhány példa:

• Nincsenek határidők, Ha a feladatunk egy bug kijavítása, annak határideje tegnap: soha nem szabadott volna léteznie annak a bugnak, mégis itt van. De gyakran az információkat is akkor kapjuk csak meg, amikor már cselekedni is késő lenne.
• Nincsenek prioritások, Nem tudom megmondani, hogy az adójogszabály melyik fele a fontosabb; ha bármelyik nem teljesül, ugyanúgy megvágják a céget emiatt. Egy komoly bug és egy nyakadon lévő adóhatóság közt pedig még a legjobb vezető se képes dönteni; hát még ha más és más vezető felelős érte! Gyakran nem tudunk mit kezdeni a prioritásokkal,
• Nincs projekt, valószínűleg ezért zavaros az egész. A karbantartás folyamatos tevékenység, miközben a projekteknek egyszer „vége van”. Elérnek egy meghatározott célt, megszűnnek. Hogy fokozatosan halad-e a célig, ez egy teljesen más kérdés; a karbantartás viszont sok kicsi célról szól, nincs olyasmi, amit ne rövid időn belül (sőt, lehetőleg azonnal) kéne befejezni.

Mi maradt a hagyományos módszerek kizárása után?

Ha nincs projekt, nincsenek ciklusok, se határidők, a fontossági sorrendről pedig nem lehet beszélni, mit tehetünk? A káosz nem elfogadható egy önérzetes profinak.

Az igazság az, hogy a Waterfall vagy másnéven vízesés modell nem egy hülyeség, amin túlléptünk a hetvenes években (mint ahogy a struktúrált programozás se, de erről máskor): a Waterfall egy gondolkodás adott szintű problémákra. A trükk az, hogy amikor kitalálták, sokkal kisebb dolgokban gondolkoztak. Mit is mond ez?

Ha van egy feladat, a megoldásának különböző fázisai lesznek: pl. minden feladatot megírás után telepíteni fogunk, ez szinte biztos. Vagy a legtöbb hibát először reprodukálni próbáljuk. Lesznek aztán dolgok, amikről tudjuk, hogy meg kéne csinálni, de még nem jutottunk el odáig, hogy hozzákezdjünk. Szinte tuti, hogy valahol majd programozni is kell a tudomásulvétel és a telepítés között.

Nem mondhatom meg, mik ezek a fázisok, pont az a lényeg, hogy mindenkinél más. De: mindenkinél vannak.

A Kanban

A fejlesztő akkor érzi magát biztonságban, ha pontosan tudja, mi történik körülötte, és akkor érzi jól magát, ha ezzel nem kell törődnie. A projektmenedzser is akkor működhet jól, ha mindig pontosan tudja, mi történik épp, ki min dolgozik, sőt: azt is látja, ha valami elakadt.

Nosza, hozzunk egy táblát, és rakjuk fel ezeket!

A kanban japánul táblát jelent. A Toyota vezette be a kilencvenes években az autógyártásban (nyilván senki se látott még félkész Toyotát közúton, mint ahogy az se jellemző, hogy a Trabantokból fokozatosan nőnének Lexusokká), persze ők mást értenek picit alatta.

A Kanbannak 3 szabálya van:

1. Jelenítsük meg a munkafolyamatot mindenki számára jól láthatóan!
2. Az egyes fázisokban korlátozzuk az egyszerre készülő dolgok számát!
3. Mérjük az átfutási időt és próbáljuk állandóvá és röviddé tenni!

Most pedig lássük őket kifejtve:

A Kanban szabályai (eredeti kép: scrumban.org)

Jelenítsük meg a munkafolyamatot mindenki számára jól láthatóan

Ez azzal jár, hogy rájövünk, mik a tényleges munkafolyamataink: mindenkinek más, de fontos, hogy elgondolkozzunk rajta.

A megjelenítés általában egy, az iroda közepén elhelyezett táblán szokott zajlani. Jogos a kérdés: lehet-e digitális? Lehet, de ne. Hidd el nekem, nem lesz az úgy jó :)

Az egyes fázisokban korlátozzuk az egyszerre készülő dolgok számát

Ez a Kanban legfontosabb szabálya: ha mindent besűrítünk az implementálás fázisba, megbízhatatlanná válunk. Ugyanígy nem érdemes túl sok energiát ölni az előkészítésekbe se, mert soha nem leszünk kész.

Mennyit lehet ide tenni? Passz. Mekkora csoportod van? Mik azok a fázisok, amik párhuzamosan végezhetőek? Melyik a leghosszabb fázis? A programozás? Valószínűleg érdeked, hogy minél kevesebb dolog legyen egyszerre hosszú fázisban, meg lehessen mellette is csinálni dolgokat, de ez mind tapasztalati tény… látod majd a harmadik szabálynál

Ha nem csinálsz semmiféle erőforrás-korlátozást, továbbra is ugyanott vagy, mint eddig: nem jöttél ki a vízből, helyzeted továbbra is egy viharban lévő hajóé. Nyilván nagyon sok látszik már abból is, ha tudod, hogy ki min dolgozik. Vagy ha tudod, hogy mi hol tart. De innentől kezdve tudsz érvelni: mi az, ami lassan megy? Mi az, amivel a legtöbbet foglalkozunk? Mire kéne jobban koncentrálnunk? Ezek alapján már lehet szabályozni a folyamatot: a kapacitások a potméterek, de ha túl sokat forgatod őket, akkor megint csak nem a gálya, a víz az úr.

Mérjük az átfutási időt és próbáljuk állandóvá és röviddé tenni

Hogy miért próbáljuk meg az átfutási időt röviddé tenni, gondolom nem kell magyaráznom. De miért próbáljuk meg állandóvá tenni?

Először is a kiszámíthatóság miatt. Mindenki úgy érzi magát biztonságban, ha nagyjából tudni lehet, hogy mennyi idő alatt lesznek készen dolgok. Nyilván mindig minden azonnalra kell, de ezzel lehet nyugtatni embereket.

Megtanulunk emiatt feladatokat darabolni. Tanuljunk meg független elemekkel dolgozni, mi az, amire nem kell várni, hogy a másik kész legyen? Az e-mail kezelés bugjainak kijavítása futhat párhuzamosan az új oldalak hozzáadásával. Ha darabolunk, kisebb, könnyebben kezelhető dolgaink lesznek.

Ha a kapacitások a potméterek, az átfutási idő a rendszer kimenete: akkor jó a rendszer, ha egyenletes. Persze, mondhatnád, hirtelen helyzetekre át kell állítani a rendszert, hiszen ez most tényleg fontos, ez most tényleg határidős – nem. Hagyd őket békén. A rendszernek adott a kapacitása: véges mennyiségű emberrel, véges lelki energiával, szellemi tőkével dolgozol. Nyilván van rendkívüli helyzet, és valamennyi – pár százalék – zaj is lesz a rendszerben. De az állandó sebességű kimenet az, amivel hosszabbtávon tervezni lehet.

Persze nem azt mondom, soha ne változtass – folyamatosan adaptálódni kell, ez a Toyota folyamatmodelljeinek alapja. De képesnek kell lenned megkülönböztetni a rövid távú (ez a taszk, ez a kiadás, ez a…) a közép- és hosszútávuaktól. Ne a rövidtávúakra optimalizálj.

Egy élő Kanban fejlődése

A mi Kanbanunk picit bonyolult lett a végére.

Először kezdtük egy triviális felosztással: vannak bejövő taszkjaink (incoming), ezek előbb-utóbb kimennek ügyfélhez elfogadásra, a kettő közt pedig le kell őket implementálni.

Nekem mérnökként ragaszkodnom kell ahhoz, hogy a feladat végiggondolása előzze meg a feladat végrehajtását, és nem szeretek engedni ebből a – talán triviális, mégis gyakran nehezen betartatható – szabályból. Viszont tény, nincs értelme különválasztani egy karbantartási projektnél a specifikációt és a tervezést: mire rájössz, mit kell csinálni, már azt is tudod, hogyan. Így ezek összevont neve lett az előkészítés.

A mértékeket következőképp állapítottuk meg: volt két programozóm, ők nagyságrendileg 2-3 dologgal tudnak foglalkozni egyszerre, de abból az egyik csak amolyan átbeszélgetős-végiggondolós, és max. 2-2 dolog, amin ténylegesen programoznak is, legyen mi között váltani. Így az implementációs fázis kapacitása 4 lett.

Mivel a túlburjánzást el akartuk kerülni, így az előkészítési fázist is négyre vettük.

Biztos-ami biztos én bevezettem a vizszintes kapacitás fogalmát: egy-egy embernél maximum 3 dolog lehet egyszerre, ha van más elfoglaltsága is (pl. teljes projekt szintű adatbázis-mérnök), akkor 2. Innen indultunk.

Az eredeti terv az volt, nem hagyunk semmit állni: ha valami két napig áll egy helyben, dönteni kell, mi legyen vele. Ehhez a pirosra váltás fogalmát használtuk.

Hamar rájöttünk, kell egy parkolópálya, ahol az e-mailben bonyolult kérdésekre választ kereső, vagy más segítségére váró feladatokat tehettük: mégse várhatjuk el, hogy a „milyen legyen a dizájn” kérdésre valaki kapásból válaszoljon, de addig se lehet állni.

Először a tesztelés a programozók felelőssége volt, illetve erre az ügyfélnek voltak emberei. Később mi is igénybe vehettük hivatásos tesztelők segítségét, ennek reprezentálására létrejött a tesztelés alatt fázis.

Mit ne

Ne legyenek nagyon nagy Kanban taszkjaink!

Ha valamire jók az iterációk, az az, hogy a nagy dolgokat kisebb részekre bontják. Értelemszerűen nem lehet egy új Windows-verziót két hét alatt három haverral megépíteni. Ha ezeket a rendszereket vízesés-szerű modellben készítenénk, bajban lennénk. De support projektről beszélünk! Egy e-mail cím kijavítása nem ekkora!

A vízesés modellt alkalmazni nagyban a webszakmában nem sok jóval kecsegtet: egy-egy kis feature esetén egységes ügyfélakaratot kicsikarni egyszerű (Ki akarod javítattni ezt a bugot? Persze!), teljes rendszernél bizonytalan.

Ne digitalizáljunk, ha nem muszáj

Ha kirakod egy weboldalra a Kanbant, senki nem kattint majd oda. Ha naponta kiküldöd a Kanbant levélben, akár vizuálisan is kikerülik… Ha RSS-be küldöd, az se fog segíteni.

Az egyetlen megoldás, ha ez egy fizikai tárgy, amit nem lehet megkerülni: tényleg rakd ki a szoba kellős közepére. Szép lenne, ha ez egy érintőképernyős tábla lehetne, de ezzel elveszíthetné állandó jellegét (mindig játszanánk rajta), másrészt céljainkra a postit, tábla tökéletesen megfelel.

Összegezve: Nincs csodafegyver

A Kanban – az informatika összes többi megoldásával együtt – nem végső megoldás: bizonyos szituációkra jól alkalmazható gyógyír. Próbálj meg egy nagy adag programot vízesés-folyamat végén leadni, és rájössz, összeomlasz: ma már fél perces (!) iterációkról is beszélünk, mégha nekem kell is egy 5 perc mire a fejembe lévő dolgot teljesen kidolgozom.

Minél tovább van valami „bent a csőben”, annál valószínűbb, hogy a végeredmény nem lesz megfelelő. Olyan ez, mint egy messzire elrúgott labda: nagy a dicsőség, ha oda érkezik, ahova szánták, de mégis, kerüld inkább.

Persze az, hogy nem végső megoldás valami, éppúgy nem ment fel senkit, azokat sem, akik kerülik a módszeresség alkalmazását, sem azokat, akik nem képesek alkalmazkodni. Nem gondolom, hogy a káosz védhető, legfeljebb akkor, ha jól mennek a dolgaink.

Ha folyamatosan terhelésproblémák, ide-oda kapkodások vannak egy projektben, lépni kell. Egyes projektek számára a Kanban lehet az út a megnyugváshoz.

Olvasmánylista

Aki többet akar erről olvasni, annak a kulcsszó: lean development. Különösen ajánlom a Poppendieck-házaspár munkáit, de jónéhány anyag fent van az InfoQ portálon is. Közülük kiemelkedő a Kanban versus Scrum, egy ingyen letölthető PDF, valamint érdemes ellátogatni a Scrum-ban oldalára is (ahonnan a mellékelt képet is hoztam). További dolgokat a kanban.blog.hu oldalon gyűjtöttem össze.

A cikk ikonjához Dennis Hamilton fotóját kölcsönöztük.