Op te leveren cijfers
Eénmaal per maand moeten er cijfers in QPR worden opgeleverd en op de eerstvolgende stuurgroep INF besproken. Hoewel de releases altijd centraal staan, ligt het meer voor de hand om de iteraties als centraal startpunt voor de cijfers te nemen. Uiteindelijk draait alles om die ene maand.
- facturen van de externe partijen worden maandelijks samengesteld.
- De stuurgroep INF bespreekt de cijfers iedere maand.
- De resource planning die de externe programmeurs en analisten vastlegt, wordt ook per maand vastgelegd.
- Iedere maand kan een programmeur met 3 releases bezig zijn : de huidige release, de volgende en de daaropvolgende. Het enige wat tijdens de maand niet wijzigt, is de iteratie zelf en die duurt (vanaf juni 08) ook een maand.
De volgende cijfers moeten opgeleverd worden
- # uren besteed aan ontwikkeling voor de daaropvolgende release die op integratie wordt klaargemaakt;
- # uren besteed aan het rechtzetten van fouten op de acceptatieomgeving;
- # uren besteed aan het rechtzetten van fouten op de productieomgeving.
De bovenstaande cijfers geven een idee van de kwaliteit van de integratie- en acceptatietesten.
Tijdens iedere iteratie zijn er 3 releases actief : de huidige op de productieomgeving, de volgende op de acceptatieomgeving en de daaropvolgende die op de integratieomgeving wordt samengesteld.
De nadruk van de iteratie moet altijd liggen op de daaropvolgende iteratie. Tijdens de vergaderingen met de sleutelgebruikers wordt er afgesproken welke requesten er moeten aangepakt worden. Voor een goede planning is het aangewezen dat je al voor het begin van een iteratie weet welke requesten je gaat doen en dat je zo weinig mogelijk in deze planning wijzigt.
Hoe goed de planning is, leid je af uit de volgende cijfers :
- # user stories in release bij begin van de iteratie
- # user stories verwijderd in de loop van de iteratie
- # user stories toegevoegd in de loop van de iteratie
En dit is de kern van het probleem : we hebben historische gegevens nodig en die vinden we in feite nergens terug, noch in Lotus Notes, noch in Rallydev. Of anders gezegd : je vindt ze wel terug, maar dan moet je telkens in de details van de requesten in Lotus Notes naar de historiek van de request gaan kijken. Hetzelfde geldt voor de gegevens in Rallydev.
Kortom, de gegevens zijn er wel, maar het is onbegonnen werk om die op te halen en te verwerken.
En hierbij moet het project Engelbert een oplossing bieden. Als we iedere week de gegevens vanuit Rallydev in MySQL bewaren met een datum erbij, dan kunnen we de historische gegevens wel automatisch ophalen en verwerken.
