Mi is a cím? Gyáva nyúl ütemezés? Igen. De mit is jelent ez?
Szeretem Johanna Rothman blogját olvasni, mert olyan gyakorlati tanácsokat olvashatok ott a projektek menedzseléséről, amit ige4ncsak meg kellene minden menedzser jellegű munkakörben ülő emberkének fontolni. mostanság indított egy sorozatot az ütemtervekről, illetve azok buktatóirúl. Tervezem, hogy hevenyészett magyar fordításban itt is közreadom azokat. Csak úgy grátisz, mindenki okulására.
Mi is az a gyáva nyúl játék? Valami angol (amerikai) szleng kifejezés arra, mikor ezerrel téptek az utszán egymásal szemben egészen addig, amig valamelyikőtök ki nem tér a másik utjából. Aki kitér az csirke, aki nem az győzött. (Biztos láttatok már amerikai filmeket, amiben ez megtörtént!) Nézzök, hogy ez mit is jelent a szoftverfejlsztésben és, hogy miért is nem jó ez!
Akartam egy sorozatot írni a ütemterv-játékokról, és egy történet, amit éppen a hétvégén hallottam rávett, hogy elkezdjek írni a gyáva ütemezésről.
Leginkább a gyűléseken történő gyáva ütemezés játékokban vagyok járatos. Általában a projekt státusz gyűléseken, ahol a PM és a projekt tagok összeülnek, mindenki azt mondja, hogy időben vannak. De a valóság az, hogy minden ember a másikra vár, hogy elmondja, miért is nincs készen. Ebben az esetben minden ember nyájasan azt mondja, hogy „Ó, ez nekem nagyszerű, ha még pár extra hétig tart. Semmi probléma.” Természetesen nincs probléma, ha mindenkinek több időre van szüksége.
De éppen most értesültem egy másik fajta gyáva ütemezésről. Ebben az esetben mindenki azt állítja, hogy időben van. És a fejlesztők minden éjjel becsekkolják és buildelik a kódot. De képzeld el, hogy van egy olyan mérföldkő, hogy „code freez”. A befagyasztás után nem adhatsz hozzá új kódot, csak a meglévőket javíthatod. Egy nappal a befagyasztás előtt a fejlesztők kétszer, háromszor, négyszer több forráskódot commitálnak, mint akármelyik korábbi napon. Az eredmény? Az biztos, hogy code freez mérföldkő OK lesz, de a build nem fog működni, vagy ami még rosszabb, nem is lehet fordítani. A következő egy vagy két hetet (valamelyik kliensemnél három hét is) azzal telik el, hogy legalább annyira rendbe hozd a kódot, hogy le lehessen fordítani. Most, hogy már van egy működő builded (valamivel később, mint a tesztelők várták) a tesztelők mindenféle problémát találnak.
Gyáva nyúl ütemezés akkor történik, mikor a PM a projekt egész ideje alatt csak a mérföldköveket (dátumok) követi és nem a ténylegesen létrehozott cuccokat (feature), a cucc létrehozásának folyamatát (gyorsaság) és azt, hogy a cucc milyen jó (hiba szint). Ha tudod, hogy az emberkék mennyire haladnak ki tudod szagolni, hogy azok a commit-ok azért voltak, hogy meglegyen a befagyasztás vagy azért, hogy a fejlesztők betakarják-e a seggüket.
Mikor én vezetem a projektet, a valóságot akarom tudni akár tetszik, akár nem. Nem akarok játszani a csapattal, és azt sem akarom, hogy ők játszanak velem. És ha a szenior menedzsmentben vagy, vagy projekt szponzor szerepkört viseled, ne engedd, hogy az embereid „committálják” a határidőt, ha nem hiszik, hogy képesek rá, mert akkor készen állsz csirkézni.
