Feedback als groep en individueel
Vanavond als groep kleine pitch gedaan van project. Feedback was positief en project kan levensvatbaar zijn,
De vervolg stap is concreter maken, dingen om op te leveren aka deliverables.
Hoofdvraag prima, bevat het probleem.
Geneigd om probleemanalyse over te slaan, laddering (project van ver af te bekijken)? De vraag achter de vraag, achter de vraag, enz Keer een uutje samendoen, en kijken wat de uitkomst is.
Sub vragen:
- onderzoeksvragen zijn altijd open.
- Het zijn goede vragen als je weet wat de impact zal zijn op het project.
- Relevant voor oplossen van hoofdvraag, kan je met de info van de sub vragen de hoofdvraag beantwoorden, zo niet dan zijn er meer sub vragen nodig (of breder trekken van sub vraag)
Onderzoeken strategieën/methode meenemen in de sub vragen verwerken. Scope focus, wat willen we echt opleveren dit semester.
Todo:
- Verdeel de 3 sub vragen en werk deze uit.
- Neem de 3 ander op in, of laat voor nu achterwegen.
- Laddering Focus op leer uitkomsten!
Na het geven dan de pitch presentatie:
Het is een ambitieus project, goed de scope bepalen en wat wel / niet opleveren (deliverables)
- functionals en non-functionals specificeren.
Is ML wel haalbaar? zo niet op tijd aangeven en ander oplossing kiezen. Goed de leraren en groep op de hoogte houden van voortgang.
Field research is erg belangrijk, waarom ligt ander project al 2 jaar stil?
Roadmap laat goed de scheiding tussen werkzaamheden van groepsleden zien We hebben helder en duidelijk wat het project inhoud.
Directe feedback op iteratie rapport 1
conceptueel klopt het rapport.
tabel en volgde stappen maakt het duidelijk
voor volgde stap requirement document maken, backlog in Jira vullen met de taken.
Jira goed ingericht.
Afhankelijk van onderzoek, komt later
vragen: strategie en methode, onderbouwen. per sub vraag onderzoeks stappen maken, per stap methode een strategie noteren.
goed, aanwezig, betrokken, feedback vragend.
voor volgde stap: presentatie geven of iets degelijks.
prima, goed voorbeeld dat je bezig bent met learning. laat zien hoe je met feedback omgaat, (reflectie toepassen op feedback)
'De 1e aanzet is er . Denk al eens na over validatie.'
'Zowel procesmatig (Jira) als codetechnisch (Git) de zaken al netjes ingericht.'
'Denk eens aan het koppelen van methodes aan de deelvragen en de onderbouwing daarbij.'
'Erg betrokken, aanwezig en feedback-gericht.'
'Is een echt groeiend leerdoel. Je bent echt al serieus bezig en neemt initiatief. Op deze manier gaat dit helemaal goed komen.'
- Validatie door middel van een requirements document, hieruit tickets maken, en deze in de komende sprints oppakken om zo tot een doel te geraken.
- Een tabel maken waarin per subvraag beschreven wordt welke onderzoeksmethodes gebruikt gaat worden samen met een onderbouwing
- Goede opzet.
- target, makkelijk om te valideren
- opschonen -> transformeren
- zodat de dataset binnen HA uniform kan worden.
- Er zit een verbetering in de onderzoeksvragen.
- In de subvraag kan er een ander woordkeuzen maken en flexibelere omgaan met de design challenge om zo de onderzoeksvragen leesbaarder te maken.
- Verder moeten er niet te lang stil blijven staan bij de onderzoeksvragen, hier kan altijd feedback op gegeven worden maar goed is goed genoeg.
- Het is goed om regelmatig feedback vragen aan de klas door middel van een presentatie dit lever een hoop feedback op.
Het is belangrijk om onze kwaliteits bewaken te gaan omschrijven. Dit is essentieel voor ieder project.
daarnaast is een risico analyse belangrijk om te doen. er kan altijd iets mis gaan, ook in een kleinschalig project.
Het is goed om een aanleiding te omschrijving, dit geeft meer context voor het projectplan en het probleem wat we willen oplossen.
We kunnen hoofdstukken wat verder uitbreiden, het is niet nodig maar wel goed om hiermee te oefenen.
De product breakdown moet nog geplaatst worden in een visuele representatie. en alle omschrijvingen in een tabel zetten
context --> organisatie
naar (4) project management
organisatie gaat over bedrijf waar je stage loopt / werkt voor dit project dus niet belangrijk (weg laten)
aanleiding in context zetten
doel: hoe gaan we het probleem oplossen. "automations aanmaken is moeilijk"
afwijken van template mag, pas aan naar wat duidelijker is voor de lezer
- uit scope: is goed
- in scope: denk na over wat je wilt opleveren
out of scope: denk na over wat je niet gaat doen weerspiegelt technische readynes level , bv prototype, qa prod
omschrijf om aannames te voorkomen
- onderbouwing waarom scrum? alternatieve onderzoeken.
- wat ga je doen, scrum rituele en artifacts(backlogs, epics) (hoe gaan we zien dat dit scrum is)
Onderzoeksvragen, goed is goed we nemen het serieus, om het goed te doen is waardevol voor het afstuderen.
idee: denk naar over alles wat je gaat opleveren. voorbeelden:
- nevenproducten
- documentatie
- CI/CD
- onderzoek en onderzoeksresultaten
laat zien dat we er serieus over nagedacht hebben tabel toevoegen met omschrijvingen ipv alles in schema proppen
Kwaliteits bewaking
- testen is er een van
- wat helpt om in dit project wat er opgeleverd wordt te valideren
- wat is de kwaliteit van de code (code review / pull request)
- specificeren welke tools we gebruiken om kwaliteit te leveren
- Dingen die mis kunnen gaan in het project noteren.
- Invullen om mee te oefenen (wat voorbeelden).
- Escalatie, wat te doen als het mis gaat / Hoe om te gaan met bepaalde situaties.
requiremtens document is essentieel voor analyse, met functonals en non-functionals. Dit oppakken, concrete invulling
presenteren over inhoudelijke resultaten inhoudelijke presentatie.
Unit test komen laster pas, zodra er code is.
Available product analyse mist iets, analyse uitwerking is de volgde stap.
Voor analyse moet eerst duidelijk zijn "Wat heb ik nodig". hoe kan het resultaat eerlijk is (van bepaalde kwaliteit)
Geef nu even de focus aan de analyse en werk dan e.e.a. verder uit in het ontwerp en implementatie.
Hier willen we graag een stukje concrete invulling van zien, bijv. requirements. Op basis daarvan toon je een beginnend niveau aan. Hou in de gaten dat je analyse invloed kan hebben op beslissingen etc.
Er wordt gebruik gemaakt van Jira die je al eerder hebt ingericht. Later zullen vooral kwaliteitsstappen belangrijk.
Er is een design-challenge gemaakt. Daarbij hebben we het uitgebreid gehad over de onderzoeksvragen.
Dat komt wel goed maar er liggen ook nog flink wat kansen (demo's, presentaties etc).
De manier waarop je met feedback omgaat en de initiatieven die je ontplooit is zeker heel goed. We missen, ondanks de link, nog jouw available product analysis.
use cases flow nummeren stappen toevoegen ipv verhaald. alt flow in standaard flow aangeven: 1 2 3 en dan alt flow 1.x
acceptatie test maken. (V model)
tekstuele beschrijving van landschap diagram toevoegen, om zo verkeerde interpretatie van de lezer weg te nemen.
is de hoofdvraag opgelost? Kan ik de vertaalslag maken om dit te doen? overall conclusie, dat het concept werkt
proficient demo gedaan
methodes die nut hebben en er bij passen
Demo gedaan, vragen gehad over gebruik van Python en Ioniq, maar geen concrete feedback
Denk na over een (acceptatie)testplan
Denk aan een korte toelichting op de modellen.
Er is al een PoC. Nu op naar de app zelf
Met het beantwoorden en beredeneren van de hoofdvraag kom je op Proficient.
I.v.m. de demo nu naar Proficient
wie is de actor en wat is een de systeem interactie?
Laat zien wat het systeem doet (meldingen tonen, controlles)
b.v.: sensor bestaat al error --> uitzondering situatie, un-happy flow (alt flow)
SensorId bij automation? waarom wel/niet.
Voortaan de uitleg/onderbouwen opschrijven.
Schrijf toelichting en onderbouwingen van flows en seq diagram
Mist API design.
inzichtelijk maken op deps in pipeline.
checken of er vulnerabilities zijn in de gebruikte packages.
is concreet, en zinvolle invulling van de hoofdvraag.
zorg ervoor om process te volgen, documenteren.
Denk aan de actor-systeem interactie. Denk ook eens na over de non-happy flow -> uitzonderingen of alternatieve scenario's
De conclusies op de onderzoeksvragen vormen jouw advies. Op een later tijdstip kunnen nog adviezen volgen voor doorontwikkeling.
Denk aan onderbouwing van schema's en ontwerpen. Ook ontbreekt de API-documentatie
Denk aan de dependency's
Fast API heeft ingebouwde swagger.
keuzen van design is belangrijk voor onderbouwen. (belangrijk voor afstuderen)
Demo front-end (met backend) met HA tonen om voortgang te laten zien. kwaliteitsbewaking (unit testing)
De use-cases zijn wel beschreven maar zijn qua stappen uit elkaar gehaald m.b.t. Actor en Systeem.
Dat maakt het wat lastiger om de scenario's te volgen, ook qua uitzonderingssituaties.
Jouw API documentation voldoet. Maar neem voor de volgende keer wel de ontwerpkeuzes mee in het verhaal. Die zijn erg belangrijk.
Laat een goed werkende implementatie zien en onderbouw dat. Hoe is de kwaliteit geborgd.
Vandaag demo late zien van front-end en back-end van de addon.
daarbij ook de unit test voor beiden projecten laten zien, en dat deze ook in de pipelines gedaan werden.
dit was voldoende om het laatste Criteria (Implementation) op Proficient te krijgen.