Agile Scrum Handboek E-Book

Frank Turley

• Herausgeber: Van Haren Publishing
• Kategorie: Bildung
• Sprache: Niederländisch
• Veröffentlichungsjahr: 2018

Seitenzahl: 154

Beschreibung

Dit boek heeft een nieuwe versie: 9789401807937 - Agile Scrum Handboek – 3de druk https://www.vanharen.store/agile-scrum-handboek-3de-druk    Dit is een eenvoudige, gemakkelijk te begrijpen gids voor iedereen die het Agility concept en het Scrum framework wil leren. Het behandelt de onderliggende concepten en principes, samen met Scrum rollen en verantwoordelijkheden, gebeurtenissen, artifacts en schalingsbenaderingen. Ook komen algemene praktijken en technieken aan de orde.❶ In plaats van lof te uiten voor Agility, concentreert het boek zich op het begrijpen van de ware betekenis ervan op een eenvoudige en consistente manier en bekijkt het de soorten projecten waarvoor het werkt en waarvoor mogelijk niet. Dit fundament helpt je de weg te vinden in dagelijkse problemen in de echte wereld. ❷ Het boek is een complete gids voor de kern van het Scrum framework, gebaseerd op de Scrum Guide (editie november 2017). Het behandelt alle rollen en verantwoordelijkheden, events en artifacts. Met een korte sectie over het schalen van Scrum.❸ Er is een hoofdstuk over eXtreme Programming, dat is gebruikt als excuus om een aantal van de belangrijkste Agile werkwijzen en technieken, zoals Test Driven Development en Pair Programming, op een geïntegreerde manier te verkennen.❹ Het vierde hoofdstuk is een overzicht van de DSDM® methodiek, dat voornamelijk gericht is op de aanpak en het beheer van scope en fixed-price contracten op een gestructureerde manier.❺ In het laatste hoofdstuk staat een overzicht van Kanban en ScrumBan.Dit boek is in lijn met het certificeringsprogramma van EXIN Agile Scrum Foundation.

Leseprobe

Agile Scrum Handboek

Andere uitgaven bij Van Haren Publishing

Van Haren Publishing (VHP) is gespecialiseerd in uitgaven over Best Practices, methodes en standaarden op het gebied van de volgende domeinen:

- IT en IT-management;

- Enterprise-architectuur;

- Projectmanagement, en

- Businessmanagement.

Deze uitgaven zijn beschikbaar in meerdere talen en maken deel uit van toonaangevende series, zoals Best Practice, The Open Group series, Project management en PM series.

Op de website van Van Haren Publishing is in de Knowledge Base een groot aanbod te vinden van whitepapers, templates, gratis e-books, docentenmateriaal etc. Ga naar www.vanharen.net.

Van Haren Publishing is tevens de uitgever voor toonaangevende instellingen en bedrijven, onder andere: Agile Consortium, ASL BiSL Foundation, CA, Centre Henri Tudor, Gaming Works, IACCM, IAOP, IPMA-NL, ITSqc, NAF, KNVI, PMI-NL, PON, The Open Group, The SOX Institute.

Onderwerpen per domein zijn:

IT and IT Management

ABC of ICT

ASL®

CATS CM®

CMMI®

COBIT®

e-CF

ISO/IEC 20000

ISO/IEC 27001/27002

ISPL

IT4IT®

IT-CMF™

IT Service CMM

ITIL®

MOF

MSF

SABSA

SAF

SIAM™

TRIM

VersiSM™

Enterprise Architecture

ArchiMate®

GEA®

Novius Architectuur Methode

TOGAF®

Business Management

BABOK®Guide

BiSL® and BiSL® Next

BRMBOKTM

BTF

EFQM

eSCM

IACCM

ISA-95

ISO 9000/9001

OPBOK

SixSigma

SOX

SqEME®

Project Management

A4-Projectmanagement

DSDM/Atern

ICB / NCB

ISO 21500

MINCE®

M_o_R®

MSP®

P3O®

PMBOK®Guide

PRINCE2®

Voor een compleet overzicht van alle uitgaven, ga naar onze website: www.vanharen.net

Colofon

Titel:

Agile Scrum Handboek

Auteurs:

Nader K. Rad & Frank Turley

Oorspronkelijke titel:

Agile Scrum Handbook

Oorspronkelijke uitgever:

Van Haren Publishing, ’s-Hertogenbosch, 2018

Vertaling:

Theo Wanders, Maarssen

Tekstredactie:

Janneke Wolters

Uitgever:

Van Haren Publishing, ’s-Hertogenbosch, www.vanharen.net

ISBN Hard copy:

978 94 018 0350 2

ISBN eBook:

978 94 018 0351 9

ISBN ePub:

978 94 018 0352 6

Druk:

Eerste druk, eerste oplage, november 2018

Lay-out en DTP:

Coco Premedia, Amersfoort – NL

Copyright:

© Van Haren Publishing, 2018

Trademarks:

PRINCE2® is een registered trademark van AXELOS.

PRINCE2 Agile® is een registered trademark van AXELOS.

DSDM® is een registered trademark van Agile Business Consortium Limited.

EXIN Agile Scrum Master™ is een registered trademark van EXIN.

Niets uit deze opgave mag vermenigvuldigd, vastgelegd in een geautomatiseerd bestand of openbaar gemaakt worden op of via enig medium, hetzij elektronisch, mechanisch, door fotokopieën of anderszins, zonder voorafgaande schriftelijke toestemming van de uitgever.

Ondanks alle zorg die aan deze uitgave is besteed, kunnen er eventuele fouten in voorkomen. De uitgever en de auteurs aanvaarden geen aansprakelijkheid voor het optreden van fouten en/of onvolkomenheden.

OVER DE AUTEURS

1.   AGILITY (HET BEHENDIGHEIDSCONCEPT)

1.1 Projectleveringsmethode en levenscyclus

1.2 Voorspellende versus adaptieve levenscyclus

1.3 Agile versus Waterval

1.4 Is Agile nieuw?

1.5 Het Agile Manifesto

1.6 Agile principes

1.7 Praktische overwegingen over adaptieve levenscyclusfasen

1.7.1 Fixed-scope versus fixed-time iteraties

1.7.2 Duur van iteraties

1.7.3 Dezelfde tijdsduur of verschillende tijden voor iteraties?

1.7.4 Wat als sommige functies niet zijn afgerond?

1.7.5 Wat gebeurt er binnen de iteraties?

1.7.6 Machtigingen

1.8 Is dit alleen geschikt voor IT-projecten?

1.9 Is Agile sneller?

2.   SCRUM

2.1 Methodologie versus framework

2.2 Algemeen overzicht van het Scrum Framework

2.3 Scrum rollen

2.3.1 Scrum Team

2.3.2 Rol 1: De Product Owner

2.3.3 Rol 2: De Scrum Master

2.3.4 Rol 3: Het Development Team

2.3.5 Andere rollen

2.3.6 Wie is de Projectmanager?

2.3.7 Varkens en kippen (pigs and chickens)

2.3.8 Geschikte werkruimte

2.3.9 Osmotische communicatie (osmotic communication)

2.3.10 Virtuele teams

2.4 Scrum gebeurtenissen (events)

2.4.1 Introductie in Scrum events

2.4.2 Timeboxing

2.4.3 Event 1: De Sprint

2.4.4 Event 2: Sprint Planning

2.4.5 Event 3: Daily Scrum

2.4.6 Event 4: Sprint Review

2.4.7 Event 5: Sprint Retrospective

2.4.8 Activiteit: Product Backlog Refinement

2.4.9 Slack (speling)

2.4.10 De eerste Sprint

2.4.11 Release planning

2.4.12 Testen bij Agile

2.4.13 Planning onion

2.5 Scrum artifacts

2.5.1 Artifact 1: Product Backlog

Product Backlog Items

Alleen functionele features?

De twee regels

INVEST op de Product Backlog Items

Epics en Themes (verhalen en thema’s)

Estimating (schatten)

Storypoints

Velocity (snelheid)

Ideal Hours/Ideal Days (ideale uren/ideale dagen)

Velocity versus succes

Velocity versus Velocity

Planning poker

Triangulation (triangulatie)

Triangulation board (triangulatiebord)

Affinity estimation (affiniteitsschatting)

Re-estimating (herschatten)

Ordenen van Product Backlog Items

Wat is de Value?

Hoe de Product Backlog te ordenen?

Value gerelateerd jargon

2.5.2 Artifact 2: Sprint Backlog

Onvoltooide items aan het eind van de Sprint

Alle items zijn gedaan in het midden van de Sprint

Bevroren versus dynamisch

Onvoltooid werk versus Velocity

2.5.3 Artifact 3: Increment

2.5.4 Definition of Done

2.5.5 Definiton of Ready

2.5.6 Projectprestaties bewaken

2.5.7 Sprintvoortgang bewaken

2.5.8 Information radiators

Burn-Down Chart

Burn-Down Bars

Burn-Up Chart

Cumulatieve flowdiagrammen

Niko-Niko kalender

2.6 Geschaalde Scrum

2.6.1 Rollen

2.6.2 Artifacts

2.6.3 Events

Sprint Planning

Daily Scrums

Sprint Reviews

Sprint Retrospective

3.   EXTREME PROGRAMMING

3.1 Pairing

3.2 Assignment (toewijzing)

3.3 Design (ontwerp)

3.4 Write test (schrijf de test)

3.5 Code

3.6 Refactoring

3.7 Integrate (integreren)

3.8 Go home (ga naar huis)!

3.9 Daily standup

3.10 Tracking (bijhouden)

3.11 Risk Management (risicobeheer)

3.12 Spiking

4.   DSDM®

4.1 Project Constraints (projectbeperkingen)

4.2 Vooraf plannen

4.3 Prioriteren met MoSCoW

4.4 Uitzonderingen

4.5 Zelforganisatie

4.6 Contractsoorten

5.   KANBAN EN SCRUMBAN

5.1 Kanban

5.1.1 Visualiseren

5.1.2 Limited WIP

5.1.3 Pull versus push

5.2 ScrumBut

5.3 ScrumBan

Nader K. Rad is auteur, spreker en adviseur over projectmanagement bij Management Plaza. Zijn carrière begon in 1997 en hij was betrokken bij veel projecten in verschillende industrieën. Hij heeft een groot aantal projectmanagementcursussen ontworpen, een aantal e-learningcursussen en hij heeft meer dan veertig boeken geschreven.

Nader is consultant en was een officiële recensent voor PRINCE2® 2017, PRINCE2 Agile®, P3.express en EXIN Agile Scrum Master™.

Meer over de auteur:

http://nader.pm

Website van de auteur:

https://mplaza.pm

LinkedIn profiel van de auteur:

be.linkedin.com/in/naderkrad

Frank Turley is al meer dan vijftien jaar projectmanager. Hij is een PRINCE2® Practitioner, een Scrum Master en een PRINCE2®- en projectmanagementtrainer en -coach. Hij heeft een aantal PRINCE2®- en projectmanagementgerelateerde boeken geschreven en is vooral bekend in de PRINCE2®-wereld vanwege zijn werk voor het creëren van het meest populairste PRINCE2®-zelfstudie trainingsmateriaal.

Meer over de auteur:

https://mplaza.pm/frank-turley/

Website van de auteur:

https://mplaza.pm

LinkedIn profiel van de auteur:

http://linkedin.com/in/frankturley

Als je doel met het lezen van dit boek is om iets te leren dat je in je projecten ten goede kan komen, moet je eerst twee cruciale dingen weten die meestal verkeerd worden begrepen:

1.   Wat je vaak hoort is: ‘Agile is een mindset.’ Het punt is dat Agile een mindset nodig heeft, net zoals al het andere. Maar het is onjuist om te zeggen dat het een mindset is. Zeggen dat ‘Agile een mindset is’ heeft slechts één praktisch gevolg: je bent erdoor in staat te werken zoals jij wilt. Noem het maar Agile zonder kritiek accepteren en zoeken naar verbeteringen.

2.   Als je een beetje bekend bent met de manier waarop autoritaire systemen werken, weet je dat ze altijd een vijand nodig hebben. Dit vijandsbeeld vult de gaten in het systeem en helpt de menigte onder controle te houden. Veel Agile aanhangers gebruiken het woord ‘Waterval’ om naar de vijand te verwijzen, terwijl deze nooit duidelijk gedefinieerd is. Zij impliceren dat het gaat om de gevestigde projectmanagementsystemen. Als je doel is om succesvolle projecten te realiseren, heb je de illusie van een externe vijand niet nodig. Bovendien moet je onthouden dat elk succesvol systeem boven op bestaande systemen gebouwd is in plaats van dat het helemaal opnieuw begonnen is. Hoewel kritiek absoluut noodzakelijk is, moet die met respect en kennis gegeven worden.

Laten we beginnen over de echte aard van Agile.

■ 1.1 PROJECTLEVERINGSMETHODE EN LEVENSCYCLUS

Wanneer je een stukje software ontwikkelt, worden de volgende stappen op een of andere manier uitgevoerd voor afzonderlijke functies, of voor de oplossing als geheel:

■   Analyseren

■   Ontwerpen

■   Construeren/bouwen

■   Integreren

■   Testen

Je kunt natuurlijk andere namen voor die stappen gebruiken, ze samenvoegen, in minder stappen opsplitsen, of in meer; dat is prima. Deze stappen kunnen ‘delivery (leverings)processen’ genoemd worden.

Nu is de vraag: hoe ga je deze processen organiseren en uitvoeren? Denk aan een paar opties voordat je de rest van dit hoofdstuk leest.

En? Hoeveel opties heb je bedacht?

Je hebt misschien veel opties in gedachten, maar ze behoren allemaal tot een van de twee generieke vormen. Overigens zijn deze opties de ‘ontwikkelingslevenscyclus’ (development lifecycle).

Ons algemene levenscyclusmodel is iets als dit:

In dit levenscyclusmodel is elke processtap voltooid voordat we naar de volgende gaan; dat wil zeggen dat wij eerst alle eisen compleet analyseren en dan pas beslissen wat we als oplossing willen hebben; dan ontwerpen we de architectuur van de oplossing en zoeken we uit wat de beste manier is om alle eisen en kenmerken te realiseren en vorm te geven. Vervolgens gaan programmeurs aan de verschillende onderdelen werken en daarna worden de verschillende onderdelen geïntegreerd in één oplossing en wordt de oplossing getest.

Het is duidelijk dat de stappen elkaar kunnen overlappen. Je hoeft bijvoorbeeld niet te wachten tot alle oplossingsonderdelen compleet zijn voordat ze worden geïntegreerd en getest. De levenscyclus kan er als volgt uitzien:

Dit is geen fundamenteel verschil met het voorgaande model, we hebben nog steeds een volgorde van ontwikkelprocessen als de belangrijkste factor voor de levenscyclus.

Zoals je ziet, is dit type levenscyclus gebaseerd op de gedachte dat we willen begrijpen wat we moeten gaan produceren. We hebben een upfront specificatie, een upfront ontwerp en bijgevolg een passend plan. Daarom noemen sommigen het een planningsgestuurde ontwikkeling. We proberen te voorspellen wat we willen en hoe het geproduceerd kan worden, en daarom heeft het de naam ‘voorspellend’. Voorspellende levenscycli zijn een normale en geschikte manier om veel projecten te ontwikkelen, zoals een bouwproject. Je plant en ontwerpt eerst en volgt vervolgens het plan. Dit is echter voor sommige soorten projecten geen prettige manier van werken.

Denk aan een typisch IT-ontwikkelingsproject. Je kunt veel tijd besteden aan het opgeven van de eisen en het analyseren ervan, en vervolgens al het andere hierop baseren. Wat gebeurt er nu? De klant zal niet altijd blij zijn als hij het resultaat ziet! Hij zal vragen om wijzigingen. Wijzigingen zijn duur in deze levenscyclus omdat je misschien al het voorgaande werk moet herzien.

In deze branche is het gebruikelijk dat de klanten pas weten wat ze willen als ze het product zien. Wanneer zien ze het product? Tegen het einde van het project. Op dat moment zijn de kosten om het product te veranderen maximaal.

Om dit probleem op te lossen, kunnen we het comfort en de structuur van een voorspellende levenscyclus opofferen en er een gebruiken die het product incrementeel maakt en in delen oplevert, dat wil zeggen in meerdere versies, elke keer met meer functies. Dit is een luxe die we in IT-ontwikkelingsprojecten hebben en die niet elk ander project heeft: meerdere versies van werkende software, telkens met meer functies. Denk aan een bouwproject: daar zijn geen zinvolle incrementele opleveringen voor. Het product kan pas op het einde worden gebruikt.

Om eerlijk te zijn, dit nadeel van een bouwproject weegt op tegen het feit dat als je een project start om een ziekenhuis te bouwen, het niet veel uitmaakt hoeveel veranderingen er zijn. Het eindresultaat zal een ziekenhuis zijn, en niet bijvoorbeeld een pretpark! Echter, in IT-ontwikkelingsprojecten zou je een project kunnen starten om zoiets als een ziekenhuis te maken en eindigen met zoiets als een pretpark.

We kunnen dus een incrementele levering krijgen in IT-ontwikkelingsprojecten. Dit biedt de kans een levenscyclus te gebruiken als deze:

Er is geen echte voorspelling voor het eindresultaat in deze levenscyclus. In plaats van het eindproduct te voorspellen en daarop te vertrouwen hebben we korte perioden (iteraties) waarin we incrementen (delen) van het product maken. Wij laten de incrementen (de laatste versie van het product) aan de klant en de eindgebruikers zien, ontvangen hun feedback en beslissen wat te doen in de komende periode. Dus in plaats van te voorspellen, gaan we afhankelijk van de incrementen door met het project en gebruiken telkens de feedback. Hoe zou je deze levenscyclus willen noemen? ‘Adaptief’ is een geweldige naam: adaptieve levenscyclus.

Voor elke increment doorlopen we alle ontwikkelingsprocessen in de tijdsperiode die nodig is voor het maken van die increment. In de volgende periode herhalen we deze processen: we itereren. Dat is de reden waarom deze methode van ontwikkeling soms iteratieve ontwikkeling genoemd wordt. De tijdsperioden waarbinnen we itereren kunnen ‘iteraties’ worden genoemd. Dit is niet de enige naam die daarvoor wordt gebruikt; je weet mogelijk al minstens één andere naam voor iteraties. We komen verderop terug op dit onderwerp.

■ 1.2 VOORSPELLENDE VERSUS ADAPTIEVE LEVENSCYCLUS

De voorspellende en adaptieve levenscycli hebben elk voor- en nadelen. De juiste keuze is afhankelijk van vele factoren, maar de belangrijkste is de aard van het product. Je kunt twee essentiële vragen stellen voordat je beslist welk type levenscyclus je nodig hebt voor je project:

1.   Moet ik adaptief zijn? Want als dat niet nodig is, gaat het om een voorspellende levenscyclus! Die is eenvoudiger en gestructureerder. Een adaptief systeem is nodig als er een risico is dat je begint met het idee om zoiets als een ziekenhuis te bouwen en eindigt met zoiets als een pretpark.

2.   Kan ik adaptief zijn? Deze vraag is nog belangrijker. Om adaptief te zijn, moet je de mogelijkheid hebben om iteratief te ontwikkelen en incrementeel op te leveren. Laten we nogmaals een bouwproject beschouwen: Kun je het gebouw iteratief ontwerpen? Kun je de constructie van een gebouw ontwerpen zonder de rest van het gebouw te ontwerpen die bepaalt wat de belasting op de constructie is? Het antwoord is simpelweg nee! Het is niet mogelijk om bouwprojecten iteratief te ontwikkelen. Ook is incrementele oplevering niet mogelijk, zoals we eerder hebben besproken. We kunnen dus geen adaptieve levenscyclus gebruiken om een gebouw te bouwen (verwar dit niet met interieurontwerp en decoratie, of zelfs met renovatie, waarvoor we mogelijk wel een adaptief systeem kunnen gebruiken).

Mijn belangrijkste boodschap is dat voorspellend versus adaptief geen kwestie is van goed of kwaad. Als kleine oefening: denk aan een IT-project voor het upgraden van de besturingssystemen van driehonderd computers in een organisatie, of een IT-project voor de ontwikkeling van een netwerkinfrastructuur voor een zeer grote organisatie met kantoren op zes locaties. Welke ontwikkelingscyclus is naar jouw mening het geschiktst voor deze twee projecten?

■ 1.3 AGILE VERSUS WATERVAL

‘Agile’ is de populaire naam voor systemen die de adaptieve levenscyclus gebruiken. Dat is hoe je Agile echt kunt definiëren, in plaats van te zeggen: ‘Agile is een mindset’! Agile ‘fans’ gebruiken het woord Waterval om naar een voorspellende levenscyclus te verwijzen. Dan gebeurt dat vaak om te verwijzen naar een voorspellende levenscyclus in IT-projecten; je hoort mensen niet zeggen: ‘Dit gebouw is gebouwd met behulp van een Watervalmethode.’ Om er zeker van te zijn dat je alles weet als het gaat om terminologie, moet je je ervan bewust zijn dat het woord Waterval tegenwoordig praktisch een vloekwoord binnen de IT is, en je het recht hebt om je boos en beledigd te voelen als iemand je vertelt dat je Waterval gebruikt! Dat is waarom ik voorstel de meer formele naam in dit boek te gebruiken: ‘voorspellende levenscyclus’.

■ 1.4 IS AGILE NIEUW?

Agile wordt meestal geadverteerd als het nieuwe. Het gebruik van de term ‘Agile’ om te verwijzen naar de adaptieve levenscyclus is zeker nieuw, maar hoe zit het met de levenscyclus zelf?

Ik weet niets over jou, maar ik kan me moeilijk voorstellen dat veel projecten en programma’s in de menselijke geschiedenis niet met enige vorm van een adaptieve levenscyclus zijn uitgevoerd. Kun je een voorbeeld bedenken?

Ik kan je er een geven. Denk aan een zeer populair initiatief (een project of programma) van vroeger (althans in het westen): oorlog voeren. Kun je een oorlog met een voorspellende aanpak managen? Waarbij alles in het begin gepland en ontworpen wordt? Zeker niet. Je hebt misschien een plan op hoog niveau dat meer lijkt op een strategie dan op een plan, maar waarschijnlijk manage je de oorlog op één slagveld (een iteratie) tegelijkertijd (of op een paar tegelijk) en pas je op basis van het resultaat van elk gevecht de rest van het initiatief aan.

Geen prettig voorbeeld, maar een duidelijk voorbeeld waaruit blijkt dat adaptieve levenscycli niet nieuw zijn.

Wat is er dan nieuw?

Op een bepaald moment in de historie werden de zogenaamde ‘wetenschappelijke managementbenadering’ en het ‘taylorisme’ de norm, zozeer zelfs dat elke andere benadering als inferieur en zelfs verkeerd werd ervaren. Taylorisme was volledig en sterk gebaseerd op voorspellende systemen; daarom domineerden voorspellende systemen de hele wereld, om zo te zeggen.

Toen bereikten we de tijd dat steeds meer IT-ontwikkelingsprojecten werden geïnitieerd, en voorspellende levenscycli waren niet echt de beste manier om deze projecten te managen. Mensen probeerden het te tolereren, terwijl de druk toenam, tot er demonstraties en uiteindelijk revolutie van kwam! Zoals elke andere revolutie, verslindt deze zijn kinderen, maar dat is een onderwerp voor een andere keer.

■ 1.5 HET AGILE MANIFESTO

Sommige mensen begonnen adaptieve systemen te gebruiken voor IT-ontwikkeling en geleidelijk aan structureerden ze deze in herhaalbare managementprocessen. Een groep van deze pioniers kwam in 2001 samen om het nieuwe systeem officieel te maken door het een naam te geven en daarvoor een manifesto op te stellen.

Laten we beginnen met de naam. Zoals de legende zegt, waren de twee laatste opties daarvoor ‘Agile’ en ‘Adaptief’. Helaas was hun beslissing Agile. Adaptief zou veel beter zijn omdat dit de aard van de aanpak beschrijft en dat voorkomt veel misverstanden.

Dus het Agile Manifesto, dat beschikbaar is op de zeer geavanceerde en moderne website van AgileManifesto.org, is dit:

Wij laten zien dat er betere manieren zijn om software te ontwikkelen door het te doen en door anderen ermee te helpen. Daarmee komen we tot de volgende waardestatements:

mensen en hun onderlinge interactie

boven

processen en tools

werkende software

boven

allesomvattende documentatie

samenwerking met de klant

boven

contractonderhandelingen

inspelen op verandering

boven

het volgen van een plan

Dat wil zeggen dat hoewel de items aan de rechterkant waardevol zijn, wij toch aan de items aan de linkerkant meer waarde hechten.

Kent Beck

Mike Beedle

Arie van Bennekum

Alistair Cockburn

Ward Cunningham

Martin Fowler

James Grenning

Jim Highsmith

Andrew Hunt

Ron Jeffries

Jon Kern

Brian Marick

Robert C. Martin

Steve Mellor

Ken Schwaber

Jeff Sutherland

Dave Thomas

© 2001, de bovenstaande auteurs. Deze verklaring mag in elke vorm, maar alleen in zijn geheel als mededeling vrij worden gekopieerd.