foglalkozom a kérdéssel szemszögéből szoftverfejlesztés, bár sok a tanulságok is vonatkoznak más projektek is. A pontos projektbecslések készítése az egyik legnehezebb feladat a szoftverfejlesztésben és egy gyakran figyelmen kívül hagyott készség, amelyet a legtöbb mérnök (beleértve magam is) nem tudja, hogyan kell jól csinálni. Az is előfordul, hogy azok az emberek, akiknek korábban nem kellett becsülniük a projektek befejezési idejét, hajlamosak alábecsülni a nehézséget, és gyakran becsléseiket legalább kétszeresére tévesztik. Mint minden készség, az ember csak a gyakorlattal lesz jobb.
a projektbecslések legélénkebb emléke néhány hónappal azután történt, hogy csatlakoztam mérnökként az Ooyala-hoz, egy startuphoz, amely végpontok közötti Online video platformot biztosított. 2008 augusztusában, alig több mint egy évvel a cég alapítása után, a mérnöki csapat megkezdte a termék Flash-alapú videolejátszójának átírását. Célunk az volt, hogy a játékos modulárisabb és teljesítményesebb legyen, és tisztább és jobban tesztelt kódbázissal rendelkezzen. Egy 3 fős kezdeti csapat tervezett és írt néhány alapvető infrastruktúrát, mielőtt behúzta magam és a ~10 fős mérnöki csapat többi részét. Becslések szerint 4 hónap telt el a projekt befejezéséig, a CTO és a termékmenedzser pedig Gantt-diagramokat készített, amelyek összefoglalták a munka lebontását és függőségeit. Az új játékos végül 9 hónappal később, 2009 májusában indult el teljesen .
nem a kemény munka vagy a tehetséges mérnökök hiánya miatt hiányzott a cél; volt egy sor hónap, amikor a csapat legtöbb embere 70-80 órát húzott (nem ajánlott). A projekt során, még néhány napos gyakorlatokat is gondosan átéltünk, ahol óránkénti becsléseket rendeltünk a meglehetősen szemcsés feladatokhoz. A legnagyobb késések szinte mindig tényezőkből adódtak, sok külső, hogy nem vettük figyelembe a kezdeti becslésekben:
- kiemelt ügyfélkapcsolatokat írtak alá, amelyek megkövetelték a mérnököktől a kontextusváltást az egyéni munkára,
- az Adobe flash player kódjának hibái, amelyek megnehezítették a videó tényleges szüneteltetésének, pufferelésének és lejátszásának pontos meghatározását,
- nehezen reprodukálható videó korrupciós hibák, amelyek összeomlasztják a lejátszót, amikor bizonyos videofelvételeket keresnek az IE-ben,
- termékfejlesztés folytatásához szükséges 4 hónapokkal a projektbe annak érdekében, hogy a jelenlegi ügyfélkör boldog legyen,
- skálázhatósági problémák, amelyeket a az elemzési adatok növekedtek,
- egy korai mérnök elhagyta a csapatot a projekt közepén, ami nagy mennyiségű tudástranszfert tett szükségessé a kódbázis nagy részeiben,
- stb.
míg a játékos újraírása feltétlenül szükséges volt a vállalat számára, az előre nem látható módon, amelyben elhúzódott, nagy károkat okozott a korai indításkor. Más projektek, amelyeken dolgoztam, használt, vagy más mérnökökkel beszéltem, hasonló mintákat követtek, ahol a Tényleges befejezési idő gyakran megduplázza az eredeti becsléseket.
íme néhány elvihető tanulságom eddig ezekből a tapasztalatokból:
amennyire csak lehetséges, a feladat becsléseit előállító emberek legyenek a tényleges emberek, akik dolgozni fognak rajta. Ez hasonló Ian McAllister pont a B-player becslés — ez már hihetetlenül nehéz egy személy pontosan megjósolni, hogy mennyi ideig egy listát a feladatok venné magát csinálni, akkor is, ha a feladatok meglehetősen szemcsés; ez még nehezebb megjósolni, hogy mennyi ideig tartana valaki más a különböző fokú ismerete és a különböző fokú készség. Ooyala játékos-átírása során nyilvánvalóvá vált, hogy a kezdeti becslések közül sok rendkívül agresszív volt, és figyelmen kívül hagyta a mérnök rampup idejét a kódbázis azon részein, amelyeket kevésbé ismert.
Óvakodj a második rendszer hatásától. A mitikus Emberhónapban, Frederick Brooks az IBM-nél szerzett projekttapasztalataiból leírja, hogy a második rendszer túlzott tervezésére való emberi hajlam jelentősen megnövekedett komplexitáshoz vezet, ami az újratervezési projektek ütemterveinek csúszását okozza :
egy építész első munkája alkalmas arra, hogy takarékos és tiszta legyen. Tudja, hogy nem tudja, mit csinál, ezért óvatosan és nagy visszafogottsággal teszi.
amikor megtervezi az első művet, Fodor után Fodor, díszítés után díszítés történik vele. Ezek kap tárolt el kell használni ” legközelebb.”előbb vagy utóbb elkészül az első rendszer, és az építész szilárd bizalommal és a rendszerek ezen osztályának bizonyított mesteri képességével készen áll egy második rendszer felépítésére.
ez a második a legveszélyesebb rendszer, amit ember valaha tervezett… Az általános tendencia az, hogy túltervezik a második rendszert, felhasználva az összes ötletet és sallangot, amelyek óvatosan mellékvágányra kerültek az elsőnél.
különösen egy olyan projekt esetében, amely magában foglalja a meglévő szoftverek átírását, csábító egy sor új funkciót csomagolni az egyébként egyszerű portba, azzal az érvvel, hogy a csapat is megteheti, ha egyébként átírja a kódbázist. A megnövekedett bonyolultság nem vezethet sem az átíráshoz, sem az új funkciók elindításához, csak jelentősen később.
ügyeljen arra, hogy a projekt tevékenységei mennyi időt vesznek igénybe, és mennyi idő múlva fejezik be a projektet. Minél tovább tart egy projekt, annál nagyobb a valószínűsége annak, hogy külső környezeti változók lépnek működésbe, és meghosszabbítják a projekt teljes ütemtervét. Az Ian által említett ismétlődő húzás hozzájárul a projekt idővonalához, de a váratlan események is. Azoknál a projekteknél, amelyeken az év elején dolgoztam a Quora-nál, számuknak a vártnál hosszabb ideig tartott az indítása a kumulatív időköltségek miatt:
- válaszadás és felépülés egy váratlan, többnapos AWS leállás után,
- perioidikus személyhívó-riasztások kezelése a webhely fenntartása érdekében,
- ütemezett vakáció, amely egykor távolinak tűnt egy projekttől, de átfedésben volt vele,
- felkészülés és részvétel toborzó eseményeken,
- kontextus váltás több projekt között ez trükkösebbnek bizonyult, mint az eredetileg várták.
bármely projekt esetében valószínűleg fel lehetne sorolni tetszőleges számú eseményt és zavaró tényezőt, amelyek külön-külön valószínűleg nem valószínűek vagy költségtelenek, de amelyek együttesen szükségszerűen megtörténnek és összeadódnak egy kellően hosszú időkereten belül. Minél hosszabb a projekt, annál több zavaró tényező lesz, és fontos a külső, ismeretlen tényezők időpufferének költségvetése.
költségvetés elegendő idő az integrációval kapcsolatos feladatokhoz. Különösen a sok egymással összefüggő komponenssel rendelkező projektek esetében sok mérnök hajlamos 1) A végpontok közötti integrációs feladatokat a legvégére halasztani, és 2) jelentősen alábecsülni az összes darabnak egy működő rendszerbe történő integrálásához szükséges időt. Mivel az integráció általában olyan messze van, és mivel a kockázatok általában ismeretlenek – az integrációs idő feltételezése az, hogy minden összetevő sikeresen elszigetelten működik-az integrációs idő alábecsülése meglehetősen gyakori. A projektek gyakran a teljes projektidőnek csak egy apró töredékét kapják meg a végpontok közötti teszteléshez, annak ellenére, hogy ez általában a projekt egyik kockázatosabb aspektusa, és a korábbi mérföldkövekhez képest lényegesen több kommunikációs költséget igényel a csapattagok között.
ennek az a következménye, hogy a lehető leghamarabb el kell kezdeni az end-to-end tesztelést az integrációs kockázatok és problémák mielőbbi azonosítása érdekében, hogy elegendő idő álljon rendelkezésre azok kezelésére.
becsülje meg a tevékenységek tényleges időtartamát, nem pedig az alapján, hogy Ön vagy valaki más mennyi ideig szeretné tartani őket. Mindig lesz nyomás a projektek gyorsabb befejezésére, akár önmagadtól, a csapattagoktól, a vezetőségtől vagy az ügyfelektől, és gyakran az érzelmi válasz erre a nyomásra lehorgonyoz minket a külsőleg igényelt ütemtervekhez, és szisztematikusan alábecsüli a feladatokat. Pszichológiailag senki sem akarja cserbenhagyni más embereket, és könnyű elmondani magának, hogy ha csak egy kicsit keményebben vagy hatékonyabban dolgozik, akkor betarthat egy bizonyos határidőt. Különösen a hosszú projektek esetében azonban ez a fajta vágyálom végül fenntarthatatlan.
a projekt előrehaladásával rendszeresen felülvizsgálja és felülvizsgálja a projekt becsléseit. Ahogy a legtöbb jó szoftver épül és javul fokozatosan, úgy a projektbecslések is. A projektbecslések felülvizsgálata és az elmúlt hét feladatainak becsléseinek összehasonlítása a tényleges idővel segít a becslési hibák feltárásában és a korábban előre nem látható kockázatok alapján történő ütemtervek felülvizsgálatában.
a Projektbecslések szinte mindig inkább alábecsülik, mint túlértékelik; ritkán hallani olyan hosszú projektekről, amelyek az ütemterv előtt befejeződnek. Ha tudatában van annak, hogy a projektbecslés nehéz, és elgondolkodik azon, hogy miért hibáztak a becslések egy adott projekten, akkor a következő projektek kisebb becslési hibáihoz vezet.
sokkal többet kell végrehajtani egy projekten, mint pontos becsléseket készíteni. Ha mérnök vagy, és szeretné elsajátítani a legjobb szoftvermérnökök által használt technikákat, hogy projektjeiket sikerekké alakítsák, töltsön le egy ingyenes, minta fejezetet a könyvemből, a hatékony mérnök. Több száz történetet, betekintést és cselekvésre alkalmas stratégiát tartalmaz A Szilícium-völgy vezetőitől.
———-
http://en.wikipedia.org/wiki/Gantt_chart
http://go.ooyala.com/Swift.html
http://www.the-wabe.com/notebook/second-system.html