00ec74320a77ebc6f8de6637497c2fcd.ppt
- Количество слайдов: 12
e. Xtreme Programming: An Introduction Presentation by: Jon Banta
What is it ? • Agile Software Development Methodology • Iterative • Lightweight – Fewer rules, practices and documents than a heavyweight methodology. • Stresses customer satisfaction and teamwork
When does it work? • Risky Projects – Short timeframes, new technology/concepts • Dynamic Requirements – Frequently changing functionality needs • Small Programming Teams – 2 -12 persons, possibly more • Highly Testable Projects – Must conform to automated unit and acceptance Testing
Rules and Practices • Theology can be split into 4 categories – Planning – Coding – Designing – Testing
Planning • Customer Writes User Stories – Same purpose as use cases • Release Planning Creates Schedule – Lays out overall project • Frequent Releases – Prioritized small releases of functionality • Measure Project Velocity – Measure of work actually getting done
Planning (cont. ) • Iteration Planning – Meeting sets plan for next iteration based on previous iteration’s velocity • Move People Around – Cross training for flexibility • Stand-up Meetings Every Day – Everyone contributes • Fix XP when Breaks – Change procedures if they don’t fit the project
Designing • Strive for Simplicity • Choose a System Metaphor – System for naming classes/methods • Use CRC Cards • Create Spike Solutions – Code to explore technical problem, ignoring all other aspects (thrown away) • No Functionality Added Early • Refactor Mercilessly Whenever, Wherever
Coding • Customer ALWAYS Available – All phases to write user stories/answer questions • Create Coding Standards – Consistent Code • Code Unit Tests First – Tests written before code • Pair Programming – One person code, one critique
Coding (cont. ) • Only One Integration at a Time – Easier to ID new bugs location • Integrate Often – Developers have access to latest version • Collective Code Ownership – Everyone Contributes to all parts • Optimize Last – Bottleneck guesses frequently wrong • No Overtime – Bad for morale
Testing • All Code Has Unit Tests – Tests submitted into Repository with code • Code Must Pass Unit Test Before Release • Create Test When Bug Encountered – Create test before debugging • Frequent Acceptance Tests – Close relationship with quality assurance – All scores published – Customer verifies all results (black box)
Conclusions • The e. Xtreme Programming method is designed to free developers from the overhead of heavyweight methodologies in order to increase productivity and creativity while still providing a framework for organized software development. • Focuses on getting the customer exactly what they want quickly but with high quality.
More Info • www. e. Xtremeprogramming. org • www. Xprogramming. com
00ec74320a77ebc6f8de6637497c2fcd.ppt