Mert Atakan Kaya
THINK 1
Ik heb ervoor gekozen om mijn document in 2 Cycles te realiseren, om zo eerst een basis te kunnen leggen over Scrum zelf en vervolgens wil ik het hebben over specifieke problemen en het advies om die problemen op te lossen.
In dit eerste Cycle zal ik willen beginnen met de Manual gedeelte van mijn document. Hierin hoop ik iedereen hun kennis te verfrissen op het gebied van Scrum en hoe het volgens dit project verwacht wordt.
Scrum Manual
-Wat is Scrum ook alweer?
-Hoe hoor je te “Scrummen” bij Advanced Game Design?
De bronnen/theorie die ik zal gebruiken zal bij dit onderdeel wel grotendeels uit het artikel “Do Better Scrum - ScrumSense” van Peter Hundermark komen, maar ook zal ik de project-handleidingen van dit semester gebruiken. Voor de rest van mijn bronnen kan je de bronvermelding van mijn document zelf bekijken.
Het resultaat dat ik zou willen behalen, is om een document te hebben met wat Scrum ook alweer allemaal inhoud en hoe je het volgens dit project kunt implementeren.
Software: Beheren
MAKE 1
Om te beginnen met de manual heb ik eerst de 2 onderdelen die ik wil behandelen nog verder opgedeeld.
CHECK 1
Bij het maken van de manual probeerde ik vooral zo objectief als mogelijk te zijn en niet alvast advies te geven hoe sommige onderdelen bij dit project beter toegepast konden worden. Tijdens het schrijven ben ik er ook achter gekomen dat de volgorde misschien niet altijd goed werkt, aangezien ik soms een term probeer uit te leggen waar ik een andere term voor nodig heb dat ik pas veel later uit leg. Ook de keuze die ik heb gemaakt om bij de artefacten de Burndown Charts niet uit te leggen is misschien wel juist een slechte keuze van mij geweest. Dat onderdeel is namelijk juist wat meestal bij Scrum vergeten wordt en juist veel problemen kan voorkomen. Ondanks deze conclusies heb ik wel mijn doel behaald deze cycle door een uitgebreide maar toch nog compacte manual te maken voor Scrum en hoe het tijdens Advanced Game Design verwacht wordt volgens de projecthandleiding.
THINK 2
In dit tweede Cycle zal ik verder willen gaan over scrumproblemen waar ik met mijn groepje tegenaan ben gelopen en hoe we deze hebben opgelost of hadden kunnen oplossen.
Voor dit onderdeel zal ik wel veel moeten terugkijken op de afgelopen aantal maanden en herinneren wat er ook alweer precies fout ging en wat de oorzaak daarvan zou kunnen zijn. Dit lijkt me nog wel een probleem waar ik tegenaan zou kunnen lopen, dat ik bepaalde problemen niet meer helder herinner of misschien zelfs helemaal niet herinner. De bronnen die ik zal gebruiken om op advies te komen staan ook in mijn bronvermelding van het rapport zelf, maar de meeste oplossingen voor de problemen zullen waarschijnlijk uit mijn eigen ervaring komen of door wat ik in de eerste cycle heb geleerd.
MAKE 2
Als eerste ben ik maar begonnen met het toevoegen van de artefacten die ik vorige cycle weg had gelaten, omdat ik er van overtuigd ben dat het wellicht problemen had kunnen oplossen of voorkomen die wij in het team hebben gehad.
CHECK 2
Ik vind het voor deze cycle wel moeilijk om te beoordelen of ik mijn doelen wel of niet heb behaald. Ik heb namelijk wel de missende onderdelen toegevoegd aan het Manual gedeelte van mijn document en ik heb een voorwoord + conclusie geschreven. Wat ik wou doen heb ik dus wel gedaan, maar de kwaliteit van mijn conclusie vind ik veel te mager. Het is duidelijk te merken dat ik het helemaal gehad had met het schrijven van het document, laat staan met het schrijven van deze check. Nog een conclusie dat ik kan trekken is dat de punten waar ik advies over geef in iedere geval niet alle mogelijke problemen dekken, maar ik hoop wel echt dat ik minstens 1 iemand die volgend jaar dit semester gaat doen weet te helpen met dit document.
Nog een punt is dat ik uiteindelijk helemaal geen gebruik heb gemaakt bij dit gedeelte van de genoemde bronnen, behalve voor het halen van motivatie om advies te blijven geven (raar genoeg werd ik gemotiveerd om te zien dat iemand anders over hetzelfde onderwerp ook advies aan het geven was).
CONTEXT 2
Zoals ik ook al in de context van mijn vorige cycle zei is de reden waarom ik dit rapport wil schrijven, omdat er toch weer iedere project het een of het ander mis gaat op het gebied van Scrum. Ik hoop door middel van het rapport/manual de volgende studenten die het verdiepende themasemester/minor “Advanced Game Design” gaan volgen te helpen met het werken volgens Scrum en hoe ze moeten handelen bij de meest voorkomende problemen bij dit project. Tot nu toe heb ik in mijn eerste cycle alleen nog maar de manual geschreven om iedereen zijn/haar geheugen op te frissen op het gebied van Scrum. Alleen zou ik bij mijn tweede cycle graag punten willen opnoemen wat allemaal mis ging bij mijn groepje en de groepjes waarmee ik heb gesproken. Waarna vervolgens advies te geven over hoe volgens mij het beste gehandeld kan worden in de genoemde situaties.
LEARNINGS 2
Het is moeilijk om advies te geven zonder je persoonlijkheid teveel te laten merken. Het is namelijk heel erg duidelijk dat het adviesrapport gedeelte dat ik heb geschreven veel verschilt van de manual gedeelte erboven. De manual was zeer onpersoonlijk en meer professioneel, terwijl het adviesrapport gaat over mijn beleving en hoe ik er over denk of hoe wat volgens mij de beste manier is om te handelen bij de genoemde situatie.
CONTEXT 1
Om mijn beroepstaak Software: Beheren te bewijzen zal ik een Adviesrapport/Manual schrijven genaamd “How2Scrum@AGD”. De reden waarom ik dit rapport wil schrijven is omdat er toch weer iedere project het een of het ander mis gaat op het gebied van Scrum. Ik hoop door middel van het rapport/manual de volgende studenten die het verdiepende themasemester/minor “Advanced Game Design” gaan volgen te helpen met het werken volgens Scrum en hoe ze moeten handelen bij de meest voorkomende problemen bij dit project.
LEARNINGS 1
Het moment dat ik deze manual schreef besefte ik me opeens dat mijn groepje veel punten niet goed heeft uitgevoerd volgens Scrum. Ook mijn eigen kennis over Scrum was duidelijk niet op niveau voordat ik deze manual had geschreven. We hebben misschien wel eens in het eerste schooljaar een toets gemaakt over Scrum, maar dat was lang niet goed genoeg om een volledig begrip te krijgen over wat Scrum nou echt allemaal inhoud en waarom je het wel of niet zou willen toepassen. Dit zijn dan op het moment wel punten die ik weet vooral door de essentie van Scrum te hebben behandeld.
Bij het gedeelte “Wat is Scrum ook alweer?” geef ik in mijn eigen woorden nog snel samengevat alles wat Scrum inhoudt, zodat de lezer zijn/haar geheugen wordt ververst over wat Scrum ook alweer is. Ik heb namelijk zelf vaak gehad dat wanneer een project weer begint er altijd weer mensen in het project zijn die opeens niet meer weten wat alle termen van Scrum inhouden, of hoe ze zich volgens Scrum moeten gedragen.
Met als eerste een definitie van Scrum gevolgd door de essentie van Scrum.
Daarna alle Scrum rollen met de bijbehorende verantwoordelijkheden per rol.
Gevolgd door alle meetings die horen plaats te vinden volgens Scrum.
Bij het schrijven en uitleggen van alle Scrum artefacten heb ik er uiteindelijk voor gekozen om niet de Sprint en Product/Release Burndown Charts te vermelden, omdat ik vind dat door te kijken naar de Sprint en Product Backlog de huidige progressie ook wel duidelijk genoeg te merken is. Vooral bij het project AGD werd er nooit van ons verwacht om de Burndown Charts te gebruiken of ze te laten zien.
Bij het gedeelte “Hoe hoor je te “Scrummen” bij Advanced Game Design” geef ik in mijn eigen woorden de punten die in het projecthandleiding voorkomen, zodat de lezer rekening kan houden met alles wat van je wordt verwacht bij het project zelf en dit zo allemaal makkelijker in de Scrum werksfeer kan uitvoeren.
Het resultaat dat ik zou willen behalen, is om het document af te ronden met nu dus het tweede gedeelte (Het adviesrapport zelf) er in, een voorwoord die de lezer voorbereid op alles wat in het document staat en te eindigen met een algemene conclusie. Bovendien wil ik zoals ik in mijn Check van de eerste cycle al opnoemde de artefacten die ik niet heb behandeld nu wel toevoegen aan de manual gedeelte.
Vervolgens begon ik op chronologische volgorde terug te denken naar wat er allemaal fout was gegaan.
Alleen kon ik mij natuurlijk niet alles herinneren en heb ik hier als bron de Sprint backlogs gebruikt aangezien wij deze nog allemaal hadden.
Ik kwam er al gauw achter dat ik eindeloos door kon gaan met schrijven, aangezien er een oneindig aantal zijn aan problemen die kunnen voorkomen. Daarom heb ik alleen maar de meest essentiële problemen behandeld die te maken hebben met Scrum.
