Joel a szoftverről szoftvermenedzsment egyszerűen

Joel lapja

Gerilla magyar fordítások

Hivatalos fordítások

Szoftverütemezés egyszerűen

Írta: Joel Spolsky (2000. március 29.)
Fordította: Plesz Gábor
Lektorálta: Kovács Emese, Nagy Balázs, Tímár András (2003. január 18., 2004. szeptember 10.)
Az eredeti cikk

Múlt októberben az USA északkeleti részén minden valami Acela nevű, Bostontól Washingtonba vezető új expresszvonat reklámjával volt teleragasztva. Tévéreklámok, hirdetőtáblák és poszterek voltak mindenütt, emiatt azt hihetnénk, hogy az Amtraknek sikerült legalább egy kicsit felkelteni az utazóközönség érdeklődését a gyorsvonat iránt.

Nos, talán. Az Amtraknek nem volt lehetősége ezt kideríteni. Az Acela elindítását elhalasztották, majd ismét elhalasztották, így a marketingkampány véget ért, még mielőtt a szolgáltatás egyáltalán elérhető lett volna. Ez emlékeztetett arra, amit egy marketingmenedzsertől hallottam, mikor a termékéről ömlengő ismertető jelent meg egy hónappal a forgalomba hozatal előtt: „Micsoda hírverés! Kár, hogy megvenni persze nem lehet a ketyerét.”

A tesztoszteronnal elöntött agyú játékszoftveríró cégek azzal kérkednek a weboldalukon, hogy a következő kiadandó játékukat azonnal szállítják, „amint elkészül”. Ütemezés? Minek az a nyavalyás ütemezés? Mi király játékkóderek vagyunk! A legtöbb cég nem engedheti meg magának ezt a luxust. Nézzük a Lotust! Amikor először szállították az 123 3.0-ás verzióját, a követelmény 80286-os processzor volt, ami akkoriban nem volt olyan elterjedt. Ezért 16 hónappal elhalasztották a szállítást, míg sikerült a programot a 8086-os 640K-s korlátozott memóriájába beszorítaniuk. Mire elkészültek, a Microsoft Excel terméke már 16 hónapos előnnyel rendelkezett, csak a hab a tortán, hogy időközben a 8086-os elavult!

Miközben ezt írom, a Netscape 5.0 webböngésző már két éve késik. Részben azért, mert a fejlesztők öngyilkos hibát elkövetve kidobták a régi kódot, és újrakezdték előről: ugyanez lett az Ashton-Tate, a Lotus, és az Apple MacOS végzete is. A Netscape használóinak aránya mára 80%-ról 20%-ra eset vissza, mindeközben a cég nem tud foglalkozni a versenyhelyzettel, mivel a fő szoftvertermékük ezer darabban hever a padlón, és nem tudják, hogy kéne összerakni. Ez az egy hibás döntés volt az az atombomba, amivel a Netscape felrobbantotta magát (Jamie Zawinski világhírű zsémbelődése további részletekkel szolgál).

Tehát ütemezésre szükség van. Ez olyasmi, amit szinte egy programozó sem akar csinálni. Tapasztalataim alapján a túlnyomó többség megpróbálja teljesen elsumákolni az ütemezést. Azon kevesek, akik mégis készítenek ütemtervet, többnyire csak azért teszik, mert a főnökük utasította erre őket, és csak ímmel-ámmal csinálják. Tulajdonképpen senki sem hisz az ütemtervben a felsővezetésen kívül, de ők ezzel párhuzamosan hisznek abban, hogy „nincs szoftverprojekt, ami időre elkészül”, ja, és az UFO-k létezésében is.

Szóval miért is nem készít senki ütemtervet? Ennek két fő oka van: az egyik a gyötrelem. A másik az, hogy senki sem hiszi, hogy az egész ér valamit. Miért is fárasszam magam ütemterv készítésével, ha úgysem lehet betartani? Van, aki azt vallja, hogy az ütemtervek következetesen hibásak, és ez az idő előrehaladtával csak rosszabb lesz; akkor miért szenvedjek a semmiért?

Van egy egyszerű, fájdalommentes módszer, amellyel olyan ütemtervet készíthetünk, ami még használható is.

1) Használj Microsoft Excelt! Ne használj a Microsoft Projecthez hasonló csillogó-villogó eszközöket. A Microsoft Projecttel az a gond, hogy feltételezi, hogy sokat akarsz vacakolni a függőségekkel. A függőség az, mikor van két munkád, és az egyiknek be kell fejeződnie, hogy a másik elkezdődhessen. Úgy találtam, hogy a szoftverprojektek függőségei annyira egyértelműek, hogy nincs értelme erőfeszítéseket tenni a nyomonkövetésükre.

A másik probléma a Projecttel, hogy feltételezi, hogy nyomogatni akarsz majd egy kis gombot, ami „kiegyensúlyozza” az ütemtervet. Ez elkerülhetetlenül azt jelenti, hogy a program átcsoportosít dolgokat, az egyik ember feladatait egy másiknak osztja ki. Szoftver esetében ennek egyszerűen nincs értelme. A programozók nem felcserélhetők. Pistinek hétszer több időbe telhet Rita hibáját kijavítani, mint Ritának. Ha ráállítasz egy UI programozót egy WinSock problémára, bizonyára egy hetet elpazarol, mire belejön a WinSock programozásba. A lényeg az, hogy a Project irodaépületek kivitelezéséhez való, nem szoftverfejlesztéshez.

2) Törekedj az egyszerűségre! Az ütemtervek általam használt szokásos formája olyan egyszerű, hogy könnyen megjegyezhető. Kezdetben hét oszlopból áll:

Ha több fejlesztőd van, nyithatsz egy-egy munkalapot minden egyes fejlesztőnek, vagy bevezethetsz egy új oszlopot a fejlesztő nevével.

3) Minden funkció több feladatból álljon! Egy funkció (feature) lehet például a helyesírás-ellenőrzés hozzáadása. A helyesírás-ellenőrzés elég sok egyedi feladatból áll, amit a programozónak meg kell oldania. Az ütemterv legfontosabb része a feladatok listájának elkészítése. Ezért roppant lényeges a következő szabály:

4) Csak az a programozó tudja ütemezni a feladatot, aki el is fogja végezni a kódolást. Bármilyen rendszer, ahol a menedzsment írja az ütemezést, majd átadja azt a programozónak, bukásra van ítélve. Csak az a programozó tudja kitalálni az implementáláshoz szükséges lépéseket, aki végzi a munkát. A lépésekhez szükséges időtartamot is csak a programozó becsülheti meg.

5) Minél részletesebben határozd meg a feladatokat! Ez a legfontosabb, hogy működjön az ütemterv. A feladatok idejét órában, és nem napokban kell mérni (ha látok egy olyan ütemtervet, amelyben napokban vagy hetekben mérnek, már tudom, hogy nem valódi). Most azt gondolhatod, hogy a feladatokat részletező ütemterv csak egyszerűen pontosabb. Tévedés! Nagy tévedés! Ha egy ütemtervet a nyers feladatokkal kezded, majd ezeket kisebb feladatokra bontod szét, meglátod, más eredményt kapsz, nem csak pontosabbat. Teljesen más szám jön ki. Miért lehetséges ez?

Amikor részletesebben meghatározod a feladatokat, valójában arra kényszeríted magad, hogy kitaláld, milyen lépéseket kell tenned. Meg kell írni a foo szubrutint. Létre kell hozni ezt és ezt a párbeszédablakot. Be kell olvasni a wawa fájlt. Ezeket a lépéseket könnyű megbecsülni, mivel már írtál szubrutinokat, hoztál létre párbeszédablakot, és olvastál már be wawa fájlokat.

Ha hanyag vagy, és „nagy darab” feladatokat veszel (pl. „nyelvtani javítás implementálása”), akkor nem is gondoltad végig, mit kéne tenned. És ha nem gondoltad át, hogy mit kell tenned, egyszerűen nem tudod megmondani, hogy meddig fog tartani.

Aranyszabály, hogy a feladatok kettőtől tizenhat óráig tarthatnak. Ha van egy 40 órás (egy hetes) feladatod az ütemtervben, nem osztottad fel azt kellőképpen.

Van egy másik oka, hogy részletesebben határozd meg a feladatokat: rákényszerít, hogy megtervezd a nyavalyás funkciót. Ha beterveztél egy „Internet integráció” nevű csingilingi funkciót, és három hetet adsz rá, véged van, haver! Ha ki kell találnod, hogy milyen szubrutinokat kell megírnod, rákényszerülsz, hogy leszögezd a funkciót. Ha már ezen a szinten kényszeríted megad a tervezésre, a szoftverprojekt bizonytalanságának nagy részét kiküszöbölheted.

6) Tartsd számon az eredeti és a jelenlegi időbecslést! Mikor először hozzáadsz egy feladatot az ütemtervhez, becsüld meg, mennyi időbe telik (órában), és írd be ezt mind az E[redeti] becs[lés] és a J[elenlegi] becs[lés] oszlopba. Az idő haladtával, ha egy feladat láthatólag több (vagy kevesebb) időbe telik, mint ahogy gondoltad, javíthatod a J becs oszlopot. Ez a legjobb módja annak, hogy tanulj a saját hibáidból, és hogy megtanuld, hogyan becsüld meg a feladatokat pontosan. A legtöbb programozó nem tudja, hogy találja ki, meddig tartanak a dolgok. Ez rendben van. Amíg folyamatosan tanulsz, és folyamatosan javítod a becslést, az ütemterv működni fog (lehet, hogy húzni kell a funkciólistából, vagy csúszol, de az ütemterv attól még tökéletesen működni fog). Úgy találtam, hogy egy év tapasztalat után a legtöbb programozó nagyon jó időbecslő lett.

Mikor a feladat kész lett, a J becs és az Eltelt mezők megegyeznek, és a Marad mező nullára jön ki.

7) Minden nap frissítsd az Eltelt oszlopot! Igazából nem kell kódolás közben a stopperórát bámulni. Mielőtt hazaindulnál, vagy elaludnál az asztalod alatt (ha olyan megszállott vagy), tégy úgy, mintha 8 órát dolgoztál volna (hah!), találd ki, milyen munkákon dolgoztál, és ossz el kb. 8 órát az Eltelt oszlop sorai között, értelemszerűen. A Marad mezőt az Excel automatikusan kiszámolja.

Ugyanekkor frissítsd a J becs oszlopot a megfelelő feladatoknál, hogy az új tényeket tükrözze. Az ütemterved napi frissítése csak két percig kell, hogy tartson. Ezért fájdalommentes ez az ütemezési módszer: gyors és könnyű.

8) Legyen betervezve a szabadság, ünnepnap stb.! Ha az ütemterv kb. egy évre szól, valószínűleg minden programozónak lesz 10-15 szabadnapja. Ezeket mind vedd fel az ütemtervbe funkcióként szabadság, ünnepnap és más egyéb néven, ami az emberek idejét fogyasztja. Ebből könnyen számítható a szállítás ideje, ha összeadjuk a Fennmaradó Idő oszlopot, és elosztjuk 40-nel: ennyi hét van még hátra, mindent egybevetve.

9) A hibajavítás is legyen benne az ütemtervben! A hibajavítást a legnehezebb megbecsülni. Gondold végig az utolsó projektet, amin dolgoztál. Igen valószínű, hogy a hibajavítás az eredeti kód megírásának 100–200%-át kitette. Ezt az ütemtervben egy soros bejegyzéssel jelölni kell. Valószínűleg ez a sor fogja a legnagyobb értéket tartalmazni.

így működik: mondjuk, hogy egy fejlesztő az wawán dolgozik. Az Ered. Becs. 16 óra volt, de eddig 20 órát foglalkozott a dologgal, és úgy tűnik, hogy még 10 órát rá kell szánni. Így a fejlesztő 30 órát ír be a J Becs mezőbe, és 20-at az Eltelt oszlopba.

A mérföldkő végén az ilyen csúszások jócskán összeadódnak. Elméletileg az ilyen csúszások kompenzálásához meg kell nyirbálnunk a funkciókat, hogy időben szállítani tudjuk a programot. Szerencsére az első funkció, amit megnyirbálhatunk, a Tartalékidő nevet viseli, amire már jó sok órát allokáltunk.

Alapelv, hogy minden fejlesztő fejlesztés közben saját maga javítja az általa fejlesztett kód hibáit. Egy programozó addig nem kezdhet hozzá új kód megírásához, amíg tud hibát javítani. A hibák számát mindenkor a lehető legalacsonyabban kell tartani két okból kifolyólag:

1. Egyszerűbb aznap kijavítani a hibát. Nagyon nehéz és időrabló lehet egy hónappal később ugyanazt a hibát kijavítani, amikor már rég elfelejtettük, hogy is működik pontosan a kód.

2. A hibajavítást kutatáshoz lehet hasonlítani. Lehetetlen megbecsülni, mikor fedezzük fel és javítjuk ki a hibát. Ha csak egy vagy két makacs hiba van egy megadott időben, könnyű megjósolni, mikor szállítható a program, mivel nincs sok meghatározhatatlan tényező a jövőre nézve. Másrészről, ha százával vagy ezrével állnak halomban a hibák, lehetetlen megjósolni, mikor lesz az összes kijavítva.

Ha a fejlesztők mindig javítják a hibákat munka közben, akkor minek a hibajavítás sorelem? Nos, még ha ki is próbálod javítani az összes hibát, minden mérföldkőnél elkerülhetetlen a felgyülemlett hibák javítása, mikor a (belső és béta) tesztelők megtalálják az igazán nehezen megtalálható hibákat is.

10) Tégy integrációs időt az ütemtervbe! Ha több mint egy programozód van, elkerülhetetlen, hogy lesz olyan cucc, amit két programozó összeegyeztethetetlenül oldott meg, ezeket össze kell simítani. Létrehozhattak mindketten párbeszédablakot közel ugyanarra a feladatra, ez fölösleges következetlenségeket visz a programba. Valakinek végig kell mennie a menükön, a gyorsbillentyűkön, az eszköztáron stb., letisztítani és csoportosítani az új menüelemeket, amiket mindenki kénytelen-kelletlen írt csak meg. Lesznek fordítási hibák, amik azonnal felbukkannak, amint több, mint egy ember dolgozik a kódon. Ezeket ki kell javítani, ehhez is kell egy sor az ütemtervben.

11) Legyen tartalékidő az ütemtervben! A projektek hajlamosak kifutni az időből. A tartalékidő két fontos fajtáját javaslom bevezetni: először szánj tartalékidőt azokra a feladatokra, amelyek több ideig tartottak, az eredetileg becsültnél. Másodszor szánj tartalékidőt azokra, amelyekre eredetileg nem gondoltál, a legtöbbször azért, mert a menedzsment úgy döntött, hogy a wawa RENDKÍVÜL FONTOS, és nem szabad kihagyni a következő kiadásból.

Talán meglep, hogy a szabadság, ünnep, hibajavítás, integráció és puffer több időt tesz ki, mint a feladatok. Ha ez meglep, még nem programozol régóta, ugye? Ezeket csak saját felelősségedre hanyagolhatod el.

12) Sose engedd, hogy a menedzserek csökkentessék a becsült időt! Számos kezdő szoftvermenedzser azt hiszi, hogy azzal „motiválhatja” a programozókat gyorsabb munkára, ha szorosabb (valószerűtlenül rövid) ütemtervet irányoz elő. Úgy hiszem, ez hülyeség. Mikor kések a munkával, lesújtottnak, csüggedtnek és motiválatlannak érzem magam. Amikor gyorsabban megy a munka az ütemtervnél, akkor pedig vidámnak és produktívnak. Az ütemterv nem pszichológiai játszótér.

Ha a menedzsered csökkentetni akarja a becsült időt, tégy így: hozz létre egy újabb oszlopot az ütemtervben, és nevezd el Ricsi által becsült időnek (feltéve, hogy Ricsinek hívnak). Tedd oda a te becsült idődet. Engedd a menedzsert, írjon amit csak akar, a Jelenl. Becs. mezőbe. Felejtsd el a menedzser becsült értékét. Mikor a projektnek vége, nézd meg, melyikőtöké volt közelebb a valósághoz. Azt tapasztaltam, hogy ilyennel fenyegetőzni is csodát művel, főleg, mikor a főnököd ráébred, hogy épp olyan versenybe csöppent, amiben az a cél, hogy megmutasd, milyen lassan tudsz dolgozni!

Miért akarják az alkalmatlan menedzserek rávenni a programozókat, hogy csökkentsék a becsült időt?

Mikor egy projekt elkezdődik, a technikai vezetők elmennek megbeszélésre az üzleti emberekkel, és visszatérnek egy funkciólistával, amiről azt hiszik, hogy kb. 3 hónapig tart, de valójában 9 hónapba telik. Mikor programírásra gondolsz anélkül, hogy végiggondolnád a szükséges lépéseket, mindig úgy tűnik, a dolog n ideig tart, pedig valójában több, mint 3n ideig is elhúzódhat. Mikor egy rendes ütemtervet készítesz, amiben minden feladatot kirészletezel, kiderül, hogy a projekt sokkal tovább fog tartani, mint amire először gondoltál. A valóság kezd érvényesülni.

Az alkalmatlan menedzserek megpróbálják úgy megoldani a problémát, hogy kitalálják, hogy vehetik rá az embereket gyorsabb munkára. Ez nem igazán reális. Felvehetsz több embert, de nekik fel kell venniük az összeszokott csoport sebességet, és valószínűleg 50%-os hatékonysággal fognak dolgozni az első hónapokban (és ezzel rontják a többi programozó hatékonyságát is, hiszen ők tanítják be az újoncokat). Egyébként is, manapság hat hónapig tart egy jó programozó kiképzése.

Képes lehetsz 10%-kal több nyers kódot kiszedni az emberekből ideiglenesen, azon az áron, hogy 100%-osan kiégnek egy éven belül. Nem nagy előny. Picit olyan, mintha a vetőmagot ennéd meg.

Képes lehetsz 20%-kal több nyers kódot kiszedni az emberekből, könyörögve, hogy dolgozzanak nagyon keményen, nem számít, milyen fáradtak lesznek. Puff, a hibajavítási idő duplájára nő. Idióta húzás, ami sorsszerűen vissza is lő!

De soha, soha sem leszel képes 3n-ből n-t csinálni. Ha még mindig nem érted, kérlek küldd el a céged részvényjegyzési nevét, hogy gyorsan megszabadulhassak a részvényektől.

13) Az ütemterv olyan, mint az építőkockák. Ha van egy rakás építőkockád, és nem fér bele egy dobozba, két választásod van: vagy veszel egy nagyobb dobozt, vagy kiveszel néhány kockát. Ha azt gondoltad, hogy képes leszel 6 hónapon belül szállítani, de 12 hónapod van az ütemtervben, vagy késlelteted a szállítást, vagy keresel néhány funkciót, amit kidobhatsz. Nem tudod összepréselni a kockákat, és ha azt színleled, hogy mégis, egyszerűen csak megfosztod önmagadat attól a lehetőségtől, hogy ténylegesen beleláss a jövőbe azáltal, hogy hazudsz önmagadnak arról, hogy mit látsz ott.

Aztán tudod, az ilyen ütemterv tartásának megvan az a csodálatos mellékterméke, hogy rá vagy kényszerítve funkciók kidobására. Miért is jó ez? Tegyük fel, hogy van két funkció: az egyik nagyon hasznos, és tényleg remek lesz tőle a terméked (példa: táblázat kezelése a Netscape 2.0-ban), és egy másik, ami nagyon könnyű, és amit a programozóid örömmel kódolnának (például: a BLINK tag), de nincs semmilyen haszna vagy jelentősége a marketing szempontjából.

Ha nincs ütemterved, a programozók először az egyszerű funkciót implementálják. Aztán kifutnak az időből, és nem lesz választási lehetőséged, csúsztatnod kell a megjelenést, hogy beépítsd a hasznos/fontos funkciót.

Ha van ütemterved, még a munka megkezdése előtt észreveszed, hogy ki kell hagyni valamit, így ki tudod venni a könnyű/poénos funkciót, és csak a hasznos/fontos funkciót hagyod meg. Ezáltal rákényszeríted magad arra, hogy válassz, melyik funkciót dobod. Így végül hatékonyabb, jobb terméket tudsz kiadni, amelyben a fontos funkciók biztosan jelen vannak, és időben tudod a szoftvert megjelentetni.

Emlékszem, mikor az Excel 5-ön dolgoztunk. Az eredeti funkciólistánk hatalmas volt, és jóval túlléptük volna az ütemtervet. Ó jaj! – gondoltuk. Azok mind szuper fontos funkciók! Hogy élhetünk makrószerkesztő-varázsló nélkül?

Mivel nem volt választásunk, és el kellett dönteni, mit kell kihúzni ahhoz, hogy a lényeg megmaradjon, de beleférjünk az időbe is. Mindenki szomorú volt a nyirbálások miatt. Hogy csillapítsuk rossz érzésünket, azt mondogattuk, hogy nem kidobjuk a funkciókat, csak késleltetjük a megvalósításukat – az Excel 6-ban implementáljuk majd a kevésbé fontosakat.

Ahogy az Excel 5 a befejezéshez közeledett, elkezdtünk dolgozni az Excel 6 specifikáción egy kollégámmal, Eric Michelmannel. Leültünk és átnéztük azokat az „Excel 6” funkciókat, amelyek kimaradtak az Excel 5 ütemtervéből. Teljesen megrázott bennünket, hogy a halasztott funkciók a mind ócskák voltak. Egyik funkció sem érte meg, hogy megvalósítsuk. Nem hiszem, hogy akár egy is megvalósult közülük, akár az elkövetkezendő három kiadásban. A funkciók kiválogatása volt a leghasznosabb dolog, amit tehettünk. Ha nem tettük volna, az Excel 5 kétszer olyan hosszú lett volna, és funkciók 50%-a használhatatlan szemét lenne (egyáltalán nincs kétségem, hogy pontosan ez történt a Netscape 5/Mozillával: nem volt ütemtervük, nem volt jól meghatározott funkciólistájuk, senki sem volt, hogy meghúzza a funkciókat, és ezért sohasem lett kiadva. Mikor kiadják, teli lesz ál-funkciókkal, mint az IRC-kliens, amelyre egyszerűen kár lenne időt fordítani. (Pontosan ez is történt – ford. megj.)).

Függelék: amit tudnod kell az Excelről

Az egyik oka, hogy az Excel olyan remek termék szoftverütemtervek készítésére, egyszerűen az, hogy a legtöbb Excel programozó kizárólag az ütemterv karbantartására használja az Excelt! (Nem sokuknak van szüksége az üzleti mi-lenne-ha forgatókönyvekre… végülis ők programozók!)

Közös használat (Shared Lists): az Eszközök/Közös használat parancs lehetővé teszi, hogy egyszerre többen megnyissák a fájlt, még szerkeszthetik is párhuzamosan. Mivel a teljes csapatod rendszeresen frissíti az ütemtervet, ez sokat segít.

AutoSzűrő (AutoFilter): ezzel a beállítással remekül lehet szűrni az ütemtervben, például a csak neked kiadott funkciókra. Az AutoRendezéssel (AutoSort) kombinálva láthatod a neked kiosztott funkciókat, prioritás szerint: rendezve, ez valójában a te „tennivalóid” listája. Remek!

Kimutatások (Pivot tables): ez hasznos összesítők és kereszttáblázatok készítésére. Például készíthetsz egy grafikont, amely a fennmaradó órákat mutatja minden fejlesztőnek, prioritásonként leválogatva. A kimutatás olyan, mint a szeletelt kenyér és csokoládés turmix. Meg kell tanulni használni, mert milliószor hatékonyabbá teszi az Excelt.

A WORKDAY függvény az Excel Analysis Toolpak bővítményéből szintén csodás módszer, hogy naptári dátumokká alakítsd a Fájdalommentes Ütemterv számadatait.

Egy kérdés és válasz a cikkel kapcsolatban: Bűvészmutatványok Excelben

A Safari Software ingyenesen közzé tett egy feladatkezelő Excel sablont, a MasterList-XL-et, a cikkben szereplő alapelvek figyelembe vételével.