Ik zal de vraag vanuit het perspectief van software engineering behandelen, hoewel veel van de geleerde lessen ook van toepassing zijn op andere projecten. Het produceren van nauwkeurige project schattingen is een van de moeilijkste taken om te doen in software engineering en een vaak over het hoofd gezien vaardigheid die de meeste ingenieurs (mezelf inbegrepen) niet weten hoe goed te doen. Het is ook het geval dat mensen die niet nodig hebben om de voltooitijden voor projecten schatten eerder de neiging om de moeilijkheid te onderschatten en vaak krijgen hun schattingen verkeerd met ten minste een factor twee. Zoals elke vaardigheid, wordt men alleen beter met oefening.
mijn meest levendige herinnering aan projectramingen die fout waren gegaan gebeurde een paar maanden nadat ik was toegetreden als ingenieur bij Ooyala, een startup die een end-to-end online videoplatform bood. In augustus 2008, iets meer dan een jaar na de oprichting van het bedrijf, begon het ingenieursteam te werken aan een herschrijving van de Flash-gebaseerde videospeler van het product. Onze doelen waren om de speler modulair en performanter te maken en ook een schonere en beter geteste codebase te hebben. Een eerste team van 3 mensen ontwierp en schreef een aantal kerninfrastructuur voordat ik en de rest van de ~10-persoons engineering team. Ze schatten 4 maanden voor het project te voltooien, en de CTO en product manager produceerde Gantt grafieken een samenvatting van de verdeling van het werk en afhankelijkheden. De nieuwe speler eindigde volledig lancering 9 maanden later in Mei 2009 .
we misten het doel niet door gebrek aan hard werken of getalenteerde ingenieurs; er waren een reeks maanden waarin de meeste mensen in het team 70-80 uur weken trokken (niet aanbevolen). Een deel van het project, we gingen zelfs zorgvuldig door een paar dagen van oefeningen waar we uurlijkse schattingen toegewezen aan vrij korrelig taken. De grootste vertragingen waren bijna altijd het gevolg van factoren, vele externe factoren, die wij in de oorspronkelijke ramingen niet in aanmerking hebben genomen.:
- hoge prioriteit klant behandelt wordt ondertekend dat nodig ingenieurs context switch naar aangepast werk,
- fouten in Adobe ‘ s flash player code dat maakte het moeilijk om nauwkeurig te bepalen wanneer de video was eigenlijk onderbroken, buffering en spelen,
- moeilijk te reproduceren video corruptie bugs die crash van de speler bij het zoeken naar bepaalde video-frames in IE
- productontwikkeling hoeft te hervatten 4 maanden in het project in stand te houden op het huidige klantenbestand gelukkig,
- schaalbaarheid problemen die moeten worden aangepakt als het bedrag van de analysegegevens groeiden,
- een vroege ingenieur verliet het team halverwege het project, waardoor een grote hoeveelheid kennisoverdracht van belangrijke delen van de codebase nodig was,
- enz.
hoewel het herschrijven van de speler absoluut noodzakelijk was voor het bedrijf, eiste de onvoorziene manier waarop dragged out een grote tol bij het vroege opstarten. Andere projecten die ik heb gewerkt aan, gezien tweedehands, of sprak met andere ingenieurs over, hebben dezelfde patronen gevolgd waar de werkelijke voltooiing tijd vaak verdubbelt de oorspronkelijke schattingen.
hier zijn enkele van mijn lessen die ik tot nu toe uit deze ervaringen heb geleerd:
laat de mensen die de schattingen voor een taak maken zoveel mogelijk de werkelijke mensen zijn die eraan zullen werken. Dit is vergelijkbaar met Ian McAllister ‘ s punt van het gebruik van de schatting van de B-speler – het is al ongelooflijk moeilijk voor een persoon om nauwkeurig te voorspellen hoe lang een lijst van taken zou duren om zichzelf te doen, zelfs als de taken zijn vrij korrelig; het is nog moeilijker om te voorspellen hoe lang het zou duren iemand anders met een andere mate van vertrouwdheid en een andere mate van vaardigheid. Het werd duidelijk tijdens Ooyala ‘ s speler herschrijven dat veel van de eerste schattingen waren extreem agressief en negeerde een ingenieur rampup tijd op Delen van de codebase die hij minder bekend was met.
pas op voor het effect van het tweede systeem. In The Mythical Man-Month beschrijft Frederick Brooks vanuit zijn projectervaringen bij IBM hoe een menselijke neiging om het tweede systeem te over-ontwerpen leidt tot aanzienlijk grotere complexiteit, waardoor tijdschema ‘ s van redesignprojecten wegglijden :
het eerste werk van een architect is vrij en schoon. Hij weet dat hij niet weet wat hij doet, dus hij doet het voorzichtig en met grote terughoudendheid.
terwijl hij het eerste werk ontwerpt, komen franje na franje en versiering na versiering bij hem op. Deze worden opgeborgen om de volgende keer gebruikt te worden.”vroeg of laat is het eerste systeem klaar en is de architect, met een sterk vertrouwen en een bewezen beheersing van die klasse van systemen, klaar om een tweede systeem te bouwen.
deze tweede is het gevaarlijkste systeem dat een mens ooit ontwierp… De algemene tendens is om het tweede systeem te over-ontwerpen, met behulp van alle ideeën en franje die voorzichtig werden afgeleid op de eerste.
vooral voor een project dat gaat om het herschrijven van bestaande software, het is verleidelijk om een hoop nieuwe functies te bundelen in wat anders zou kunnen zijn een eenvoudige poort, met behulp van het argument dat het team net zo goed kan doen als ze gaan om de codebase toch te herschrijven. De toegenomen complexiteit kan leiden tot noch de herschrijving noch de nieuwe functies lanceren tot aanzienlijk later.
wees voorzichtig met het combineren van hoeveel tijd de taken van een project zullen duren met hoe snel een project zal eindigen. Hoe langer een project duurt, hoe groter de kans dat externe omgevingsvariabelen in het spel komen en de totale projecttijdlijn verlengen. De terugkerende sleep die Ian noemt draagt bij aan de tijdlijn van een project, maar dat doen ook onverwachte gebeurtenissen. Voor projecten waar ik eerder dit jaar bij Quora aan heb gewerkt, duurde een aantal ervan langer dan verwacht vanwege de cumulatieve tijdskosten van:
- reageren op en herstellen van een onverwachte, meerdaagse AWS-uitval,
- omgaan met periodieke pager-waarschuwingen om de site up te houden,
- geplande vakanties die ooit ver weg leken van een project, maar die er uiteindelijk overlappen,
- voorbereiden op en bijwonen van wervingsevenementen,
- contextverandering tussen meerdere projecten die lastiger bleek dan aanvankelijk verwacht.
voor elk project kan men waarschijnlijk een lijst maken van een aantal gebeurtenissen en afleidingen die individueel onwaarschijnlijk of ongecompliceerd kunnen zijn, maar die gezamenlijk moeten gebeuren en over een voldoende lange periode moeten worden opgeteld. Hoe langer het project, hoe meer afleiding er zal zijn, en het is belangrijk om de begroting buffer tijd voor externe, onbekende factoren.
Budget voldoende tijd voor integratiegerelateerde taken. Vooral voor projecten met veel onderling verbonden componenten hebben veel ingenieurs de neiging om 1) end-to-end integratietaken tot het uiterste uit te stellen, en 2) De tijd die nodig is om alle onderdelen samen te integreren in een werkend systeem aanzienlijk te onderschatten. Omdat integratie de neiging heeft zo ver weg te zijn en omdat de risico ‘ s typisch onbekend zijn-de aanname door integratietijd is dat alle componenten succesvol in isolatie werken-is het onderschatten van integratietijd vrij gebruikelijk. Projecten krijgen vaak slechts een minuscuul fractie van de totale projecttijd toegewezen voor end-to-end testen, hoewel het meestal een van de risicovollere aspecten van een project is en, in vergelijking met eerdere mijlpalen, aanzienlijk meer communicatie overhead tussen teamleden vereist.
het gevolg hiervan is dat zo vroeg mogelijk met end-to-end-tests wordt begonnen om integratierisico ‘ s en-problemen sneller op te sporen, zodat er voldoende tijd is om ze aan te pakken.
schatten op basis van hoe lang taken daadwerkelijk zullen duren, niet op basis van hoe lang u of iemand anders ze wilt nemen. Er zal altijd druk zijn om projecten sneller te voltooien, hetzij van jezelf, van je teamleden, van het management, of van klanten, en vaak wordt de emotionele reactie op die druk ons verankerd in extern geëiste tijdlijnen en leidt ons tot systematisch onderschatten taken. Psychologisch wil niemand andere mensen teleurstellen, en het is gemakkelijk om jezelf te vertellen dat als je gewoon wat harder of efficiënter werkt, je een bepaalde deadline kunt halen. Vooral bij lange projecten is dit soort wishful thinking echter uiteindelijk onhoudbaar.
periodiek projectramingen herzien en herzien naarmate het project vordert. Net zoals hoe de meeste goede software is gebouwd en verbeterd op stapsgewijs, zo zijn ook project schattingen. Het opnieuw bekijken van projectramingen en het vergelijken van schattingen voor taken in de afgelopen week met de werkelijke tijd die nodig is, helpen om inschattingsfouten aan de oppervlakte te brengen en om schema ’s te herzien op basis van eerder onvoorziene risico’ s.
projectramingen zijn bijna altijd eerder onderschatting dan overschatting; men hoort zelden dat lange projecten eerder dan gepland eindigen. Bewust zijn dat project schatting is moeilijk en nadenken over waarom schattingen ging mis op een bepaald project zal u begeleiden naar kleinere schatting fouten op de volgende projecten.
er is veel meer aan het uitvoeren van een project dan alleen het produceren van nauwkeurige schattingen. Als je een ingenieur bent en je wilt technieken die worden gebruikt door top software engineers beheersen om hun projecten om te zetten in successen, download dan een gratis, voorbeeldhoofdstuk van mijn boek, De effectieve Engineer. Het zit vol met honderden verhalen, inzichten en bruikbare strategieën van leiders in Silicon Valley.
———-
http://en.wikipedia.org/wiki/Gantt_chart
http://go.ooyala.com/Swift.html
http://www.the-wabe.com/notebook/second-system.html