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 dingen 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.

Achtergrond van het project

In de achtergrond geef je aan waar en voor wie jij de opdracht uitvoert en wat voor hen het belang van het project is.
Denk in elk geval aan:

• Beschrijving bedrijf/organisatie in je eigen woorden (geen teksten letterlijk overnemen van website)
• De belangrijkste groepen van stakeholders: wie hebben er –naast de opdrachtgever en de projectgroep- te maken met (de resultaten van) het project?
• Indien relevant: organisatiestructuur van het onderdeel waar opdracht betrekking op heeft
• De aanleiding voor het project: Wat is de urgentie van het project, de reden dat het bedrijf juist nu dit project wil laten uitvoeren (en niet een ander –mogelijk ook belangwekkend- 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, zijn. Verder wordt dit project begeleidt door Jaap Papavoine. De reden voor dit project is dat JDI een HR portaal nodig heeft waarin dingen als werknemersbeheer, werkplekken, reiskosten en verlof kunnen worden gemanaged.

De mate van urgentie die op dit project van toepassing is moet nog samen met de opdrachtgever worden vastgesteld. → vragen tijdens het overleg met de opdrachtgever

Doelstelling, opdracht, en op te leveren resultaten voor het bedrijf en school

Als de aanleiding helder is geformuleerd beantwoord je de vraag naar ‘het waarom’ (de doelstelling) en ‘het wat’ (de beoogde resultaten) van het project.

De opdrachtgever heeft op dit moment een niet-digitale oplossing voor het bijhouden van de verlofaanvragen en het bijhouden van de administratieve bezigheden van werknemers, zoals op welke dagen mensen op kantoor aanwezig zijn en wat de reiskosten zijn.

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.

Het HR-portaal wordt gemaakt met behulp van het front-end framework Vue.js, en gebruikt Java spring boot als back-end.

Probleemstelling

• Formuleer eerst het probleem of de uitdaging dat het bedrijf heeft: welk probleem/welke uitdaging moet door of voor het bedrijf worden opgelost? Bijvoorbeeld: het probleem is dat klanten via te veel verschillende kanalen contact opnemen met het bedrijf waardoor er geen goed beeld is of de klant al afdoende is geholpen. Waarom wil het bedrijf deze opdracht?

Doelstelling

• Aansluitend daarop formuleer je de doelstelling. Bijvoorbeeld: het bedrijf heeft wil alle contacten met de klant via de website te laten lopen. Let daarbij op: de doelstelling kan veel groter zijn dan jij met je resultaat oplost, dit is soms een veel te grote klus als afstudeer- of projectopdracht. Het is voldoende als jouw resultaat er een bijdrage aan levert.

De opdracht

• Deze doelstelling mondt uit in jouw opdracht. Wat ga je precies voor het bedrijf doen, en wat ga je opleveren? Jij hebt misschien als opdracht: Ontwerp een goede user-interface voor de website. Of: ontwerp een perfecte database. Zo’n opdracht kan een essentiële bijdrage leveren aan het behalen van de doelstelling.

Concrete resultaten

• Formuleer welke concrete resultaten het bedrijf van jou wil krijgen als je project is afgelopen? Wat is af als het af is? Geef daarbij duidelijk aan welke vereisten op het moment van schrijven al bekend zijn. Het gaat dan bijvoorbeeld om programmeertaal, omgeving/platform. Mocht er al een ontwerpdocument of een concept meegeleverd worden met de opdracht, dan is dat een bijlage. Het is niet de bedoeling dat je zelf al ontwerpdocumentatie maakt in deze fase.

Hieronder staat een overzicht met alle concrete op te leveren resultaten:

• Plan van aanpak.
• Software requirement specification (SRS).
• Software Design Documentation (SDD).
• Broncode (Java Spring Boot en Vue.js) inclusief unit tests ← hier nodig om aan te geven waaruit de broncode bestaat???
• Testrapportage.
• Projectbeheerartefacten (Hoofdstuk 6).
• Individueel verslag per groepslid (Dit onderdeel leveren we alleen aan school).

Projectgrenzen

Gek genoeg geeft opschrijven wat je nét niet meer doet in je project vaak heel veel helderheid over wat je juist wél gaat doen.
Hierdoor kun je ook voorkomen dat stakeholders tijdens het project met eisen komen die echt buiten de opdracht vallen. In deze
paragraaf baken je je project dus af. In elk geval ga je hierbij in op:

• Hoe lang duurt het project, dus wanneer houdt het op?
• Wat hoort inhoudelijk nét niet meer tot de opdracht? Bijvoorbeeld: ontwikkelen voor Windows, maar niet voor Linux; of wel een concept uitdenken, maar niet realiseren.

Organisatorische grenzen

toelichten dat we ook aan onze skills moeten werken

aantal te besteden uren per week - verslag, ontwikkeling, standups, vergaderingen, plannen, reviewen.

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. (Opdrachtgever mag sprintplanning niet aanpassen tussendoor) De laatste twee weken zijn gereserveerd om de eindpresentatie te maken en het softwarepakket te overhandigen en toe te lichten (Gaan we dit doen?).

Het ontwikkelteam is beschikbaar op werkdagen tussen 09:00 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. (Hieronder een overzicht waar alle uren heen gaan! moet nog worden verbeterd, dit is puur om een beeld te schetsen.)

Bezigheden die tijd kosten buiten het maken van het product.

Het komt erop neer dat er per sprint gemiddeld 20 uur per persoon overblijft om te werken aan het product. In deze tijd gaat het team de bijbehorende documenten schrijven, software schrijven, unit testen en reviewen.

softwaregrenzen

Het op te leveren softwarepakket wordt een Proof Of Concept (POC).

Het front-end gedeelte realiseren op basis van Vue.js

Het backend gedeelte realiseren door middel van Java springboot.

Randvoorwaarden

Succesvol zijn gaat maar zelden ‘zomaar’. Bij randvoorwaarden geef je SMART aan welke zaken door anderen voor jou geregeld moeten zijn zodat je zelf vlot door kunt werken. Denk bijvoorbeeld aan:

• Schoolritme dicteert (denk hierbij bijvoorbeeld aan inleverdeadlines) externe opdrachtgevers
• Schoolopdracht gaat voor (externe opdrachtgevers)
• Beschikbaarheid begeleider bedrijf. Is hij bijvoorbeeld op de juiste momenten beschikbaar voor het geven van feedback en het tijdig nemen van beslissingen?
• Welke resources (b.v. soft- of hardware) moeten er zijn om te kunnen werken? Denk aan toegang tot systemen, ontwikkelsoftware, aanschaffen van benodigde licenties.
• - ….

Gebruik bij het SMART maken de relevante aspecten van 5xW 1xH: Wie moet Wanneer Wat, Waar, Waarom en Hoe geregeld
hebben zodat jouw project niet in gevaar komt.

Om dit project en de bijbehorende opdracht goed af te kunnen ronden, hebben we de volgende zaken nodig van de volgende personen:

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. ← de 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.

De opdrachtgever

• Moet tijdens kantooruren beschikbaar zijn tot het verduidelijken van vragen, bijvoorbeeld via email.
• 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.
• Moet toegang verlenen tot een Slack systeem om geautomatiseerde berichten naar te kunnen sturen.
• levert uiterlijk op 14-6 voorbeeld data aan, anders kan het team niet gaan ontwikkelen
• levert een API koppeling voor Google maps anders kan het

Het eindproduct

• Moet ethisch verantwoord zijn, en het portaal kan niet in strijd zijn met de Nederlandse (privacy) wet. (Is dit een randvoorwaarde die we aan iemand stellen of juist andere aan ons?)
  

Op te leveren producten en kwaliteitseisen

In dit hoofdstuk behandel je alle producten die je in hoofdstuk 4 beschreven hebt en moet opleveren, zoveel mogelijk in detail. Het gaat dan zowel om producten die je aan je opdrachtgever levert, als om de producten die school van je vraagt. Daarin rafel je de resultaten die je moet opleveren uiteen in kleinere (deel)producten. Zo kan het resultaat ‘een stuk werkende code’ bestaan uit een ontwerp, code, een testrapport en overdrachtsdocumentatie, etc.
In elk geval staan de volgende zaken ook op die lijst:

• Een eindverslag
• Eindpresentatie
• Reflectieverslag (afstudeerders) of projectverslag (onderwijsprojecten)
• Bijlagen (waarnaar je in de hoofdtekst correct verwijst)

Voor ieder van de beschreven producten definieer je vervolgens meetbare (SMART) kwaliteitseisen. Je bedenkt welke activiteiten je moet doen om de producten volgens die kwaliteitseisen te maken en hoe je ervoor zorgt dat die kwaliteit ook in het proces bewaakt wordt (proceskwaliteitseisen). Dit breng je onder in een tabel. Hieronder staat een voorbeeld, dat expres niet uitputtend is ingevuld, ook zijn de kwaliteitseisen nog niet SMART geformuleerd. En… realiseer je dat het slechts een voorbeeld is!

Ontwikkelmethode

Nu je weet wat je gaat opleveren (producten en kwaliteit daarvan) en wat je daarvoor moet doen (overzicht activiteiten) met welkegrenzen en randvoorwaarden, geef je aan welke methode(n) jij gaat inzetten in je project. Heb je te maken met een adviestraject dan ligt het voor de hand om eerst een onderzoek te doen en daarna met een advies te komen. Ben je bezig met het ontwerp van bijvoorbeeld een website of ga je een stuk software ontwikkelen, maak dan eerst een onderbouwde keuze tussen bijvoorbeeld waterval, incrementeel, iteratief of een combinatie van die laatste twee. Daarna kun je eventueel specifieker worden door het kiezen van een bepaalde ontwikkelmethode. Hierbij spelen in elk geval de volgende overwegingen een rol:

• In hoeverre kunnen de resultaten van het project snel en volledig worden beschreven?
• Welke methoden hanteert het bedrijf en in hoeverre kun of moet je daar bij aansluiten?
• Schrijft de school een methode voor (bij propedeuse- en semesterprojecten)?

Wees hierbij wél kritisch: tijdens het afstuderen werk je bijvoorbeeld meestal in je eentje, en niet iedere methode (bijvoorbeeld Scrum bij het ontwikkelen van software) leent zich om individueel mee aan de slag te gaan. Soms is het handig om een methode daarop aan te passen. Dat kan, als je het maar goed onderbouwt en je daarbij baseert op betrouwbare bronnen. En als de methode is voorgeschreven: onderbouw waarom jij vindt dat deze methode passend is bij het soort project dat je moet gaan uitvoeren.Onderaan dit document vind je enkele suggesties voor literatuur over ontwikkelmethoden.

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 tussen 9:00 en 9:15 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 print 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 van JDI.

(Opdrachtgever mag sprintplanning niet aanpassen tussendoor)

Projectorganisatie en communicatie

____________________________________

De afspraken over contact momenten met zowel de opdrachtgever als de Procesbegeleider als de PS docent moeten nog gemaakt worden. Wij hopen hierbij vaste momenten in te plannen voor ieder. 

____________________________________

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. 

Het ontwikkelteam werkt alle werkdagen van 9:00 tot 17:00 gezamenlijk op locatie op de HAN in Nijmegen. Op deze dagen wordt dagelijks een stand-up gehouden om 9:00, met uitloop tot 9:15 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.

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. 

Planning

In dit hoofdstuk maak je een koppeling tussen de ontwikkelmethode en je activiteiten. Geef overzichtelijk weer wanneer de productopleveringen zijn, en wanneer belangrijke afspraken zijn. Zorg dat je ontwikkelmethode herkenbaar is in deze planning.

OW-0 is week 14, van 04 tot 10 april

Mogelijke opties om planning te verduidelijken                                                    Of een GANT planning

• Strokenplanning

Risico’s

Dit hoofdstuk is een soort ‘final check’. Je vraagt je af ‘wat kan er nu nog mis gaan?’. Een risico is iets wat buiten je macht/invloed op kan treden, en als het optreedt dan wordt de doelstelling van het project niet gehaald. Het project wordt dan te laat, met budgetoverschrijding of met (sterk) verminderde functionaliteit opgeleverd. Iets wat kan optreden maar wat planmatig bestreden kan worden is dus geen risico. Dit soort zaken neem je op in je planning, je randvoorwaarden, of daar waar het in het plan van aanpak thuishoort. Denk bijvoorbeeld aan voldoende overlegmomenten met je opdrachtgever.
Alléén de risico’s die je niet vooraf kunt beïnvloeden neem je op in deze paragraaf. Een voorbeeld: als je weet dat je tijdens je project gaat verhuizen kun je in je planning opnemen op welke dagen je niet werkt. Afwezigheid door verhuizing is dus geen risico. Maar, als je afhankelijk bent van de levering van een server door een nieuwe leverancier, kan het anders zijn. Natuurlijk neem je eerst in de planning op dat je er nog een keer extra achter aan belt (dit noemen we een tegenmaatregel), maar je vraagt je ook af wat je gaat doen als het onverhoopt tóch misgaat (je uitwijkstrategie). Dit geef je weer in een tabel die er zo uit kan zien: