Agilis projektmenedzsment valós vállalati környezetben

Lean alapelvek

A lean/kanban szoftverfejlesztés a fejlesztési folyamat gördülékeny, kontrollált és jól mérhető megvalósítására fekteti a hangsúlyt. A Scrum keretrendszerhez képest nagyobb rugalmasságot biztosít és nagyobb figyelmet fordít a megvalósítás fázisainak mérésére. A lean/kanban rendszerű fejlesztési projektek menedzselését néhány egyszerű, világos alapelv vezérli.

A folyamat megjelenítése

A lean szemléletből adódóan a kanban rendszer kialakításának első lépése a fejlesztés munkafázisainak meghatározása. A fejlesztendő funkciók ezeken a fázisokon keresztülhaladva valósulnak meg a felméréstől az éles üzembe állításig. Ezeket a fázisokat a csapat számára jól látható helyen kell megjeleníteni. Ez a gyakorlatban legtöbbször a Scrum táblához hasonló, de több státusz oszlopot tartalmazó táblával valósul meg.

Feldolgozás alatt lévő feladatok számának korlátozása

A kanban modell legfontosabb szabálya az egyes munkafázisokban feldolgozás alatt lévő elemek számának korlátozása. Ez a korlát határozza meg, hogy a csapat egyszerre mennyi feladaton dolgozhat egy adott munkafázisban. Ezt a korlátot WIP (Work In Progress) limitnek nevezik. Ez a korlát biztosítja, hogy a team ne halmozzon fel “készleteket” előkészített, de meg nem valósított feladatokból. A gyakorlatban ez azt jelenti, hogy a fejlesztést a folyamat végén álló elemek állapota határozza meg, azaz például egy új funkció tesztelése csak akkor kezdődhet meg, ha egy már tesztelés alatt lévő elem tesztelése sikeresen lezáródott és a következő (pl. telepítés) fázisba lépett, felszabadítva ezzel egy helyet a tesztelés státuszban.

Áramlás és húzó rendszer

A feldolgozás alatt lévő elemek számának korlátozása végső soron a lean legfontosabb alapelveinek az áramlásnak és a húzórendszernek a betartását szolgálja. Ezek az elvek biztosítják azt, hogy a fejlesztési folyamat során egyenletes ütemben készüljenek el az élesbe állítható funkciók. A húzó rendszer azt jelenti, hogy a fejlesztési tevékenységet az ügyfél igények megjelenése vezérli. Ha a csapat egy új igényt azonosít, akkor annak a megvalósítása csak akkor kezdődhet el, ha van szabad kapacitás az első munkafázisra (pl. felmérés), azaz a felmérés státuszban a WIP korlátnál kevesebb elem vár feldolgozásra. Ha ez nem így van, akkor előbb végezni kell legalább egy elem felmérési feladatával, ami akkor lehetséges, ha az szintén további fázisba továbbítható. Ez a vezérlő elv kikényszeríti a feladatok folyamatos megvalósítását egészen az élesbe állításig.

Problémák azonnali elhárítása

A kanban rendszer kifejezetten intoleráns a hibákkal szemben. Ez egyrészt abban jelentkezik, hogy egy funkció csak megfelelő tesztelés után állítható élesbe. Ha egy funkció hibásan lett megvalósítva, akkor a tesztelés, hibajavítás státuszban várakozik a hiba kijavításáig. A WIP korlát miatt ugyanakkor ez a várakozás meggátolja, hogy más, időközben implementált funkciók a tesztelés státuszba kerülhessenek át, ami az azt megelőző fázisokban lévő elemek továbbítását akadályozza. Ennek következtében egy idő után a teljes fejlesztési folyamat blokkolt állapotba kerülhet. Ez a mechanizmus felszínre hozza a hibákat és rákényszeríti a fejlesztő teamet azok azonnali elhárítására.

Állandó tökéletesítés

Mivel a kanban rendszer a hibákat azonnal felszínre hozza, a fejlesztő teamnek lehetősége (és kényszere) van a hiba okainak gyors feltárására. A problémák okainak meghatározása után a fejlesztési folyamatot úgy kell módosítani, hogy a későbbiekben elkerülje a hasonló jelenségeket. Ez a kultúra gyorsan és állandóan fejlődő munkaszervezéshez vezet, ami igen gyorsan stabil és hatékony folyamatok kialakítását teszi lehetővé.