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