Afkortings: Waarvoor staan ​​DEAD en DITO?

Ek ontwikkel, definieer, integreer en skat projekte al meer as 'n dekade. Nadat ek met honderde maatskappye gewerk het, sowel as met talle interne ontwikkelings- en eksterne konsultasiemaatskappye, is ek altyd verbaas oor hoe verkeerd die bedryf altyd is met die opstel van ramings vir voltooiing en spertye vir voltooiing. As gevolg hiervan het ek die nuwe DEAD- en DITO-berekeninge beraam vir projekskatting en voltooiing. Hier is hulle:

DOOD: Skattings en sperdatums vir ontwikkeling:

1. Verkoopsbestuur: Die verwagtinge van die kliënt sal neem 25% langer ontwikkel as die werklike projek wat deur die verkoopsman belowe is.
2. Funksionele vereistes: Die funksionele vereistes wat u gedefinieer het, sal nie werk nie. Voeg by 25% meer beplanningstyd om te verseker dat funksionele vereistes werklik geïmplementeer kan word op grond van u stelselargitektuur en toepassingskoppelvlak.
3. Funksionele vereistes: Die funksionele vereistes wat u gedefinieer het, sal nie regtig ontwikkel word soos u verwag het nie. Dit het iets te doen met die taalhindernisse van Klingon versus Engels (of andersom) tussen ontwikkelaar en produkbestuurder. Voeg by 25% meer ontwikkelingstyd vir u projek, pre-release om te verseker dat dit volgens u vereistes ontwikkel word.
4. Projekbestuur: Die werklike ontwikkeling sal neem 25% langer om te ontwikkel as die werklike skatting van die projek.
5. Gebruik gevalle: Die sake-gebruiksgevalle wat u omskryf het, bestaan ​​slegs uit 25% van die werklike gebruiksgevalle wat aangegaan sal word. Voeg 50% meer ontwikkelingstyd by u projek, na vrystelling, om aan te pas vir werklike gebruik teenoor verwagte gebruik. Dit sluit funksionaliteit sowel as prestasie in.

DOOD toegepas:

1. Projek word beraam en verkoop vir 10 werksdae voltooi.
2. Dit sal eintlik 12.5 dae neem om te voltooi soos belowe.
3. Dit sal eintlik 15.625 dae neem om probleme met verkeerde of gemisde vereistes op te klaar.
4. Dit sal eintlik 19.53125 dae neem om die projek te voltooi soos dit behoorlik omskryf is.
5. Die projek is dus binne ~ 20 dae voltooi.
6. Nadat dit bekendgestel is, sal dit nog tien dae benodig om uitstaande kwessies reg te stel.
7. Die totale projektyd is 30 dae.

DITO: Ontwikkelaarslapeloosheid en uithaal.

Gelukkig het ons ondernemings egter die DITO-kompenserende faktor om toe te pas, die projek te stoor en die volgende projek aan te haal.

DITO toegepas:

1. Die ongelooflike ontwikkelaars wat u aangestel het, is eintlik slapeloosheid en kan dikwels 8 werksure in baie meer strek, insluitend naweke. 'N 100% toename in produktiwiteit Besparings: ~ 10 dae. Nou is ons net tien dae te laat.
2. Deur programmeurs met uithaal-voedsel te verheug, kan u naweke wen en maaltye deurwerk. (Ontwikkelaars is briljante ouens, maar ek het altyd gewonder hoekom 'n programmeerder van $ 75 / uur 'n uur middagete sou werk vir 'n pizza van $ 10 ... wie weet ?!). Besparings: ~ 25%. Nou is ons net 5 dae laat.
3. Aangesien sperdatums opduik en kliënte kwaaier word, moet u Mountain Dew by die Take-Out voeg, maar dit lei soms tot 24 tot 36 uur direkte programmering. Die oplossing wat hieruit voortspruit, sal vrygestel word, met foute (soms as gevolg van pizzakorskrummels in die sleutelbord) op tyd.
4. ditotoegepas na vrylating lei tot 'n besparing van 5 dae op verbetering na vrylating.

Die kombinasie van die DOOD en dito berekeninge het 'n eenvoudige 1.5-veelvoud by voltooiing van die projek. Gebruik altyd 50% meer tyd vir voltooiing van projekte as wat u verwag.

NOTA: Die akroniem DOOD is van toepassing omdat ontwikkelaars gemiddeld 25% gouer sal sterf as die gewone werknemer weens komplikasies as gevolg van slaap, hoë bloeddruk, suikersiekte en gewigsprobleme deur Pizza, Donuts, Mountain Dew en Coffee wat deur die werkgewer gekoop is. dito is van toepassing omdat u verkopers die oorspronklike skatting sal toepas op die volgende projek wat verkoop word.