felix donkers...agile development agile manifesto (2001): – personen en interacties, eerder dan...

Flexibel doch planmatig werken -> Agility

Flexibel doch planmatig werken Felix Donkers


Inhoudsopgave

1.  Waarom planmatig werken ? 2.  “Cowboy” development

3.  “Waterfall” development

4.  “Incremental” development

5.  “Agile” development

6.  “Scrum” canvas

7.  Stapsgewijze aanpak

8.  Requirements management


1.  De middelen om dingen voor elkaar te krijgen zijn beperkt: –  Tijd

–  Geld

–  Mensen

–  Apparatuur en andere middelen

2.  Deadlines zijn meestal “hard” een event wordt zelden verzet omdat “het drukwerk” niet klaar is

3.  Risiso’s zijn onvermijdelijk: Beter beheersen dan ontkennen

Toch verwacht een klant maximale kwaliteit “Voor jou 1000 anderen”

Waarom planmatig werken?


Planmatig werken

Definitie:

Het eigen werk op zo'n manier organiseren dat de resultaten die gehaald moeten worden binnen de gestelde tijd en met de aanwezige middelen worden gerealiseerd. Dit door nauwkeurig te werk te gaan en zonder anderen in hun werk te belemmeren.


Planmatig werken

Voordelen:

•  Overzicht krijgen: een uitdaging lijkt vaak een ondoorzichtige kluwen: er moeten allerlei dingen gebeuren, maar wat het eerst moet is niet altijd duidelijk. Een planmatige aanpak helpt om overzicht te krijgen en dwingt de medewerker langs grove lijnen te werken. Eerst de grote lijnen, dan de details.

•  Een start maken: medewerkers hebben vaak geen idee hoe en waar te beginnen. Planmatig werken helpt ze aan een begin. Zet wat op papier.

•  Denken in resultaten: planmatig werken helpt om te denken in resultaten, en ook in deelresultaten.

•  Volgorde: een planmatig aanpak schept inzicht in de logische volgordelijkheid van de verschillende deeltaken.


Planmatig werken

Knelpunten:

Het grootste knelpunt bij planmatige aanpak is de weerstand van medewerkers. De praktijk wijst uit dat deze medewerkers aan één of meer van de ‘3 O’s’ leiden: Onervarenheid, Onwetendheid en Onzekerheid: •  Onervaren - Medewerkers zijn onervaren, hebben het nooit eerder gedaan. Of ze

hebben wel met een projectplan gewerkt, maar hebben de tegenslagen en knelpunten niet goed weten op te pakken en hebben daar een slechte leerschool aan gehad.

•  Onwetendheid - zij hebben nooit een succesvolle planning gehad die hen dusdanig overtuigde dat ze door willen gaan met plannen.

•  Onzekerheid – er zijn medewerkers die bang zijn om afgerekend te worden op het niet halen van de planning. Ze hebben dit wellicht eerder meegemaakt en hebben er geen prettige herinnering aan overgehouden.


Cowboy development

•  ‘Cowboy model’ wordt vaak gebruikt door beginnende, gedreven teams:

–  Teams hebben een gezamenlijk doch slechts beperkt gedefinieerd belang/doel –  Teamleden hebben autonomie over hun aanpak; planning, tools, methodes, etc

•  Voordelen: –  Alle ruimte voor ieders expertise inbreng; inhoud en ideeen

–  Alle vrijheid voor ieders persoonlijke werkstijl –  Bijzonder flexibel tav veranderende omstandigheden

•  Valkuilen: –  Geen heldere focus, “shooting (fast) moving targets” –  Geen onderliggend plan

–  Geen borging van opgedane kennis

–  Weinig samenhang tussen de “losse onderdelen” –  Uitkomst onvoorspelbaar


Cowboy development

•  Stopt als: –  De klus geklaard is…

–  De tijd om is… –  Het geld op is…

–  Het team om andere redenen ontbonden wordt…

Start

Einde ?


Waterfall development

•  ‘Waterfall model’ wordt vaak gebruikt door (middel)grote, ervaren teams:

–  Top-down “Engineering” projecten –  Proces gedreven, Tijd, Geld en Kwaliteit (TGK) zijn leading factors

–  Mening van individuele teamleden ondergeschikt

•  Voordelen: –  Risicominimalisatie –  Maximale voorspelbaarheid tav TGK,

–  Proces biedt duidelijkheid aan alle teamleden –  Hergebruik van ervaringen uit eerdere projecten

•  Valkuilen: –  Big bang integratie

–  Rigide tov veranderende omstandigheden –  Duur, traag, log, …



•  Stopt als –  Project voltooid is => als product aan verwachtingen voldoet

–  Business case niet langer meer positief is (Prince II)

Waterval model



•  Ideaal als –  Risico’s minimaal zijn

–  Expertise / ervaring maximaal herbruikt kan worden


Itterative development

•  ‘Itterative model’ wordt vaak gebruikt door middelgrote, ervaren teams:

–  Acquisitie op basis van engineeringcompetenties ipv productkennis –  Cyclische realisatie tbv stapsgewijze risico reductie

•  Voordelen: –  Risicoreductie gestuurd (grootste onzekerheden

eerst aanpakken)

–  Leren van ervaringen uit eerdere processtappen

•  Valkuilen: –  Minder voorspelbaar tav Tijd en Geld (TG)

–  Alleen een eindoplevering, geen tussentijdse oplevering –  Weinig contact met klant/eindgebruikers,


Itterative development

•  Ideaal als: –  (Technische) onzekerheden onderzocht en opgelost moeten worden


Spiral development

•  ‘Spiral model’ Vaak gebruikt door kleine, ervaren teams: –  Itteratief (6 mnd - 2 jaar / cyclus)

–  Ongoing proces

•  Voordelen: –  Beheersde groei van prototype naar eindproduct –  Procescontrole middels PDCA cyclus (waterfall-like)

•  Valkuilen: –  Onvoorspelbaar mbt eindresultaat –  Moeilijk voorspelbaar tav Tijd en Geld (TG)


Spiral development

•  Ideaal als: –  Nieuwe ideeen ontwikkeld moeten worden die zouden kunnen uitgroeien tot

een serieus eindproduct

–  Stapgewijze verbeteringen doorgevoerd moeten worden


Agile development

Agile Manifesto (2001): –  Personen en interacties, eerder dan processen en tools

–  Software die werkt, eerder dan lijvige documentatie –  Samenwerking met de klant, eerder dan onderhandeling over het contract

–  Omgaan met verandering, eerder dan het volgen van een plan

Agile voor CMD –  Vervang de term “software” door bijv. website,

smart friend, event, …

Agile –  Behendig

–  Lenig


Agile development

•  Principles –  Klanttevredenheid, door snelle, continue levering van bruikbare software

–  Zelfs late veranderingen in de requirements zijn welkom –  Werkende software wordt regelmatig geleverd (weken eerder dan maanden)

–  De ontwikkelaars werken nauw en dagelijks samen met de mensen die de business kennen

–  Projecten steunen op gemotiveerde en betrouwbare personen –  Een gesprek in levende lijve is de beste manier van communicatie, wat

betekent dat men zich best op dezelfde plek bevindt

–  Werkende software is de eerste maatstaf van vooruitgang –  De ontwikkeling kan te allen tijde worden voortgezet

–  Er is voortdurende aandacht voor technische uitmuntendheid en goed ontwerp –  Eenvoud is belangrijk: hoe meer er niet gedaan wordt, hoe beter

–  De teams organiseren zichzelf –  Men past zich aan aan de omstandigheden


Agile development

•  Vaak gebruikt door kleine, ervaren teams: –  Klant is intensief betrokken

–  Max 20 – 40 experts / team –  Itteratief (timeboxing 2 - 4 weken)

–  Regelmatige productoplevering

–  Ongoing process –  One-room approach

•  Voordelen: –  Zie volgende slides

•  Valkuilen: –  Onvoorspelbaar mbt eindresultaat (niet SMART) –  Moeilijk voorspelbaar tav Tijd en Geld (TG)

–  Veiligheidsaspecten lastiger te managen


Scrum - development

Scrum is een raamwerk voor Agile management ("behendig beheren") van softwareontwikkeling. Er wordt gewerkt in multidisciplinaire teams die in korte sprints (iteraties) werkende software opleveren. Samenwerking, communicatie en teamgeest zijn hierbij sleutelwoorden.

Scrum in een 10-min video


Scrum - development proces


Scrum - timeline

Sprint 1 Sprint 2

Sprint 3 Sprint 4

Sprint 5

t

Product maturity

•  Er wordt gewerkt met vaste tijdblokken (time-boxing) -> sprint

•  Afhankelijk van de projectkarakteristieken duurt een sprint: 2 en 4 weken

•  Tbv elke sprint wordt een afgebakend setje features vastgesteld die in die sprint zullen worden gerealliseerd.

•  Na elke sprint is er een “eindproduct” dat overdraagbaar is naar de klant.

•  Na elke sprint is het “eindproduct” weer een stapje “volwassener”


Scrum - roadmap

Sprint 1 Sprint 2

Sprint 3

Sprint 4 Sprint 5

nu

einddoel


Scrum - standup meeting

Bij scrum worden de experts uit de verschillende fasen bij elkaar in één team gezet. Het team wordt geleid door de "scrum-master" en houdt vrijwel dagelijks bij aanvang van de werkdag een zogenaamde "scrum-meeting" (ook wel "standup-meeting" genoemd). In deze ontmoeting die ongeveer 15 minuten duurt, beantwoordt elk teamlid de volgende drie vragen:

– Wat heb je gedaan?

– Wat ga je doen? – Wat zijn je problemen?

Daarna gaat de expert weer aan het werk met zijn eigen team om de opdracht te volbrengen. De personen werken veel samen en pakken het project met zijn allen tegelijkertijd aan.


Stapsgewijze aanpak

•  Waarom doen we dit Missie

•  Wat willen we bereiken Visie

•  Hoe gaan we dat realiseren Strategie

Bij het opstellen van een ‘missie, visie en strategie’ is niet zozeer de einduitkomst belangrijk maar vooral het pad waarlangs deze to stand komt zodat een gezamenlijk draagvlak ontstaat.


Strategie-aanpak

1.  Definieer einddoel (K=kwaliteit) 1.  alle deliverables & requirements (producten, diensten, middelen,

prioriteiten, etc)

2.  SMART definieren

2.  Stel een planning op (T=tijd) 1.  alle activiteiten om doelen te kunnen realiseren (WBS)

2.  alle benodigde resources (mensen, materiaal, faciliteiten, etc) 3.  alle onderlinge afhankelijkheden

3.  Bereken benodigd budget (G = geld)

4.  Finetune TGK

5.  Neem besluit: GO/NOGO

Tijd Geld

Kwaliteit


Requirements management

•  Behelst het opstellen en beheren van alle specificaties van het te realiseren eindproduct/-resultaat.

•  Draagt er aan bij dat het projectresultaat zal gaan voldoen aan de verwachtingen van de opdrachtgever en overige belanghebbenden.

•  Begint met het analyseren en in kaart brengen van de doelen en randvoorwaarden van de organisatie.

•  Ondersteunt de planning voor het implementeren en het in gebruik nemen van de requirements.

•  Impliceert communicatie met project teamleden en belanghebbenden mbt het wederzijds begrip (en evt actualiseren) van de requirements.


Requirements man. - SMART

•  Specifiek –  Omschrijf het doel duidelijk en concreet. Het moet een waarneembare actie, gedrag of resultaat

beschrijven waaraan een getal, bedrag, percentage of ander kwantitatief gegeven verbonden is.

•  Meetbaar –  Wat is er af als het af is? Een SMART-doel moet je kunnen zien, horen, proeven, ruiken of voelen.

•  Acceptabel –  Is er draagvlak voor wat we doen? Is het in overeenstemming met het beleid en de doelstellingen van

de organisatie? Zijn de betrokkenen bereid zich te verbinden aan de doelstelling?

•  Realistisch –  Is het doel haalbaar? Is er een uitvoerbaar plan met aanvaardbare inspanningen? Kunnen de

betrokkenen de gevraagde resultaten daadwerkelijk beïnvloeden? Hebben ze voldoende know-how, capaciteit, middelen en bevoegdheden? Dit is belangrijk, want een onbereikbaar doel motiveert mensen niet.

•  Tijdsgebonden –  Wanneer beginnen we met de activiteiten? Wanneer zijn we klaar? Wanneer is het doel bereikt? Een

SMART-doelstelling heeft een duidelijke startdatum en einddatum.


Requirements man. - SMART

•  Goede voorbeelden –  Dit jaar wil ik 20 studiepunten van mijn management opleiding halen. –  Over 5 jaar wil ik project manager zijn, verantwoordelijk voor ICT-projecten van 100.000

tot 1.000.000 euro. –  De winst moet volgend jaar 30% hoger zijn dan die van vorig jaar.

•  Slechte voorbeelden –  Ik wil een leuke baan (niet specifiek, niet meetbaar, niet tijdgebonden). –  We worden de beste in onze markt (niet meetbaar, niet tijdgebonden). –  Om de arbeidsparticipatie te bevorderen moeten mensen terugkeren in het

arbeidsproces en langer werken (Koningin Beatrix, Troonrede 2004).

Bron: Carrieretijger


Requirements Man. - Product backlog

Product Backlog

Sprint1 Sprint2 Sprint … Sprint N N/A

Feature 1 X Feature 2 X Feature 3 X Feature 4 X Feature 5 X Feature 6 X …

•  Backlog = feature list –  1 voor het eindproduct

–  1 voor elke ‘sprint’


Requirements Man. - Sprint backlog

Sprint Backlog Must Should Could Would Feature 1 X Feature 4 X Feature 13 X Feature 17 X Feature 27 X

•  MoSCoW –  Must: deze eis moet in het eindresultaat terugkomen, zonder deze eis is het

product niet bruikbaar

–  Should: deze eis is zeer gewenst, maar zonder is het product wel bruikbaar

–  Could: deze eis mag alleen aan bod komen als er tijd genoeg is (evt voor 2e ronde) –  Would: deze eis zal in dit project niet aan bod komen maar kan in de toekomst, bij

een vervolg project, interessant zijn.


Totaaloverzicht

Methode Teamomvang Flexibiliteit Voorspel- baarheid

Cowboy <10 ++++ ---- Waterfall >25 -- ++++ Itterative <100 +/- ++ Agile / Scrum <50 ++ +/-

felix donkers...agile development agile manifesto (2001): – personen en interacties, eerder dan...

Documents