Agile

Agile metrics – Agile en software metrieken

Agile metrics

Vaak wordt beweerd dat Agile en software metrieken niet samen gaan. Onzin vinden wij, want zowel Estimating als Benchmarking zijn ook bij Agile super belangrijk! Agile metrics dus!

Ook bij projecten die Agile worden uitgevoerd heb je namelijk te maken met geld dat te besteden is (budget) en gebruikerseisen die de basis vormen voor de op te leveren software (requirements).
De op te leveren software moet binnen een bepaalde periode gerealiseerd worden en dat moet ook nog eens passen binnen het totaal van andere activiteiten binnen de afdeling (planning).

Zo beschouwd wijkt Agile eigenlijk niet eens zoveel af van andere projectmanagement methoden.

Een business owner weet bij Agile vaak wel hoeveel geld hij kwijt is en hoelang het gaat duren, maar niet hoeveel software hij daarvoor krijgt!

Agile Budgettering en planning = Agile Estimating

Ook bij Agile is budgettering en planning van geld en resources op projectniveau bittere noodzaak. Alleen op die manier blijft de opdrachtgever in control van de projectkosten en kunnen de scrum teams zich concentreren op hun eigenlijke werk.
Door vooraf een estimate op projectniveau te maken krijg je als organisatie inzicht in de driehoek met omvang product, benodigde doorlooptijd en kosten.

Agile Omvangbepaling

Wanneer de product backlog (deels) beschikbaar is dan kan daarop al sizing plaatsvinden. Afhankelijk van de mate van detail passen we daarvoor FPA (functiepunt analyse) of FPAv (FPA in het voortraject) toe. De omvang van enkele sprints is vaak al voldoende om op basis daarvan de omvang van het gehele project te bepalen.

Door het toepassen van functiepunten en estimating houd je grip op de totale uitgaven. In combinatie met Scrum blijf je flexibel doordat je de richting en de scope kunt blijven bijsturen. Het gezamenlijke doel is dat je het probleem zo snel, zo goed en zo goedkoop mogelijk oplost!

Scrum en functiepunt analyse gaan daarom goed samen. Zodoende kunnen we voorkomen dat de controle verloren gaat en dat het budget wordt overschreden.

Voordelen van toepassen Agile metrics

  • Snel inzicht geven in de omvang van de product backlog
  • Omvang bepalen van het beoogde einddoel
  • Omvang bepalen van opgeleverde functionaliteit (earned value)
  • Hulp bij het indelen van sprints (prioriteren en plannen van functionaliteit)
  • Onderbouwing voor het opstarten van verbeteracties
  • Onderbouwing van de business case voor Scrum

(deze voordelen worden door Jolijn Onvlee en Rini van Solingen onderschreven in hun artikel “Scrum en Functiepunten: vrienden of vijanden?“, maart 2012, Automatiseringsgids)

Wat is Agile?

Agile is een werkwijze die sinds ca. 2000 aan populariteit wint en kan worden toegepast bij verschillende ontwikkelmethoden.

Er is een principieel verschil met de traditionele Waterval aanpak.

Centraal staat het Agile Manifest:

  • Mensen en hun onderlinge interactie boven processen en tools
  • Werkende software boven allesomvattende documentatie
  • Samenwerking met de klant boven contractonderhandelingen
  • Inspelen op verandering boven het volgen van een plan

De meest toegepaste Agile methodes zijn:

  • Extreme programming – (Beck, 1999)
  • Scrum – (Schwaber & Beedle 2002)
  • Crystal family methods – (Cockburn, 2002)
  • Feature Driven Development – (Palmer & Felsing, 2002)
  • Rational Unified Process – (Kruchten, 2000)
  • Dynamic System Development Method – (Stapleton, 1997)
  • Adaptive Software Development – (Highsmith, 2000)
  • Open Source Software development – (O’Reilly, 1999)

Een ontwikkelmethode is Agile wanneer deze als volgt software ontwikkelt:

  • Incremental (small software release with rapid cycles)
  • Cooperative (customers and developers working constantly together with close communication)
  • Straightforward (the method itself is easy to learn and to modify and well documented)
  • Adaptive (Able to make last moment changes)

(Ref. Agile Software  Development methods, Pekka Abrahamsson, 2002)

Wanneer en waarmee kunnen we Estimaten bij Agile?

Agile estimation

Estimation is een proces dat is terug te voeren op de volgende kernvragen:
– Wat is de omvang van het product en met welke (on)zekerheid?
– Wat weten we over de mensen die het gaan maken en de ontwikkelomgeving?
– Wat zijn de randvoorwaarden die het management stelt?

Estimation Proces
Uitdagingen bij Estimaten en Benchmarken van Agile projecten

1. Relatief nieuwe werkwijze met veel varianten (weinig betrouwbare referenties)
2. Weinig consistent historisch materiaal
3. Andere terminologie, andere filosofie
4. Andere eenheden voor kwantificering en planning
5. Onvoldoende specificaties bij project start
6. Risico van onvoldoende documentatie opleveren t.b.v. onderhoud
 (zie 2e manifest statement)
7. Agile ‘estimation’ eenheden niet gestandaardiseerd (storypoints, velocity)
8. Geen uniformiteit binnen Agile community

Ad. 1.
Vrijwel alle IT-organisaties die met Agile aan de slag willen ontbreekt het aan know-how. Eigenlijk is Agile nog steeds een nichemarkt. Er zijn nog weinig specialistische bedrijven die goede waardevolle diensten kunnen leveren. Die er zijn hebben hun eigen aanpak.

Veel dienstverleners doen alsof ze specialist zijn, maar bieden gewoon ‘business as usual’ ofwel: zoveel mogelijk uren verkopen.
Door metrieken toe te passen kunnen deze externe leveranciers onder controle worden gehouden.

Ad. 2.
Weinig historie ligt voor de hand maar is ook een feit, dat voorlopig blijvend is vrezen wij. Juist omdat Agile een totaal andere filosofie heeft, en daardoor geen gestandaardiseerde ‘estimation eenheden’ kent, is er heel weinig benchmark materiaal beschikbaar.
Sommige leveranciers schermen met ‘enkele honderden projecten’ in hun database, maar getwijfeld kan worden aan de waarde van dat materiaal en hoe dat tot stand is gekomen.
Reden hiervoor is de verscheidenheid in aanpak, veelal ‘hybride’.

Ad. 3.
Agile methoden hanteren een andere terminologie dan de ‘Waterval’ methoden. Illustratief is het ontbreken van het begrip ‘functional requirements’ of specificaties. Ook ‘functional size’ is geen begrip dat binnen Agile herkend wordt. De specificaties bestaan uit ‘features’ (client valued function of the system) en/of ‘story’s’ (systeemfunctie met client value én duidelijke ‘completion criteria’). Op basis van prioritering en praktisch inzicht worden story’s gegroepeerd in ‘iterations’ (of een sprint, zoals het bij Scrum heet). In Scrum heet de verzameling te realiseren story’s van een sprint de ‘backlog’.
Door deze afwijkende terminologie lijkt het dat de historisch verzamelde metrieken niet meer van toepassing zijn op Agile projecten. Wij zijn van mening dat dat wel het geval is. Het is meer een kwestie van willen.

Ad. 4
Er worden eigen eenheden gebruikt voor de kwantificering van het werk en de planning.
De hoeveelheid werk die het realiseren van een story kost, wordt uitgedrukt in ‘storypoints’. Een story wordt ‘ge-estimate’ in storypoints op basis van know-how, ervaring, vakmanschap. Na een ‘planning-game’ wordt de definitieve waarde toegekend. Hiervoor wordt meestal de reeks van Fibonacci gebruikt (1, 2, 3, 5, 8, 13, …). 13 is al zeer uitzonderlijk; het houdt meestal wel op bij 5. Als er punten zijn toegekend is de omvang van de ‘backlog’ dus bekend.
Een storypoint is het equivalent van een ‘ideale ontwikkeldag’ (d.w.z. ongestoord uitsluitend daaraan kunnen werken).
De productiviteit wordt bij Agile uitgedrukt in ‘velocity’. De velocity is het aantal storypoints dat het team in één iteratie (‘sprint’) heeft gerealiseerd. In combinatie met de duur van een iteratie kan zoiets als ‘productiviteit’ worden bepaald (van dit team in deze specifieke situatie).

Ad. 5.
Omdat Agile een ‘incrementele’ werkwijze is, is het normaal dat er bij de start niet al te veel specificaties bekend zijn. Dit verschilt overigens per methode. Bij Scrum is het gebruikelijk dat er aan het begin een globaal beeld van het geheel aanwezig is en een verdere uitwerking op het niveau van stories van de eerste en soms de tweede sprint.
Het probleem hierbij is dat een estimate van het geheel vooraf slechts met een zeer grote onzekerheidsmarge gemaakt kan worden.
Deze uitdaging kan worden tegemoet getreden door slimme estimate en sizing methoden (FPAv, analogie, case base reasoning).

Ad. 6.
Manifest statement 2 ‘werkende software boven allesomvattende documentatie’ kan gemakkelijk leiden tot het vervaardigen van onvoldoende documentatie t.b.v. het latere onderhoud. Dit kan worden getackeld door hierover duidelijke afspraken te maken of ISO/IEC standaarden voor te schrijven aan het ontwikkelteam.

Ad. 7.
De eenheden ‘storypoint’ en het daaraan gerelateerde ‘velocity’ zijn niet gestandaardiseerd. Dit maakt benchmarking op basis van deze eenheden heel lastig, zo niet onmogelijk. Desondanks heeft COSMIC een waardevolle bijdrage geleverd aan dit aandachtsgebied (Trudel en Buglione), zie hiervoor COSMIC_Agile_Projects_Guideline_v10.pdf.
De werkwijze die zij hanteren kan evengoed worden uitgevoerd met FPA. Earned Value wordt dan uitgedrukt in functiepunten naast ‘features delivered’.

Ad. 8.
Het onderzoek van Trudel en Buglione heeft verder aangetoond dat binnen de Agile-gemeenschap weinig uniformiteit bestaat over begrippen en werkwijzen.
Dit betekent dat in voorkomende gevallen duidelijke afspraken moeten worden gemaakt over regels, procedures en definities.

Meer weten over hoe Agile metrics toe te passen?

Neem geheel vrijblijvend contact met ons op.