eXtreme Programming Fad, Fall-back or Fail-safe Focus? Fast Defect-Free Software Delivery! Ian Mitchell [email protected] http://www.xp.co.nz.
Download
Report
Transcript eXtreme Programming Fad, Fall-back or Fail-safe Focus? Fast Defect-Free Software Delivery! Ian Mitchell [email protected] http://www.xp.co.nz.
eXtreme Programming
Fad, Fall-back or Fail-safe Focus?
Fast Defect-Free Software Delivery!
Ian Mitchell
[email protected]
http://www.xp.co.nz
SW Delivery - What do we want?
Implement the business processes
Deliver to “expectations”
User-friendly, “Intuitive”, Just how I would do it!
Reliable software - Defect-free
On Time delivery
Within budget
Future proofed.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
Software Development
Failures
70% of projects result in failure (legal letters)
70% of these are not technology problems
But are change management or communication
problems!
Can we continue with methodologies with a
rd
chance of success of less than 1/3
?
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
“Old Economy”
We know what we are doing – ‘cause we
have done it a 1000 times before
Give our really bright programmers detailed
specifications and they will do exactly what
they are told (they won’t need to think!)
We managers cannot learn much useful
from geeks (Programmers don’t know anything about business!).
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
“New Economy”
I have not been here before
There are no roads on my map
Hey, I’m off the map!
Where are:
–
–
–
–
the deserts (there is nothing there)
the uncrossable ravines (we cannot go forward)
the wild gorillas (what will get us out there?)
the swamps? (Will we catch a disease?)
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
How to cross new territory!
Set strategic goals
Take short day marches
– Record every thing you do
– Make sure at least 2 people are familiar with the route
Look around – what can you see?
Make a decision about where to go tomorrow
Check against our strategic goals.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
Some people say . . .
Develop software iteratively
Manage requirements
Use component-based architecture
Visually model software
Verify software quality
Control changes.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
But we say . . .
Develop software incrementally
Review requirements after every small step
Deliver small incremental components into
production every three weeks
Don’t visualise - See the real thing
Build in and prove it is defect free
Review all requests every three weeks.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
To effect change . . .
Hit
the block . . .
Admit the way we do it is not working
Seek another way
Try another way
If it works . . .
Embed it as OUR way.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
Common Sense
to the Extreme!
Everybody will design every day
System will always be the simplest possible
Review code all the time
Test all the time
Define and refine architecture all the time
Integrate and test several times a day
Iterate every hour; deliver every day.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
What is XP?
Early, concrete and continuing feedback to the
user in short cycles
Incremental planning all the time
Flexible implementation schedule responding to
business needs
Automatic tests to allow customers to monitor
progress
Communication: Oral, tests, source code
Evolutionary design!
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
XP in Short
User Stories
The Planning Game
Small Releases
Metaphor
Simple Design
Test every case
Refactoring
Tuesday, 24 April 2001
On-site customer
Pair programming
Coding Standards
Collective Ownership
Continuous
Integration
40-hour week.
Confidential to Ian Mitchell, FNZCS
Basic Attitudes
Rapid Feedback
Assume simplicity
Incremental change
Embracing change
Quality work
Plus . . .
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
Four Values
Communication – user management to coders
Simplicity
Feedback
Courage.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
Secondary Principles
Teach learning
Small initial investment
Play to win
Concrete experiments
Open, honest communication
Work with people’s instincts, not against them
Accepted responsibility
Local adaptation
Travel light
Honest measurement.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
Managers must:
Make
IT happen
Co-ordinate
Report
Reward.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
My Experience (Large package)
Hit the Block (1m lines of code)
Integration tests repeatedly fail
– 3 tier – DB Mtce, SQL procs, COM objects, actual code
– Multiple environments – Unix, Novell, MS 3.1,98,Me
Brilliant code does not “fit” anymore
Cannot locate impact of a change
Bottleneck in the general admin program
Bottleneck: stored procedures, WISE, Documentation
Surfacing n-tier deep error messages.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
My Solution
Break code into separate applications & “core”
– Redesign Build scripts – 3 weekly releases
Coding
–
–
–
–
–
–
Inspection – Pre/Post-assertion
Standards and style guides
Best practice Friday sessions
Test harnesses
Coverage and performance tests
Paired programmers
Feature “razor”.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
One pair in One day
Whiteboard with user; get the Story right, Design
code unit, split into tasks, volunteer to deliver
Write Face – Pre/post-assertions
–
–
–
–
Write 50 lines of code
Write 50 lines of test harness
Inspect
Test including Coverage and Performance
Iterate for each test case – each path thru code
Show user the tests that day.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
Other Coding Practices
As soon as Face is executable
–
–
–
–
–
Move to repository
Integrate
Build
Document
Pass to QA
Release to team
Part of next customer release.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
Six is Too Many!
Project versus team size – 6 pairs plus
documentation editor plus QA (2) plus Build Script controller plus
Install Script controller
Time in communication
If team requires 15 minutes per each two way pair then the
7th unit costs twice as much.
So need to segment project into separately
manageable and deliverable projects
Dev Environment, Build, database, menu, access
rights, etc.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
A Year is Too Long!
Keep focus, staff turnover
Cost of changing staff mid-project
But Netscape – 4 week bursts, 2 week re-set
Now continuous releases – by a team
May be 3 weeks for large packages
Focus is on every day delivering completed proven
defect-free code and test harness and documentation
Web-based systems have much smaller deliverables.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
Economics
Pay only for what works
Minimise risk
Get benefits early
Maintainable code
Measure cost, time, quality, scope
Risks are all made short-term
Complex and irresolvable debates.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
NZ Programmers
Have good IS qualifications
Learn quickly from good conceptual base
Often have commerce qualifications
Show initiative
Are not into CYA
Work well together: no internal competition
Respect common sense.
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
When to use XP
Not on very large projects
– My advice – avoid these because your chance of
winning is quite low!
Not for embedded software if the hardware is
frozen
Not with data-driven apps – RAD for these
Not with “Old Economy” management
– My advice – avoid these because your chance of
winning is quite low!
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS
Thank You!
[email protected]
http://www.xp.co.nz
Phone: +64 9 528-3350
Mobile: +64 25 965-608
Tuesday, 24 April 2001
Confidential to Ian Mitchell, FNZCS