Opdrachtomschrijving¶

Inleiding¶

Tijdens project 1 heb je gewerkt aan Dokkie. Waarschijnlijk heb je hier je eerste stappen gezet om te leren programmeren en te bouwen aan een echte webapplicatie. Tijdens het bouwen aan Dokkie heb je gebruik gemaakt van door de opleiding geselecteerde bronnen, zoals webcourses, websites, e-books en workshops om te leren over de verschillende technieken die je nodig had.

Naast deze bronnen heb je vast en zeker ook gebruik gemaakt van een zoekmachine om bijvoorbeeld op te zoeken hoe je een loop programmeert in TypeScript of wat die vervelende error-melding in Visual Studio Code nu precies betekent. Het overzicht met (IT-gerelateerde) resultaten in je zoekmachine bevat bijna altijd een of meerdere links naar een heel handige website: Stack Overflow, waar je meestal wel een antwoord op je vraag vindt. Stack Overflow omschrijft zichzelf als:

“Empowering the world to develop technology through collective knowledge. Our public platform serves millions of people every month, making it one of the most popular websites in the world.”

Het is natuurlijk een heel handige website, maar je vindt er bijvoorbeeld geen antwoord op specifieke vragen over bijvoorbeeld de API van de HBO-ICT Cloud. Zou het daarom niet handig zijn als er een community is waar je als student van de Hogeschool van Amsterdam ook vragen en antwoorden kunt posten over HBO-ICT gerelateerde programmeerproblemen en ontwikkelomgevingen?

Wat je gaat maken¶

Tijdens project 2 ga je werken aan Code Exchange, een klein platform waarmee bovenstaande mogelijk is. Schrik niet, er wordt niet van je verwacht dat je een tweede Stack Overflow gaat bouwen. Een groot verschil met Dokkie is dat iedereen nu in duo’s aan de slag gaat. Je bouwt dus met z’n tweeën aan hetzelfde project. Dat betekent dat je afhankelijk wordt van je medestudent en dus goed moet communiceren over bijvoorbeeld werkverdeling. Ook werk je samen in dezelfde GitLab repository. Het veelvuldig committen van je code met een informatieve beschrijving wordt dus heel belangrijk! En zo zijn er nog veel meer zaken waar je aan moet denken als je met z’n tweeën aan hetzelfde project werkt.

Om ideeën op te doen voor het platform mag je best kijken naar wat Stack Overflow of vergelijkbare platforms te bieden hebben. Tijdens dit blok is het erg belangrijk dat de user interface van je website, de front-end, intuïtief is en voldoet aan de verwachtingen van de gebruiker. Je gaat dan ook een gebruikersonderzoek doen en verschillende versies van je user interface bouwen en testen. Vanzelfsprekend schrijf je ook weer code om alle benodigde functionaliteiten te realiseren en de front- en back-end met elkaar te laten samenwerken. Vergeet niet om hetgeen je tijdens blok 1 geleerd hebt ook weer toe te passen. Dus denk bijvoorbeeld aan de coding conventions, het toepassen van de basisconcepten van programmeren en het documenteren van je werk. Verder ga je je meer verdiepen in databases en leer je een nieuwe vorm van programmeren: Object Oriented Programming (OOP).

Learning stories¶

Tijdens dit project werk je weer aan learning stories die weer in je learning journey komen te staan. Daarin staan de te leren vaardigheden en competenties binnen dit project. Ze geven je houvast bij wat je moet leren. Een learning story hoeft niet aan een Milestone te worden gekoppeld.

User stories¶

Ook voor deze opdracht zijn user stories opgesteld. Die ga je weer gebruiken om de webapplicatie te bouwen. Iedere user story bevat een aantal acceptatiecriteria en taken, die je houvast geven bij het bouwen. Wat je ook gaat doen is taken en acceptatiecriteria aan gegeven user stories toevoegen en een aantal eigen user stories schrijven. Houd hiervoor onderstaand format aan.

Wat is een user story ook al weer? Op scrumguide.nl vind je de volgende definitie:

“Een User Story is een korte beschrijving (Story) van wat een gebruiker (User) wil. User Stories worden gebruikt bij het ontwikkelen van producten of software binnen Agile raamwerken, waaronder Scrum. Een User Story bestaat uit enkele zinnen waarin staat wat de gebruiker van het product moet / wil doen. Een User Story is eigenlijk weinig gedetailleerd en zou moeten kunnen passen op een post-it. Via de User Story heeft de gebruiker invloed op het ontwikkelen van een systeem of product en uiteindelijk de functionaliteit ervan.”

Een user story noteer je volgens een vast format:

Als … (soort gebruiker) wil ik … (feature/actie), zodat … (doel/voordeel).

Een voorbeeld van een user story:

“Als gamer wil ik met mijn ruimteschip kunnen schieten als ik op de spatiebalk druk, zodat ik vijandige aliens kan uitschakelen.”

De product backlog van deze opdracht¶

Omdat we werken volgens Scrum staan de user stories en de learning stories voor deze opdracht op de Product Backlog. De product backlog vind je in deze Gitlab-repository onder Issues > Boards > Selecteer <Product Backlog> in de dropdown. Je bouwt user stories om de learning stories te kunnen voltooien.

Sprints¶

Je werkt weer in sprints. Tijdens een sprint selecteer je de user stories van de Product Backlog die je denkt te kunnen gaan bouwen tijdens een sprint. Om een user story toe te wijzen aan een sprint wijs je deze toe aan een Milestone. Dit kun je doen bij de eigenschappen van een user story. Zie hiervoor wederom de pagina Issues.

Aan het eind van een sprint moet er altijd een bruikbaar product zijn voor de eindgebruiker. Test een user story dus goed voordat je deze op Done zet! User stories die niet af zijn gaan door naar de volgende sprint.

Definition of Done (DoD)¶

Binnen scrum dient iedere user story te voldoen aan een zogenaamde Definition of Done (DoD). Door het opstellen en aanhouden van een Definition Of Done, zorg je ervoor dat het werk wat je aflevert ook daadwerkelijk gebruikt kan worden. Als je een user story hebt afgebouwd zet je ‘m in verify en controleer je of deze voldoet aan de Definition of Done (zie hieronder). Pas als dat in orde is kun je de user story op Done zetten.

DoD generiek¶

DoD specifiek¶

Behoeftes van de gebruiker zijn terug te zien in de applicatie op basis van o.a. een mindmap en Guerilla test(en).
Gebruikerservaring van de applicatie is aangepast en verbeterd op basis van een Inspiratie analyse, bevindigen uit Guerilla test(en) en gebruikerstesten.
Er is visuele feedback wanneer een gebruiker een actie uitvoert in de applicatie.

Wanneer is Code Exchange klaar?¶

Voor het bouwen van deze opdracht heb je 3 sprints de tijd. Tijdens deze sprints werk je aan learning - en user stories en krijg je feedback van verschillende docenten op je voortgang, het product dat je bouwt en je gedrag. Uit deze feedback kunnen eventueel weer nieuwe user stories onstaan. Code Exchange is dus eigenlijk nooit af.

Lesmateriaal¶

In de learning stories wordt er verwezen naar de HBO-ICT Knowledgebase. Dit is een centrale kennisbank van de HvA waar je over alle onderwerpen die je tegenkomt in je studie informatie kunt vinden. Je bent zelf verantwoordelijk om goede aanvullende informatie te vinden waarmee je de learning stories kan voltooien. Hier krijg je ook feedback op.