De Projectleiders hebben bi-weekly een overleg met de CTO en Algemeen Directeur. Hier worden alle lopende projecten van het type "softwareproject" besproken. Voor ieder project is een todo aanwezig op het Projectleidersbord en hierin wordt de voortgang besproken:
Alle notities worden bijgehouden op het kaartje (todo-item) als commentaar
De todo's hebben de volgende varianten:
Als er een nieuwe todo wordt aangemaakt, wordt deze gekoppeld aan het project t.b.v. de herleidbaarheid
Na afronding van de externe kick-off plant de Projectleider per sprint een sprintwissel in met de klant en het ontwikkelteam. In deze meeting bespreken zij de oplevering van de sprint, de planning van de volgende sprint en de voortgang van het project. Ook is er ruimte om bijzonderheden te bespreken.
Als het project korter dan 3 sprints duurt, wordt er enkel een sprintvoorbereiding en een sprintoplevering ingepland.
Software wordt ontwikkeld op basis van een projectmethodiek om structuur en voorspelbaarheid te creëren. Per project is de Projectleider verantwoordelijk om de projectmethodiek goed uit te voeren. Binnen Jump werken we op basis van Scrum. De Projectleider stemt de details hiervan af.
In Scrum wordt softwareontwikkeling opgeknipt in tijdsblokken van 2 a 3 weken - de Sprint. In een Sprint wordt door het ontwikkelteam zoveel mogelijk toegewerkt naar een afgerond stuk programmatuur.
Om aan een sprint te starten moeten er een aantal zaken zijn voorbereid.
Ter voorbereiding op de volgende sprint controleert de Projectleider de backlog. De Projectleider is verantwoordelijk voor het opnemen van de functionele eisen en een juiste beschrijving hiervan in user stories. Stories worden opgesteld op basis van de Definition of Ready.
De Projectleider bepaalt namens (of met) de klant de prioriteit van de user stories en doet een voorzet voor de set stories die de volgende sprint worden opgepakt.
De Projectleider organiseert een Sprint Planning. Tijdens deze meeting vraagt het ontwikkelteam om verheldering als functionele eisen onduidelijk zijn en wordt de technische beschrijving van de user stories verder uitgewerkt. Als de story voor iedereen helder is wordt een inschatting gemaakt van de complexiteit en de benodigde tijd. De projectleider kan op basis van de inschatting de prioriteit van de stories nog aanpassen. Waar nodig kunnen de stories al toegewezen worden aan een betreffende Developer.
Nadat de prioriteiten duidelijk zijn, start de Projectleider de nieuwe sprint op basis van de beschikbare tijd van de betrokken Developers.
Tijdens het ontwikkelen houdt de Developer zich aan de Definition of Done.
De lifecycle van een story ziet er als volgt uit:
De Reviewer van de code is een andere Developer in het team.
De code wordt beoordeeld op technische kwaliteit met de volgende uitgangspunten:
Wanneer er tijdens de review bijzonderheden zijn geeft de Reviewer feedback en behandelt dit met de oorspronkelijke uitvoerder. Als de beoordeling van de Reviewer positief is, accepteert deze de story en voegt de wijzigingen toe in het versiebeheer. Afsluitend verplaatst de Reviewer de user story van ‘Review’ naar ‘Testing’.
Bij het gebruik van een framework of 3rd party libraries houden we de volgende richtlijnen aan:
De Projectleider is verantwoordelijk voor het uitvoeren van de kwaliteitstoetsing. De projectleider controleert op de acceptatieomgeving of aan alle eisen in de Definition of Done is voldaan.
Story voldoet aan DoD: De Projectleider verplaatst de story van ‘Testing’ naar ‘Done’.
Story voldoet niet aan DoD: De Projectleider zet de story terug in "To Do", wijst hem toe aan de Developer en licht de Developer in. Het is zaak om de nog uit te voeren werkzaamheden zo snel mogelijk te voltooien.
Als alle user stories zijn getest en in de bucket ‘Done’ zijn opgenomen, zorgt de Projectleider ervoor dat de doorgeteste versie klaar wordt gezet voor de klant.
Let op! Er kan besloten worden om de oplevering van de sprint en de start van de nieuwe sprint in een presentatie te doen. Dit noemen we dan de sprintwissel.
Aan het einde van een sprint vindt de Sprint Oplevering plaats. De Projectleider presenteert de werkzaamheden aan de klant (zie: "B-210f Voorbeeld presentatie Sprintwissel"). De volgende onderwerpen worden behandeld:
De gehele sprintwissel (exclusief refinement) duurt niet langer dan een uur.
Het vervolg na de oplevering van de sprint heeft de volgende varianten:
Bij oplevering van een milestone volgt een acceptatietest. De testperiode wordt met de klant afgestemd, maar idealiter gebeurt dit voor de volgende sprint is afgerond. De klant heeft dan de tijd om het opgeleverde product te toetsen op de acceptatieomgeving en de Projectleider van feedback te voorzien. Wanneer de klant afziet van het uitvoeren van de acceptatietest, vraagt de Projectleider om een schriftelijke bevestiging (email, appje) van de klant. Opmerkingen achteraf worden in rekening gebracht.
De feedback, gegeven door de klant, wordt beoordeeld door de Projectleider. Hier maakt hij onderscheid in de feedback die binnen- en buiten de scope van de user stories vallen.