Haal uw deadlines: methoden die ontwikkelaars gebruiken om de inspanning in te schatten

Dag iedereen! Er is een enorme hoeveelheid theorie die u moet kennen om aan de slag te gaan met softwareontwikkeling. Sommige specialisten (bijvoorbeeld backend-ontwikkelaars die Java en andere talen gebruiken) weten er meer van, terwijl anderen (bijvoorbeeld frontend-ontwikkelaars die JavaScript en React Native gebruiken) misschien iets minder weten. Dat gezegd hebbende, beide groepen moeten beschikken over een grote hoeveelheid niet alleen technische, maar ook 'organisatorische' kennis. Deze "organisatorische" kennis is een overlapgebied voor frontend- en backend-ontwikkelaars. Vandaag wil ik het hebben over een aspect van deze niet-technische, organisatorische kennis. Vandaag zullen we het hebben over inspanningsschatting . Omdat ik alleen ervaring heb met het gebruik van de Agile-methodiek(wat als het meest populair wordt beschouwd), meer specifiek het Scrum-raamwerk, zal ik de inspanningsschatting beschouwen in de context van Scrum . Om te beginnen moet ik zeggen dat het moeilijk is om de inspanning in te schatten. Voor mij is het een van de meest uitdagende/onaangename aspecten van mijn werk als ontwikkelaar. Er zijn veel verschillende factoren waarmee u rekening moet houden die van invloed kunnen zijn op uw inschatting van de inspanning die nodig is voor een taak. Bovendien zullen toekomstige ontwikkelingsplannen worden gebaseerd op uw schattingen.

Wat als u een slechte schatting geeft?

Als een ontwikkelaar veel meer uren schat voor een taak dan er uiteindelijk aan de taak worden besteed, kan zijn expertise in twijfel worden getrokken omdat de schatting zo onnauwkeurig was. Met andere woorden, het was een wilde gok. Tegelijkertijd brengt een ontwikkelaar, als hij het werk niet binnen de voorspelde tijd afkrijgt, de plannen van de klant om het product of de nieuwe functie uit te brengen in gevaar. Dit is zaken, en zaken zijn geld. Weinig klanten zullen blij zijn met zo'n slip. Dat is eigenlijk waarom ik niet van schattingen hou - omdat het soms super lastig is om nauwkeurig de tijd te bepalen die nodig is om een ​​taak te voltooien.

Hoe maak je een tijdsschatting

Schattingen worden in de regel gemaakt in uren of storypoints. Mijn persoonlijke voorkeur gaat uit naar het schattingsproces met behulp van storypoints . Het is moeilijk om je te vergissen over concrete fysieke objecten, maar verhaalpunten zijn iets abstracter. Softwareontwikkelingsteams geven doorgaans schattingen in termen van tijd: uren, dagen, weken, maanden. Deze tijdsschattingen zijn voornamelijk gebaseerd op persoonlijke ervaring, giswerk en/of intuïtie. In dit geval kijken ontwikkelaars eenvoudigweg naar de taak en drukken hun veronderstelling uit over hoeveel tijd het hen zal kosten. Als gevolg hiervan zijn deze schattingen zeer zelden nauwkeurig, omdat er te veel factoren zijn die de duur van het werk kunnen beïnvloeden. Daarom gebruiken veel teams die de Agile- methodiek gebruiken ook storypoints. Laten we erin duiken!

Wat zijn storypoints?

Een storypoint is een meeteenheid om een ​​schatting uit te drukken van de totale inspanning die nodig is om een ​​bepaald stuk functionaliteit volledig te implementeren. Dat wil zeggen, we hebben het over relatiefcomplexiteit. Teams kennen een schatting toe in verhaalpunten op basis van de complexiteit van het werk, het werkvolume en risico of onzekerheid. Deze waarden worden meestal toegewezen om het werk efficiënter in kleinere stukken te verdelen, waardoor dubbelzinnigheid wordt geëlimineerd. Na verloop van tijd helpt dit teams te begrijpen wat ze in een bepaalde periode kunnen bereiken en kunnen ze volgende werkstukken nauwkeuriger plannen. Dit klinkt misschien volkomen contra-intuïtief voor u, maar deze abstractie is inderdaad handig: het zet het team ertoe aan moeilijke beslissingen te nemen over de complexiteit van het werk. Laten we eens kijken naar enkele redenen om verhaalpunten te gebruiken bij het plannen:

• U kunt onnauwkeurige tijdsschattingen voorkomen.
• In tegenstelling tot schattingen in tijdseenheden, kunt u met storypoints rekening houden met overheadkosten: communicatie tussen teamleden en de klant, diverse teambesprekingen en planningsactiviteiten, evenals onvoorziene situaties.
• Elk team zal hun werk met verschillende schalen inschatten, wat betekent dat hun capaciteit (gemeten in punten) anders zal zijn.
• Door een schaal te definiëren voor het toewijzen van elk verhaalpunt, kunt u snel punten toewijzen zonder veel controverse.

Hoe je verhaalpunten NIET gebruikt

Helaas worden verhaalpunten vaak misbruikt. Verhaalpunten kunnen misleidend zijn wanneer ze worden gebruikt om mensen te beoordelen, gedetailleerde deadlines en middelen te definiëren, en wanneer ze worden aangezien voor een prestatiemaatstaf. In plaats daarvan zouden teams ze moeten gebruiken om de reikwijdte/complexiteit van elke taak te begrijpen en prioriteiten te stellen. Misschien dat de onderdelen die als moeilijker worden beschouwd, eerst moeten worden aangepakt, zodat ze voor het einde van de sprint kunnen worden gedaan , waarbij gemakkelijkere taken mogelijk naar later worden verschoven. Laat me je eraan herinneren wat een sprint is in de context van de Scrum- methodiek: De lengte van deze periode wordt bepaald wanneer de ontwikkeling begint en wordt overeengekomen tussen het team en de klant. Dit kan een periode zijn van twee weken of een maand, of een andere periode. In de regel worden de inspanningsinschattingen aan het begin van elke sprint gemaakt om het werk te plannen dat kan worden voltooid aan het einde van de sprint, wanneer het voltooide werk aan de klant wordt opgeleverd. De demo helpt u uw voortgang bij het ontwikkelen van het product te zien, feedback van de klant te ontvangen en het traject van het project aan te passen aan de visie van de klant. Maar we dwalen een beetje af. Laten we teruggaan naar schattingen. Het zou te subjectief zijn om slechts één ontwikkelaar schattingen te laten geven voor alle taken. Dit proces is dus meestal een teaminspanning. Er zijn nogal wat technieken die teams kunnen gebruiken om schattingen te genereren. Vandaag gaan we kijken naar de meest populaire techniek: scrum poker . Deze techniek vereist een manager die optreedt als moderator voor de scrumpoker . Dit kan iemand zijn die een scrum master is of eventueel een PM .

Wat is Scrumpoker?

Scrum poker , of planning poker, is een schattingstechniek die gebaseerd is op het bereiken van een overeenkomst. Het wordt voornamelijk gebruikt om de complexiteit van het komende werk of de relatieve omvang van softwareontwikkelingstaken in te schatten. Ik zal meteen zeggen dat scrum pokeris een gebruikelijke praktijk voor softwareontwikkeling en u moet weten waar het allemaal om draait. Het gaat meestal om een ​​app of website om het gezamenlijk maken van een schatting voor een bepaalde taak door een team te vergemakkelijken. Hoe gebeurde dit? Het team pakt iets uit de backlog (een nieuwe taak, wat functionaliteit) en bespreekt kort mogelijke valkuilen en andere nuances die daarbij horen. Vervolgens kiest elke deelnemer een kaart met een nummer dat hun schatting van de complexiteit weergeeft. Oh, nog een ding, bij het maken van deze schattingen gebruiken we getallen in de Fibonacci-reeks in plaats van gewone getallen. Fibonacci-getallen zijn populair bij scrumpoker, omdat er een steeds grotere kloof tussen zit (lijkend op de niveaus van een piramide). Sommige taken zullen zeer complex zijn en we zullen niet wegkomen met een klein aantal verhaalpunten. Er zijn enkele ongebruikelijke kaarten die de volgende betekenis hebben:

Onbekend aantal eindpunten

Oneindig lange taak

Een pauze nodig

Minder gebruikelijke schattingsmethoden gebruiken:

• T-shirtmaten - S, M, L, XL
• Hondenrassen - chihuahua, mopshond, teckel, bulldog, enzovoort (persoonlijk denk ik dat dit de vreemdste maateenheid is voor inspanningsschatting =D)

Het team vergelijkt vervolgens de schattingen van verschillende ontwikkelaars voor dezelfde taak. Als ze het eens zijn, prima! Zo niet, dan moeten de redenen (argumenten) voor de verschillende schattingen worden besproken. Daarna werkt het team samen om tot één schatting te komen die iedereen min of meer accepteert. Dus waarom wordt poker zelfs gebruikt om serieuze softwareprojecten te plannen? Je moet toegeven dat dit vreemd is. Feit is dat dit soort gamification teamleden aanmoedigt om onafhankelijk te denken, en hen uitnodigt om hun schattingen tegelijkertijd met hun teamgenoten bekend te maken. Dit voorkomt op zijn beurt dat er een situatie ontstaat waarin sommige teamleden afhankelijk zijn van de mening van anderen. Als het niet op deze manier zou gebeuren, zouden minder ervaren ontwikkelaars kijken naar en zich concentreren op de schattingen van meer ervaren teamleden, en dat zou hun eigen schattingen minder bruikbaar maken. Maar tegelijkertijd de schattingen tonen, maakt dit in wezen onmogelijk. Atlassian aanbiedingeneen scrum poker-app voor gebruik in het planningsproces.

Voorbeeld inspanningsschatting

Stel dat uw team de volgende schaal heeft opgesteld voor het toekennen van verhaalpunten aan schattingen: Voor elke taak wordt scrumpoker gespeeld en u geeft als volgt een schatting:

• Je hebt nog nooit een vergelijkbare functionaliteit geïmplementeerd: +3
• De functionaliteit is van gemiddelde grootte: +2
• De implementatie zal zeer complex zijn: +3
• Schrijftesten voor de functionaliteit zullen zeer complex zijn: +3

Als je elk onderdeel bij elkaar optelt, krijg je in totaal 11 verhaalpunten, maar zo'n kaart is er niet, dus stel je 13 voor. Een collega komt met de volgende schatting voor de taak:

• Hij heeft eerder met een soortgelijke taak gewerkt: +1
• De functionaliteit is van gemiddelde grootte: +2
• De implementatie zal van gemiddelde complexiteit zijn: +2
• Schrijftesten voor de functionaliteit zullen van gemiddelde complexiteit zijn: +2

Zijn tussentijdse resultaat is 7 verhaalpunten, maar dat aantal bestaat niet in de Fibonacci-reeks, dus hij dient de kaart in met het meest geschatte aantal - 8. Andere teamleden maken hun schattingen ook op basis van hun subjectieve opvattingen. Dan laat iedereen zijn kaarten zien en je merkt dat bijna al je collega's een schatting van 13 gaven, behalve de ene ontwikkelaar die een 8 suggereerde. In dit geval mag hij praten met de redenen voor zijn lagere schatting. Stel dat hij deze rechtvaardiging biedt: hij heeft eerder aan dezelfde taak gewerkt en het is niet zo moeilijk als het lijkt. Uiteindelijk overtuigt hij de rest van het team om van gedachten te veranderen van 13 naar 8 verhaalpunten, waarbij hij zegt dat hij iedereen zal helpen die deze taak op zich neemt. Of misschien gaat hij het zelf doen. Het doet in ieder geval niet Het maakt niet uit of de anderen zijn argumenten accepteren of niet, want op de een of andere manier wordt er een schatting aan de taak toegewezen en gaat het team verder met het overwegen van de volgende. In eerste instantie zullen schattingen onnauwkeurig zijn, evenals de schattingen van de hoeveelheid werk die u van plan bent te doen in de volgende tijdsperiode (sprint). Deze schattingen zijn immers gemaakt met behulp van schattingen. Na enige tijd, misschien drie maanden later, zal het team de tijd die nodig is voor taken nauwkeuriger gaan inschatten en zal duidelijk worden hoeveel werk het team gemiddeld in een sprint kan uitvoeren. Maar dit is een proces om een ​​algemeen plan te maken voor de reikwijdte van het werk. Het richt zich vooral op tijd, maar in dit geval kunnen er veel verschillende relevante factoren zijn. Stel dat een ontwikkelaar twee weken op vakantie gaat. U zult een bepaalde hoeveelheid gepland werk moeten schrappen (geplande functionaliteit). Of stel dat een nieuwe ontwikkelaar zich bij het team heeft gevoegd, maar nog niet helemaal op de hoogte is, dus je moet haar de tijd geven om vertrouwd te raken met het project door middel van eenonboarding -proces. Dit kan twee weken zijn, een week of een week, afhankelijk van de complexiteit van het project. Dat is alles voor vandaag! Ik hoop dat ik je kennis van inspanningsschatting, een noodzakelijk niet-technisch aspect van softwareontwikkeling, enigszins heb verbeterd. Als je dieper op dit onderwerp en in de details van scrum wilt ingaan, raad ik je ten zeerste aan het boek "SCRUM" van Jeff Sutherland te lezen. Over de gevolgen kan ik niets beloven, want na het lezen krijg je een irritant verlangen om scrummaster te worden =D