290 likes | 308 Views
Learn about Extreme Programming, a dynamic software development model focusing on collaboration and iterative processes to produce high-quality software. Understand the core principles, practices, and values of XP, including customer involvement, small releases, test-driven development, and continuous integration. Discover how XP fosters team collaboration, adaptability to change, and a sustainable development pace to deliver value to customers. Explore the philosophy of simplicity, courage, and feedback that drives XP success.
E N D
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 • Can we have predictability without demeaning people?
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
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.
‘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
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
Iterations • Iterative • Feature-Based • Time boxed • Incremental • Jim Highsmith, Agile Project Management, 40 • Inch-Pebble Concept
Releases • However often you need to realease • 3 months sounds about right (or does it?)
‘Whole’ Team Concept • Customers are members of the team • Co-Location • Who needs a ‘spec’?
“When will you be done?” • 3 weeks • Implications
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
On estimating • Simple Working System • Feature at a time • Spikes as risk management
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)
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
More coding • Collective Code Ownership • Coding Standard • Simple Design • Refactoring
Code Standards Indentation Capitalization Hungarian Notation (Variable Names) Curly-Brace Placement Function Names
Problems with frequent release • Regression Testing
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
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
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
“Steering” • Requirements & Priorities Change • Estimates change – Truth is good • Steer the iteration/steer the release by managing velocity, stories, and bugs
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.)
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 …)
XP Values • Simplicity, Communication, Courage, Feedback • You ain’t gonna need it • Simplest thing that could possibly work
Tailoring XP • Few people do ‘book’ XP • Use what works for you • Apply context-driven principles • No Testers?
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
Conclusions • XP is a collection of mutually supportive practices that optimize the shared mental model and keeps developers working on code.
References • http://www.xprogramming.com • Extreme Programming Installed • Extreme Programming Explained • Planning Extreme Programming • Agile Project Management