Sprint 1
In sprint 1 stond veel onderzoek op de planning rondom het verkennen van het product en tooling. Ik moest helder krijgen wat het product precies inhoudt en of het te realiseren was. Gedurende deze sprint ging het voor mijn gevoel erg goed. Het onderzoek naar AB-testing bracht mij bij de benodigde metrieken. De data van deze metrieken waren te verkrijgen en uit te lezen op verschillende manieren. En de Proof of Concepts bewezen dat dit mogelijk was. Deze voor mijzelf gestelde doelen werden behaald en de planning werd als een checklist afgevinkt. Zelf was ik dan ook zeer tevreden met de werking van het Proof of Concept voor dit moment. Het systeem werkte, maar voor ingebruikname moest het nog wat nauwkeuriger. Hoewel het onderzoek-technisch goed verliep, waren er wat moeilijkheden rondom het opstellen van het PID. Ik vond het vrij moeilijk mijn gedachten, ideeën en afspraken helder en duidelijk te formuleren.
Sprint 2
Met het onderzoek in sprint 1 was ik erachter gekomen dat Face Tracking wat gelimiteerd was met betrekking tot afstand en de hoek waarover gemeten werd. Omdat een van de metrieke ook het aantal personen nodig had dat de content kon zien maar het niet keken, is het noodzakelijk de personen op de achtergrond (voorbijgangers) te detecteren. Bij deze sprint stond het centraal deze mogelijkheden te vinden en af te wegen. Net als in sprint 1 liep het programmeer-technisch erg goed. Echter werd het iets moeilijker om de code te begrijpen waardoor mijn inschatting qua tijd te positief was. Hoewel het lukte om object recognition toe te passen was er geen tijd meer om er een tracker aan te koppelen waardoor er vooralsnog dubbele resultaten waren. Voor nu laat ik het technisch rusten, deze code zal in een latere fase worden geïmplementeerd in het product. Dit is het moment waarop de tracker zal worden toegevoegd (Hiervoor is gekozen omdat nog niet alle kritieke onderdelen getackeld zijn, zo wil ik eerst meer inzicht verkrijgen in het streamen van content).
Het opstellen van het PID verliep nog altijd hetzelfde. De structuur en opbouw die voor mij helder waren, waren dit niet altijd voor anderen. Dit omdat ik sommige informatie te voor zichzelf sprekend vond, terwijl dit het juist niet was. In het vervolg moet ik dit soort informatie toch toevoegen.
Sprint 3
Het doel om helder te krijgen wat video streaming is binnen een sprint was wat ambitieus. Hoewel het onderzoek naar video streaming goed verliep, is dit door mij onderschat. Ik dacht het video streamen gemakkelijk toe te kunnen voegen door simpelweg een library of iets dergelijks te gebruiken. Dit bleek alles behalve waar. Het merendeel van de zoekresultaten bestond uit soortgelijke vragen zonder antwoorden. Schijnbaar is het niet zo “normaal” om de server en client om te draaien in de wereld van streaming. Daarbij blijkt dat video streamen moeilijker te begrijpen is dan gedacht, er komt veel meer bij kijken dan verwacht. Naast het helder krijgen van de werking van video streamen was het in deze sprint ook de bedoeling de interne Stakeholder te spreken en zijn beeld te krijgen van het product. Dit is echter niet gelukt als gevolg van externe wijzigingen. Het keer op keer opnieuw verplaatsen van gesprek met de Stakeholder, vanuit de Stakeholder, leverde ondertussen vertraging aan het PID. En de vervolgstappen berustten vooralsnog op de aannames die met het gesprek beantwoord dienden te worden.
Sprint 4
Hoewel ik liever eerst inzicht had verkregen in het beeld van de interne Stakeholder ben ik toch gestart met de mockups omzetten naar schetsen. Dit om communicatief beter duidelijk te maken hoe het product, in mijn ogen, eruit komt te zien en onderling in verhouding staat. Zo zou ik tijdens het interview met de Stakeholder iets hebben om naar te verwijzen en daadwerkelijk kunnen laten zien wat ik bedoel. Hoewel het allemaal leuk en aardig klonk pakte dit interview anders uit. Het interview had mij van gegevens moeten voorzien waarmee ik het product sterker zou kunnen maken. Dit verliep anders dan verwacht, zo werden we continu onderbroken waardoor het interview meer een gesprek werd, en ik niet aan de geplande vragen toe kwam. Ondanks dit alles verkreeg ik toch informatie waarmee ik iets kon. Zo bleek mijn beeld anders te zijn waardoor de scope en het project bijgesteld dienden te worden. Hoewel er geen onnodig onderzoek gedaan was, was deze informatie een stuk handiger geweest in de vorige sprint. In het vervolg zal ik meer en eerder aandringen op een gesprek met de Stakeholders om eerder een overeenkomend beeld te verkrijgen.
Door de wijziging van de focus kwamen de volgende sprints er anders uit te zien. Zo ligt in sprint 5 de nadruk op onderzoek naar Screen Mirroring en de toepassing ervan. Voordat er verder gewerkt word aan schetsen en het testen ervan.
Sprint 5
Door de wijziging werd het doel van deze sprint het begrijpen van Screen Mirroring. Nu was het geen probleem om het scherm op te nemen en op te slaan. Een gedeelte van de Screen Mirroring was dus vrij gemakkelijk. Maar dit bracht mij weer terug bij af. Nu het mogelijk was om de data van het scherm te verkrijgen moesten deze data gestreamd worden. Maar hoe was mij nog altijd niet geheel duidelijk. Het moment waarop bij mij alles op zijn plek viel voelde dan ook als een grote opluchting en een overwinning op mijzelf. Nadat dit helder was lukte het vrij snel om met behulp van een bestaand project de verkregen data te streamen. Doordat het mij veel moeite kostte om dit voor elkaar te krijgen, is er op dit portfolio extra aandacht aan besteed. Het Proof of Concept wordt daarom uitgelegd met het voorbeeld dat voor mij veel helderheid bood en ondersteund met behulp van code snippets waarop het voorbeeld van toepassing is.
Sprint 6
In deze sprint kwam het opzetten van de API centraal te staan. In mijn ogen niets anders dan het communicatiemiddel tussen de App en de database. Hetgeen waar ik voorheen niet bij stil stond was de impact die de database hierbij had. Nadat ik hierop gewezen werd heb ik de API even gelaten voor wat het was om een zo goed mogelijk passende database te gebruiken. Achteraf ben ik zeer blij dit gedaan te hebben, want dit onderzoek had behoorlijk wat impact op de prestaties. Zowel het opslaan als weergeven van de data zijn ontzettend gestegen in snelheid, mede door de betere prestaties die PostgreSQL heeft als gevolg van de B-Tree datastructuur.
Sprint 7
Samenhang is het woord dat deze sprint omvat. De API alleen kan niet veel en dient als koppelstuk tussen de App en het Python programma. Mijn eerste bedoeling was om met ssh een connectie op te zetten en het programma te starten. Maar ik werd er al gauw op gewezen, met de vraag “waarom ssh?”, dat dit niet de meest gebruikelijke aanpak zou zijn. Dit zette mij aan het denken waardoor ik inzag dat ook de API dit misschien nog zou kunnen oppakken. Na dit te achterhalen en te testen bleek dat het goed mogelijk was om dit met de API te doen. Gezien deze aanpak mij ook wat extra tijd opleverde besloot ik de App nog eens na te lopen op grote fouten en een clean install uit te voeren. Iets waar ik zeer blij om ben! De App bleek het bij een clean instal niet te doen. Dit was een gevolg van het niet accepteren van alle permissies. Om dit te voorkomen is bij het opstarten van de App een Splashscreen toegevoegd. Tijdens dit scherm wordt gecontroleerd of de permissies geaccepteerd zijn, zo niet dan krijgt de gebruiker een popup om dit alsnog te doen.
Sprint 8
Het visueel krijgen van de uitgelezen data was voor sprint 8 het hoofddoel. Een doel dat ondanks de opgelopen vertraging gehaald werd. Het voelde dan ook zeker goed om de sprongen vooruit letterlijk visueel te kunnen waarnemen. Ik was dan ook erg trots op de vorm waarin ik de heatmap wist te maken. Al waren de opmerkingen van de bedrijfsbegeleider zeker terecht. Dit onderdeel zal op een andere manier terug moeten komen omdat de data in deze vorm van de heatmap minder van waarde zijn. Dit was iets waar ik vooraf al over twijfelde en wat ik dan ook van plan was te onderzoeken. Omdat dit nu ook als feedback gegeven was zal ik dit zeker in een volgende sprint meenemen. Samen met de veranderde heatmap zal ook het opslaan van data meegenomen worden. Dit onderdeel was helaas niet binnen de sprint behaald als gevolg van een uitgevallen week door externe factoren.
Sprint 9
Sprint 9, bedoeld om de content streaming voor video en image op te zetten wordt nu voller. De eerste weken worden ingezet om de vertraging van sprint 8 op te pakken. De in eerste instantie kleiner gedachte save functionaliteit had echter wat grotere gevolgen. De opgeslagen data moesten ook getoond kunnen worden en data van verschillende demo’s of prototypes moesten gescheiden opgeslagen worden. Om deze data op te slaan waren weer verschillende tabellen nodig.
Als dit in dezelfde tabel zou komen zou deze tabel te veel data vast houden en zouden de queries die de data ophalen onnodig lang duren.
Hierdoor had de save functionaliteit invloed op het gehele proces: De App moest data opslaan, tonen en op een andere manier versturen en opvragen. De API had alleen get request die vervolgens omgezet werden naar post om de data uit de juiste tabel op te vragen. Het AB-test python programma diende de data anders op te slaan met een variabele tabel naam.
Hoewel de wijzigingen diep doordrongen waren ze, na de realisatie over de omvang ervan, sneller gemaakt dan ingeschat. Wat mij zeer opluchten.