Plan van Aanpak. project Tetris Packing. Groep: eii7aab. Geert Weening Mark Rietveld Ron Talman Ingmar te Raa Leander Nijland Daniël van Cleef

Plan van Aanpak project Tetris Packing

Groep: eii7aab Geert Weening Mark Rietveld Ron Talman Ingmar te Raa Leander Nijland Daniël van Cleef Versie: 1.0

Plan van Aanpak - Project Tetris Packing

Inleiding

4

Projectomschrijving

5

Doel van het project

5

Onderwerp van het project

5

Invulling van het project

6

Producten

7

Functioneel Ontwerp

7

Implementatierapport

7

Testrapport

7

Systeemdocumentatie

7

Aanpak

8

Projectmethodiek

8

Fasen

8

Sprints

9

Product Owner

9

Scrum Master

9

Product Backlog

9

Sprint Backlog

9

Daily Scrum Meeting

10

Uren Registratie

10

Burndown Grafiek

10

Voortgangsrapportage

10

Programmeer technieken

10

Project Hosting

10

Risicofactoren

11

Tijdnood

11

Ziekte

11

Verlies, beschadiging van werk

11 2


Kennis

11

Enthousiasme / inzet

11

Projectorganisatie

12

Rollen

12

Team Leader (Geert Weening)

12

Quality Manager (Mark Rietveld)

12

Support Manager (Ron Talman)

12

Plannings Manager (Ingmar te Raa)

13

Process Manager (Daniel van Cleef)

13

Resources

13

Werkomgeving

13

Hardware

13

Kwaliteitsborging

14

Testen

14

Daily Scrum Meeting

14

Codeconventie

14

Document en code review

14

Begeleiding

14

Planning

15

3


1. Inleiding Dit plan van aanpak dient als handleiding voor het project “Tetris Packing”. Het doel van dit document is het omschrijven van het project en bevat de afspraken die voor dit project gemaakt zijn. Het plan van aanpak wordt opgesteld voor aanvang van het project. Er kan van het plan van aanpak worden afgeweken, maar dan wordt het plan van aanpak zelf niet aangepast. Eventuele afwijkingen worden in de voortgangsverslagen opgenomen. Het plan van aanpak is verdeeld in een aantal hoofdstukken. In het eerste hoofdstuk, “Projectomschrijving” wordt ingegaan op algemene zaken met betrekking tot het project. Het hoofdstuk “Aanpak” gaat in op de aanpak van het project. In dit hoofdstuk wordt beschreven welke methodieken en technieken er gebruikt worden tijdens het project.

4


2. Projectomschrijving 2.1. Doel van het project Het doel van het project is het oplossen van het bin-packing probleem in een variant die wij invullen aan de hand van een “Tetris-situatie”. Het bin-packing probleem houdt zich bezig met het vullen van zogenaamde bins. Een bin is een container met een van tevoren bepaalde beperkte inhoud. Deze bin's worden gevuld met een van tevoren bepaald aantal blokken. Deze blokken moeten van verschillende grootte zijn en zullen dus verschillende hoeveelheid aan ruimte in beslag nemen in de bins. Bij het oplossen van het bin-packing probleem is het van belang dat er zo weinig mogelijk bin's in gebruik zijn wanneer alle blokken in de bin's zijn gestopt. Ook is het van belang dat het oplossen van het probleem zo weinig mogelijk resources kost. Het bin-packing probleem kan zich voordoen in zowel een één-, twee- als driedimensionale wereld. Bij dit project hebben we ervoor gekozen om het 2D-bin-packing probleem op te lossen met eventuele uitbreiding naar het oplossen van het 3D-bin-packing probleem.

2.2. Onderwerp van het project Het binpacking probleem willen wij gaan oplossen in de context van het spel Tetris. Tetris is een computerspel waarbij je als speler een aantal blokken in een twee- of driedimensionale wereld op een dusdanige manier in elkaar schuift, zodat er zo min mogelijk tussenruimtes ontstaan. Voor elk volledig aaneengesloten rij worden punten toegekend en verdwijnt de rij om plaats te maken voor de overige blokken. De blokken worden één voor één op het scherm gepresenteerd en verschijnen boven in het speelveld. De blokken vallen omlaag, waardoor de speler steeds minder tijd heeft om een blok in de juiste positie te zetten. De blokken zijn te roteren tijdens het vallen. Wanneer een blok de al geplaatste blokken of de onderkant van het speelveld raakt, dan is de positie van het blok definitief en verschijnt het volgende blok. Dit gaat zo door totdat de blokken op zijn of totdat de geplaatste blokken de bovenkant van het speelveld raken. In het eerste geval heeft de speler gewonnen. In het tweede geval heeft de speler verloren. De blokken kunnen verschillende vormen hebben en dus verschillende grootten ruimte in beslag nemen. Hieronder kun je de standaardvormen zien die je in Tetris kunt tegenkomen.

5


Hieronder kun je een voorbeeld zien van een Tetris speelveld.

Het spelen van Tetris kun je zien als het oplossen van een variatie van het bin-packing probleem.

2.3. Invulling van het project Als invulling van het project willen wij bepaalde eigenschappen van Tetris gebruiken om een oplossing te vinden voor het bin-packing probleem. Wij gaan dus niet het spel Tetris ontwikkelen. De eigenschappen van Tetris die wij gaan gebruiken zijn: - Een veld is een tweedimensionaal vlak - Blokken van dezelfde standaardvormen - Blokken worden vanaf de bovenkant geplaatst - Als het blok geplaatst is, staat de positie van het blok vast Naast deze eigenschappen hebben wij ook zelf een aantal eigenschappen bedacht: - Regels verdwijnen niet na het vullen van een regel - Er wordt gebruik gemaakt van een vaste verzameling van blokken - De blokken worden door het algoritme gepositioneerd - De blokken bewegen niet meer uit zichzelf naar de onderkant toe Volgens bovenstaande eigenschappen kunnen we het onderwerp als volgt definieren: Er bestaat een 2-dimensionaal veld waarin de standaard tetris figuren (zoals hierboven beschreven) kunnen worden ingepakt. De breedte van het veld en de volledige set van blokken die ingepakt moeten worden zijn van te voren bekend. Het veld moet van onderaf gevuld worden en er moeten zo weinig mogelijk regels gevuld zijn als alle blokken ingepast zijn. De blokken mogen gedraaid worden, maar kunnen alleen in een rechte lijn naar beneden geplaatst worden. Neerzetten en schuiven is hierdoor niet mogelijk. Hiervoor heeft het veld een variabele hoogte en kan na doorloop van een plaatsing de efficientie vergeleken worden op basis van regels die in gebruik zijn.

6


2.4. Producten Tijdens het project zullen er naast de applicatie verschillende bijproducten opgeleverd worden. Deze worden samen met de applicatie in deze paragraaf besproken. Onderstaande producten worden per iteratie opgeleverd. Voor dit project lopen we meerdere iteraties door. Binnen één iteratie kunnen er wel meerdere sprints zijn. Gedurende een sprint kan er wel aan de documentatie worden gewerkt, maar deze wordt dan niet opgeleverd aan de opdrachtgever.

2.4.1. Functioneel Ontwerp Voor de implementatie wordt een ontwerp opgezet waarin de functionaliteit die geïmplementeerd gaat worden staat beschreven. Dit is geen technisch ontwerp, maar een uitwerking van de functionaliteit zodat duidelijk is wat de requirements zijn van de verschillende onderdelen van de applicatie.

2.4.2.Implementatierapport Dit rapport bevat een verslag van de implementatie. Hierin staat wat voor beslissingen er zijn genomen tijdens het implementeren en waarom deze zijn genomen. Mochten er zich tijdens het implementeren problemen hebben voorgedaan, dan staan deze beschreven in het implementatierapport.

2.4.3.Testrapport In het testrapport staan de resultaten van de tests. Er wordt beschreven welke tests er uitgevoerd zijn, wat de resultaten van de gedane tests waren en wat er eventueel nog gedaan moet worden om problemen die uit de tests naar voren kwamen op te lossen.

2.4.4.Systeemdocumentatie In de systeemdocumentatie staat de beschrijving van de verschillende onderdelen van de applicatie. In dit document staan bijvoorbeeld de Class Diagrams met uitleg.

7


3. Aanpak 3.1. Projectmethodiek Wij hebben besloten om Scrum te gebruiken als project management methode voor onze ontwikkeling. Dit houdt in dat het projectduur onderverdeeld is in zogenaamde sprints en dat er per sprint een werkend product opgeleverd moet worden. Ons project is opgedeeld in meerdere iteraties, aan het eind van elke iteratie wordt er documentatie en een voorlopig werkend product opgeleverd aan de opdrachtgever. Binnen elke iteratie bestaan er sprints waarbinnen aan de documentatie wordt gewerkt en aan het eind van elke sprint ook een werkend product moet zijn gerealiseerd. Bij een scrum aanpak hoort onderstaand plaatje.

Voorafgaand aan het project stellen we een product backlog op met de beoogde functionaliteit voor de applicatie. Daarna beginnen we met een sprint waarvoor een sprint backlog wordt opgezet met de functionaliteit die voor die sprint opgeleverd moet worden. Elke dag dat we aan het project werken zal er een “daily scrum meeting” worden gehouden waarin we elkaar kort vertellen waar we mee bezig zijn en of er problemen zijn. Deze dagelijkse meetings maken het makkelijker om op tijd problemen te signaleren. Na elke sprint wordt er een product opgeleverd met de beoogde functionaliteit voor die sprint. Naast Scrum gebruiken we Extreme Programming als agile software ontwikkelmethode. Dit houdt onder andere in dat we unit tests uitvoeren en documentatie reviewen. De invulling van de XP onderdelen staan uitgewerkt verder in het document.

3.1.1.Fasen Volgens Scrum kan het project in drie fasen worden opgesteld: - Voorstudie - Ontwikkeling - Test & Oplevering Tijdens de voorstudie worden de technisch en functionele specificaties van het op te leveren product vastgelegd. Door middel van documentatie moet duidelijk worden wat de requirements voor de applicatie zijn. In de fase “Ontwikkeling” wordt er geïmplementeerd. Aan de hand van het ontwerp wordt de functionaliteit gebouwd. 8


In de fase “Test & Oplevering” wordt de applicatie getest en opgeleverd

3.1.2.Sprints Sprints zijn vaste periodes die het project onderverdelen. Voor elke sprint zullen we bovenstaande fases doorlopen. Aan het begin van een sprint wordt functionaliteit uit de backlog gepakt die voor die sprint opgeleverd moet worden. Er wordt naar deze functionaliteit gekeken en er wordt door middel van onderzoek en overleg duidelijk wat de requirements zijn voor de backlog items. Vervolgens worden de backlog items geïmplementeerd en daarna getest zodat er een werkend product aan het eind van de sprint opgeleverd kan worden.

3.1.3. Product Owner De product owner is de opdrachtgever voor het project. In ons geval zijn dit de begeleiders vanuit school, de heer Prakken en de heer Stroet. In overleg met de product owner worden de items bepaald die in de backlog komen en waar de prioriteiten liggen.

3.1.4. Scrum Master Volgens scrum is er een scrum master die als teamleader fungeert en de voortgang van het team bewaakt. Hij leidt de meetings, deelt de sprints in en bewaakt het proces. In het geval van ons project vonden wij dit wel erg veel werk voor een persoon en hebben de taken onderverdeeld. Als de scrum master rol door een persoon ingevuld moet worden dan komt deze persoon bijna niet meer aan implementeren toe. Wij hebben de scrum master rol onderverdeeld in een Team Leader, Plannings Manager en Process Manager. De invulling van deze rollen staan beschreven in Hoofdstuk 5: Projectorganisatie.

3.1.5. Product Backlog De product backlog is een lijst met alle functionaliteit die in het eindproduct geïmplementeerd dienen te zijn. Elk onderdeel wordt een story genoemd, en elke story krijgt een aantal punten waarmee aangegeven wordt hoeveel werk het is om die story te implementeren. Om deze punten te verdelen wordt de kleinste story als basis genomen, die is 1 story-point. Alle andere storypoints worden ingeschat aan de hand van hoeveel werk ze zijn ten opzichte van de basis. Als mogelijke waarden voor een aantal storypoints nemen we de reeks van Fibonacci. In de lijst van stories worden ook prioriteiten aangegeven, hiervoor gebruiken we de MoSCoW methode.

3.1.6. Sprint Backlog De sprint backlog is een lijst met functionaliteit die voor die sprint gedaan moet worden. Aan de hand van de aangegeven MoSCoW prioriteiten worden er items uit de product backlog gepakt en in de sprint backlog geplaatst. De sprint backlog kan ook activiteiten bevatten die implementatie van een bepaalde functionaliteit mogelijk maken. Dit om een beter overzicht van de benodigde tijd te hebben. Hiermee kan het opstellen van ontwerpen, documentatie en planning worden opgenomen. Voor de eerste sprint plannen we de activiteiten in op basis van de aangegeven storypoints uit de backlog. We geven een tijd aan die het uitvoeren van één storypoint zou kunnen innemen en aan de hand van die indicatie bekijken we hoeveel storypoints er in één sprint kunnen. Vervolgens beginnen we met de activiteiten binnen de sprint en komen we er achter of onze indicatie overeen komt met de ingeschatte tijd per storypoint. Als dit ongeveer klopt dan kunnen we de tijdsindicatie per storypoint aanhouden en anders moet de tijdsindicatie worden bijgesteld en kan het zijn dat er activiteiten naar een volgende sprint moeten worden verschoven. We plannen de backlog per sprint in aan de hand van storypoints uit de backlog en de hoeveelheid tijd die het gehele team gezamenlijk heeft voor die sprint.

9


3.1.7. Daily Scrum Meeting Elke dag dat wij samenkomen om aan het project te werken houden wij een daily scrum meeting. Hierin overleggen we kort de volgende punten: - Wat heeft elk teamlid gedaan? - Wat gaat elk teamlid vandaag doen? - Zijn er problemen? De “Daily Scrum Meetings” gelden tot de volgende meeting. Wij werken niet elke dag met het hele team aan het project. Er zijn twee dagen dat wij samenkomen en aan het project werken. Op die dagen wordt de “Daily Scrum Meeting” gehouden en worden er afspraken gemaakt die gelden tot de volgende meeting.

3.1.8. Uren Registratie Om onze gewerkte uren bij te houden gebruiken we de open source applicatie Redmine. Dit is een webapplicatie die op een van de pc's in het lokaal is geïnstalleerd. Redmine is daarom ook vanaf thuis bereikbaar.

3.1.9. Burndown Grafiek Tijdens het project en binnen de sprints houden we een burn down grafiek bij. Hierin staat het totaal van de story-points bovenaan de grafiek, en voor elke story die afgerond is daalt de grafiek. Op die maniek is makkelijk te zien of het project op schema ligt. Redmine heeft tools om deze grafiek te maken.

3.1.10. Voortgangsrapportage Aan het begin van elke week wordt er gekeken hoe het met de stand van het project zit, hoe staat het met de planning, wat voor backlog-items zijn er geïmplementeerd en wat moet er nog gedaan worden, zijn er problemen en hoe gaan we hier mee om. Deze rapportage wordt door de Plannings Manager en de Process Manager opgesteld en aan de hand van dit rapport bekijkt de teamleader hoe het team er voor staat. Deze rapportages worden na review en mogelijk toevoeging van de teamleader wekelijks opgeleverd aan de opdrachtgever.

3.2. Programmeer technieken Java Wij hebben er voor gekozen om ons project in Java te implementeren. Dit omdat de meeste projectleden al een goede basis in Java hebben. Dit voorkomt een voortraject waarin de taal geleerd moet worden.

3.3. Project Hosting Voor hosting van ons project maken wij gebruik van een code.google project. Op http:// code.google.com/p/eii7aab/. Deze omgeving wordt beheerd door de support manager. Wiki Op ons code.google project hebben wij ook een wiki waarin alle gemaakte documentatie opgeleverd moet worden. Ook staat hier de taakverdeling en andere projectgerelateerde documentatie op. Voordeel van een wiki is de uniformiteit van de opmaak. Het delen van documenten met elk eigen opmaak wordt snel overzichtelijk en moeilijk samen te voegen. Versie beheer Via ons code.google project hebben wij ook de beschikking over een SVN server. Wij gebruiken SVN om de code te beheren. Ook de wiki staat in SVN.

10


4. Risicofactoren Elk project kent verschillende risicoʼs. In dit hoofdstuk worden verschillende risicoʼs weergegeven en zo mogelijk een passende oplossing gegeven.

4.1. Tijdnood Voorafgaand aan het project is de complexiteit van het gehele project niet goed te overzien. Het kan zijn dat we gedurende de implementatie achter zaken komen die te ingewikkeld blijken waardoor wij als projectteam in tijdnood komen. Een manier om met tijdnood om te gaan is het definieren van prioriteiten op bepaalde functionaliteit. In het geval van tijdnood krijgt een high-prio item voorrang.

4.2. Ziekte Het kan altijd voorkomen dat een teamlid ziek wordt. Als dit voor langere tijd is dan kan dit een probleem worden voor het project. Een ander teamlid moet dan het gedeelte van het zieke teamlid overnemen. Dit kan uiteindelijk resulteren in tijdnood voor het hele team. Voor ziekte geldt dan dezelfde oplossing als bij tijdnood.

4.3. Verlies, beschadiging van werk Verlies van code of documentatie kan een groot probleem worden voor het project. Dit kan gebeuren doordat bijvoorbeeld de computer van een teamlid crasht. Om te zorgen dat onze data veilig blijft gebruiken we een SVN server waar onze code en documentatie op wordt bewaard. Deze wordt ook geregeld ge-backupped door de support manager.

4.4. Kennis Mocht er tijdens het project blijken dat er te weinig kennis is van bijvoorbeeld de programmeertaal of de theorie achter de algoritmen dan kan dit problemen opleveren. Hiervan is al een gedeelte afgedekt met de orienterende taak waarin onderzoek wordt gedaan naar verschillende algoritmes, maar gedurende het project kan het nog voorkomen dat een teamlid te weinig kennis heeft. Om gebrek aan kennis op te lossen gaan de andere teamleden het teamlid zoveel mogelijk proberen te helpen bij gebrekkige kennis. Mocht dit niet voldoende zijn dan kan de hulp worden ingeroepen van een begeleider.

4.5. Enthousiasme / inzet Elk project heeft zijn leuke en minder leuke kanten en de voortgang van een project is wel gedeeltelijk afhankelijk van de enthousiasme en inzet van de teamleden. Nu hebben we geprobeerd om een projectonderwerp te vinden waar de meeste teamleden zich in konden vinden, maar toch is het mogelijk dat een teamlid zijn enthousiasme verliest. Om dit op tijd te constateren hebben we “daily scrum” meetings op de dagen waarop we aan het project werken. Tijdens deze meetings is er aandacht voor de voortgang van de werkzaamheden van de teamleden en eventuele problemen. Door deze meetings wordt het makkelijker om afname in enthousiasme of inzet in een vroeg stadium te constateren en samen met het teamlid naar een oplossing te zoeken, eventueel met de projectbegeleiding. Als er geen oplossing te vinden is in overleg met het teamlid en de projectbegeleiding dan kan het project voortgezet worden zonder het betreffende teamlid.

11


5. Projectorganisatie 5.1. Rollen Binnen scrum zijn is het gebruikelijk om maar twee verschillende rollen te hebben: Scrum master en developer. Onze ervaring is dat een scrum master door zijn brede rol weinig tot geen tijd overhoudt om zelf te programmeren. Wij hebben daarom besloten de rol van scrum master op te splitsen in vier rollen: Team leader, Quality Manager, Planningsmanager en Process Manager. Daarnaast is besloten om iemand verantwoordelijk te maken voor de systemen die we nodig hebben, zoals een codebeheer systeem en een tracker voor de besteede tijd. Die rol is Support manager genoemd. Elk van deze rollen beschrijven de taken van het projectlid naast de normale taken van developer. De leden die geen extra rol invullen zullen dus meer tijd besteden aan de developer rol.

5.1.1. Team Leader (Geert Weening) Voor de Team Leader hebben we de volgende taken gevonden: - Bouw en onderhoud een effectief team, dit wil zeggen dat de doelen op gebied van tijd, kosten en kwaliteit gehaald worden en dat het team tevreden is met het project. - De teamleden motiveren om actief met het project bezig te zijn, dit houd in dat de teamleden hun geplande uren werken en documentatie op een juiste manier en op tijd inleveren - Problemen binnen het team oplossen - Opdrachtgever/begeleiding op de hoogte houden van de voortgang van het team - Vergadering effectief leiden, dit wil zeggen dat de teamleader er voor zorgt dat elk teamlid actief meedoet met de vergaderingen en andere activiteiten. Om de voortgang van het project goed in de gaten te houden en de opdrachtgever/begeleiding hiervan op de hoogte te houden is het zaak dat de teamleader elke week bijhoud wat de voortgang van het project is. Hij zal elke week moeten bekijken wat er gedaan is, wat er af is, wat er nog gedaan moet worden en wat voor problemen er zijn ontstaan of hoe deze opgelost kunnen worden. Vervolgens wordt de opdrachtgever/begeleiding op de hoogte gesteld door middel van wekelijkse rapporten en wordt de begeleiding gevraagd te helpen bij teamleden die consequent hun taak niet goed uitvoeren.

5.1.2. Quality Manager (Mark Rietveld) Voor de Quality manager hebben we de volgende taken gevonden: - Zorgt ervoor dat alle geschreven code door een andere developer gereviewd wordt. Hiermee wordt de kwaliteit van de code hoger, en kunnen developers van elkaar leren. - Zorgt ervoor dat alle code leesbaar is, door de afgesproken code conventie te handhaven. - Controleer dat alle op te leveren documenten dezelfde stijl hebben. - Zorgt ervoor dat alle op te leveren documenten gereviewd worden.

5.1.3. Support Manager (Ron Talman) Voor de Support Manager hebben we de volgende taken gevonden: - Zorgt ervoor dat er geschikte tools voor het ontwikkelen beschikbaar zijn en functioneren. - Zorgt dat er alleen afgesproken veranderingen aan de datastructuur en het framework worden gedaan. - Zorgt dat er een issue tracking systeem beschikbaar is. - Zorgt ervoor dat eventuele servers online blijven ( SVN, Apache, SSH ) 12


- Zorgt voor back-ups van de code

5.1.4. Plannings Manager (Ingmar te Raa) Voor de planningsmanager hebben we de volgende taken gevonden: - Leidt het team bij het maken van een indeling voor de komende sprint uit de stories die nog in de backlog staan. - Houdt de voortgang van het team bij en vergelijk dit met het plan. - Maakt iedere week een rapport van de status van het team. Binnen scrum is het zaak dat taken worden verdeeld binnen een sprint. Het bijhouden van de voortgang door middel van het meten van verbrande story-points en het meten van de efficiency is essentieel voor het verbeteren van de planning. Deze zullen dus goed bij moeten worden gehouden. Binnen de sprint liggen de volgorde van stories niet vast, die taakverdeling wordt tijdens de daily meetings gemaakt.

5.1.5. Process Manager (Daniel van Cleef) Voor de process manager hebben we de volgende taken gevonden: - Ziet erop toe dat aan het begin van elke projectdag een korte meeting gehouden wordt. - Houdt bij hoe lang de meeting duurt en laat weten wanneer het langer dan een kwartier duurt. - Bij iedere vergadering notuleren. - Meedoen aan het ontwikkelen van de voortgangsrapportage.

5.2. Resources De volgende resources worden gebruikt tijdens het project.

5.2.1. Werkomgeving Gedurende het project maken wij gebruik van een lokaal dat voor ons project ter beschikking is gesteld. Dit is lokaal W154.

5.2.2. Hardware Voor het project hebben wij de systemen ter beschikking die in lokaal W154 staan. Hier mogen wij mee omgaan volgens de regels die door systeembeheer zijn opgelegd. Deze systemen kunnen wij gebruiken om ons project op te draaien en mogelijk voor de teamleden om aan te werken.

13


6. Kwaliteitsborging 6.1. Testen We gaan gebruik maken van unit tests voor losse onderdelen van de applicatie. Voor het testen van de applicatie en uitvoer van de applicatie worden testen opgesteld die in het testrapport komen. Wij doen geen test-driven development. De unit tests worden opgesteld nadat een gedeelte van de code is geschreven. Bijvoorbeeld als een class is geïmplementeerd worden er voor die class unit tests geschreven zodat de werking van de class en de functies daarbinnen op juistheid gecontroleerd kunnen worden. Het opstellen van tests voor de werking voor de applicatie of een deel van de applicatie wordt niet van te voren opgesteld, maar gedurende de ontwikkeling en voorafgaande aan de testfase binnen een sprint. Hier hebben we voor gekozen omdat de werking tijdens de implementatiefase nog kan gaan veranderen. Het kan zijn dat we tijdens implementatie en door overleg er achter komen dat er wat verandert moet worden aan de werking van de applicatie, zaken die we niet van te voren hadden gezien.

6.2. Daily Scrum Meeting Op de dagen dat we samenkomen om aan het project te werken worden “Daily Scrum Meetings” gehouden. Door deze meetings willen we controle houden op de activiteiten en vroegtijdig problemen constateren.

6.3. Codeconventie Om de code duidelijk, overzichtelijk en overdraagbaar te houden maken we gebruik van codeconventies. Voor onze code-conventies nemen we de Java Programming Language conventies aan zoals deze door Sun Oracle is aanbevolen ( http://www.oracle.com/technetwork/java/ codeconvtoc-136057.html )

6.4. Document en code review Om de kwaliteit van de code en documentatie te waarborgen wordt de gemaakte code en documentatie door een ander teamlid gereviewed dan diegene die de code/documentatie heeft gemaakt.

6.5. Begeleiding Tijdens het project worden we begeleid door docenten vanuit school, deze vragen wij wekelijks om onze voortgang te bekijken en de kwaliteit van het project in de gaten te houden. Aan de hand van hun feedback kunnen we het project bijsturen.

14


7. Planning

Het project is opgedeeld in drie increments van vier effectieve weken (exclusief vakantie). Per week kunnen er twee werkdagen besteed worden aan het project. Er is gekozen voor sprints van twee weken, dus vier werkdagen per sprint. Hiervoor is gekozen omdat minder lange sprints erg kort worden waardoor veel overhead in administratie gaat zitten van het scrum-proces. Als gekozen wordt voor langere sprints zullen er per increment minder dan 2 sprints kunnen plaatsvinden. Er kunnen dan sprints overlappen met increments waardoor niet makkelijk aanpassingen kunnen worden gedaan op sprints afhankelijk van feedback van een incrementafsluiting.

15

Plan van Aanpak. project Tetris Packing. Groep: eii7aab. Geert Weening Mark Rietveld Ron Talman Ingmar te Raa Leander Nijland Daniël van Cleef

Recommend Documents