...

Kwaliteit geleverde eindproduct

Voor ons product waren documentatie en uitbreidbaarheid de prioriteiten. We hebben uitendelijk twee producten ontwikkeld en daarbij een boel documentatie geleverd. 

Evaluatie gehanteerde projectmethode

Tussentijdse evaluatie

Ons plan van aanpak vond ik aanvankelijk niet erg goed. Ik had het idee dat we alles goed beschreven hadden en dat alles er duidelijk in stond, maar ik had toch het gevoel dat er iets miste. Bij het assessment voor het plan van aanpak kwamen dan ook enige gebreken aan het plan van aanpak naar voren. We gingen met name bij de randvoorwaarden en kwaliteitseisen voor mijn gevoel onderuit, omdat we niet goed de 5xW, 1xH en de SMART-formulering hadden toegepast. 

Ook zijn onze SCRUM-ceremonies erg ondermaats. Ik ben nog geen SCRUM-master geweest, maar ik krijg langzaam maar zeker steeds meer in de gaten dat er flinke gebreken zijn. Zo hebben we in het begin niet eens over uren gesproken bij DSU's en hadden we het alleen over onze taken. Waar we mee bezig zijn, wat we nog moeten doen en of we ergens tegen aan gaan lopen. We hebben nog niet het jira-planbord open gehad tijdens een DSU, wat er waarschijnlijk ook voor zorgt dat we als groep niet goed weten wat er gaande is binnen het project. Ik had hier zelf ook wat over moeten zeggen, maar volgens mij hadden we het als groep niet door dat dit een vereiste was.

Definitieve evaluatie

SCRUM is geen slechte manier om een project uit te voeren. Ik vind het zelf niet fantastisch werken, maar het werkt wel effectief. We hebben als groep redelijk ontwikkeld op het gebied van SCRUM. Waar we in sprint 1 een baggere planning hadden gemaakt en eigenlijk helemaal niet zo goed wisten wat we nou aan het doen waren, kwam daar langzaam verandering in.

Image AddedImage Added

Mijn grootste probleem lag bij het inschatten van taken. Ik merkte dat onze taken erg krap waren en dat ik vaak nét genoeg tijd had om een taak af te ronden. Daarnaast zit er in een sprint planning géén speling, omdat dat tege nde SCRUM-principes in gaat. Dit was met name voor Bram een probleem, omdat hij steeds weer nieuwe problemen tegen kwam bij het maken van de broker. Dit is dan ook waarom de lijn in de burndown-charts hier en daar plots weer omhoog gaat. Wij hadden dit als groep zelf beter kunnen en moeten opvangen. Wij waren slecht geïnformeerd over de implementatie van de broker. We hadden deze taak beter moeten opdelen en het in behapbare stukken moeten opdelen zodat we niet steeds deze ophogingen hadden. Deze ophogingen waren met name in sprint vier duidelijk. We hadden een goede planning gemaakt en waren allemaal hard aan het werk. In het begin zaten we zelfs onder de trendlijn, maar alle ophogingen zorgden er voor dat we uitendelijk onze sprint toch niet gehaald hadden.

We hadden aan het einde van de sprint ongeveer 20 uur aan taken over. Het aantal uren aan ophogingen kwam uit op 23:15 uur. Dit hadden we met z'n allen kunnen oplossen door bijvoorbeeld een zaterdagmiddag te werken, maar deze taak van Bram was voor ons hocus pocus, dus konden wij niet helpen met deze taak. We hadden dit dus beter op moeten vangen.

Naast het plannen van uren is SCRUM voor mijn gevoel ook niet erg handig qua reviewen. Dit valt een beetje terug op het plannen d.m.v. tijd, want reviewen het verbeteren van producten na een review neemt ook tijd in beslag die of als taak opgenomen zou moeten worden of ope een andere manier ingepland zou moeten worden. Het wordt echter lastig dit als taak in te plannen, want een deeltaak kan some in één keer goed zijn, maar kan soms na vijf reviews nog niet goed zijn. 

Beschrijving rollen binnen projectgroep

...