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.)

Share
This entry was posted in Módszertan and tagged . Bookmark the permalink. Follow any comments here with the RSS feed for this post. Trackbacks are closed, but you can post a comment.

Comments

  • Hesz Roland

    Aug 4th, 2010

    Bár több ember olvasná ezt a könyvet. Meg deMarco-t.
    Meg mondjuk az sem ártana, ha esetleg belenéznének az érintettek Steve McConnell: Software Estimation – demystifying the Black Art című könyvébe.
    Vagy ilyesmi. Mert sokszor már ott elbukik, hogy az Estimation != Commitment értelmezése nem megy. Meg a fejlesztők nem szabvány elemek. Meg becsülni sem tudunk. Meg ilyenek.

  • 30 éve volt szokás az, hogy hadseregnyi fejlesztőt rádobnak egy feladatra. Manapság már a vizesés modell szerint is kis csapatok dolgoznak. Mindenki rájött, hogy a kis csapatok hatékonyabbak.
    Ha a projekt kellően nagy, akkor szétbontják részekre, és a részeken külön csapatok dolgoznak. Vagy egyszerűen egy külső cégtől veszik meg.

    Az a tény is közismert, hogy akármilyen jó egy menedzser, csak egy bizonyos számú beosztottat tud hatékonyan vezetni. Ismertem olyanokat, akik maguk próbáltak meg 20-40 embert vezetni, nem ment.

    A Mythical Man-month alapmű.

  • Marhefka István

    Aug 4th, 2010

    akocsis: Hatalmas lehet a különbség már akkor is, ha 6 helyett 9-en dolgoznak a projekten, tehát nem feltétlenül csak nagy méretekben számít a kommunikációs overhead.

    A projektet több kisebb részre kell szétvágni, de az se mindegy, hogyan végzik ezt. Sok embernek pl. a hiearchikus leosztás jut eszébe (mint a szervezeti hierarchia esetén), ami pl. általában egy rossz megközelítés.

    “Egyszerűen” külső cégtől csapat megvásárlása szerintem rossz attitüd. Könnyű mondani, persze…

  • Marhefka István

    Aug 4th, 2010

    Azt tudtátok, hogy pár hónapja jelent meg Brooks új könyve? Címe: The Design of Design

    http://www.amazon.com/Design-Essays-Computer-Scientist/dp/0201362988/

  • Igen igen és olyan apróságokon múlnak dolgok hogy 1 légtérben van-e a csapat vagy nem.
    Nálunk pont ez van hogy a 6 programozó 2 szobában van, és bizony már így is nagyon sokszor félreértések viszik ez az időt

Leave a Comment