1. Inleiding
JDI Smart Web applications is een bedrijf dat zich bezighoudt met het bouwen van slimme webapplicaties. JDI kan de wensen van haar klanten efficiënt vertalen naar een handige webapplicatie. Het bedrijf is opgericht door Jarno Eggink en is gevestigd in Velp. Bijzonder aan JDI is dat er binnen het bedrijf geen sprake is van een hiërarchie. JDI is een zogenaamde holocracy; een zelfsturende organisatie met zelfsturende teams. Voor deze opdracht gaat het Perlman ontwikkelteam tijdens het OOSE project aan de slag om voor JDI een HR portaal te realiseren. Dit portaal zal een plek zijn voor het werknemersbeheer, en hier kunnen zaken geregeld worden zoals het aanvragen van verlof en het bijhouden van eventuele reiskosten.
Dit document zal de basis van het project vormen, omdat hierin onderlinge afspraken, planningen en projectkeuzes zijn vastgelegd. Dit document kan tijdens de uitvoer van het project als een referentie worden gebruikt, en waar nodig kunnen aanpassingen in dit plan worden doorgevoerd.
Dit document begint bij een korte introductie van de achtergrond van dit project. Denk hierbij aan een beschrijving van JDI Smart Web applications, de stakeholders en de aanleiding tot dit project. Vervolgens zullen kort de doelstelling van JDI, de opdracht en de op te leveren resultaten worden vastgesteld. Daarna worden de projectgrenzen inzichtelijk gemaakt (hierbij gaat het om zaken die niet door het ontwikkelteam zullen worden afgehandeld), en de duur van het project. Dan volgen de randvoorwaarden en de kwaliteitseisen, en vervolgens gaat dit document over de ontwikkelmethode (denk hierbij aan het traject dat zal worden aangehouden om binnen de aangegeven projectgrenzen tot een kwalitatief hoogwaardig eindproduct te komen). Ten slotte worden de projectorganisatie, de planning en de risico's in kaart gebracht.
2. Achtergrond van het project
Voor het OOSE project gaat team Perlman aan de slag voor JDI Smart Web applications. Hierbij zullen een aantal componenten geïmplementeerd worden die te maken hebben met het werknemersbeheer van JDI. Het contact met JDI zal tussen het ontwikkelteam en Jarno Eggink, de oprichter van JDI Smart Web applications, of Wim Reuterink, de opdrachtgever, zijn. De reden voor dit project is dat JDI een HR portaal nodig heeft waarin dingen als werknemersbeheer, werkplekken, reiskosten en verlof kunnen worden gemanaged.
Het project is urgent omdat de reiskostendeclaratie en bezetting momenteel allemaal aan de hand van spreadsheats wordt bijgehouden. Dit betekend dat JDI overal losse documenten heeft met de bezetting en reiskosten, dit zou in een centraal systeem moeten komen. Momenteel worden de product owner en HR iedere keer nog handmatig gemailed, maar dat moet allemaal automatisch gaan gebeuren (bijvoorbeeld met een Slack systeem).
3. Doelstelling, opdracht, en op te leveren resultaten voor het bedrijf en school
3.1. Probleemstelling
Op het moment gaat het opgeven van werkplek bezetting via een spreadsheets op verschillende kanalen, naast het opgeven van de bezetting gaan declaraties via verschillende kanalen en is het noodzakelijk dat er een tussenpersoon de aanvragen doorstuurt naar de HR afdeling en de planner. Dit is tijdrovend en hierdoor kunnen er mogelijk inconsistenties optreden doordat het mogelijk is om fouten te maken bij het invullen.
3.2. Doelstelling
Het bedrijf (JDI) wil alle declaratie aanvragen via een digitaal portaal gaan verwerken. Door het proces te automatiseren is het niet meer nodig dat een tussenpersoon de aanvragen doorstuurt naar de juiste afdeling en dit documenteert. Door het proces te automatiseren is de kans op menselijke fouten kleiner dan met de huidige oplossing. Door de oplossing houdt JDI meer tijd over voor andere werkzaamheden. Dit zorgt ervoor dat er meer geld overblijft.
De opdrachtgever geeft aan dat er een HR-portaal moet komen, waarbij werknemer-data wordt bijgehouden.
Dit HR-portaal moet het volgende bijhouden:
- Werkt een medewerker thuis, of is de medewerker op kantoor en dan ook op welke werkplek.
- Indien een medewerker op kantoor is, wat de afstand is die is afgelegd en wat de reiskosten zijn.
- Een manier voor de medewerker om verlof aan te vragen, en voor een werkgever om deze aanvraag goed of af te keuren.
- Hierbij moet er een slack bericht verstuurd worden indien de aanvraag is beoordeeld.
3.3. De opdracht
Het is aan de opdracht om een Human Resource portaal te bouwen, in het portaal is het mogelijk om in te vullen welke dagen de werknemers thuis of op kantoor werken. Het portaal kan de reisafstanden uitrekenen en dit terugkoppelen aan de declaratieformulieren. Daarnaast wordt het mogelijk voor de werknemers om verlof aan te vragen, en voor de werkgever/planner dit goed of af te keuren. Vervolgens kan er dan door middel van Slack met een bericht aangegeven worden wat het resultaat was van de aanvraag.
3.4. Concrete resultaten
Hieronder staat een overzicht met alle concrete op te leveren resultaten:
- Plan van aanpak.
- Software requirement specification (SRS).
- Software Design Documentation (SDD).
- Broncode inclusief unit tests.
- Testrapportage.
- Projectbeheerartefacten (Hoofdstuk 6).
- Individueel verslag per groepslid (Dit onderdeel leveren we alleen aan school).
4. Projectgrenzen
4.1. Organisatorische grenzen
Het project begint op 5-4-2022 (pre-sprint) en de eerste sprint gaat beginnen op woensdag 13-4-2022, de opleverdatum is 10-6-2022. In totaal gaat het team werken in drie sprints, tijdens de sprints zijn de regels van SCRUM leidend. Tijdens de sprints mag de opdrachtgever de scope van de actieve sprint niet aanpassen. De laatste twee weken zijn gereserveerd om de eindpresentatie te maken en het softwarepakket te overhandigen en toe te lichten.
Het ontwikkelteam is beschikbaar op werkdagen tussen 09:30 en 17:00, met uitzondering van vrije dagen (https://www.han.nl/studeren/jaarrooster/). Het team bestaat uit vijf ontwikkelaars (studenten). De ontwikkelaars hebben iedere week 40 uur om aan het project te werken. Dit is wel inclusief momenten die nodig zijn buiten het project, zoals hieronder staat gedocumenteerd:
Bezigheden die tijd kosten buiten het maken van het product.
Bezigheid | Tijd | Duur |
---|---|---|
Software ontwikkelen & reviewen | 20 uur | Per week |
Daily stand up | 1.5 uur | Per week |
Gesprek procesbegeleider | 1.5 uur | Per week |
Projectverslag | 4 uur | Per week |
Sprintplanning | 2 uur | Per sprint |
Sprintreview | 1 uur | Per sprint |
Retrospective | 1.5 uur | Per sprint |
Werkoverleg | 4 uur | Per week |
Gesprek opdrachtgever | 1 uur | Per week |
Pauze | 5 uur | Per week |
4.2. Softwaregrenzen
Het op te leveren softwarepakket wordt een Proof Of Concept (POC).
Het front-end gedeelte wordt gerealiseerd met het Vue.js framework.
Het backend gedeelte wordt gerealiseerd met het Java framework springboot.
Er wordt gebruik gemaakt van de google API of een soort gelijk alternatief.
5. Randvoorwaarden
Om dit project en de bijbehorende opdracht goed af te kunnen ronden, hebben we de volgende zaken nodig van de volgende personen:
5.1. De school:
- Moet een werkende Bitbucket, Confluence en Jira omgeving aanleveren. Deze tools moeten voor alle teamleden door de gehele duur van het project beschikbaar zijn.
- Moet een aanwezige projectbegeleider leveren, die aanwezig is bij tussentijdse vragen minimaal 1x in de week en bij sprint-retrospectives.
- Moet zorgen dat er een Professional Skills begeleider is, die binnen 2 dagen op vragen en opmerkingen rondom skills-gerelateerde zaken reageert.
- Moet zorgen dat er iedere werkdag binnen dit project een locatie beschikbaar is voor het ontwikkelteam.
5.2. De opdrachtgever
- Moet tijdens kantooruren beschikbaar zijn tot het verduidelijken van vragen, bijvoorbeeld via email. Hier zit een reactie termijn op van 2 dagen.
- Moet aanwezig zijn bij het opleveren van de sprints, door fysiek of online te kunnen beoordelen naar de voortgang.
- Moet voor de start van de eerste sprint voorbeelddata kunnen produceren voor werknemers.
5.3. Het eindproduct
- Moet ethisch verantwoord zijn, en het portaal kan niet in strijd zijn met de Nederlandse (privacy) wet.
6. Op te leveren producten en kwaliteitseisen
Product |
Productkwaliteitseisen |
Benodigde activiteiten om te komen tot het product |
Proceskwaliteitseisen |
PvA |
ICA Controlekaart Voldoet aan PvA template |
Gesprek houden met opdrachtgever om informatie te krijgen Project achtergrond achterhalen Project doel en opdracht uitwerken Randvoorwaarden opstellen Projectgrenzen opstellen Kwaliteitseisen stellen aan de op te leveren producten Ontwikkelmethode uitwerken Contactgegevens noteren Planning maken Risico's opstellen Commentaar verwerken |
Goedkeuring van min. 2 groepsleden voor elk afgeronde onderdeel Oplevering en goedkeuring van product door opdrachtgever en projectbegeleider tussendoor en op de opleverdatum |
SRS |
ICA Controlekaart Voldoet aan SRS template |
Gesprek houden met opdrachtgever om specificaties te krijgen Actoren opstellen Operatie omgeving beschrijven Constraints beschrijven Use case diagram en brief descriptions uitwerken Domein model opstellen Use cases beschrijven Niet functionele requirements opstellen User interface schetsen maken Ontwerp beslissingen uitwerken Commentaar verwerken |
Goedkeuring van min. 2 groepsleden voor elk afgeronde onderdeel Oplevering en goedkeuring van product door opdrachtgever en projectbegeleider tussendoor en op de opleverdatum |
SDD |
ICA Controlekaart Voldoet aan SDD template |
Gesprek houden met opdrachtgever om specificaties te krijgen Achitectueel overzicht opstellen Deployment diagram opstellen Sub-systemen uitwerken (als deze er zijn) Database ontwerp opstellen Ontwerp beslissingen uitwerken Commentaar verwerken |
Goedkeuring van min. 2 groepsleden voor elk afgeronde onderdeel Oplevering en goedkeuring van product door opdrachtgever en projectbegeleider tussendoor en op de opleverdatum |
Broncode |
100% geslaagde unittests Minimaal 80% unittest coverage Code geschreven in Nederlands Traceable naar specifieke requirements en constraints Werkende build op Jenkins |
Code schrijven Unit tests schrijven Code reviewen Jenkins opzetten |
Goedkeuring van min. 2 groepsleden voor elke pull request. Voor opleveringen moet het product door alle groepsleden zijn beoordeeld. Oplevering en goedkeuring van product door opdrachtgever en projectbegeleider tussendoor en op de opleverdatum |
Applicatie |
Respons in maximaal 1 sec Bevat geen bugs die geschreven usecases blokkeren. |
Code omzetten tot applicatie Applicatie testen |
Goedkeuring door het hele team Oplevering en goedkeuring van product door opdrachtgever en projectbegeleider tussendoor en op de opleverdatum |
Testrapportage |
Bevat alle unittests Bevat zowel de verwachte resultaten als de daadwerkelijke resultaten van de unittests |
Unittests uitvoeren Bugs rapporteren |
Goedkeuring van min. 2 groepsleden voor elk afgeronde onderdeel Oplevering en goedkeuring van product door opdrachtgever en projectbegeleider tussendoor en op de opleverdatum |
Eindverslag |
ICA Controlekaart Voldoet aan Eindverslag template |
|
Goedkeuring door het hele team Oplevering en goedkeuring van product door opdrachtgever en projectbegeleider op de opleverdatum |
Eindpresentatie | Bevat alle belangrijke punten |
Project afgerond Presentatie opzetten |
Oplevering en goedkeuring van product door PS docent en projectbegeleider op de opleverdatum |
Reflectieverslag |
ICA Controlekaart Voldoet aan Reflectieverslag template Alle competenties uitgewerkt 2 uitgewerkte leerdoelen |
Kwaliteitsoordeel geven over de producten De gehanteerde projectmethode evalueren Rol beschrijven Competenties uitwerken Leerdoelen uitwerken Conclusie trekken over het project Factsheet opstellen |
Tussentijds ingeleverd Oplevering en goedkeuring van product door PS docent en projectbegeleider tussentijds en op de opleverdatum |
Bijlage |
Bevat alle benodigde bijlage |
Bijlage gebruiken |
Gebruikte bijlagen direct linken Oplevering en goedkeuring van product door PS docent en projectbegeleider tussentijds en op de opleverdatum |
DoD: Na gekeken en goedgekeurd door 2 andere teamleden, alle betrevende tests slagen en voldoet aan de bijbehordende productkwaliteitseisen.
7. Ontwikkelmethode
Binnen dit project zal het ontwikkelteam op een Agile manier te werk gaan. Aan de hand van Scrum wordt iedere sprint een iets groter product opgeleverd, en na de laatste sprint zijn pas alle use cases geïmplementeerd. Dit betekend dat het HR Portaal wat JDI Smart Web applications voor ogen heeft incrementeel tot stand zal komen. Alhoewel er vanaf het begin van het project door het team gekeken wordt naar de globale requirements, wordt bij elke individuele sprint echt vastgelegd welke use cases er na de desbetreffende sprint af moeten zijn. Op deze manier weet de opdrachtgever waar hij aan toe is, omdat er na iedere sprint een concreet resultaat af is (het gaat hier om een subset van de uiteindelijke features). Voordat het ontwikkelteam begint met de incrementele sprints, zal in de eerste week nog een globaal overzicht van het project worden gevormd aan de hand van overlegmomenten en doormiddel van dit Plan van Aanpak.
Om dit project goed via Scrum te kunnen uitvoeren, zijn een aantal vaste momenten van belang. Ten eerste zal het ontwikkelteam dagelijks om 09:30 een daily standup houden. Dit is een kort overleg waarbij wordt afgestemd wat ieder teamlid de voorgaande dag gedaan heeft, en wat hij voor die dag op de planning heeft. Op deze manier zal duidelijk inzichtelijk worden waar iedereen staat, en wordt het duidelijk of er knelpunten in het proces zijn. Naast de daily standup die in de ochtend plaatsvindt, kan er ook nog gekozen worden om een mid-daily standup te houden. Dit is hetzelfde als de daily standup, maar dan om te checken of iedereen die ochtend goed aan de slag is geweest en om een planning te maken voor de rest van de dag. Of er ook ruimte en belang is voor een mid-daily standup zal tijdens de eerste sprint duidelijk worden. Naast de daily standups zullen er tussen de sprints ook sprint planning en sprint retrospective ceremonies plaatsvinden. Dit is om te kijken waar de verbeterpunten van de afgelopen sprint in zitten, en om al vast voor te bereiden op de aankomende sprint. Denk hierbij bijvoorbeeld aan het selecteren van de use cases die in de volgende sprint worden opgepakt. Ten slotte wordt er na iedere sprint ook een sprint review gehouden, waarbij de resultaten van de afgelopen sprint worden gepresenteerd aan de stakeholders, dus o.a. aan Jarno Eggink en Wim Reuterink van JDI.
8. Projectorganisatie en communicatie
Hieronder staan de contactgegevens van de opdrachtgever en de andere stakeholders van het project. Ook staan de vaste afspraakmomenten hierin opgenomen wanneer deze bekend zijn.
Naam | Rol | Vaste afspraak moment | |
---|---|---|---|
Wim Reuterink | w.reuterink@jdi.nl | Opdrachtgever | Aan het eind van iedere afspraak wordt er een nieuw contactmoment afgesproken. |
Jarno Eggink | j.eggink@jdi.nl | Opdrachtgever | Aan het eind van iedere afspraak wordt er een nieuw contactmoment afgesproken. |
Jaap Papavoine | jaap.papavoine@han.nl | Procesbegeleider | Iedere woensdag om 09:30 |
Sjir Schütt | sjir.schutt@han.nl | PS docent |
Het ontwikkelteam werkt alle werkdagen van 9:30 tot 17:00 gezamenlijk op locatie op de HAN in Nijmegen. Op deze dagen wordt dagelijks een stand-up gehouden om 9:30, met uitloop tot 9:45 als er groepsleden te laat zijn. Wanneer een student later komt of wanneer hij ziek is, laat hij dit weten door een bericht te sturen via een van de beschikbare communicatie middelen, Microsoft Teams of Discord.
Na iedere Sprint wordt er een gesprek ingepland met de opdrachtgever en de projectbegeleider om te kijken naar de vooruitgang van de afgelopen Sprint en om te kijken naar wat de plannen zijn voor de volgende Sprint. Ook is er tijdens deze contactmomenten ruimte voor het schuiven in prioritering van de nog uit te werken use cases.
Hieronder staan de contactgegevens van het ontwikkelteam vermeldt, inclusief studentnummer en projectrol.
Naam | StudentNummer | |
---|---|---|
Niels van der Hoeven | N.vanderHoeven2@student.han.nl | 643459 |
Connor Newton | CM.Newton@student.han.nl | 591671 |
Tobias Feld | TDW.Feld@student.han.nl | 649385 |
Thijmen Schoonbeek | T.Schoonbeek@student.han.nl | 654632 |
Gino Janssen | GA.Janssen1@student.han.nl | 620837 |
Gezamenlijk email voor communicatie | perlman-han@outlook.com | n.v.t. |
Voor het project heeft ieder groepslid van het ontwikkelteam een rol op zich genomen waar bepaalde verantwoordelijkheden aan hangen. Welk groepslid welke rol opneemt en de verantwoordelijkheden daarbij staan hieronder uitgewerkt.
Rol | Teamlid | Verantwoordelijkheid |
---|---|---|
Scrum master | Niels van der Hoeven | Verantwoordelijk voor het naleven van de scrum handelingen binnen de project groep. Het leiden van de daily standup, het bewaken van de voortgang. |
Kwaliteitsmanager | Connor Newton & Gino Janssen | Eindverantwoordelijke voor de kwaliteit van het project. Belangrijke rol bij de code reviews. |
Product owner by proxy | Tobias Feld | Verantwoordelijk voor de communicatie met de opdrachtgever en het doorvoeren van de wensen. |
Planner | Thijmen Schoonbeek | Verantwoordelijk voor het indelen van realistische sprints. |
Teamlid | Iedereen | Verantwoordelijk om op tijd te komen, kwalitatief goede code schrijven aan de hand van de definition of done. |
9. Planning
Week | Sprint fase | Op te leveren producten | Overige aandachtspunten |
---|---|---|---|
OW-0 | Pre-sprint | ||
OW-1 | Start van de eerste sprint | Plan van Aanpak, Eerste versie SRS | Op maandag eerste versie PvA af, inleveren op dinsdag |
OW-2 | |||
OW-3 | Start van de tweede sprint | Uitwerking van de in sprint 1 opgepakte use cases | |
OW-4 | Eerste versie SDD | Op woensdag tussentijdse versie inleveren | |
OW-5 | Start van de derde sprint | Uitwerking van de in sprint 2 opgepakte use cases | |
OW-6 | |||
OW-7 | Start van de afronding van het project | Uitwerking van de in sprint 3 opgepakte use cases | |
OW-8 | Op vrijdag uiteindelijke versie inleveren; SRS, SDD, Broncode inclusief unit tests, Testrapportage, Projectbeheerartefacten en Individueel verslag | ||
OW-9 | Presentatie eindproduct aan de opdrachtgever | Gezamenlijk de eindpresentatie voorbereiden voor de opdrachtgever |
OW-0 is week 14, van 04 tot 10 april
10. Risico’s
Risico |
Kans |
Impact |
Tegenmaatregel | Uitwijkstrategie |
---|---|---|---|---|
COVID | middel | klein |
Herverdelen opdrachten tijdens afwezigheid Thuis online werken |
|
Uitvaller in de groep | klein | groot | Herverdelen opdrachten, sprints re-scopen. | |
Version control | middel | middel |
Goed via Bitbucket bijhouden wie wat doet. Branch protection rules (vereiste reviews) |
|
Ontwikkelomgeving is niet beschikbaar | klein | groot | Zelf lokaal proberen te werken totdat de problemen opgelost zijn. | |
Achterliggende API veranderd (optioneel/checken) | klein | groot | Goed bijhouden aankomende aanpassingen API |
User | Edits | Comments | Last Update |
---|---|---|---|
Connor Newton | 31 | 14 | 926 days ago |
Thijmen Schoonbeek | 21 | 1 | 935 days ago |
Gino Janssen | 19 | 2 | 878 days ago |
Niels Hoeven, van der | 15 | 0 | 934 days ago |
Tobias Feld | 8 | 0 | 926 days ago |
Auto Mation | 3 | 0 | 942 days ago |
Jaap Papavoine | 0 | 5 | 935 days ago |
Add Comment