agile software development in theory and practice johannes brodwall

Agile Software Development

In Theory and Practice

Johannes Brodwall

Copyright 2004 – Johannes [email protected]

Slide 2

Who am I?


Slide 3

Johannes Brodwall


Slide 4

Board member, smidig.no

http://smidig.no/forum/




Slide 5

Organizer,

Oslo XP Meetup

Every first Monday of the month at Scuba bar (Grünerløkka)

http://xp.meetup.com/13/




Slide 6

Lead Software Architect


Slide 7

Sole developer

Small chat solution


Slide 8

Who are you?


Slide 9

Who works on ”a large project”?


Slide 10

Who works on (what you feel is) ”a large project”?


Slide 11

Who release software infrequently?


Slide 12

(0)


Slide 13

Intro


Slide 14

Course in an agile method

Extreme programming

Scrum

Lean Software Development

DSDM


Slide 15

Course in an agile method

Extreme programming

Scrum

Lean Software Development

DSDM


Slide 16

History lesson

SnowbirdAgile Manifesto

We value

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan


Slide 17

History lesson

SnowbirdAgile Manifesto

We value

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan


Slide 18

Specific for Perl

Test::MoreDevel::Refactor

JiftyPerlActor

Tinderbox


Slide 19

Specific for Perl

Test::MoreDevel::Refactor

JiftyPerlActor

Tinderbox


Slide 20

Experience report on using agile techniques in small and large environments

Continuous Integration

Relentless Testing

Frequent releasesCollective Ownership

Refactoring


Slide 21

Experience report on using agile techniques in small and large environments


Relentless Testing

Frequent releasesCollective Ownership

Refactoring


Slide 22

(1)


Slide 23

The Problem


Slide 24

Projects in crisis


Slide 25

Failure to deliver value


Slide 26

Barry Boehm: ”Software Engineering Economics”, 1984


Slide 27

”An infant engineering discipline”


Slide 28

(2)


Slide 29

The Response


Slide 30

”

”Make sure the reqs are right before you do anything”


Slide 31

”

”Make sure nobody changes the requirements”


Slide 32

”

”Try Harder!”


Slide 33

BRUF


Slide 34

”

BigRequirementsUpFront


Slide 35

(Picture: RUP analyst hard at work)


Slide 36

Trying to stuff everything into my small head!

It hurts!


Slide 37

And then the world changes!


Slide 38

When I guessed wrong...


Slide 39

... my work is wasted


Slide 40

... it is even harder to change the system


Slide 41

Speculation breeds complexity


Slide 42

Complexity breeds complexity


Slide 43

And again....

.. my crystal ball

is broken!!!


Slide 44

So I get a poorly divided, rigid design


Slide 45

Formality:


Slide 46

make decision ”correctly”


Slide 47

The right decision


Slide 48

Change control mechanism


Slide 49

Just-in-case requirement

(”free” in the beginning)


Slide 50

Failure to deliver value


Slide 51

These ”solutions” are part of the problem


Slide 52

Fixed-price, fixed-scope contract bids


Slide 53

(3)


Slide 54

The Alternative


Slide 55

Instead of just-in-case...


Slide 56

... just-in-time


Slide 57

Boehm was wrong


Slide 58

(or at least Boehm’s phasist readers)


Slide 59


Slide 60


Slide 61

Harness the Power of Myopia


Slide 62

1... 2... 3...


Slide 63

1. Focus on short term


Slide 64

Requirements for current feature


Slide 65

Design for current requirement


Slide 66

2. Deliver something


Slide 67

Ideal: Deliver working, tested features as often as you safely can


Slide 68

3. Get feedback


Slide 69

(talk to people!)


Slide 70

4. Adapt


Slide 71

Get Feedback

Avoid Speculation


Slide 72

The cost of speculation


Slide 73

Myopic requirements


Slide 74

Analyse the current release


Slide 75

Myopic development


Slide 76

Design for the current problem


Slide 77

Myopic programming


Slide 78

Write a test – make it pass – Remove duplication


Slide 79


Slide 80

(4)


Slide 81

Changing your minds


Slide 82

... is not always easy


Slide 83

... is not always safe


Slide 84

(painted into a corner)


Slide 85

(Experience: Sustainable myopia varies with org.)


Slide 86

Agile: Enabling safe myopia


Slide 87

Not technology


Slide 88

Practices, discipline, communication


Slide 89

1. Prioritize requirements with a backlog


Slide 90

Prioritize requirements with a backlog


Slide 91

(NB: Software maintainance)


Slide 92

Too fully take advantage: Close communication with

stakeholders


Slide 93

2. Simple design: Goal and means


Slide 94

Avoid designs that make change expensive:

Don’t Repeat Yourself!


Slide 95

For example: Jifty


Slide 96

Solve the current problem only


Slide 97

3. Automated regression suite


Slide 98

Test::Simple

Test::More (Schwern)


Slide 99

4. Refactor all the time


Slide 100

Def: Refactor“To transform a program while

preserving its behavior.”


Slide 101

Refactor to simple design


Slide 102

5. Continuous Integration


Slide 103


Slide 104

6. Collective Ownership


Slide 105

It’s not: ”Your code and mine code”


Slide 106

Refactor everything


Slide 107

Continous integration keeps you safe


Slide 108

(5)


Slide 109

Fine tuning your agile process


Slide 110

Deliveries


Slide 111

Large organization Less frequent releasesHigh risk Less frequent releases


Slide 112

Staged (internal delivery)


Slide 113

Breaking it up


Slide 114

”The smallest meaningful task”


Slide 115

Small releases: Penalizes half-work


Slide 116

One click deployment


Slide 117

Extreme: Deploy every feature


Slide 118

Mastering Testing


Slide 119

”Only test what you want to work”

-- Ron Jeffries


Slide 120

Many types of test

Acceptance test

Databases

User interfaces

Integration tests

Unit test

Performance/Load/Stress


Slide 121

All can be automated


Slide 122

Greatest value: Acceptance tests


Slide 123

Easiest to implement: Unit tests


Slide 124

Starting unit testing:


Slide 125

Don’t


Slide 126

Try to test everything in the beginning


Slide 127

Do:


Slide 128

Focus on ”bang for the buck”


Slide 129

Good: New features


Slide 130

Better: Bugs


Slide 131

Even better: Bug ridden code


Slide 132

Smoke test

Def: ”A rudimentary form of testing; power is applied and the tester checks for sparks,

smoke, or other dramatic signs of fundamental failure”


Slide 133

Perfecting unit tests


Slide 134

Remember: Test is a noun!


Slide 135

Tests as specification


Slide 136

Write tests first


Slide 137

Consider test brittleness


Slide 138

Consider unit test running time


Slide 139

Implementing Continuous Integation


Slide 140

Avoid sliding back


Slide 141

Not useful in small projects (1-3 people?)


Slide 142

Can at least scale to 50 people


Slide 143

Be prepared to pay the price


Slide 144

Continuous Integration will become critical to you org.


Slide 145

Has given us the ability to do enormous refactorings


Slide 146

Has enabled us to treat 500 KLOC as one code base


Slide 147

Communication


Slide 148

What is the biggest cost driver?


Slide 149

Misunderstandings


Slide 150

Misunderstood business needs


Slide 151

Misunderstood interface to integrate with


Slide 152

Misunderstanding your neighbours code


Slide 153

Not knowing that you neighbour is doing the same

as you!


Slide 154

Techniques:


Slide 155

Keep your customer close


Slide 156

Obvious, difficult(But if the customer won’t be close, how

important is the project, really?)


Slide 157

Pair programming


Slide 158

Fun, difficult, rewarding, exhaustingHard to sustain (but great if you

can!)


Slide 159

Stand up meetings


Slide 160

• ”What did you achieve since yesterday?”• ”What do you plan on achiving today?”

• ”What is standing in your way?”


Slide 161

Keep it short!


Slide 162


Slide 163

Keep it short!


Slide 164

Fun, easy, rewardingExhausting (if you don’t do it right!)


Slide 165

Reflection workshops


Slide 166


Slide 167

Fun, easy, rewardingValue decreases with time


Slide 168

(6)


Slide 169

Conclusion


Slide 170

Phasist development...


Slide 171

Forces us to guessForces us to consider a too

much at the same time


Slide 172

... leads to suffering


Slide 173

(and our poor reputation as professionals)


Slide 174

When I speculate, I’m usually wrong


Slide 175

So instead...


Slide 176

1. Short-term decisions


Slide 177

2. Deliver something


Slide 178

3. Get feedback


Slide 179

4. Adapt


Slide 180

(requires practices and tricks)


Slide 181

Summary of tricks


Slide 182

Prioritize with a backlog


Slide 183

Keep in touch with stand-up meetings


Slide 184

Just-in-time planning and requirements


Slide 185

Simple design


Slide 186

Test only what you want to work


Slide 187

Refactor mercilessly


Slide 188



Slide 189

Parting words


Slide 190

Software isn’t a canned good


Slide 191

It rots during storage


Slide 192

Good luck with your agile project!


Slide 193

Thank you for listening

http://smidig.no/forum/http://xp.meetup.com/13/




agile software development in theory and practice johannes brodwall

Documents

plan slide

com13 slide

intro slide

noforum slide

problem slide

lead software architect

agile software development

agile techniques