gevraagde cijfers
QPR biedt voor applicatiemanagement de volgende cijfers aan.
De cijfers die als waarde een percentage vermelden, zijn berekende waardes
De waardes waarvoor we de cijfers moeten invullen, zijn dus de volgende :
- effectieve tijd BF ACC
- effectieve tijd BF PRD
- effectieve tijd op dev/itg gerealiseerde US
- geplande tijd extra US
- geplande tijd gerealiseerde US
situatie op dinsdag 10 juni '08
Op dinsdag 10 juni was release R02.03 net in productie gegaan. Release R02.02B was niet lang daarvoor in productie gegaan. Deze releases staan voor
- R02.02B : Speos
- R02.03 : technisch zicht
Deze releases bepaalden de datum van inproductiename. Pas als alle gewenste code in productie kon gaan, is de release ook effectief in productie gegaan. Dit zorgde voor een hoop problemen, verschuivingen en verwarring. De cijfers opzoeken zal dan ook moeizamer gaan dan in de toekomst zou mogen gaan.
Het streefdoel is dat de inhoud van de omgevingen (integratie, acceptatie) niet meer de datum bepaalt maar dat de datum de inhoud bepaalt. Als de datum van inproductiename er is, moet alles van acceptatie naar productie gekopieerd worden. Kan het om een of andere reden toch niet, dan vervalt de release en richten we ons op de volgende datum. Bedoeling is dat we iedere maand nieuwe code opleveren.
opbouw van de cijfers
opmerking vooraf
Wat er alvast ontbreekt aan de cijfers, is de notie van iteratie. Uiteindelijk richt iedereen zich op de periode die door de iteratie bepaald wordt. Streefdoel is een periode van 4 weken waarin er aan de ontwikkeling wordt gewerkt van de R(next+1), de fouten van R(next) worden verbeterd en de fouten van de R(current) op productie worden middels hot fixen weggewerkt.
effectieve tijd BF ACC
Voor R02.03 hebben we de cijfers nodig van 2 iteraties. Gezien het gaat om fouten op acceptatie, is hiervoor een defect suite opgestart. Hier halen we onze cijfers uit.
In het overzicht van de defect suites zie je al de samenstelling van de betreffende defect suite.
Maar als je de defect suite in detail neemt, heb je het voordeel dat je ook de details van de bijbehorende defects kan raadplegen.
Het aantal effectief gepresteerde uren zie je hieronder in de verschillende defects. Let wel dat iedere defect aan een bepaalde iteratie is gekoppeld. Voor technisch zicht hebben we meerdere iteraties doorlopen. Voor de doorsnee release zou je voor fouten in acceptatie maar één iteratie mogen nodig hebben.
effectieve tijd BF PROD
Hier hebben we eveneens de cijfers uit de defect suites nodig, maar dan wel de defect suite die gemaakt is voor fouten op productie bij R02.02B. Belangrijk is alvast dat je de user story koppelt vanuit de defect en niet andersom. Je loopt anders het risico dat je wel de defect maakt, de user story apart inleest en geen koppeling voorziet. Het opleveren van de cijfers wordt dan opzoeken in rallydev op basis van de release notes.
Een eerste bron van controle voor het samenstellen van de cijfers zijn de release notes.
Een tweede bron van controle zijn de hot fixen in het Lotus Notes requestensysteem.
Een derde bron van controle is het overzicht van de XPO-bestanden in Axapta.
Aan de hand van de gevonden user stories kan je dan de tijd opzoeken die men hiervoor had ingepland en die effectief besteed werd voor het oplossen van de hot fixen.
effectieve tijd op dev/itg
We beschouwen de integratieperiode als de periode van (doorgaans) 4 weken waarin de programmeurs vrij tussen de ontwikkelingsmachine en de integratiemachine code over en weer mogen zetten. Nu zijn er diverse manieren om het geheel van een release te bekijken.
