Lets build something Extreme Software Engineering

Tobias Kuipers Software Improvement Group 2001 Reasonably large project Not too hard
Administrative

Lets implement WSF 18+ Studiefinanciering!

Project WSF
Plan Different tasks
Architect Analyst
Technical Functional Datamodel

Develop a plan
Overview Functional subsystems
Business Logic (The law)

Domain Expert (Lawyer?) Project Manager

Technical subsystems Datamodel Functional design Technical design

A Year Later
(or more?) The project has been split up in parts Hire some programmers Hire some DBAs Buy the iron Hire the ops guys

Go build it
Now, its just a matter of time Small parts all scheduled Total time = parts + integration Go home, come back when schedule tells you its finished. Go 1.0

Done
Any questions?

Problems
Its not finished Integration is a bitch Its not what the customer wanted Its too slow It cant handle the volume The world has changed

Technical details
Design
Functional / Technical

No customer involvement
Requirements at start of project Project staff spends year/year
planning/development

Software development
Programming

No feedback from customer

Who didnt actually know what he wanted in the first place

A million tiny decisions needed

Not in the design

Big bang integration

Interfaces well defined?
Yes? Code probably complex No? Youre dead

XP Executive Summary
Software Engineering Trouble
Schedule Slips Project canceled Defect rate Business Misunderstood Business Changes False Feature Rich

Functionality of subsystems slightly off

Build integration ok Test integration fails

Now what?

XP Executive Summary
XP Solutions
Schedule Slips
Short cycles - Release, Iteration, Task

XP Executive Summary
Business Changes
Short cycle, functionality substitution

False Feature Rich

Highest priority features only

Project canceled
Choose smallest release that makes sense

Defect rate
Both programmers & customers test

Business Misunderstood
Customer is part of development team

Four Variables
Cost Time Quality Scope

Four Values
Communication
Problems originate at not talking

Simplicity
Do the simplest thing that can possibly work

Feedback
Measure. Always have a running system

Courage
Throw stuff away. Try alternatives.

Cost of Change
Simple Design, no extras Automated tests - confidence Lots of practice modifying Example change
start of project: few minutes 2 years production: 30 minutes

XP Practices
Planning Game Pair Programming Simple Design Collective Ownership Continuous Integration

XP Practices contd
Coding Standards Refactoring Testing Customer on Site 40 hour week Facilities

Environment
Lots of space, encourage interaction

Business
Tells you what to do

Tech
Wants cool tools and hardware

Planning Game
Exploration
Write story Estimate story (in Ideal Engineering Time) Split story

Planning Game contd

Steering
Iteration (pick stories for one iteration) Recovery (if slow, reset stories for iteration) New story (replace old story with same est.) Reestimate (all remaining stories & velocity)

Commitment
Sort by value (business) Sort by risk (development) Choose scope

Development Strategy
Continuous Integration
no code unintegrated for more than couple hours

Design Strategy
Simplest thing that could possibly work
tomorrow may never come learn a better way between now and later

Collective Ownership Pair Programming

System must communicate everything Contains no duplicated code Fewest possible classes Fewest possible methods

XP Life cycle
Exploration
preproduction

Roles
Programmer
communication, simplicity acknowledge your fears

Planning Iterations to first release Productionizing

Make it run, make it right, make it fast

Customer
"This is more important than that"

Tester
Not a separate person, just someone who runs the test regularly

Maintenance Death

Roles (Cont'd)
Tracker
conscience of team log, provide loop in feedback-loop

Roles (Cont'd)
Consultant
Show how it's done, then watch your code being shredded

Coach
Responsible Make team see what you see (suggest test rather than fix)

Big Boss
Be confident Trust the answers you get from the team They're not whining

20-80 rule
80% of benefit comes from 20% work So first put most valuable 20% of functionality in production

XP is hard
It's simple, but not easy Balance is everything Collaboration is hard

When you shouldn't XP

Big specification Long hours Size of project Technology
Mainframe system where you cant change the db schema

Wrong physical environment

two floors? Forget it!

By giving up explicit preparation for change, paradoxically the team become entirely prepared for any change

Thanks