gevraagde cijfers
In QPR moeten we een overzicht opleveren waaruit er per release het volgende kan afgeleid worden :
- Hoeveel user stories waren er op voorhand ingepland ?
- Hoeveel user stories zijn er in de loop van de iteratie bijgekomen ?
- Hoeveel user stories zijn er effectief afgewerkt ?
- Hoeveel user stories zijn er verschoven naar een volgende iteratie ?
We hebben het al eerder aangehaald : de cijfers zijn tot nu toe gebouwd rond het concept van de release.
We gaan de iteratie als centraal begrip nemen, omdat we een zicht willen hebben op het werk dat geleverd is tijdens
één iteratie, ongeacht voor welke release dit ook is.
user stories als startpunt
Vanuit Rallydev maken we wekelijks een export van de user stories , waarbij we telkens filteren op de huidige iteratie.

Merk op dat we niet alleen de sub user story zien maar ook de moederstory die zelf geen release of iteratie heeft.
Zodra een iteratie loopt, noteren we wekelijks welke user stories er in de iteratie zitten.
Tevens noteren we de release waaraan deze user story is toegekend. Normaal zal een iteratie gefocust zijn op
één release, maar je kan ook aan andere releases werken. Denk maar aan een fout rechtzetten op productie of acceptatie.
Of je kan al maanden op voorhand aan een groot project werken, waarvan de integratietesten nog lang niet gestart zijn.
export vanuit Rallydev

In Rallydev kan je een overzicht vragen van alle user stories die aan een bepaalde iteratie zijn toegekend. Je filtert eerst tot je enkel de user stories van de gewenste iteratie ziet. Daarna kan je via het menu aan de rechterkant om een export vragen. Je kiest het beste de export in CSV-formaat.
Hieronder zie je een voorbeeld van zo'n export in CSV-formaat. Merk op dat je niet alleen de user stories van de betreffende iteratie ziet maar ook de moederstories. Die heb je in feite niet nodig.

EN hieronder zie je het CSV-bestand en de overeenkomstige lijst uit Rallydev.
Zoals gezegd hebben we in MySQL de moederstories niet nodig.

gewenste structuur van de gegevens
Tussen 7 en 28 juli '08 had ik verlof. In die periode is er dan ook van export vanuit Rallydev niet altijd veel in huis gekomen. Ik had te weinig gegevens geëxporteerd en dus heb ik de gegevens gereconstrueerd zoals ze zouden moeten zijn voor het opbouwen van een historiek.
Waar gaat het in essentie om ?
We noteren in de eerste week van de iteratie welke user stories er in de lopende iteratie genoteerd zijn.
In de tweede, derde en vierde week doen we hetzelfde. In die periode kunnen er user stories bijkomen. ER zullen er nog niet teveel geschrapt worden, al kan dit natuurlijk wel.
Na de iteratie moet er gekeken worden welke user stories er al dan niet effectief zijn afgewerkt. En dus verschuiven de niet afgewerkte user stories naar een volgende iteratie.
Daarom moet je iedere week van de iteratie in de databank de user stories importeren. Via SQL instructies kan je dan naderhand uitvissen welke user stories er in welke week van de iteratieperiode gekend waren.
Als je zoiets handmatig uitpluist, kom je op de volgende gegevens uit.

Bedoeling is echter iedere week te noteren welke user stories er in de iteratie zitten. In het bovenstaande schema wordt enkel de datum genoteerd dat de user story voor het eerst is toegevoegd aan de iteratie. In feite moet je die iedere week noteren dat de user story voorkomt.
We hebben een iteratie van 4 weken. We noteren iedere week van de iteratie welke user stories er voorkomen. Enkele dagen na de iteratie - als de gegevens van rallydev zijn bijgewerkt- nemen we weer een export om te kijken welke user stories er nu effectief zijn afgewerkt zoals voorheen afgesproken.
In het scherm hieronder geven we een overzicht van 3 user stories die op voorhand waren ingepland. Zij komen dus terug in de 4 weken van de iteratie. De export van de effectief afgewerkte user stories moet hier nog aan toegevoegd worden.

import in MySQL
klaarmaken van het CSV-bestand
Hieronder zie je een werkblad van een XL werkboek waarin we een aantal taken uit Rallydev hebben bewaard.

We bewaren dit XL werkblad in CSV-formaat. Hiervoor kiezen we bewaren als - andere indelingen.
We kiezen voor het csv-formaat en geven het bestand een naam.
import in MySQL
Om de gegevens te importeren doen we een beroep op Navicat, een grafische schil rond MySQL. We selecteren het bestand "historiek taken" en klikken op "import wizard".

We geven vervolgens aan dat we een tekstbestand willen inlezen.

We kiezen voor CSV-formaat en selecteren het bestand.

We geven aan dat de velden door een puntkomma (;) van elkaar gescheiden zijn.

Vergeet niet aan te duiden dat de import pas gebeurt vanaf de tweede rij. De eerste rij bevat immers de hoofding van de velden.

We vergelijken de structuur van het importbestand en de tabel. ALs alles goed is voorbereid, kan je hier zonder meer bevestigen om naar de volgende stap van de wizard te gaan.

En tot slot bevestigen we dat we nieuwe records willen toevoegen. Als alles lukt, zien we onderstaande scherm.






