A mesebeli emberhónap

Szofverfejlesztési projekteknél gyakori jelenség a rövid határidő. Szinte látom is lelki szemeim előtt a PM-et, ahogy projekttervet készít: feladatokra bont, ütemezi a feladatokat, erőforrásokat rendel hozzá és szintez. Közben a kirajzolódó Gantt-diagramban gyönyörködik: belenagyít, jobbra-balra szkrollozza. “Ezek a feladatok kritikus úton találhatóak. Rövid a határidő, rendeljünk több embert ezekhez a feladatokhoz!” Vagy: “Késésben vagyunk, rakjunk rá még embert a projektre!”

Több, mint 30 éve tudjuk már, hogy az elképzelés teljesen hibás.

A mesebeli emberhónap

Frederick P. Brooks, Jr. 1975-ben egy azóta legendává vált könyvet jelentetett, amelynek címe: The Mythical Man-Month. A könyvben több esszé is szerepel, amelyből az egyik azzal foglalkozik, miért hibás gondolat emberhónapokban becsülni egy projektet és annak feladatait.

A könyv példáival élve – a gyapotszedés és a búzaaratás olyan feladatok, amelyek sok munkás között partícionálhatóak, és a munkásoknak egymás között nem kell kommunikálniuk. Azaz, ha van egy munkamennyiség, amit el kell végezni, akkor 2x annyi rendelkezésre álló munkás esetén 2x olyan hamar lehet végezni a munkával is.

(Az x tengely a projektbe bevont emberek számát jelenti, míg az y tengely (hónapok) azt, hogy mennyi a projekt időtartama (durationje).)

A másik szélsőséges példa egy gyermek kihordásának esete. Hiába rakunk 2x annyi nőt a feladatra, a gyermek kihordása attól még ugyanúgy 9 hónapig fog tartani. A feladat nem partícionálható annak szekvenciális jellege miatt.

A szoftverfejlesztési feladatok ugyanígy nem particionálhatóak tökéletesen, mert abban is megfigyelhetőek szekvenciális kényszerek (pl. kód írás – debuggolás). Ráadásul az egyes részfeladatok végrehajtása során komplex együttműködés van jelen a résztvevő felek között, ezért a kommunikációra fordított időt is bele kell számítani a teljes ráfordításba.

A kommunikáció egy egyszerű modellel – nagyságrendjében – közelíthető. Középiskolában már találkoztuk az alábbi matek feladattal: “Egy partyn N ember vesz részt. Ezen emberek bemutatkoznak egymásnak, mindenki kezet fog mindenkivel. Összesen hány kézfogás történik?” A megoldás:

Vagy másképpen:

Azaz ha egy csapat a részfeladatok megoldása közben folyamatosan egyeztet, akkor a kialakuló kommunikációs vonalak száma négyzetesen arányos a résztvevő felek számával. 2x annyi ember esetén 4x annyian kommunikálnak párban, 10x annyi ember esetén 100x annyian. (5 ember: 10 kézfogás, 10 ember: 45 kézfogás, 20 ember: 190 kézfogás.)

Nagyobb projekt esetén nyilván nem engedhető meg, hogy egy fejlesztő dolgozzon a problémán (akkor van a legkevesebb kommunikációs overhead, ugyebár?), mert a feladat annál jobban párhuzamosítható, és végeredményben sokkal hamarabb végezhetünk. Rakhatunk rá még egy fejlesztőt, esetleg még egyet, valószínűleg csökkenni fog a feladat időtartama. Azonban – a fenti elv miatt – egy ponton átfordul a görbe, és ahogy egyre több fejlesztőt vonunk be, úgy válik egyre lassabbá a fejlesztés a kialakuló bonyolult kommunikáció miatt.

Tanulság

A fenti okfejtésnek – kiegészítve helyenként más megfigyelésekkel is – több tanulsága van.

Kényelmesnek tűnhet az emberhónapokban történő számolás, hiszen az közvetlenül költségre konvertálható. Becslés szempontjából azonban hibás megközelítés, mert ugyanazt az emberhónap ráfordítást – új emberek bevonásával – tetszőlegesen rövid időtartamra lehet csökkenteni. (A becslés önmagában is rázós terület, érdemes legalább elgondolkozni pl. a Scrumban alkalmazott becslési módszereken. Kulcsszavak: product backlog, iterációk (sprintek, timeboxing), iterációk előtti tervezés, yesterday’s weather, sztoripont.)

Ha késésben lévő projektre új embert vonunk be, az jó eséllyel további késést fog okozni.

Ahelyett, hogy sok embert foglalkoztatnánk, alkalmazzunk kevesebb, de jobb embereket. (Nem feltétlenül a drága emberek a jó emberek.)

Nem érdemes sok embert bevenni a csapatba, mert a kialakuló kommunikáció jelentősen lelassítja a munkát. Nem véletlenül hangsúlyozzák az “agilisek” a pehelysúlyú, motivált csapatokat. A Scrum ajánlásai szerint egy csapatba kb. 7 +- 2 embert válogassunk be úgy, hogy ezek külső segítség nélkül is szállítani tudjanak (keresztfunckionális csapatok). Többet valószínűleg nem érdemes.

Ha a munka jellege megkívánja, hogy sokkal több ember dolgozzon egyszerre a projekten, akkor több csapatot kell alakítani. Az ezek közötti összehangolt munka kialakítása nem egyszerű feladat. A munkát valahogyan szinkronizálni és folyamatosan integrálni kell. (Ez már túlmutat a jelenlegi poston.)