In deze post neem ik jullie mee met de voorbereidingen van het maken van een Android app. Nu zie ik de vraagtekens in je hersenspinsels verschijnen, want je hebt gelijk: een Android app kan van alles zijn. Daarom is de eerste stap bij het maken van een stuk software, zoals een app, belangrijk om te bepalen wat de gebruiker (of klant) wilt. Specifieker nog: welk probleem wil de gebruiker verholpen zien worden?
In een team op de werkvloer wordt deze vraag vaak in kaart gebracht door de product owner. Als product owner werk je naar een bepaald doel (bijvoorbeeld 10% meer omzet) van het bedrijf en dit doe je door je software te maken naar de wensen van je (potentiële) gebruikers. Vervolgens zet je deze wensen om in software features (of user stories) en splits je deze op in kleine taken. Daarna buigt het development team zich erover om de technische kant vorm te geven en weer te verdelen in taken. Deze taken worden op een sprint (vaak een periode van 1 - 4 weken) gezet om af te ronden. Door dit proces blijf je altijd werken aan taken die er toe doen voor de klant.
Aanvulling: Tegenwoordig is er wel eens kritiek op bovenstaande aanpak en zou het beter kunnen zijn om het development team zelf de wensen van klanten in kaart te laten brengen. Hierdoor kan het development team rechtstreeks de klant helpen in plaats van te communiceren met een tussenpersoon.
Het makkelijke aan een eigen project is dat je zelf de klant bent. In dit geval heb ik een probleem en deze wil ik oplossen. Daardoor is het relatief eenvoudig om het probleem vast te stellen, namelijk: er is geen makkelijk te gebruiken Android app om een lijst van taken aan te maken en van deze lijst iedere ochtend 1 willekeurige taak als notificatie binnen te krijgen. (misschien bestaat zo een app wél al, maar ik wil ook graag leren hoe je aan app maakt! :)). Nu dit probleem duidelijk is kan de product owner (wederom ikzelf, ik heb nog niemand aan kunnen nemen door de krapte op de arbeidsmarkt) aan de user stories beginnen.
Wanneer je begint aan het maken van de user stories is het belangrijk om niet te gedetailleerd te zijn. Het is vaak handiger om een ruwe prototype te maken (ook wel een minimal viable product (MVP) genoemd). Hiermee kan je snel vaststellen of je de capaciteiten in het team hebt om het product te maken. Maar misschien nog belangrijker, je kunt snel feedback vragen aan de gebruiker zodat je kan testen of de user stories daadwerkelijk het probleem van de gebruiker oplossen. Of dat er misschien onduidelijkheden waren waardoor de user stories niet 100% aansloten maar dat je nu nog op tijd bent om de software aan te passen. Voor mij is dat ook het doel, om met een MVP bovenstaand probleem op te lossen.
De MVP
Wanneer je begint aan het maken van de user stories is het belangrijk om niet te gedetailleerd te zijn. Het is vaak handiger om een ruwe prototype te maken (ook wel een minimal viable product (MVP) genoemd). Hiermee kan je snel vaststellen of je de capaciteiten in het team hebt om het product te maken. Maar misschien nog belangrijker, je kunt snel feedback vragen aan de gebruiker zodat je kan testen of de user stories daadwerkelijk het probleem van de gebruiker oplossen. Of dat er misschien onduidelijkheden waren waardoor de user stories niet 100% aansloten maar dat je nu nog op tijd bent om de software aan te passen. Voor mij is dat ook het doel, om met een MVP bovenstaand probleem op te lossen.
| MVP | Volgende Versie |
|---|---|
| Lijst met hardcoded practices | Lijst dynamisch kunnen aanpassen en opslaan in een database |
| 1 willekeurige practice van bovenstaande lijst pakken | Tijd van de notificatie en hoeveel notificaties aanpasbaar maken |
| Bovenstaande practice als notificatie geven | Willekeur als optie kunnen aanvinken |
| Niet 2x dezelfde notificatie achter elkaar | Practice voor de dag weergeven wanneer je de app opent |
| Alles met unit en functionele tests | |
| CI/CD pipeline | |
| Versie controle (Git) |
Deze vereisten worden dan door het technische team in taken verdeeld om dit technisch op te lossen. Het is dan fijn wanneer de taken zo klein mogelijk zijn, zodat je iedere dag werkende (en geteste) code kan toevoegen aan je project en je niet hoeft te werken in branches. Belangrijk hierbij is dat de taken zichtbaar zijn, zodat je (bijvoorbeeld) de volgende vragen kunt beantwoorden: Waar wordt aan gewerkt? Loopt er een taak vast? Dit zorgt er mede voor dat je de obstakels kunt oplossen of verbeteren, waardoor je in het vervolg soortgelijke taken sneller kan afronden en daarmee ook sneller de gebruiker (die vaak ongeduldig zijn) kan helpen!
De DevOps principes in dit project
Zoals in de vorige post uitgelegd wil ik mij met ieder project ook bezig houden met de DevOps principes (om daar beter in te worden). Nu voel ik mij niet geschikt om DevOps samen te vatten, maar toch probeer ik het: “DevOps is een werkwijze welke het doel heeft om zo snel en goed mogelijk problemen op te lossen van een gebruiker (met software)”. Een voorbeeld daarvan is de taken zichtbaar maken (zoals hierboven beschreven). Maar er zijn ook vele andere manieren om het DevOps doel te bereiken (daar zijn verschillende boeken over bijvoorbeeld Accelerate van Nicole Forsgen en The DevOps Handbook van Gene Kim). De manieren in dit project om op de DevOps manier te werken wil ik hier graag herhalen:
- Vergaar en implementeer klant feedback: maak een MVP dat de klant zo snel mogelijk kan beoordelen en jij daardoor kan aanpassen.
- Alles in versie controle (ook configuratie bestanden!)
- CI/CD pipeline. Dat betekent in het kort: na iedere code incheck dat er automatisch testen worden uitgevoerd en wanneer deze testen succesvol zijn uitgevoerd dat deze nieuwe code automatisch in de live software komt.
- Werk in kleine batches/taken opdelen. Het liefste in taken die maximaal in 1 dag af te ronden zijn. Hierdoor hoef je niet in branches te werken.
- Maak je werk zichtbaar! Zelf gebruik ik nu een Trello board (dit ga ik misschien nog veranderen) waarin ik taken kan slepen van todo naar in progress en dan naar done.
Er zijn nog veel meer principes, maar voor dit project focus ik mij op bovenstaande punten.
Voordat ik deze post afrond wil ik nog melden dat dit de eerste keer is dat ik een android app maak. Dat betekent dat ik op de afgelopen tijd vooral bezig was met het leren van Kotlin voor Android apps. Hiermee ben ik nu klaar. Daarnaast ben ik ook bezig geweest met Flutter. Met Flutter kan je gemakkelijk multi-platform apps maken, wat het een interessante tool maakt. Daarom wil ik deze eerste app met Flutter schrijven om daar beter in te worden.
Tot de volgende keer!
Geniet van vandaag :)
Mees