Agilis alapelvek: Fenntarthatóság

Az idén huszonkét éves Agilis Kiáltvány alapelveit értelmező sorozatunk utolsó témája a fenntarthatóság. (A sorozat korábbi cikkei megtekinthetők itt: ügyfél-elégedettség, változás vs tervezés, csapat, kommunikáció.

Hogy mennyire fontos téma a fenntarthatóság, illetve hogy mekkora kihívás volt ez a szoftveripar számára a kétezres évek elején, tisztán mutatja, hogy a kiáltvány tizenkét alapelvének egynegyede, azaz három alapelv is ezzel a témával foglalkozik. A fenntarthatóság fogalmához olyan kifejezések társulnak, mint stabilitás, megbízhatóság, tervezhetőség, hosszú táv. Nem csoda hát, hogy a kiáltvány megalkotóit erősen foglalkoztatta a téma.

Kialakítható olyan termékfejlesztési módszertan, ami önmagában biztosítja a fenntarthatóságot? Bármennyire is szeretnénk, az élet mindig hoz meglepetéseket, a tervek könnyen felborulhatnak. Hogyan lehet a nem várt események negatív hatásait csökkenteni, mielőbb visszatalálni egy egészséges működéshez? Fel lehet-e ezekre készülni valahogy?

Cél

A nyolcadik alapelv egyértelműen megfogalmazza a célt: „Az agilis eljárások a fenntartható fejlesztést pártolják. Fontos, hogy a szponzorok, a fejlesztők és a felhasználók folytonosan képesek legyenek tartani egy állandó ütemet”. (Eredetiben: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”)

Ez az alapelv a megvalósításban még nem segít, pusztán felhívja a figyelmet a célra. Ha összekötjük azonban a korábban megismert agilis alapfogalommal, az önszerveződéssel, máris könnyen átfordíthatjuk praktikus tanáccsá. Az önszerveződés egyik aspektusa, hogy a termékfejlesztő csapat, azaz a tényleges fejlesztési feladatok végrehajtói határozzák meg, hogy adott időegység alatt mennyi feladatot képesek elvégezni. Hogyan kapcsolódik ez a fenntarthatósághoz?

Ha a termékfejlesztő csapat túltervezi az iterációkat, többet vállal, mint amennyit megbízhatóan el tud végezni, akkor:

– 1. vagy nem készül el minden elvállalt feladat,
– 2. vagy nem a megfelelő minőségben készül el,
– 3. vagy csak a tervezettnél nagyobb erőbefektetéssel, túlórával készül el.

Az első eset a legegyszerűbb, ha sorozatosan sikertelenek az iterációk, akkor nem ismert a keresett, állandó ütem, ami a tervezhetőséget lehetetlenné teszi.

Természetesen, ha az elkészült munka nem a megfelelő minőségben készült el, akkor azt is mondhatjuk, hogy valójában nincs kész. Minősített esetről van szó azonban, ugyanis ez a hiányosság gyakran nem látszik egyértelműen. Így hosszabb távon ássa alá a fenntarthatóságot, a következő iterációk instabil alapra építkeznek.

Az utolsó pont pedig a személyes oldalról sérti a fenntarthatóságot, hiszen a túlhajszoltság csak rövid ideig tartható. És még akkor is veszélyes, hiszen a fáradt ember többet hibázik, így könnyen ördögi kör alakulhat ki: a fáradtan elkövetett hibák kijavításáért kell még többet dolgozni, de ez még nagyobb fáradtsághoz vezet, … Emiatt a pont miatt sajnos jogos a Scrum módszertannal kapcsolatos kritika, hogy, bár jól illeszkedik a rugbytől kölcsönzött nyelvezetbe, szerencsétlen választás volt az iterációt Sprintnek nevezni. Hiszen a sprint során a futó mindent belead, a végére kimerül, pihennie kell. De a Scrumban a Sprintet nem pihenés, hanem egy újabb Sprint követi.

A túl gyorsra állított sebesség tehát nem fenntartható, ahogy erről korábban a Többet akartok elérni a sprintben? Dolgozzatok kevesebbet! című cikkünkben is írtunk.

De mi a helyzet a túl lassú sebességgel? Szerencsére a vizsgált alapelv nem csupán a termékfejlesztőkről beszél, a felsorolás rámutat, hogy a fenntarthatóság többet között a szponzorok célja is. Egy szándékosan lassú fejlesztés jóval drágább a szükségesnél, így túlterheli a szponzorokat, miközben piaci előnyhöz juttatja a versenytársakat. A túl alacsony sebesség tehát üzletileg fenntarthatatlan.

A megfelelő sebesség megtalálásában egy tapasztalt Scrum Master sokat segíthet. Erről a témáról is többet tanulhatsz Advanced Scrum Master képzésünkön.

Első megoldás: minőség és műszaki tervek

A nyolcadik alapelvben megismert cél elérésében segít a kilencedik alapelv: „A műszaki kiválóság és a jó terv folyamatos szem előtt tartása fokozza az agilitást.” (Eredetiben: “Continuous attention to technical excellence and good design enhances agility.”)

Fel kell hívnunk a figyelmet a magyar fordítás kétértelműségére: „a jó terv” ez esetben műszaki tervet (design) és nem megvalósítási tervet, projekttervet, stb. (plan) jelent. Ez utóbbiról a változás vs tervezés témakörnél írtunk.

Műszaki kiválóság, azaz minőség

Futóhomokra nem építünk várat. Az egyértelmű minőségi elvárások teljesítése a elengedhetetlen a fenntarthatósághoz. Hogy mit értünk minőség alatt, iparáganként eltérhet. Általános szempont azonban, hogy nem csak a termék „látható”, felhasználó által észlelhető minőségére kell elegendő figyelmet szentelni, hanem a „belső”, technikai minőségre is. Hiába szép a termékünk borítása, ha belül rozsdásak az alkatrészek, akkor előbb-utóbb leáll a gép.

A bevezetőben feltett kérdésre, hogyan lehet a nem várt események negatív hatásait csökkenteni, mielőbb visszatalálni egy egészséges működéshez, itt a válasz. A műszaki minőség biztosításával. Megesik, hogy sietni kell. Olyan hibát találtunk, ami percenként milliós károkat okoz. Ilyenkor nem jövőbiztos megoldás kell, hanem gyors megoldás. Először. Itt azonban nem állhatunk meg. A tűz eloltása után rá kell szánni az időt megkeresni a jövőbiztos megoldást, és el is készíteni azt. Erről a témáról bővebben Küszöböld ki a technikai adósságot, segítünk! cikkünkben olvashatsz.

Jó terv

Milyen a jó agilis terv? Az iparági különbségek miatt nehéz konkrét javaslatot adni, ezért inkább csak szempontokat adunk.

Az agilis design olyan, mint egy puzzle: először megkeressük a sarkokat, és azokat rögzítjük. Aztán a kereteket. A tartalmat pedig folyamatosan töltjük ki, ahogy halad a termék fejlesztése.

Ahol a tervezés során több lehetőség felmerül, érdemes a legkönnyebben kiegészíthető/bővíthető vagy a legolcsóbban lecserélhető megoldást választani.

Amennyiben a termékfejlesztő csapatnak rálátása van a várható igényekre, nagyobb magabiztossággal tud olyan megoldásokat szállítani, amik a későbbi igények beérkezésekor nem igényelnek túl nagy áttervezést.

Második megoldás: a folyamat fejlesztése

A fenntartható fejlesztés egyik kulcsa a folyamatos fejlődés. A bevezetőben azt a kérdést is feltettük, hogy fel lehet-e készülni a nem várt helyzetekre. Definíció szerint természetesen nem, ezért nem várt helyzetek. De kialakítható olyan folyamat, ami kellőképpen ellenálló, reziliens. Erről szól az utolsó, tizenkettedik alapelv: „A csapat rendszeresen mérlegeli, hogy miképpen lehet emelni a hatékonyságot, és ehhez hangolja és igazítja az működését.” (Eredetiben: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”)

A rendszeres mérlegelés, a folyamat rendszeres finomhangolásának technikája a Scrum módszertanban retrospektívként lett ismeretes. Ennek fontosságával több cikkben is foglalkoztunk már:

– Retrospektív meeting – Miért fontos a visszatekintés?
– “Nem kell a retrospektív, mi annyira jók vagyunk, hogy menet közben foglalkozunk a problémákkal”

Az agilis alapelvek közös megértése kulcsfontosságú. Ha úgy érzed, segítségre van szükségetek ebben, figyelmedbe ajánljuk az agilis csapatokra tervezett Scrum / Agilis szintlépés online tréningünket.