Geïntegreerd Agile Begrippen¶
- ATS¶
- Automatisch Test Script¶
Een (of meerdere test) die volledig automatisch kunnen draaien en aantonen dat een (stukje) functionaliteit werk. Een ATS omvat de altijd een validate van de resultaten.
Typisch omvat een ATS zowel een (executeerbaar) script als meerdere input en (verwachte) output vectoren (data). En levert het 1bit informatie op: gefaald of niet.Vaak is een ATS geschreven in een taal als Python; omdat die goed bruikbaar is voor testers; het moet primair een goed test zijn; niet een fraai programma. Het test-framework (zie ook Pathways) mag wel geschreven/onderhouden worden door programmeurs.
- BAV¶
- Business Added Value¶
- Business Added Value Graph¶
- Product BurnDown¶
Een grafische weergave van de voortgang van het project. Zowel de (geschatte) omvang van het project, als de reeds opgeleverde delen zijn in de tijd uitgezet (typische maandelijks). En meestal voorzien van een trendlijn. Waar die twee kruisen is het project waarschijnlijk echt klaar.
Het is ook een belangrijk stuur. Als de verwachte einddatum te laat is, kan vroegtijdig ingegrepen worden. Dit kan grafisch; door de gewenste lijnen te tekenen, die voor de gewenste datum kruisen.
Daarna kan een plan gemaakt worden hoe die oplever-snelheid verhoogd kan worden, danwel het project-scope te beperken.- BurnDown¶
- BurnDown-Chart¶
- Sprint BurnDown¶
Dit is het belangrijkste stuur voor het team. Het is een grafisch overzicht van de status (cq voortgang) van de sprint. Typisch omvat de Burndown-Chart twee lijnen, die laten zien hoeveel werk er nog gedaan moet worden, uitgezet in (kalender)dagen. Eén (rode, rechte) lijn dient als referentie en de andere wordt elke dag bijgewerkt tijden de Standup.
Als de sprint (veel) vrije dagen bevat wordt de referentie-lijn vaak hierop aangepast; dan zitten er horizontale (of minder dalende) delen in die lijn. Dit actuele zijn daar immers ook vlak zijn; zodat de grafiek een beter inzicht geeft.Scrum kent ook een product- (of project-) burndown; al wordt die vaak vergeten of verward met de sprint-versie. In Geïntegreerd Agile gebruiken we alleen de sprint-versie en gebruiken we de BAV als stuur voor het product/project.
- FP¶
- FeaturePoint¶
Een betekenisloze eenheid waarmee de relatieve kosten van Features worden uitgedrukt. Een Feature van 10FP is tweemaal zo duur als een van 5FP en 10 maal zo duur als een van 1FP
Er is geen vaste relatie tussen FeaturePoints en mensuren/dagen! Al kan de verhouding (achteraf) uitgerekend worden en zal die factor (de v-factor) van sprint tot sprint weinig veranderen.Omdat FPs betekenisloos zijn, is het vergelijken van FPs tussen teams (of projecten) zinloos.
Zo kan het ene team een Feature inschatten als 5FP, waar een ander team een vergelijkbare Feature begroot op 20FP. Waarschijnlijk zal het aantal mensuur ongeveer hetzelfde zijn. Het verschil zegt dus meer over de v-factoren van de teams; en maar van de eerste Features waarmee de ‘1’ gedefineerd is.Zie ook
- k-factor¶
De meeste engineers zijn te optimistisch bij het inschatten van werk. Dat geldt ook voor groepen en zelfs bij PlanningPoker is dat het geval. Daarom worden in de P2 sessie alle mensuren vermenigvuldigd met deze factor voordat de uren opgeschreven worden.
Omdat deze factor slechts weinig varieert van sprint tot sprint kan de gemeten waarde van de vorige sprint(s) gebruikt worden voor de komende sprint. Het is typisch een getal tussen anderhalf en twee.Deze factor wordt alleen gebruikt in de P2 sessie en alleen voor mensuren.
Omdat de FPs relatief zijn is hij daar (in de P1 sessie) niet nodig. Hij wordt ook niet gebruikt bij het bijwerken van de (taak) T2C; al zou dan wel kunnen, het is dan niet nodig.Zie ook
- Standup¶
- Daily Scrum¶
- Daily Standup¶
Dagelijkse planningsmeeting; waar het hele team de voortgang bespreekt en het ScrumBoard, inclusief de T2C, en de Sprint BurnDown bijwerkt.
- P1¶
- Planning 1¶
Deel één van de sprint-planningssessie(s) heeft als doel om voldoende Features in te schatten (in FP). Daarom is de ProductOwner altijd aanwezig. Er zijn voldoende Features ingeschat als de ProductOwner de selectie voor de komende sprint kan maken.
Vanuit scrum is men vaak gewent om deze sessie aan het begin van elke sprint te houden. Omdat dat ook het laatste mogelijke moment is, is dat ook Lean; een P1 sessie van Feature die nooit gerealiseerd worden is verspilling.
Maar dat is niet noodzakelijk; er zijn vele geode argumenten op het eerder te doen. De maximale verspilling is immer maar een paar uur.Vaak is het wenselijk om de belangrijkste Features vooraf (up-front) in te schatten; bijvoorbeeld om inzicht te krijgen in de totale project-kosten.
Ook is het vaak handig om de P1 sessie halverwege de volgende sprint te plannen; en daarmee de drukte van de SprintWissel te verlichten.
Bovendien is het verstandig om een voorraadje ingeschatte Features te hebben. Zodat een sprint ook effectief begonnen kan worden als de ProductOwner ziek is.- P2¶
- Planning 2¶
In deel twee van de sprint-planningssessie(s) worden Features (voor die sprint) opgedeeld in taken (en activiteiten). En die taken worden geschat; in mensuren.
Deze sessie is typisch wel aan het begin van de sprint.
Al hoeven niet alle Features dan ingeschat te worden. Als men gebruik maakt van de Hoog/Middel/Laag prioriteiten (de 70-30-30 regel) is het voldoende om initieel alleen de Features met hoge prioriteit te behandelen. De andere Features komen dan later in de sprint aan bod; daar mag met nog niet mee beginnen. Ook hiermee kan men drukte van de SprintWissel verlagen.- PlanningPoker¶
Planning poker is een agile manier om werk in te schatten. Het is een speelse variant op ‘Wideband Delphi’; die al meer dan een halve eeuw gebruikt wordt. Mits correct ‘gespeeld’ geeft het goede, betrouwbare resultaten.
Door het hele team te betrekken geeft het bovendien commitment (toewijding).Planning poker wordt zowel in de P1 als P2 sessies gebruik; maar soms ook op andere momenten ‘werk’ ingeschat moet worden.
Elke teamlid geeft, onafhankelijk van elkaar, een schatting af over hetzelfde ‘werk’; waarna de verschillen besproken worden en men elkaar probeert te overtuigen van het eigen gelijk. Daarna volgt een tweede ronde en eventueel een derde; meer is meestal zinloos.Het debatteren is hierbij erg belangrijk; dit geeft meer inzicht in wat er moet gebeuren. Men probeert de anderen te overtuigen waarom zij zaken over het hoofd zien, dan wel te pessimistisch zijn. ‘Middelen’ of ‘volgen’ moeten daarom voorkomen worden.
- PO¶
- ProductOwner¶
De ProductOwner, die we ook kennen in Scrum, vertegenwoordigd de klant, of de business. Hij bepaalt of een Feature, gezien de kosten (door het team bepaald in FP), nuttig is of niet; dus of het gerealiseerd gaat worden.
In beeldspraak kan gezegd worden dat de PO bepaald waarvoor betaald wordt, maar vaak niet hoeveel het mag kosten. Het team bepaald de posten per Feature en de baas van de PO bepaald hoeveel er in totaal uitgegeven wordt.
- QB¶
- QuarterBack¶
Een informele rol in een Geïntegreerd Agile team; maar ook bruikbaar bij Scrum. De QB vervangt de operationeel rol van de ScrumMaster om voor de standup bijeen te roepen, de BurnDown bij te werken, etc. Dit maakt scrum efficiënter. Maar de ScrumMaster blijft verantwoordelijk.
Zie ook
- T2C¶
- Time-2-Come¶
- Time-2-Complete¶
De (geschatte) tijd die nog nodig is om brok werk (typisch: een taak) af te ronden.
Tijdens de P2 sessie wordt voor elke taak een (initielle) schatting gemaakt hoeveel mensuur nodig is voor die taak. Tijdens de sprint wordt deze T2C bijgesteld; tijdens de Daily Scrum. Typisch omdat men ‘bezig’ is met die taak en steeds minder tijd nodig heeft om hem af te ronden.De T2C kan echter ook omhoog gaan; als blijkt dat er meer tijd nodig is. Daarbij wordt niet gekeken hoeveel tijd verbrand is, maar alleen naar hoeveel tijd nodig is! Bijvoorbeeld: als na een dag hard werken de inschatting is dat er nog 4 uur nodig is, dan is de T2C dus 4 uur! Ook als was die taak initieel ingeschat was op drie uur, en is er al 8 uur aan gewerkt. Rekenkundig is er dan (3-4) min-één uur verbrand.
Ook de som van alle T2C’s is belangrijk; dat geeft elke dag een nieuwe meeting op de (sprint) BurnDown-Chart.
- TG¶
- Technisch Geweten¶
Een informele rol in een Geïntegreerd Agile team; maar ook bruikbaar bij Scrum. In elk team moet (minimaal 1) iemand zitten waar de rest van team inhoudelijk op kan leunen. En waar ook de ScrumMaster op kan bouwen. Hij (of zij) is letterlijk het geweten van het technisch aspect van het team.
Zie ook
- v-factor¶
- velocity¶
- team-velocity¶
In Geïntegreerd Agile wordt de snelheid van het team genormaliseerd voor teamomvang en sprint-duur; waarmee de ‘v-factor’ flexibeler is dan de in scrum gebruikelijke ‘velocity’.
En hoewel het idee verder gelijk is, is deze v-factor rekenkundig het inverse: het is het (gemiddelde) aantal benodigde mensdagen per FeaturePoint. Dit heeft historische en praktische redenen: het rekent gemakkelijker.In praktijk wordt ook regelmatig rekent met het aantal FP dat het team per week verzet; soms wordt dat getal ‘team-velocity’ genoemd.
Zie ook
De v-factor: Waarom de v-factor ‘beter’ is dat de scrum-velocity.
- VisualFeedBack-Board¶
Het VisualFeedBack-Board is een veralgemenisering van het ScrumBoard. Dit (prik)board bevat allerlei zaken die voor het team (op dat moment, cq in de huidige sprint) belangrijk zijn.
Denk aan verbeterpunten, de BAV, vakantie-overzichten etc.
Disqus
Aardige feedback is altijd welkom, evenals alternative meningen; zolang ze relevant zijn voor alle lezers. Hiervoor gebruik ik momenteel ‘Disqus’.