1 / 29

Extreme Programming: Introduced

Extreme Programming: Introduced. Matthew Heusser Excelon Development – xndev.com - matt@xndev.com Presented to CS 611 at GVSU, 4/6/2005. Surfin’ the waterfall. The Caste System The factory mentality Scientific Management ‘Managing Scope Creep’ and other bad ideas

mrivers
Download Presentation

Extreme Programming: Introduced

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Extreme Programming:Introduced Matthew Heusser Excelon Development – xndev.com - matt@xndev.com Presented to CS 611 at GVSU, 4/6/2005

  2. Surfin’ the waterfall • The Caste System • The factory mentality • Scientific Management • ‘Managing Scope Creep’ and other bad ideas • Can we have predictability without demeaning people?

  3. Enter XP • If our software development groups could just provide visibility and consistency, maybe customers, management, and coders could share the uncertainty. • “Extreme Programming is a discipline of business and software development that focuses both parties on common, reachable goals. XP teams produce quality software at a sustainable pace. The practices that make up “book” XP are chosen for their dependence on human creativity and acceptance of human frailty.” – Kent Beck, Extreme Programming Installed

  4. Implications • XP is a from-scratch development model that expects change and tries to share risk, instead of forcing it onto one group or another. • The Truth is always a good thing. Even when it’s bad news. • Self-Determination (Content, Collaboration, and Choice) • The central person in the story of development is the CODER.

  5. ‘Book’ XP • Whole Team • Small Releases • Simple Design • Test-First Development Design Improvement • Coding Standard Metaphor • Sustainable Pace Continuous Integration • Pair Programming Planning Game • Collective Code Ownership Customer Tests

  6. Agile requirements … • Customer and Developers write stories • Developers estimate stories in “Points”; • 1-3 points per story • Customers Prioritize Stories • Developers break Stories into tasks • Developers sign up for work • 1st iteration: Roughly 3 weeks

  7. Iterations • Iterative • Feature-Based • Time boxed • Incremental • Jim Highsmith, Agile Project Management, 40 • Inch-Pebble Concept

  8. Releases • However often you need to realease • 3 months sounds about right (or does it?)

  9. ‘Whole’ Team Concept • Customers are members of the team • Co-Location • Who needs a ‘spec’?

  10. “When will you be done?” • 3 weeks • Implications

  11. Velocity • V = D/T • Velocity = Points Accomplished/Weeks • Velocity normalizes over time • Points for a story – “About the same size as” heuristics get better over time

  12. On estimating • Simple Working System • Feature at a time • Spikes as risk management

  13. Design Sessions • Two guys at a Whiteboard • Emergent design (3 weeks ain’t that long) • Very few, high-value artifacts • Focus on design, documentation, etc in working code (you ain’t gonna update it)

  14. Coding sessions • Pair Programming • One Task at a time / Continuous Integration • Integration Machine • Test Everything that could possibly break • AUTOMATED, Test Driven Development – Unit, Integration, System

  15. More coding • Collective Code Ownership • Coding Standard • Simple Design • Refactoring

  16. Code Standards Indentation Capitalization Hungarian Notation (Variable Names) Curly-Brace Placement Function Names

  17. Problems with frequent release • Regression Testing

  18. Test Driven Development • Objects and Functions have unwritten, contracted behavior • Mis-understanding about expected behavior causes integration defects • Automated tests establish and evaluate expected behavior

  19. More TDD • Test-First Development (see handout) • Maintenance programming: Find a defect, write a test for it, fix it, make sure it passes the test • After the fix, automatically regression test the entire system

  20. The XP Life-Style • Sustainable Pace Rarely work 1 week of mild overtime • Minimal Coding Simplest solution • Least number of interfaces, modules, classes, functions Do not "design for extensibility" • Refactoring Get Rid of Duplicate Code

  21. “Steering” • Requirements & Priorities Change • Estimates change – Truth is good • Steer the iteration/steer the release by managing velocity, stories, and bugs

  22. When do you release? • Customer-derived acceptance test • No QA Department! No V&V! • Iterate until the customer is happy or the money runs out. (Shippable at any time; always deliver business value.)

  23. No Testers? • 3. Cease dependence on mass inspectionEliminate the need for mass inspection as the way of life to achieve quality by building quality into the product in the first place. Require statistical evidence of built in quality in both manufacturing and purchasing functions. - Dr. Deming’s 3rd Point of TQM • Note that this requires massive, constant peer review. • (Pair Design, Pair Programming, Pair Test Script Writing …)

  24. XP Values • Simplicity, Communication, Courage, Feedback • You ain’t gonna need it • Simplest thing that could possibly work

  25. Tailoring XP • Few people do ‘book’ XP • Use what works for you • Apply context-driven principles • No Testers?

  26. Cons Probably best for small-to-medium projects Involves change and investment (time) in learning new methods of testing Culture Problems (“We don’t need no silly pair programming”) May have problems with shrink-wrapped development

  27. Conclusions • XP is a collection of mutually supportive practices that optimize the shared mental model and keeps developers working on code.

  28. Discussion

  29. References • http://www.xprogramming.com • Extreme Programming Installed • Extreme Programming Explained • Planning Extreme Programming • Agile Project Management

More Related