Schatting van softwarekosten - Waarom niet?

Soms heb ik het gevoel dat ik niet in dezelfde wereld leef als de rest. ik was (en ben), betrokken bij professionele softwareschatting, benchmarking, en contractprocessen voor bijna de helft van mijn leven, en nog steeds hebben de meeste mensen met wie ik praat geen idee waar dit over gaat. Vooral de 'groovy', stoer, nieuw, jong, super chill jongere generatie ', heeft geen idee waar ik het over heb. ‘Softwareschatting is moeilijk, en gaat altijd fout, dus waarom zou je het zelfs proberen??‘‘ #Noestimates ’, bekijk het op twitter, het is echt. En deze mensen zijn serieus! Ze geloven in de kracht van het team. Dit is gemakkelijker gezegd dan gedaan wanneer u een bedrijf moet runnen. Als een goede vriend van mij, die werkt voor een grote internationale systeemintegrator, vertelt het me altijd: 'Geen enkele klant heeft ons ooit een miljoen dollar gegeven met het verzoek om welke softwareoplossing dan ook te maken, zolang het enige zakelijke waarde oplevert '. Ik ben gewoon zo geïrriteerd wanneer mensen zeggen dat softwareschatting niet meer nodig is in de flexibele wereld van levering. Het is, en zelfs meer dan voorheen!

Agile teams gebruiken vaak verhaalpunten, een meeteenheid voor willekeurige inspanning die relatief is aan een bepaalde hoeveelheid werk. Verhaalpunten zijn niet herhaalbaar, niet verifieerbaar, niet objectief en niet verdedigbaar. Maar de agile community lijkt het IT-management op deze planeet te overtuigen dat metrische gegevens op basis van verhaalpunten nuttig zijn om managementbeslissingen te ondersteunen.

Het is echt alsof iemand de schilders ter wereld ervan heeft overtuigd om 'muurpunten' te gebruiken in plaats van een gestandaardiseerde metriek zoals vierkante meter om de afmetingen van de muren te meten en hun muurschilderingen te schatten. Ik denk niet dat veel mensen een quote zouden accepteren als ‘Ik zal je kosten in rekening brengen $ 100 per muurpunt ', Rechtsaf? Klopt gewoon niet, aangezien het aantal muurpunten nooit objectief kan worden gemeten, omdat het niet gestandaardiseerd is. Om een ​​quote te geven zoals ‘$ 100 per vierkante meter 'is heel logisch, omdat het gestandaardiseerd is, en daardoor transparant, voorspelbaar en verdedigbaar.

 

Alleen vandaag, Ik sprak met 2 verschillende klantorganisaties, beiden klagen dat hun leverancier, agile werken, onderschatte volledig de inspanning die nodig is om een ​​'must have'-stuk software te implementeren, resulterend in ernstige kosten en geplande overschrijdingen. Hoe is dit zelfs mogelijk in agile, je vraagt? Erg makkelijk! Hoewel het bereik variabel moet zijn, organisaties hebben nog steeds een bepaalde minimale set functioneel nodig (en niet functioneel) gebruikersvereisten om op een bepaald moment klaar en geïmplementeerd te zijn en daar wordt ook wat budget aan toegewezen, omdat ze moeten voldoen aan financiële en boekhoudkundige wetten. Als je de inspanning onderschat (en dat doe je als je alleen deskundige schattingen gebruikt!), het team zal te klein zijn en de software zal niet klaar zijn wanneer het zou moeten zijn.

De schatting van softwarekosten is nog steeds erg relevant, ook in behendige tijden. Op de jaarlijkse conferentie van de International Cost Estimation and Analysis Association (ICEAA), afgelopen juni in Phoenix (DE, VS), ICEAA en Nesma introduceerden de Software Cost Estimation Body of Knowledge (sCEBoK). In deze conferentie, over- 450 kostenramers van organisaties als Boeing, NASA, Lockheed Martin, Amerikaanse marine, enzovoort. bijeengeroepen om professionele kostenramingspraktijken te bespreken, ook wat betreft software. Voor hen is het geen optie om zich achter willekeurige verhaalpunten te verschuilen, ze moeten voldoen aan internationale normen en beste praktijken om ervoor te zorgen dat de schatting zo nauwkeurig is, maar ook zo verdedigbaar mogelijk.

Als sociaal experiment, Ik besloot om een ​​bericht te plaatsen om de industrie te informeren over het Nesma / ICEAA-initiatief in verschillende LinkedIn-groepen, en ik was vooral geïnteresseerd in de reacties van de groep ‘Agile and Lean Software Development’, die voorbij is 140.000 leden. De tekst:

‘De schattingsvolwassenheidsprocessen zijn gemiddeld nog steeds vrij laag. Er worden nog steeds grote sommen geld verspild omdat projecten niet professioneel werden ingeschat, resulterend in kosten- en schemaoverschrijdingen. Een van de problemen in de hele branche is het feit dat de softwarekostenschatter vaak geen erkend beroep is. In veel organisaties, schattingen zijn gebaseerd op ervaring en meningen van bevooroordeelde menselijke experts, in plaats van gebaseerd te zijn op relevante historische data en parametrische modellen. Nesma en ICEAA (International Cost Estimation and Analysis Association) werken samen om een ​​trainingsprogramma en certificering voor ‘Software Cost Estimator’ te creëren, een professionele rol voor het schatten van softwaregerelateerde activiteiten en producten.

In samenwerking met een aantal ondersteunende organisaties en professionals in de branche, Nesma en ICEAA hebben samengewerkt om een ​​kennisinstituut voor softwarekostenramingen te ontwikkelen (sCEBoK). In lijn met de trainings- en certificeringsprogramma's die ICEAA al heeft voor kostenraming, het doel is om speciaal voor de softwarekostenschatter een opleidings- en certificeringsprogramma te ontwikkelen. Het plan is om de eerste professionele kostencalculators voor software volgend jaar te laten certificeren tijdens de ICEAA-conferentie in mei 2019 in Tampa, FL en op de IWSM in november 2019 in Haarlem, Nederland'

Bekijk het als je de kans hebt: https://www.linkedin.com/groups/37631/37631-6422686037318860800

 

Het is echt ongelooflijk wat deze gemeenschap van praktijkmensen vindt van het schatten van softwarekosten. Een paar reacties:

'Waarom zouden we volwassen willen worden door onze tijd te verspillen??’

‘Nooit onder de indruk van nauwkeurige schattingen van nieuwe ontwikkelingen.’

'Sorry als dit sarcasme overkomt, maar je hebt een chiquere kristallen bol uitgevonden om nauwkeurigere willekeurige getallen te produceren. '

‘Ik denk dat het beter is om dit mee te nemen naar waterval- en projectmanagersgemeenschappen, aangezien agile gemeenschappen hier gewoon om zullen lachen.’

‘Ik heb wat dampende paardenpoep in deze groep gezien, maar dit staat bovenaan de stapel '

‘Budget wat u kunt betalen. Laat teams continu leveren, zodat u kunt zien wat u voor uw geld krijgt. Continu verbeteren. Als u niet genoeg waarde krijgt, grondoorzaak waarom. ‘

‘Weer een certificering voor hoopvolle kopers… Precies wat deze branche nodig heeft. '

 

En nog veel meer harde en oneerlijke opmerkingen, van de gemeenschap die helemaal niet lijkt te geven om de financiële implicaties van softwareontwikkeling (hoewel er ook enkele ondersteunende opmerkingen waren, ik moet toegeven).

Leidinggevenden op deze planeet, let op deze reacties, omdat ze de ware gevoelens en overtuigingen van veel beoefenaars in de branche belichamen. Ze hebben echt het gevoel dat ze geen schatting nodig hebben (want het is toch niet hun geld) en ze willen nergens verantwoordelijk voor zijn, snelheid uitdrukken in 'willekeurig, niet herhaalbaar, niet-gestandaardiseerde willekeurige meeteenheden (b.v., verhaal punten)'En dus nergens verantwoordelijk voor. Geld naar agile teams gooien en op het beste hopen, kan in sommige gevallen werken, maar zal u in de meeste gevallen teleurstellen! ‘Software is een R&D proces en resultaten zijn onvoorspelbaar!' Dit is niet waar! Software-inschatting is niet eenvoudig, maar het kan op een nauwkeurige manier worden gedaan, het voorkomen van veel schema- en budgetoverschrijdingen zoals we vandaag zien!

Werkelijk, dit is het fundamentele probleem van de hele software-industrie. Door te ontkennen dat het mogelijk is om de omvang van softwarevereisten nauwkeurig te meten met behulp van internationale standaarden, geschatte looptijd blijft laag. Als je het werk van professor Abran bestudeert, bijvoorbeeld zijn onderzoek naar de voorspellingskracht van verhaalpunten versus functionele groottemeting (https://tinyurl.com/y9jf98tq), je ziet dat zelfs de meeteenheid voor willekeurige inspanning is uitgevonden voor teams om onvergelijkbaar en onverantwoordelijk te blijven (verhaal punten), heeft lang niet zoveel voorspellingskracht als het gaat om softwareschatting als functionele maatmeting doet.

De fundamentele vraag blijft ... doen de leidinggevenden in deze wereld die met agile teams te maken hebben, dit echt blijven kopen? Op een gegeven moment zou je denken dat ze begrijpen dat ze zijn opgelicht om meer geld naar de teams te gooien met twijfelachtige resultaten die moeten worden gevolgd: minder functionaliteit dan verwacht / vereist, lagere kwaliteit, hogere kosten, vooral in onderhoud.

ICEAA en Nesma hebben er alle vertrouwen in dat de gecertificeerde Software Cost Estimator een echt beroep in de branche zal worden, waarmee organisaties hun procesvolwassenheid met betrekking tot schattingen kunnen verbeteren, controle, prestatiemeting, benchmarking en sourcing. De Software Cost Estimator helpt IT-managers grip te houden op hun flexibele leveringsteams zonder de teams lastig te vallen met overhead en verspilling, met voldoende transparantie om weloverwogen beslissingen te nemen.

Deel deze post op:

Laat een antwoord achter