Inhoudsopgave:
software projectschatting
Pixabay
Invoering
Schatten is gewoon moeilijk. Helaas is het ook erg nodig. Bedrijven gebruiken schattingen om vrijgaveschema's te projecteren, toezeggingen aan hun klanten te doen, te beslissen of een voorgestelde functie de moeite waard is om te implementeren, de snelheid van teams te volgen en het werk effectief te prioriteren. Leidinggevenden willen vaak weten wanneer een functie of product klaar is voor productie. Softwareontwikkeling is immers geen triviale investering. Hoe zou de projectmanager zonder schattingen een beoordeling maken? Als mensen de toekomst nauwkeurig zouden kunnen voorspellen, zouden mensen niet 2% van de tijd winnen bij paardenrennen. Schatten is het grote raadsel. Het is essentieel en noodzakelijk dat bedrijven hun mensen vragen het onmogelijke te doen: de toekomst voorspellen.
Laten we eerst enkele populaire schattingsmethoden bekijken (voor het geval u wat van de opwinding hebt gemist). Dan kunnen we kijken wat dit voor ons en onze projecten betekent.
Het waarzegger-model
Dit model vereist bijna geen inspanning om een schatting te maken. Schatters denken even na over wat er moet gebeuren om een functie te implementeren en te testen, en gooien dan een cijfer weg. Het klinkt veel als "… (lange pauze)… Ummmmm… 6 weken." Dan knikt iedereen en gaan we verder. Ze zouden een hele tijd aan de voorkant kunnen doorbrengen met praten over wat ze weten over de vereisten (wat waarschijnlijk niet het volledige plaatje is). Door deze zorgvuldige analyse voelt hun schatting betrouwbaarder aan. Aan het einde van het project is er altijd een geaccepteerde reden waarom de schatting zo ver van de werkelijkheid afwijkt. Er zijn altijd onvoorziene omstandigheden die als zondebok kunnen dienen. Het komt vaak niet bij iemand op dat het model ernstige gebreken vertoont.
Dus hoe kunnen we dit proces verbeteren? Ik weet! We kunnen de Decompositietechniek gebruiken (dwz verdeel en heers). Bij deze benadering wordt ervan uitgegaan dat u de volledige reikwijdte van de functie of het project aan de voorkant kent. Elke functie is onderverdeeld in hapklare brokken. Elk deel wordt geschat (waarzegger-stijl), daarna tellen we ze op om een algemene functie / projectschatting te krijgen. Dit is zeker een meer gecompliceerde benadering, maar het lijkt om twee redenen beter:
- Kleinere stukken werk zijn doorgaans gemakkelijker betrouwbaar in te schatten.
- Hoewel er nog steeds kans is op fouten (+/- een bepaald bedrag), wordt aangenomen dat de fouten elkaar opheffen wanneer u alles optelt en u een betrouwbaardere algemene schatting krijgt.
De fundamentele fout met deze benadering is dat individuele medewerkers (de mensen die het werk daadwerkelijk doen) universeel onderschatten. Ze zijn nog steeds aanzienlijk beter dan die boven en om hen heen, maar dat is geen hoge lat. Dit lijkt niet het geval, want we hebben allemaal gevallen gezien waarin ontwikkelaars zichzelf verrasten door iets eerder dan gepland te bereiken. Maar dit is een enkel gegevenspunt, geen trend. Mensen winnen eigenlijk af en toe in het casino; geef een jaar lang elke dag geld uit in een casino en je hebt minder geld dan waarmee je begon. Als u schattingen versus werkelijke waarden gedurende een jaar of twee bijhoudt, zult u ontdekken dat de schattingen achterblijven bij de werkelijkheid. Hoewel veel zakenmensen er absoluut zeker van zijn dat ontwikkelaars hun schattingen lui opvullen en de extra tijd gebruiken om hun voorraden te 'vergulden' of te controleren,uit de gegevens blijkt anders. De "annuleringsstrategie" werkt niet.
Dus wat nu? Laten we het waarzegermodel achterwege laten en overschakelen naar een op grootte gebaseerde benadering. Het blijkt dat, hoewel mensen behoorlijk slecht zijn in het inschatten van de doorlooptijd, we eigenlijk best goed zijn in het zeggen hoe groot iets is. We zijn vooral goed in vergelijkende maten ("het is groter dan dat, maar kleiner dan dat daar"). Als we denken in termen van grootte of complexiteit in plaats van in tijd, verwerken onze hersenen het betrouwbaarder. Dan kunnen we de grootte-waarden nemen en het werkelijke aantal uren voor het project berekenen op basis van een handige magische formule! En dat is wanneer het populaire functiepuntenmodel de scène binnenkomt (podium links).
Functiepuntanalyse (FPA)
Voor functiepuntanalyse moeten we vijf soorten dingen in onze applicatie identificeren: externe inputs, externe outputs, externe vragen, externe interfacebestanden en interne logische bestanden (maak je niet al te veel zorgen over definities; je kunt die later onderzoeken). Elk voorbeeld daarvan (een functie) heeft een bijbehorende complexiteit (laag, gemiddeld of hoog). We gebruiken de onderstaande tabel om erachter te komen hoeveel punten elke functie krijgt toegewezen.
Als we nu de punten voor al onze functies bij elkaar optellen, krijgen we misschien een getal als 457 functiepunten voor ons project. Dan hebben we alleen een formule nodig om het aantal uren te berekenen… Op basis van ons laatste project was ons “leveringspercentage” 15 functiepunten per persoon per maand. Dat is ongeveer 30 mensmaanden werk, wat iets meer dan twee en een halve maand zou kosten voor mijn team van 12. Ta-da!
Dit is zeker complexer dan ons vorige model. In feite zijn er vier belangrijke gebieden van complexiteit om te herkennen.
- De vijf componenttypen zijn niet per se intuïtief, en het is gemakkelijk om iets in de lijst te vergeten of aan de verkeerde bucket toe te wijzen.
- De tabel die wordt gebruikt om de functiepunten daadwerkelijk te genereren, bevat magische getallen die veel moeite zouden kosten om te valideren. Zijn deze cijfers correct gekalibreerd om betrouwbare schattingen voor mijn teams te genereren?
- Het leveringspercentage (een cruciaal stukje van de puzzel) wordt berekend op basis van de productiviteit van uw team. Hoe vaak moeten we een nieuw getal berekenen? Hier zijn eigenlijk heel weinig richtlijnen voor.
- Wat is een lage, gemiddelde of hoge complexiteit? Hoe definiëren we dat zodat iedereen het begrijpt? Is dat juist niet cruciaal voor de nauwkeurigheid van onze berekeningen?
Er zijn verschillende bewegende delen in dit zeer eenvoudige voorbeeld en we hebben niet eens gesproken over meer gecompliceerde complexiteitsmodellen en de andere gegevens die een rol kunnen spelen (bijv. Kostentarief, ondersteuningspercentage, defectdichtheid, enz.). Meer bewegende delen betekent meer kans op fouten. Maken we schattingen nu te ingewikkeld? We betalen ontwikkelaars niet om veel tijd te besteden aan schattingen. Ik kan geen schatting aan mijn klanten verkopen. Ik heb werkende software nodig. Is er nog iets anders?
Agile gaan
Laten we nu eens kort kijken naar agile scrum (net genoeg om een vergelijking te maken). Zoals eerder vermeld, zijn mensen slecht in het inschatten van de tijd en zijn ze redelijk goed in het vergelijken van maten. Hier zijn een paar termen die u moet begrijpen:
- Een sprint - een tijdsperiode (meestal twee weken).
- Gebruikersverhaal - een discreet stuk werk, bij voorkeur klein genoeg om door één persoon in een sprint te worden gedaan. Dit schatten we in.
De meest populaire strategie is het gebruik van een fibonacci-reeks (0, 1, 2, 3, 5, 8, 13) voor schattingen. Het is niet lineair - naarmate je hoger gaat, worden de gaten groter. De sleutel is dat de hiaten groot genoeg moeten zijn, zodat er geen reden is om over onbeduidende verschillen te discussiëren. Als je eenmaal boven de 3 komt, is het verschil tussen 4 en 5 of 7 en 8 zo verwaarloosbaar dat het zinloos is om tijd te besteden aan het uitzoeken welke het is. Een base-2-reeks zou ook werken (0, 1, 2, 4, 8, 16, etc.).
'Maar wacht, dit is maar een nummer. Wat betekent het? Hoeveel uur is een punt? " Punten zijn niet bedoeld om direct te correleren met uren, want als ze dat deden, zouden teams in de verleiding komen om terug te gaan naar schatten in uren en dat dan op de een of andere manier om te rekenen naar punten. Zoals eerder besproken, komt de nauwkeurigheid van onze schattingen voort uit vergelijkende dimensionering en niet door het aantal uren te schatten dat iets zal duren. Als u het team de mogelijkheid geeft om in uren te denken, brengt u uw vermogen om nauwkeurig in te schatten in gevaar.
Stel dat u bent begonnen met een kalibratie-oefening. Trek je team een kamer binnen en leid ze door een lijst van 10-12 gebruikersverhalen. Kies er een die klein maar niet de kleinste is en doe dat eerst. Bekijk het en kondig aan dat dit verhaal een "3" is. Je vraagt het niet. Je vertelt het. Ga dan verder met het volgende verhaal. "Als dat een 3 was, wat is dit dan?" Nu vergelijkt het team verhalen ten opzichte van andere verhalen. Uiteindelijk zullen ze een redelijk goed idee hebben wat een "1", een "2", enz. Is, enz. Ze maken geen schatting. Tijd doet er niet toe. Ze maken verhalen op maat, in vergelijking met andere verhalen die al een nummer hebben. U kunt dan voorbeeldverhalen voor elk nummer in de reeks in een document plaatsen dat een liniaal wordt genoemd. Ze kunnen dat als referentie gebruiken als ze niet zeker weten wat een "5" is.
Nu is hier de sleutel. De magische saus die dit laat werken is "snelheid" (het aantal punten dat een team kan voltooien in een sprint, gemiddeld over 3-4 sprints). Stel dat uw sprint twee weken duurt en uw team van 8 personen een gemiddelde snelheid van 35 punten heeft. Je krijgt 35 punten behaald in 640 uur werk (8 x 80 uur). Als we erachter komen dat een functie ongeveer 100 punten aan werk gaat kosten, van begin tot einde, dan weet ik dat dat ongeveer 6 weken werk en ~ 1900 uur is. Het team wordt erg goed in het consequent rangschikken van verhalen, en u gebruikt dat om uw projectplanning te doen. Deze berekening werkt omdat de duur consistent is van sprint tot sprint.
Om langetermijnplanning op hoog niveau te doen, kunt u uw leads vragen om functies op hoog niveau op te splitsen in tussentijdse oneliner-verhalen en er puntwaarden op te zetten. Er gaat een zekere mate van nauwkeurigheid verloren, maar je maakt gebruik van het model dat ze al begrijpen. Een nauwkeuriger pad is de relatieve grootte op kenmerkniveau. "Dit kenmerk is groter dan dat 40-punts kenmerk, kleiner dan dat 120-punts kenmerk daar, en iets groter dan het 65-punts kenmerk dat we zojuist hebben gedaan." Verhalen zijn gegroepeerd in "heldendichten". Als elke functie een epos is, weet je aan het einde hoeveel punten er nodig waren om die functie te voltooien. Houd daarvan een geschiedenis bij en u kunt deze gebruiken voor uw releaseplanning.
Conclusie
Er zijn tegenwoordig tal van methodologieën in gebruik. Elk heeft voor- en nadelen. Op de een of andere manier moeten we erachter komen hoe we de nauwkeurigheid van onze schattingen kunnen maximaliseren, zodat we goede beslissingen kunnen nemen. Dat betekent niet dat onze schattingen nauwkeurig moeten zijn. Ze moeten gewoon nauwkeurig genoeg zijn om nuttig te zijn. Als u schattingen niet begrijpt, kunt u aannemen dat de schattingen niet kloppen omdat het team het niet goed heeft gedaan. Ze hebben de juiste schatting niet gemaakt, of ze hebben het project niet correct uitgevoerd. Mishandeling zal doorgaan totdat de schattingen verbeteren. Maar schattingen mogen nooit als een verplichting worden gebruikt. Het is een beste schatting op basis van de beperkte informatie die we vandaag hebben. Als er nieuwe informatie opduikt, moeten we schattingen laten herzien. Al het andere verwacht het onmogelijke, wat een probleem is met leiderschap (niet met het team).
De aanpak van Scrum is veel eenvoudiger dan wat we zien in functiepuntanalyse. En ik zou zeggen dat het veel betrouwbaarder is dan magische tafels met magische getallen. Het krijgt de meeste waar voor zijn geld (minimale inspanning met een redelijk hoge mate van nauwkeurigheid). Vanuit het oogpunt van inspanning creëert het geen zwaar proces dat de teams kunnen begrijpen en gebruiken. Het schattingsstuk van agile kan eigenlijk heel snel gebeuren als iedereen de details van het geschatte werk begrijpt. Het is zeker beter dan cijfers uit de lucht halen. Het benutten van snelheid doet iets heel belangrijks: het brengt historische gegevens in de berekening. Elke sprint herberekent je snelheid. Dit is van cruciaal belang, omdat de doorvoer na verloop van tijd verandert. Teams die FPA gebruiken, kunnen hun leveringspercentage afleiden uit hun vorige project,wat in sommige gevallen enkele maanden geleden was. Sindsdien is er waarschijnlijk veel veranderd. Mijn suggestie is om Agile te verkennen en echt moeite te doen om verhaalpunten en snelheid te begrijpen. Val niet terug op schatten in uren, alleen maar omdat u dat begrijpt. Ik denk dat je jezelf later zult bedanken.