QPR is de omgeving waarin AWW diverse KPI's of Key Performance Indicators opvolgt.
Voor releasebeheer is er ook een reeks cijfers waarin de kwaliteit van planning en testen wordt opgevolgd.
Hieronder zie je de cijferreeksen voor releasebeheer. Deels worden ze ingevuld en deels berekend op basis van de ingevulde cijfers.
startpunt in Rallydev
Het startpunt nemen we in het overzicht van de taken. Hiervoor ga je naar "backlog & schedules" - Tasks. Het is eender welke view je neemt. Op de meeste views zie je zowel het aantal ingeschatte als effectief gepresteerde uren.
Via release en iteratie kan je filteren. de filter bepaalt dan welke cijfers je te zien krijgt en dus welke cijfers je in QPR kan overnemen.
Release en iteratie voor zelfde releasenummer
Indien je zowel release als iteratie op hetzelfde releasenummer zet, dan heb je de ontwikkelperiode van de release. Je vindt hier dus de ingeschatte en effectieve uren van de user stories die ontwikkeld zijn voor de betreffende release.
cijfers QPR
effectieve tijd op dev/itg gerealiseerde US
geplande tijd gerealiseerde US
Release en iteratie voor R+1
We zijn in de acceptatieperiode van de geselecteerde release. Hier noteer je dus de uren die nodig waren voor het rechtzetten van acceptatiefouten.
cijfers QPR
effectieve tijd BF ACC
Release en iteratie voor R+2
We zijn in de productieperiode van de geselecteerde release. Hier noteer je dus de uren die nodig waren voor het rechtzetten van productiefouten.
cijfers QPR
effectieve tijd BF PROD
Om zeker te zijn dat je cijfers volledig zijn, moet je ook even kijken in de zogenaamde Defect Suites. Indien er geen koppeling is tussen een taak en een defect, kan het zijn dat je een productiefout en gepresteerde uren over het hoofd ziet.
Vind je nog niks, controleer dan even Lotus Notes. Als je daar ook geen enkele request met RXXYY HF1 vindt, dan heb je inderdaad een release gevonden zonder enige productiefout.
samenstellen van de cijfers
effectieve tijd BF ACC
Het eerste cijfer dat ons gevraagd wordt, is de benodigde tijd voor bug fixing op acceptatie. Het gaat hier dus om de ontwikkeling voorzien voor een bepaalde release die volgt in de acceptatieperiode. En de acceptatieperiode is de periode die volgt op de ontwikkelingsperiode van deze release.
We gaan naar backlog - tasks en maken gebruik van de filter. We selecteren de release waarvoor we de cijfers willen opvoeren en we filteren verder ook op de periode die volgt op de ontwikkelperiode van de betreffende release. In andere woorden, we selecteren de ontwikkelperiode van de daaropvolgende release.
In het scherm zie je dat we zoeken naar cijfers van R02.07 en ons dus beperken tot de periode van DEV 02.08.
effectieve tijd BF PRD
Het tweede cijfer dat ons gevraagd wordt, is de benodigde tijd voor bug fixing op productie. Het gaat hier dus om de ontwikkeling voorzien voor een bepaalde release die gebeurt tijdens de productieperiode. En de productieperiode is de periode die ligt in de ontwikkelingsperiode van de (release + 2).
We filteren dus op de betreffende release en de ontwikkelperiode van 2 releases verder. We noteren het aantal effectieve uren in QPR.
Merk op dat we hier iteratiegewijs werken en niet per release. In de vorige paragraaf (effectieve tijd BF op ACC) hebben we ons beziggehouden met R02.07 en DEV02.08. Hier kijken we naar R02.06 en iteratie DEV 02.08.
Anders gezegd, de releases verschillen maar de iteratie is dezelfde, met name DEV02.08 of nog anders uitgedrukt de iteratieperiode die zonet is afgelopen. Het is deze iteratie die ons cijfers oplevert van :
- uren ontwikkeling voor release R
- uren verbetering op acceptatie voor release R-1
- uren verbetering op productie voor release R-2
effectieve tijd op dev/itg gerealiseerde user stories
Het derde cijfer is de tijd die we besteed hebben aan de release tijdens de ontwikkelingsperiode. In dit geval vermeldt iteratieperiode en release dus hetzelfde nummer.
We zitten weer in backlog-tasks en filteren deze keer release en iteratie op hetzelfde releasenummer. Hiervan noteren we de effectief gepresteerde cijfers.
geplande tijd extra US
Hiervoor moeten we een beroep doen op de MySQL databank die we voor het project Engelbert hebben opgestart. Hierin bewaren we de historiek van de user stories en de taken die we wekelijks exporteren vanuit Rallydev.
geplande tijd gerealiseerde US
De geplande tijd van gerealiseerde user stories vinden we op hetzelfde scherm als we de effectieve tijd op dev/itg hebben gevonden : backlog - tasks en filter release en iteratie op hetzelfde releasenummer. Noteer ditmaal echter de ingeplande tijd.
