Waarom moet je schatting

0
36

,

HET Pro-Gids: Het is een vuile werk, maar iemand heeft om het te doen. Simon Jones ziet u hoe inschatting uw bedrijf kunnen helpen geld te besparen

Het schatten van de zwarte kunst van het project management. Het is niemands favoriete taak. Maar willen of niet het succes of falen van een project is afhankelijk van nauwkeurige schattingen. Pessimisme kan de dood van het project voordat het begint als de klant denkt misschien dat het te duur is. Overdreven optimistische schattingen, aan de andere kant kan kosten u of de klant graag bij het project uitloopt.

Waarom Schatting?

Als u voorstellen iets te doen deze dagen, is iemand die gebonden is om te vragen “wat gaat het kosten” of “hoe lang zal het duren”, die, wanneer u het bouwen van software, is bijna hetzelfde. Voor kleine projecten, deze vragen zijn relatief eenvoudig te beantwoorden.

De problemen zijn lelijke kop opsteekt, echter, als de grootte van het project toeneemt. Met meerdere programmeurs, gewijd testen teams en interfaces met bestaande systemen de tijd die nodig is voor grotere projecten lijkt exponentieel toenemen.

Hoe in te Schatten

Met de fallibilities van het menselijk geheugen en psyche, hebben we de neiging te vergeten onze fouten en overschatten onze mogelijkheden. Verwijst terug naar de tijden die specifieke taken nam in eerdere projecten kan u helpen, maar alleen als je het kan vinden met vergelijkbare taken met elkaar te vergelijken.
Evenzo, als u vertrouwen op een persoon uit te voeren, de schatten zal je een antwoord krijgen maar niets te meten tegen. Verschillende mensen hebben verschillende ideeën over hoe lang iets zal aan doen. Sommige mensen denken vanuit de bottom-up, waarbij alle kleine taken en het toevoegen van de tijd. Anderen denken van boven naar beneden, het schatten van de hoog-niveau taken en het verdelen van de tijd in de sub-taken.

Bottom-up-mensen zijn over het algemeen komen met een grotere schat dan top-down mensen, als het alleen door de granulariteit van hun schatten. Een top-down-jongen kunnen zeggen dat een taak duurt acht uur, maar een bottom-up persoon zou kunnen zeggen dat de tien sub-taken duurt ongeveer een uur elk.

Het vakmanschap, de kennis en ervaring van de betrokken personen moeten ook in aanmerking worden genomen. Een ervaren, hoogopgeleide programmeur kan 10 keer sneller dan een rookie, maar neem hem of haar uit hun comfort zone en hun productiviteit kunnen dalen. Het is natuurlijk voor mensen om in te schatten op basis van hun eigen ervaring en omdat de mensen verschillend zijn, zo zijn hun schattingen.

Breedband-Delphi

Het krijgen van veel mensen die betrokken zijn in de raming is een manier om dichter bij ‘de waarheid’ en het geeft het projectteam een gevoel van ‘ownership’ van de cijfers geproduceerd. Maar als je gewoon de gemiddelde waarden van de verschillende schattingen van het einde cijfers niet overeenkomen met iemands eerste schatting zo loopt u het risico van het vernietigen van een ‘buy-in’ van het team zou kunnen hebben van een deel van de schatten van het proces in de eerste plaats.

De Breedband-Delphi-methode helpt teams voor de ontwikkeling van het bereiken van een consensus over de schattingen voor een project, zodat die meer nauwkeurige cijfers en een meer betrokken en hecht team.

Het werkt als volgt: een team van drie tot zeven schatters van het project team afzonderlijke schattingen en vervolgens, samen met een moderator, de analyse van de veronderstellingen en problemen over de taken, het verfijnen van hun ramingen zoals ze gaan. Niemand blijkt de nummers, behalve aan de moderator en hij of zij trekt een project van iedereen totalen op een bord, als de kruisen op een getallenlijn. De anonieme aspect van deze methode helpt bij het elimineren van vooroordelen op basis van vooroordelen van mensen in de status of verschillende doelen.

Vier rondes van de schatting levert een goede schatting en de gemiddelde (het verdisconteren van de omliggende waarden) moet een accurate weerspiegeling is van het team denken.

Functie Punt Analyse

Waar Breedband Delphi maakt gebruik van de meningen van mensen over hoe lang een taak moet nemen, Functie Punt Analyse probeert om meer objectief.

In FPA lees de specificatie van de software, het identificeren van alle transacties, bestanden, rapporten, formulieren en dergelijke, en dan breken die in hun samenstellende elementen te worden ingedeeld, afhankelijk van hoe complex ze zijn en toegewezen numerieke waarden – de functie punten.

Deze worden vervolgens opgeteld en als je weet dat het team van de productiviteit (in functie punten per uur) je moet dan weten hoe lang het project gaat duren. De theorie is dat verschillende mensen uitgevoerd FPA aan hetzelfde project moet komen met het zelfde antwoord. In werkelijkheid, goed opgeleide mensen kunnen heel dichtbij komen, maar FPA is meer dan een beetje ingewikkeld om te leren.

Alternatief

Een radicaal alternatief te schatten is het niet te doen – al is onnodig te zeggen dat deze aanpak zal niet voor elk bedrijf van het project. Een software huis, belast met het onderhouden van een interne toepassingen, had een SLA (Service Level Agreement) die zei dat het enige wat ze hoefden te doen was om een raming te geven van hoe lang een reparatie of uitbreiding zou nemen binnen twee dagen na ontvangst van de aanvraag wordt ontvangen.

De schatten kostte zoveel tijd dat er geen tijd overblijft voor het daadwerkelijk uitvoeren van het werk. Een lange achterstand van het werk ook voor gezorgd dat er niets gebeurde snel. Het hele systeem van het werk was gebroken en moest een radicale verandering.

Door terug te kijken op het verleden werk vonden ze dat bijna alle oplossingen duurde ongeveer vijf man dagen, zodat ze gestopt te schatten, werd het onzinnige SLA en eenvoudig betalen een vast bedrag voor het hele jaar. Sommige oplossingen duurde vijftien dagen, maar veel maakte zo weinig als drie, zodat niemand verloren. Het verwijderen van de last van het schatten vrijgemaakt personeel om het werk te doen, de achterstand werd ontruimd en iedereen was gelukkig.

No pain, No gain

De raming is een pijn, maar het moet gedaan worden. De Extreme Programming methode zegt dat alleen de persoon die het werk doen, moeten schatten hoe lang het zal duren. Breedband Delphi gebruikt het team aanpak om de ‘buy-in’. FPA en Agile Programmeren beide pleiten voor het meten van de werken in meer of minder formele manieren, gebaseerd op prestaties uit het verleden.

Maar je doet het, hoewel, als het goed is heb je veel meer kans om van uw project komt in on-time en on-budget. En dat is het uiteindelijke doel.

Verder lezen

  • Boek: Software Engineering Economics door Barry Boehm http://www.amazon.com/gp/product/0138221227/sr=8-1/qid=1145964013/ref=pd_bbs_1/104-8200390-9611916?%5Fencoding=UTF8
  • Boek: van Toepassing is de Software Project Management door Andrew Stellman & Jennifer Greene http://www.amazon.co.uk/exec/obidos/ASIN/0596009488/qid%3D1145981862/026-6215175-2133257
  • Website: Karl Wiegers’ Proces Impact http://www.processimpact.com/pubs.shtml
    (vooral Stoppen Veelbelovende Wonderen http://www.processimpact.com/articles/delphi.html)
  • Website: Longstreet Consulting http://www.ifpug.com/default.htm
    (vooral De Fundamenten van Functie Punt Analyse http://www.ifpug.com/fpafund.htm)
  • Blog: David J Anderson ‘ s Agile Management http://www.agilemanagement.net/Articles/Weblog/blog.html (vooral Van Slechtste naar Beste in 9 Maanden http://www.agilemanagement.net/Articles/Papers/TOCICOBarcelona.html)