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