Dragons Den¶

In het tweede blok word je uitgedaagd om als ondernemers samen met een andere student een zogenaamde Software as a Service (SaaS) oplossing te bedenken en te bouwen voor kleinere bedrijven.

Dragons Den

Wat je gaat maken¶

Na een kort onderzoek kom je tot een idee die je uitwerkt in een business plan. Gelijktijdig bouw je een “Minimum Viable Product”, dat je gebruikt om feedback te krijgen van potentiële klanten. De beste teams presenteren aan het einde van het project hun business plan en product voor ondernemers in een zogenaamde Dragon’s Den sessie, die vervolgens kiezen welke ze willen laten doorontwikkelen.

Aan de slag als duo¶

Je hebt als duo nu 1 project aangemaakt in Gitlab. Zorg ervoor dat jullie beiden de juiste rechten hebben in dit Gitlab project. Kijk daarvoor bij Manage>Members (1 is owner, de ander minimaal maintainer). Clone daarna beiden dit project naar je eigen ontwikkelmachine (je eigen laptop). Dit doe je hetzelfde als in Blok 1 bij de Dokkie opdracht, dus via de blauwe CLONE knop.

Omdat je nu met meer dan 1 persoon gaat werken in dezelfde code, zul je moeten leren omgaan met branches. Branches zorgen ervoor dat wijzigingen in de code netjes in aparte vakjes komen. Oefen dit nu eerst.

Een persoon maakt een wijziging in de code.
Deze persoon doet nog geen commit.
Deze persoon maakt eerst een nieuwe branch aan in GIT, noem deze dev. Lees na wat dit is.
Nu pas doe je de commit. Zorg ervoor deze deze commit plaats vindt in de nieuwe branch dev.
Sync (oftewel push en pull) naar je remote (Gitlab project).
Controleer op Gitlab of je nu de nieuwe branch ziet (Code > Branches). Controleer of je daarbinnen de wijziging vindt die je verwacht.
Nu gaat de tweede persoon de wijzigingen binnenhalen, en daarmee de nieuwe branch (welk knop druk je dus op?)
Controleer op de ontwikkelmachine of je daar de wijzigingen ziet. Controleer of je de juiste branch ziet en erin werkt.

Beschrijving van het project template Dragons Den¶

Je hebt een minimale Flask-applicatie gekregen. In BIM Dokkie (blok 1) staat al heel veel voorbeeldcode. Deze kan je hier als inspiratie gebruiken. Ook heb je de beschikking over de twee grote Flask manuals die we aanraden, zie hiervoor de desbetreffende learning story. Bepaal ook de afspraken over het werken in branches. Werk niet in main, maar in dev of beter nog, in een branch per user story.

Zo gebruik je deze repository als opdracht-template¶

User stories
- Voor de opdracht zijn een aantal user stories opgesteld als start van het project, maar in dit blok maak je ook een aantal eigen user stories. Die ga je gebruiken om de webapplicatie te bouwen. Maar wat is een user story eigenlijk? 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.”
- Deze user stories vormen zogenaamde Product Backlog. De product backlog vind je in deze Gitlab-repository onder Issues > Selecteer <User Stories> in de dropdown.Anders dan in het eerste blok is deze lijst nog niet compleet. Via Issues > kun je user stories aanmaken voor de opdracht. Het handigste is om deze dan het label soort::user story te geven. De user stories zijn daarmee te onderscheiden van bijvoorbeeld learning stories.
- Tijdens het plannen van een sprint kan jullie de user story in een Milestone opnemen. Een Milestone gebruiken we hier synoniem van een sprint. Als een van jullie begint met het bouwen van een user story kan je je naam aan het issues koppelen en wordt het issues ongoing onder Issues > Milestone > Sprint.
Learning stories
- De learning stories geven je houvast bij wat je moet of wilt leren. Tijdens het project werk je aan deze learning stories. Daarin staan de te leren vaardigheden en competenties binnen dit project. Voor dit project krijg je een aanvullende set learning stories om te importeren in jouw Learning Journey.
- Anders dan in het eerste blok leg je in dit blok ook eigen learning stories vast.
Milestones en sprintboard
- Je werkt in zogeheten sprints. Tijdens een sprint selecteer je de learning stories en de user stories van de Product Backlog die je wil gaan oppakken en afronden in 2 of 3 weken (de duur van een sprint in deze opdracht). In totaal zijn er 3 sprints. Om een user story of learning story toe te wijzen aan een sprint wijs je deze toe aan een Milestone. Dit kun je doen bij de eigenschappen van een issue. Je kan hiervoor ook het board Planning Sprint 1 gebruiken.
- Onder Issues > Milestones > Sprint 1 kun je de burndown zien, wat er voor de sprint gepland staat, waar je mee bezig bent en wat af (done) is.
- Aan het eind van een sprint moet er altijd een bruikbaar product zijn voor de eindgebruiker. User stories die niet af zijn gaan door naar de volgende sprint. Test en documenteer een user story dus goed voordat je deze op done zet.
- Sprint 3
  In de eerste sprint van dit project bedenk je zelf een app waarmee je de MKB-markt kan bedienen. Tijdens de eerste sprint doe je een aantal korte onderzoeken om de markt te verkennen en maak je user- en learning stories voor de tweede sprint.
- Sprint 4
  In deze sprint ontwerp en bouw je de app. Om te beginnen zijn er daarvoor al een aantal user- en learning stories vastgelegd in GitLab maar deze zijn niet compleet. Aan jou de taak om deze af te maken.
- Sprint 5
  In deze sprint bouw je de app en het business plan verder af en demonstreer je die aan mogelijke investeerders.
- Onder de pagina Issues > Milestones(te vinden via de balk links) vind je verschillende sprints en sprintboards:
- Sprint 3: 4 november - 15 november;
- Sprint 4: 18 november - 6 december;
- Sprint 5: 9 december - 10 januari;
Technische documentatie
- In de docs folder van de broncode komt de technische documentatie. Per learning story schrijft je uit wat je hebt geleerd. Het is belangrijk dat de documentatie onderdeel wordt van de broncode. Zo kan je vanuit de ontwikkelomgeving je documentatie bijhouden :).

Kwaliteitsnormen¶

Je werkt volgende onderstaande kwaliteitsnormen: - Je werkt volgens de agile methodiek van HBO-ICT. - Je code voldoet aan de code conventies - Je code is (technisch) gedocumenteerd en relevant voor collega ontwikkelaars.

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¶

Wanneer is ben je klaar?¶

Voor het bouwen van deze opdracht heb je 3 sprints de tijd. Aan het einde van die periode kan je aantonen dat je voldoet aan de leeruitkomsten, waarmee je laat zien dat je de betreffende beroepstaken en professionele vaardigheden beheerst. Zie hiervoor de studiehandleiding op de DLO.

Lesmateriaal¶

In de learning stories staan verwijzingen naar het lesmateriaal. Bijvoorbeeld de Knowledge Base, de Digitale Leeromgeving (DLO), videomateriaal, etc.