Éppen keresem scrum master társamat, ha dolgoznál velem, írj rám linkedinen!

“If you can't measure it, you can't improve it.” - W. Edwards Deming

Fejlesztő csapatok teljesítményét többnyire velocity-vel mérik, tehát megvizsgálják, adott sprint alatt összesen hány story pontnyi feladatot készítenek el. Ez egy relatív mérőszám, nem összehasonlítható, nem mutatja meg, mekkora veszteségekkel dolgoznak.

 A lean megközelítés szerint veszteség minden olyan tevékenység, ami nem ad értéket az ügyfélnek. Ilyen például az a helyzet, amikor a tesztelő nem a csapat része, hanem egy külön funkcionális csapat tagja, és két emelettel feljebb ül, vagy rosszabb esetben egy másik épületben. Mivel az idejét szétosztja a csapatok között, akiknek besegít, így többnyire csak a sprintzárás előtti pár napban jelenik meg, hogy teszteljen. Addig viszont a feladatok torlódnak a teszt oszlopban, és senki nem nyúl hozzájuk. Talál néhány hibát, a fejlesztők vakargatják a fejüket, hogy az egy hete vagy akár három napja írt kódban milyen változtatásokat kell eszközölni, miközben az éppen aktuális feladataikat is megszakítják (már ha megszakítják). A scrum master pedig halántékán kidomborodó erekkel figyeli az eseményeket. 

Hatékony vs. eredményes

A két fogalmat gyakran használjuk szinonimaként, ám két egészen különböző dolgot takar. Az eredményesség azt jelenti, hogy a jó, értékes dolgot csináljuk, a hatékonyság pedig azt, hogy jól, azaz minél gyorsabban, kevesebb költséggel. Fontos különbséget tennünk, hiszen különböző eszközökkel mérjük őket, és eltérő intézkedésekkel lehet rajtuk javítani.

• Ha valami eredményes, de nem hatékony, akkor a bevétel vagy csak túlélésre elég, vagy megszedjük magunkat, de a kihasználatlan potenciál feszültséget generál, ami hosszú távon szintén nem fenntartható.
• Ha értéktelen dolgot nagyon gyorsan állítunk elő, akkor az hamar a földbeáll, hiszen nem fognak érte pénzt adni.
• Lassú halállal vérzik el az olyan termék, ami nem teremt értéket, és hosszadalmas az előállítása, hiszen sok időbe telik, amíg piacra kerül és kiderül, hogy értéktelen. Erre remek példa a Juicero, a méregdrága gyümölcsfacsaró története

Ebből látszik, hogy nincs értelme azelőtt hatékonyságra fókuszálni, mielőtt tudnánk, hogy elég értékes-e, amit csinálunk. Habár most a hatékonysággal foglalkozunk, fontosnak tartottam tisztázni, hogy önmagában a hatékonyság és a veszteségminimalizálás fabatkát sem ér. Először ki kell tűznünk a megfelelő célt, majd az ahhoz vezető stratégiát, végül pedig optimalizálnunk kell a működésünket.

Melyik az értékesebb?

Scrum Baby koromban kaptam a beugratós kérdést a mentoromtól:

Melyik képviseli a nagyobb értéket, a feladat, amibe a csapat még bele sem kezdett, vagy amivel már elkezdtek foglalkozni, de még nem fejezték be?

Én rávágtam, hogy az, amivel már dolgoztak, hiszen valami már elkészült. Az igazság az, hogy ez nem igaz. Az elkezdett, de be nem fejezett feladatban van költségünk, de még semmi értéke nincs, hiszen a felhasználó számára nem használható, nem hoz bevételt, nem enyhít fájdalmat. Minél több feladatba kezdünk bele, annál nagyobb a ráfordításunk. Ha folyamatosan értékteremtő munkát akarunk végezni, arra kell törekednünk, hogy gyorsan, kész feladatokat tegyünk le az asztalra.

Nem a kihasználtságát kell maximalizálnunk a csapatnak (mindenki ideje 100%-ban ki legyen tömve - oh, hányszor hallottam ezt), hanem az átfutási idő és a folyamatban fellépő veszteségek minimalizálására kell törekednünk.

Velocity vs. hatékonyság

Adott a két csapat, az egyik folyamatainak 99,9%-a veszteség, a másiknak mindössze csak a 60%-a. Ha veszteségek nélkül tudnának dolgozni, a Lassú csapat 100.000 sztoripontot, míg a Gyors csapat 100 sztoripontot tudna elkészíteni átlagosan egy sprintben. A veszteségekkel viszont a Gyors csapat 40 USP-t, a Lassú pedig 100-at.

A következő pár sprintben mindkét csapatnak sikerült 10%-kal emelnie az átlagos velocity-jét, így a Lassú csapat már 10, a Gyors pedig 4 pontottal többet tud elkészíteni. Ezzel kalkulálva Lassúak 0,01%-kal, Gyorsék pedig 4%-kal javítottak folyamataikon. 

Láthatjuk tehát, hogy a velocity növekedés önmagában nem mond sokat. Egy olyan csapatban például, ahol jellemzően az architectre dependál az egész sprint, hiszen csak ő merge-ölhet, és a feladatok folyamatosan be vannak ragadva, a veszteségek csökkentésére kell törekednünk ahelyett, hogy jobban éreznénk magunkat, ha valamennyire megnőtt a kibocsátásunk.

Hatékonyság számítása

Ahhoz, hogy egy csapatnak gyorsítsuk a szállítási sebességét, a folyamataik hatékonyságát kell optimalizálnunk, ehhez pedig először meg kell mérnünk azt. A lean termelésben folyamat ciklus hatékonyságnak (angolul process cycle efficiency, sajnos nem találtam jobb fordítást) nevezik az erre szolgáló mérőszámot.

Amennyiben a csapat logolja a feladattal töltött idejét, használd a következő képletet:

Folyamat ciklus hatékonysága = értékteremtő idő / ciklusidő

Értékteremtő idő: minden olyan idő, amit a csapat a feladattal eltölt.

Ciklusidő: az az idő, ami eltelt attól kezdve, hogy valaki elkezdett a feladattal foglalkozni, odáig, hogy elkészült (megfelelt a definition of done-nak). Tehát ha hétfő reggel elkezdett egy feladaton dolgozni a csapat, és péntek reggel készült el (kód review-val, teszteléssel, kikerült a megfelelő környezetre stb.), akkor a ciklusidő 4 nap (munkaidővel számolunk, tehát átváltva ez 32 órát jelent).

Abban az esetben, ha a csapat nem vezeti az idejét a feladatokra, számold ki azt az időt, amit megszakításokkal (meeting, egy másik feladat, lerohadt a build stb.) töltenek, és használd ezt a képletet:

Folyamat ciklus hatékonysága = (ciklusidő - megszakítások ideje) / ciklusidő

Megnéztem a sprintben először elkészülő feladat folyamatának hatékonyságát:
A feladat teljes ciklusideje: 81,5 óra
Összes rálogolt idő: 68,5 óra (52,5 óra fejlesztés, 10 óra review, 6 óra teszt + hibajavítás)
Folyamat hatékonysága = 68,5 / 81,5 = 84%

Egy kisebb feladaté:
Az egyik fejlesztő hétfő reggel megcsinálta a 2 órás feladatot, majd a tesztelő másnap reggel vette észre, 15 perc alatt letesztelte, majd behúzta done-ba. A feladattal összesen 2,25 órát foglalkoztak, a ciklusidő 8,25 óra, így a hatékonyság 27%.

Az érték maximum 100% lehet, de az igen ritkán fordul elő.
Amennyiben 100% körüli, úgy a feladat áramlása folyamatos, nincsenek megszakítások, minimális veszteséggel készül el, állandóan érték adódik hozzá.
Ha az érték 0%, úgy a feladat sosem készül el, és minden vele töltött perc kárba vész.

Az igaz harcos nem bízza egy fegyverre az életét

Ez a metrika sem elég önmagában ahhoz, hogy átfogó képet kapjunk csapatunk teljesítményéről. Attól, hogy egy feladattal mindig foglalkozik valaki, még nem jelenti azt, hogy ne lehetne csökkenteni pl. a ciklusidőn. Többek között érdemes figyelni a csapat velocity-jét, a ciklusidők egymáshoz viszonyított változását, a minőség alakulását. A folyamat hatékonyságának mérése hasznos kvantitatív adatokat szolgáltat ahhoz, hogy minél gyorsabban, kevesebb költséggel és veszteséggel tudjatok értéket szállítani.
Végül, mindig vizsgáljátok meg azt, mit rejtenek a számok, mert azok csak jelzik a hibát, de nem oldják meg.



Források
Swarming: One-Piece Continuous Flow 
Guthy Miklós - Eredményesség vs. hatékonyság
Jeff Sutherland és társai - Process Efficiency – Adapting Flow to the Agile Improvement Effort

Ha tetszett, iratkozz fel a blogomra, vagy kapcsolódjunk linkedinen.