Software- en Gameproject Inleidende colleges periode 3-4 2016/2017 College 2 Risico s, Planning, Communicatie Johan van Rooij Zorg dat je als projectgroep bij elkaar zit! 1
Vorige week: Agile en Scrum Eerste stappen met scrum: 1. Stel een product vision op. 2. Het product backlog vullen. 3. Grove prioritering (MoSCoW). 4. Opsplitsen van belangrijkste stories. 5. Start de eerste sprint. 6. Review product met de klant. 7. Review proces met het team. 8. Onderhouden van het backlog. 2
Dit college: risico s, communicatie, planning Veel grote softwareprojecten mislukken. Ook met agile aanpak, alleen wel wat minder. Dit college gaat over de grootste risico s. Eerst: marshmallow challenge. Ervaar het zelf Risico s. Belangrijke uitdagingen bij softwareprojecten. 1. Inschatten van risico s. 2. Planning. 3. Communicatie. 3
Software- en gameproject THE MARSHMALLOW CHALLENGE 4
The marshmallow challenge Bouw een vrijstaand bouwwerk op basis van spaghetti, tape en touw met de marshmallow bovenop. Je mag de spaghetti aan de tafel vastplakken. Je mag niet iets bouwen dat hangt aan het plafond of een anderszins hoger object. Ik meet straks de afstand tussen de tafel en de onderkant van de marshmallow. Het team met het hoogste bouwwerk wint de rest van de zak marshmallows. Je mag spaghetti breken, de tape of het touw in stukje knippen, etc. De marshmallow moet wel intact blijven. 5
The Marshmallow challenge Jullie kunnen (zo meteen) bij mij ophalen: 1 marshmallow. 20 stengels spaghetti. 1 meter tape. 1 meter touw. Als we beginnen krijg je 18 minuten. Het team met het hoogste bouwwerk wint! Vragen? 6
7 Reflectie
Kijk eens naar dit filmpje https://www.youtube.com/watch?v=h0_ykbito8m Is dit verhaal herkenbaar? Kun je hier iets mee voor jullie softwareproject? 8
Waar ik hoop dat je iets van meepikt Het belang van het identificeren van risico s. Het voordeel van iteratief ontwikkelen. Dit verkleind risico s. Bedenk ook: 1. Jullie zijn geen architecten! Het Softwareproject bevat genoeg nieuwe dingen waar je waarschijnlijk nog weinig ervaring mee hebt. 2. Onderschat niet het belang van goed samenwerken en het soepel lopen van het proces. Rol van de `executive admin ligt bij jullie bij de scrum master en de voorzitter. 9
Software- en gameproject RISICO S 10
11 Risico s
Risico s Risico inschattingen zijn altijd op basis van: Verwachtte kans. Verwachtte impact. Risico s goed inschatten is bijna onmogelijk. Een selectie maken van risico s die meer aandacht verdienen kan wel. 12
Verwachtte kans en impact Als informatici zijn wij getraind om te denken in technisch risico: Hoe lastig is het om feature X te implementeren? Wat komt er bij kijken om met systeem Y te interfacen? Hoe roep ik library Z aan? Bedenk dat het meeste (onverwachte) risico in hele andere factoren zit. 13
Risico s zitten waar het vaak mis gaat 14 Uit IT Cortex, The Bull survey (1998)
Uitdaging 1: communicatie Nr 1! Slechte communicatie ook vaak onderliggende oorzaak van andere problemen. 15 Uit IT Cortex, The Bull survey (1998)
Uitdaging 2: slechte planning Nr 2! 16 Uit IT Cortex, The Bull survey (1998)
Niet technisch risico Kans dat een teamlid tijdens het project uitvalt. Kans dat teamleden ruzie krijgen. Onderling of met de klant. De klant heeft eigenlijk geen idee van wat hij precies wil. De projectgroep heeft eigenlijk geen idee van wat de klant wil. De klant heeft tijdens het project andere prioriteiten. Het product wordt gebouwd voor de contactpersoon, de eindgebruiker kan er later echter niets mee. Samenwerken/afhankelijk zijn van een derde partij. Deze risico s komen vaak pas boven water als het te laat is. 17
Overige onderliggende uitdagingen en risico s Software in een nieuw toepassingsdomein? Kun je met de klant meepraten hierover? Bedoel je dan ook echt hetzelfde? Data. Data zit altijd en consistent vol met problemen. Nieuwe technologie? Waar je nog niet mee bekend bent misschien? Velen van jullie hebben geen ervaring met werken voor een echte klant en/of in een team in project verband. Zorgt wellicht voor vertraging of het nemen van een verkeerde beslissing. Voor team leden is er meer dan het software project: andere cursussen, baantjes, hobby's, etc. 18
Software- en Gameproject Inleidende colleges periode 3-4 2016/2017 College 2 Risico s, Planning, Communicatie Johan van Rooij 19
Dit college: risico s, communicatie, planning Veel grote softwareprojecten mislukken. Ook met agile aanpak, alleen wel wat minder. Dit college gaat over de grootste risico s. Eerst: marshmallow challenge. Ervaar het zelf Risico s. Belangrijke uitdagingen bij softwareprojecten. 1. Inschatten van risico s. 2. Planning. 3. Communicatie. 20
Inschatten van risico s Risico inschattingen zijn altijd op basis van: Verwachtte kans. Verwachtte impact. Risico s goed inschatten is bijna onmogelijk. Een selectie maken van risico s die meer aandacht verdienen kan wel. 21
Manieren om met risico s om te gaan Avoidance (reduction) - voorzorgsmaatregelen nemen: Met proven technology werken. Werken met mocks, stubs, etc. Minimisation (reduction) Eigenaarschap van code delen zodat het ontwikkelen niet stagneert als iemand ziek is. Demo prototypes maken om informatie op te halen bij de klant. Contingency plans - accepteer het risico maar plan voor als het mis gaat: Welke stories vallen buiten scope als we tijd tekort komen? Tolerance Programma s zo ontwerpen dat ze tegen een stootje kunnen. 22
23 Risico s
24 What is your marshmallow?
Het vinden van de grootste risico s Bekijk de MoSCoW geprioriteerde user stories. Geef ieder teamlid de planningpoker kaarten 1, 2 en 3. Iedereen legt deze kaarten bij de stories waar hij/zij denkt dat het meeste risico mee gemoeid is. Bespreek de toegewezen scores en besluit gezamenlijk per story hoe risicovol deze is. Houd deze risico score s bij in het backlog. Hierna: laat ieder teamlid risico s die niet aan stories te relateren zijn opschrijven op post-its. Bespreek de post-its en groepeer post-its die over hetzelfde gaan. Herhaal bovenstaand proces met de planning poker kaarten. 25
Wat te doen met de grootste risico s Het proces op de vorige slide leidt tot het identificeren van de grootste risico s. Bediscussieer voor de grootste risico s: Hoe zullen we hier mee om gaan? Heeft het risico of de aanpak impact op onze aanpak of architectuur? Komen er hierdoor nieuwe stories bij? Heeft dit effect op de prioriteiten in het backlog? 26
Software- en gameproject PLANNING 27
Risico s en Planning Als je er van uit gaat dat klanten niet precies weten wat ze willen Dan hoop je dat door iteratief ontwikkelen je convergeert naar een product waar hij/zij tevreden over is. Maar, dit is niet het hele verhaal. Verschillende planningen brengen hele andere risico s met zich mee. Met een goede planning kun je belangrijke risico s uit te weg gaan, namelijk door risico s naar voren te halen. Iteratief ontwikkelen betekent niet geen planning hebben! 28
Het goede detail van planning Een goede planning is als een goed backlog. Veel details over wat op korte termijn moet gebeuren. Minder details over de lange termijn, maar wel plannen. Het verloop van fijn naar grof kan geleidelijk. Een goede planning is een verdeling in tijd en resources. Waarin prioriteiten goed afgestemd zijn met capaciteiten. Op welke volgorde pakken we de belangrijkste stories op? Er is meer dan wat belangrijk is volgens de MoSCoW methode. 29
30 De korte en middellange termijn planning visueel
De korte en middellange termijn planning visueel 1. Wat doen we deze sprint? 2. Wat komt er de volgende sprint? 3. Wat staat er op de middellange termijn op de planning. Handig overzicht bij: Bepalen prioriteiten. Voorbereiden meeting klant. Voortgang controle. 31
Een goede lange termijn planning (project planning) Het projectplan dient ter: Communicatie met de klant (wanneer wat te verwachten). Voortgangscontrole (lopen we achter? wat doen we dan niet?) Het projectplan bestaan uit milestones. Een aantal test releases waarin belangrijke stories samen komen. Test releases waaraan de klant kan zien waar hij staat. De projectplanning is één van de eerste deliverables. 32
Een goede lange termijn planning (project planning) Een goede projectplanning haalt risico s naar voren. Technische risico s. Risico s in begrijpen van de klant (snel basaal werkend product maken). Data risico s. 33
34
35
Een goede planning Een goede projectplanning haalt risico s naar voren. Technische risico s. Risico s in begrijpen van de klant (snel basaal werkend product maken). Data risico s. Vaak komt dat neer op o.a. zo snel mogelijk een functional walking skeloton maken. Dat kan er visueel als volgt uitzien Visueel zodat voortgang ook meteen voor het hele team duidelijk is (communicatie!). 36
37
Visuele overzichten Jullie hebben in mijn colleges een aantal verschillende visuele overzichten gezien: Scrum board Sprint planning / middellange termijn planning. Lange termijn prioriteiten (project planning). In softwareproject heb ik ook gezien: Aanwezigheid verschillende teamleden. Reminders grootste risico s. Kies hierin wat je handig vind: Visuele overzichten zijn makkelijke interne communicatie. Worden steeds meer standaard in het bedrijfsleven. Moeten wel bijgehouden worden (een owner hebben). 38
Software- en gameproject COMMUNICATIE 39
Een wensenlijstje van de klant Ik wil een serious game om X te onderwijzen. We willen dat het gebruikt kan worden in de bachelor, master en ook voor PhD studenten. Het spel zal zich moeten aanpassen aan het niveau van de speler. Het zal aanpasbaar zijn om verschillende facetten van X te onderwijzen. Het moet op alle denkbare apparaten werken. The moon on a stick. 40
Echte klanten Klanten hebben de neiging om: Te veel te willen. Te praten over wat ze willen vanuit hun perspectief. De essentie van wat ze willen als detail te zien. Geen idee te hebben van wat technisch moeilijk is. Niet door te hebben dat software engineers geen verstand hebben van hun werkveld (jargon). Een flinke kloof om te overbruggen En dat terwijl communicatie vaak niet precies is. Verschillende mensen kunnen dezelfde woorden echt anders bedoelen en/of interpreteren. 41
Het goede nieuws Het projectbureau probeert: Projecten te definiëren die passen binnen de scope van een softwareproject. De verwachtingen van de klant vooraf al (een beetje) te managen. De projectgroepen te coachen (begeleiding). Maar dit blijft heel moeilijk. Niet voor niets de nummer één reden dat projecten mislukken. 42
Wat wil de klant? Een echt voorbeeld! Toen het softwareproject ongeveer halverwege was, vertelde een student mij: Onze klant heeft ons nog steeds niet verteld wat de requirements van ons programma zijn. Wie zijn taak is dit? 43
44 Hoe kun je er achter komen wat de klant wil?
Hoe kun je er achter komen wat de klant wil? Een aantal ideeën: Schrijf een product vision op en bespreek deze met de klant. Iteratief ontwikkelen. De klant bij het prioriteren van stories te betrekken. Zorgen voor validatie van ideeën en gebouwd prototype. Bij iedere demo de klant achter de computer zetten. Van begin tot eind steeds (en steeds weer) om feedback vragen. Ook: Bereid sessie met de klant goed voor. Weet waar je zeker feedback op wilt. Weet welke informatie je zeker nodig hebt in de komende, en daaropvolgende sprints en vraag hiernaar. 45
Wees je bewust van het verschil in belevingswerelden De meeste klanten hebben geen informatica achtergrond. Het is dus best moeilijk in te schatten wat weinig werk is en wat heel moeilijk is. Wees je hier bewust van. Leg zaken in hoofdlijnen aan de klant uit. Niet technisch, wel wat voor hem de gevolgen zijn. Laat de klant desnoods keuzes maken uit verschillende mogelijkheden en gevolgen (bijvoorbeeld kost veel tijd). 46
Dit verschil geldt ook andersom Mensen met een heel andere achtergrond verwoorden belangrijke eisen anders: Het programma moet een sexy uitstraling hebben Het programma moet met de gebruiker meedenken Bovenstaande verwoordingen heb je als programmeur weinig aan, maar kun je wel afpellen. Doorvragen. Iteratieve prototypes maken (doel is niet iets maken, maar informatie vergaren). 47
Dit verschil geldt ook andersom en is het meest vervelend als het om domeinkennis gaat. Wees je bewust dat jij niet volledig bekend bent met het toepassingsdomein van de klant. Je maakt altijd onbewust aannamen. Wees je bewust dat details uit het toepassingsdomein van de klant voor hem vanzelfsprekend zijn. Dûh Hij zal hier niet altijd vanzelf over gaan praten Bovenstaande is extreem belangrijk bij: Opstellen requirements en ontwerpen van modelstructuur. Interpretatie van data. Zorg voor validatie en feedback! 48
Hoe om te gaat met de klant? Drie adviezen van een consultant Ten eerste de klant is een persoon. Hoe obvious dit ook is, hier moet je wel tijd aan besteden. Verschillende mensen hebben verschillende stijlen van werken. Is je klant emotioneel ingesteld? Rationeel? Is je klant dominant? Of juist erg teruggetrokken? Pas je manier van werken hier op aan! Denk hier over na. Een gezellig één op één praatje maken Hebben sommige klanten ook behoefte aan. Kan het vervolg van de sessie veel effectiever maken. 49
Hoe om te gaat met de klant? Drie adviezen van een consultant Ten tweede de klant is vaak meer dan één persoon. Ook al heb je maar één contact persoon zijn er altijd: Degene die betaald. Degene die het product gaan gebruiken (soms op verschillende afdelingen met verschillende wensen). De baas van de gebruikers. Degene die het moet ondersteunen in het IT landschap. Al deze stakeholders zijn personen waarvoor de vorige slide geldt. Maar ook: verschillende personen hebben binnen een organisatie vaak verschillende belangen. Realiseer je dit. Waarom wil iemand iets Dit is een heel vak: stakeholder management. 50
Hoe om te gaat met de klant? Drie adviezen van een consultant Ten derde sta stil bij hoe de relatie/verhouding tussen het team en de klant is. Drie uitersten, het projectteam is: 1. Uitvoerder (handlanger). De klant zegt wat er moet gebeuren, jullie doen het. 2. Oplossing voor het probleem (expert). De klant laat alles aan jullie over. 3. Partner. Je hebt een 50/50 relatie, belangrijke beslissingen worden samen genomen. Zo weet je ook zeker dat de klant commitment heeft bij het project. 51
52 Waarom je geen oplossing voor het probleem wil zijn.
Ten slotte nog wat over communicatie in het algemeen. Communicatie is nooit precies. Veel misverstanden ontstaan door dezelfde woorden anders geïnterpreteerd worden dan ze bedoelt zijn. Veel misverstanden ontstaan omdat iedereen er toch zijn eigen sausje overheen gooit. Dit geldt zowel: Tussen het development team en de klant. Tussen leden van het development team onderling. 53
54
Ten slotte nog wat over communicatie in het algemeen. Communicatie is nooit precies. Hoe ga je hier mee om? Les één als consultant: luisteren is ook actief bezig zijn. Meestal wordt het LSD genoemd: 1. Luisteren actief luisteren en proberen te begrijpen wat er gezegd wordt. 2. Samenvatten checken of je het goed begrepen hebt door in andere woorden te herhalen wat er gezegd is. 3. Doorvragen net even een niveau dieper doorvragen om te zien of je het ook echt begrijpt, of dat er nog meer is. 55
Ten slotte nog wat over communicatie in het algemeen. Iedereen doet continu veronderstellingen/aannames. Dingen waar we vaak niet eens stil bij staan. Het zal wel zo werken Het zal wel dit zijn Iedereen zegt Wees je hier bewust van. Stel vragen, stel meer vragen, stel nog meer vragen. Dit zorgt voor duidelijkheid. Een waardevol teamlid stelt juist de domme vragen. Dit geldt zowel voor communicatie met de klant als communicatie intern. 56
Software- en gameproject TOT SLOT 57
Tot slot Identificeer de grootste risico s aan jullie project. Technisch en niet technisch. Door goede planning en communicatie kom je al een heel eind om de grootste risico s op te lossen / de grootste uitdagingen aan te gaan. Maar dit is niet triviaal. Volgende week: Agile development betekent continu (kleine) veranderingen aan de wensen van de klant. Deze verandering brengen ook risico s met zich mee. Oplossingen hiervoor zijn van net iets andere aard. 58