Docstoc

Fad Fall back or Fail Safe Fast Forward Extreme Programming

Document Sample
Fad Fall back or Fail Safe Fast Forward Extreme Programming Powered By Docstoc
					    eXtreme Programming

 Fad, Fall-back or Fail-safe Focus?
Fast Defect-Free Software Delivery!
            Ian Mitchell
            Ian@Mitchell.co.nz
            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

               chance of success of less than 1/3
                                                 rd?
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                                On-site customer
   The Planning Game                           Pair programming
   Small Releases                              Coding Standards
   Metaphor                                    Collective Ownership
   Simple Design                               Continuous
   Test every case                              Integration
   Refactoring                                 40-hour week.


Tuesday, 24 April 2001   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!
 Ian@Mitchell.co.nz
 http://www.xp.co.nz
 Phone: +64 9 528-3350
 Mobile: +64 25 965-608




Tuesday, 24 April 2001   Confidential to Ian Mitchell, FNZCS

				
DOCUMENT INFO