wie ben ik? agile software developmentmvdbrand/courses/se/0708/slides/college... · 2008-03-04 ·...

1

Agile Software Development

Februari 2008, Philippe Dirkse

Wie ben ik?

• 2002:Afgestudeerd TU/e

• 1999 - 2005: Mondo Bizzarro, Crystal Interactive,Siemens Atea

• 2005 – heden:PTS: Leica Microsystems

SES/MiPlaza

Inhoud

• Traditionele ontwikkeling/waterval

• Agile

• Scrum

• XP

• (cases)

Het waterval model

Fouten die in een vroegtijdig stadium

van het ontwikkelproces worden

gevonden zijn vele malen goedkoper

(qua tijd en inzet) op te lossen, dan

wanneer ze later aan het licht komen

2

Het waterval model

Onderhoud

Validatie

Implementatie

Ontwerp

Eisen • Iedere fase dient 100% compleet te zijn

• Iedere fase dient 100% correct te zijn

• Iedere fase wordt geborgd in een

document dat als uitgangspunt voor de volgende fase dient

Het waterval model

• De klant die van te voren precies weet wat

hij hebben wil moet nog geboren worden

• Het ontwerp dat 100% alle problemenafdekt die je tijdens het implementeren

tegen gaat komen moet nog gemaakt

worden

Feiten:

• De verkeerde software wordt gemaakt

• Onjuiste documentatie

• De klant is niet tevreden

Gevolgen:

3

• Features worden niet toegevoegd op basis van prioriteit

• Schatting is commitment

• Er wordt geen gebruik gemaakt van hetgeen we leren TIJDENS het project

Oorzaken: “Agile”

• Gebruik hetgeen je leert tijdens het proces

om het proces te verbeteren

• Geef de klant eerlijke informatie

gedurende het proces

• Lever gedurende het proces continu

werkende code op aan de klant

• Stel jezelf open voor de veranderende

wensen van de klant

Agile Manifesto

• Individuals and interactions over processes and

tools

• Working software over comprehensive

documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile methoden

• eXtreme Programming

• Scrum

• Crystal Clear

• Adaptive Software Development

• Feature Driven Development

• Agile RUP

• …

4

Agile methoden

• eXtreme Programming

• Scrum

• Crystal Clear

• Adaptive Software Development

• Feature Driven Development

• …

XP @ SCRUM

Scrum rollen

Klant

• Bepaalt de prioriteiten

• Bepaalt de business value

• Spreekt met één stem

• Is beschikbaar

Team

• Zelf-organiserend

• Implementeert de business value, bepaalt de kosten

• Kan te allen tijde werkendesoftware demonstreren

Scrum master

• Houdt het proces in de gaten (vorderingen, vertragingen, blokkades)

• Maakt het proces inzichtelijk (bijhouden scrum board, backlog)

User Stories

Als … (belanghebbende)Wil ik … (requirement)Zodat ik … (rechtvaardiging)

Schrijf IEDERE requirement op als een user story

User Stories

Als spelerWil ik een hiscores lijstZodat ik kan zien welke de te verslanescore is

Schrijf IEDERE requirement op als een user story

5

User Stories

Als spelerWil ik een hiscores lijstZodat ik kan zien welke de te verslanescore is

Schrijf bij iedere user story een acceptance test

Als het spel is afgelopen verschijnt ereen tabel met daarin de 10 beste scores plus de namen van de bijbehorendespelers

……

221000Jantje

ScoreNaam

User Stories

Als spelerWil ik een hiscores lijstZodat ik kan zien welke de te verslanescore is

Schrijf bij iedere user story een schatting

24

Schatten

• Schatten is moeilijk, zeker in het begin,

ga er dus van uit dat je er naast kan zitten

• Schat in story points:

“deze taak is 2x zoveel werk als die”

• Indien nodig, pas de schattingen aan

• Alleen het team doet de schatting,

LAAT NOOIT DE KLANT MEEDOEN

Planning poker

• Ieder teamlid krijgt een set kaarten met

story points

• Per user story legt iedereen afgedekt zijn

schatting neer

• Draai tegelijkertijd de kaarten om en

bespreek de verschillen

6

Backlog

• Lijst met alle op dit moment bekende user

stories

• Geprioritiseerd door de klant

• Variabel: stories kunnen wordentoegevoegd en verwijderd

• Filter: minder belangrijke stories zinken

naar de bodem

Sprint

• Korte periode (1-3 weken)

• Begint met een sprint planning meeting

• Eindigt met een demonstratie van de

afgeronde user stories

Sprint planning meeting

• Klant kiest de user stories uit die hij op dit

moment het belangrijkste vindt

• Team geeft aan hoeveel van deze user

stories ze in de komende sprint denken te

kunnen realiseren

Velocity

• De velocity van een sprint is de som van

de story points van alle user stories die in

die sprint zijn afgerond

• Gebruik de gemiddelde velocity van een

aantal sprints als basis voor hoeveel user

stories er in een iteratie passen

• Gebruik de velocity om de voortgang van

de sprint te bepalen

7

Burn down chart

1 2 3 4 5 6 7 8 9 10

15

10

5

Velocity van dezeiteratie is 14

Velocity van de vorige

iteratie is 15

Daily standup meeting

• Vaste tijd, vaste plek

• Maximaal 15 minuten, iedereen staat

• Iedereen is welkom, maar alleen team

spreekt

• Ieder teamlid vertelt:

• Wat heb ik gisteren gedaan?

• Wat ga ik vandaag doen?

• Zijn er blokkades?

Scrum

backlog

24 h

softwareincrement

sprintbacklog

sprint

1-3 wk

Scrum board

8

Scrum board

To Do In Progress Done Burn down

Backlog

AAAAAA

Scrum board

To Do In Progress Done Burn down

Backlog

AAD

C

BA

Scrum board

To Do In Progress Done Burn down

Backlog

AAD

C

B A

Scrum board

To Do In Progress Done Burn down

Backlog

AAD

C

B A

9

Scrum board

To Do In Progress Done Burn down

Backlog

AAD

C

B A

Scrum board

To Do In Progress Done Burn down

Backlog

AAD

C

BA

Scrum board

To Do In Progress Done Burn down

Backlog

AAD

C

BA

Scrum board

To Do In Progress Done Burn down

Backlog

AAD

C

BA

10

Scrum board

To Do In Progress Done Burn down

Backlog

AAD

C

B A

Scrum board

To Do In Progress Done Burn down

Backlog

AAD

C

BA

eXtreme Programming

• Als code reviewen goed is, doe het dan altijd

• Als testen goed is, doe het dan altijd

• Als ontwerpen goed is, doe het dan altijd

• Als integreren goed is, doe het dan altijd

Pair Programming

ALLE productiecode

(dus niet alleen de moeilijke dingen)

wordt door

2 PROGRAMMEURS

SAMEN

gemaakt

11

Pair Programming

SAMEN is nietZZZ…

Pair Programming

SAMEN is

• Algoritme• Ontwerp• …

• Syntax• Tests• KISS/YAGNI•…

Pair Programming

• Kennisdeling

• Kennisoverdracht (junior/senior)

• Minder fouten

• Hogere kwaliteit code

• Meer plezier!

=

Test Driven Development

ALLE productiecode

die stuk kan gaan

MOET getest worden

12

• Test een beetje, codeer een beetje

(red->green->refactor)

• Houdt de tests kort maar bondig

(5 minute build)

• Gebruik een framework: jUnit, nUnit,

cppUnit, yaffut, …

Unit testing Continuous build

Test Driven Development

Mini case: Stack class

Test Driven Development

RED [Test]

void NewStackHasSize0()

{

Stack<int> stack = new Stack<int>();

AssertEqual(0, stack.Size);

}

13

Test Driven Development

RED

GREEN

public class Stack<T>

{

private int size = 0;

public int Size {get{return size;}};

}

Intermezzo

Refactoring

• Verbeteren van de leesbaarheid van code

• Verbeteren van de begrijpelijkheid van code

• Vereenvoudigen van het ontwerp

Verbeteren van de structuur van de code met behoud van functionaliteit en zonder fouten te introduceren

Test Driven Development

RED

GREEN

REFACTOR

public class Stack<T>

{

private int size = 0;

public int Size {get{return size;}};

}

Test Driven Development

RED [Test]

void NewStackHasSize0()

{

Stack<int> stack = new Stack<int>();

AssertEqual(0, stack.Size);

}

[Test]

[ExpectedException(typeof(Exception))]

void CannotPopFromEmptyStack()

{

Stack<int> stack = new Stack<int>();

stack.Pop();

}

GREEN

REFACTOR

RED

14

Test Driven Development

RED

GREEN

REFACTOR

RED

GREEN

public class Stack<T>

{

private int size = 0;

public int Size {get{return size;}};

public void Pop()

{

if( size == 0 )

{

throw new Exception(“Empty”);

}

}

}

Test Driven Development

RED

GREEN

REFACTOR

RED

GREEN

public class Stack<T>

{

private int size = 0;

public int Size {get{return size;}};

public void Pop()

{

if( size == 0 )

{

throw new Exception(“Empty”);

}

}

}REFACTOR

GREEN

REFACTOR

RED

GREEN

REFACTOR

Test Driven Development

…

[Test]

[ExpectedException(typeof(Exception))]

void CannotPopFromEmptyStack()

{

Stack<int> stack = new Stack<int>();

stack.Pop();

}

[Test]

void PushOntoStackIncreasesSize()

{

Stack<int> stack = new Stack<int>();

stack.Push(3);

AssertTrue(1, stack.Size);

}

RED

REFACTOR

RED

GREEN

REFACTOR

RED

Test Driven Development

public class Stack<T>

{

private int size = 0;

public int Size {get{return size;}};

public void Pop()

{

if( size == 0 )

{

throw new Exception(“Empty”);

}

}

public void Push(T value)

{

++size;

}

}

GREEN

15

RED

GREEN

REFACTOR

RED

GREEN

REFACTOR

Test Driven Development

public class Stack<T>

{

private List<T> list = new List<T>();

public int Size

{ get { return list.Count; } }

public void Pop()

{

if( Size == 0 )

{

throw new Exception(“Empty”);

}

}

public void Push(T value)

{

list.Add(T);

}

Test Driven Development

• Code veranderen zonder angst

• Beter ontworpen code

• Begrijpelijkere code

• YAGNI

=

Collective Code Ownership

IEDEREEN

kan TE ALLEN TIJDE

IEDERE regel code aanpassen

Wachten…

Change Request

Group Manager

Change Owner

Change Review

Management approval

Implementation

16

Wachten…

• Het Change Request proces kan dagen in

beslag nemen

• Change Requests kunnen verkeerd

begrepen worden

Of erger…

• De verantwoordelijke kan niet (meer)

beschikbaar zijn

• Iemand kan een Change Request voor

JOUW code indienen!

Own everything!!!

• Geen wachten of discussies

• (vooraf)

• Meer kennis van de code

• Veiligheid dankzij unit tests!!!

Collective code ownership

• Spreek een coding standard af

• Ondersteunend versie beheer systeem

Geen locks maar mergen (CVS,

SubVersion,…)

17

Continuous Integration

IEDEREEN

dient MEERDERE malen per dag

zijn code te INTEGREREN

Continuous Integration

• Rond een taak af

• Draai unit tests

• Integreer

Continuous Integration

• Hoe langer je wacht met integratie, hoe

moeilijker het wordt, dus:

• Codeer

• Merge / Test / Integreer

• Commit

XP samengevat

• Iedereen is eigenaar van alle code

• Regelmatig wisselende pair programmers

• Eén pair werkt aan één taak

• Eerst de testen schrijven, dan pas de code

• Integreer de code

• Draai de unit tests (100%!!!)

• Commit