eXtreme Programming Fad, Fall-back or Fail-safe Focus? Fast Defect-Free Software Delivery! Ian Mitchell [email protected] http://www.xp.co.nz.
Download ReportTranscript 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