1 / 17

20 March

20 March. Extreme Programming. Extreme Programming Project. http://www.extremeprogramming.org/. User Stories. Use cases Written by customer Used for planning Developers estimate by story Stories basis for iteration Used to build acceptance tests

josephtthomas
Télécharger la présentation

20 March

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. 20 March Extreme Programming

  2. Extreme Programming Project http://www.extremeprogramming.org/

  3. User Stories • Use cases • Written by customer • Used for planning • Developers estimate by story • Stories basis for iteration • Used to build acceptance tests • Remember that correctness equals meeting requirements

  4. System Metaphor • Initial system design • About the level that you’re producing

  5. Spikes • Technology explorations • Focus on high risk items • Typically considered throw-away code • If not, needs to be agreed to by the whole team

  6. Release Planning • Focused on iterations • Can be defined by function or date • Other is adjusted accordingly • (Actually four parameters: resources and quality are the other two that can be used to adjust) • Planning adapts as the project progresses • Project velocity is measured for each iteration • Next iteration looks at planned vs. actual time and adjusts accordingly • Each iteration has its own plan • Developed at the beginning of the iteration

  7. Feedback Loops

  8. Iteration • Scope of an iteration • Should cover all parts of the system • Only add the functions that you need for the current user story or stories • Recommendation: 3 weeks • Moving people around • Backup and training • Code is owned by the whole team • Pair programming • Re-factoring

  9. Egoless Programming • Weinberg 1971, The Psychology of Computer Programming • During the “cowboy” era • Observed that programmers needed to be team players • Accept inspections and reviews • Open to corrections and critiques • Ten Commandments (Lamont Adams) • But pride of ownership is critical to quality

  10. Pair Programming • Two people working at a single computer • Built-in backup and inspections • Collaboration builds better code • Mechanical model • One drives, the other talks • Keyboard slides between the two • Logical model • One tactical, the other strategic • Both think about the full spectrum but bring different perspectives

  11. Pair Programming Experiments • Typical numbers show the total manpower consumed not very different • Numbers range, but no more than ¼ additional manpower • Implication: actual time is reduced • Improved satisfaction also improves productivity • Williams et al, “Strengthening the Case for Pair-Programming”

  12. Re-factoring • Each iteration adds just the function needed • If you continue to add new functions every two weeks, code can get messy • Re-factoring is the cleaning up of the code at the end of the iteration • Critical to maintaining quality code • (Also applies to the design)

  13. Coding Rules • The customer is always available. • Code must be written to agreed standards. • Code the unit test first. • All production code is pair programmed. • Only one pair integrates code at a time. • Integrate often. • Use collective code ownership. • Leave optimization till last. • No overtime.

  14. Communications • Avoid unnecessary meeting • Daily stand-up meetings • In a circle • No chairs • Everyone must attend • Minimizes other meetings • Primarily informal as needed

  15. When to Use XP • Types of projects • High risk • Poorly understood requirements • Team • Small size: 2 to 12 • Needs to include customer • Automated testing • Timing issue

  16. What Makes a Project XP • Paradigm - see change as the norm, not the exception, and optimize for change • Values - honor the four values- communication, simplicity, feedback, and courage- in your actions • Power sharing - business makes business decisions and development makes technical decisions • Distributed responsibility and authority - people get to make the commitments for which they will be held accountable • Optimizing process - you are aware of your software development process and when it is working and when it isn't, you are experimenting to fix the parts that aren't working, and you consciously acculturate new team members Ward Cunningham, Ron Jeffries, Martin Fowler, Kent Beck

  17. References • Agile Methodologies www.martinfowler.com/articles/newMethodology.html • Discussion http://xp.c2.com/ExtremeProgrammingRoadmap.html

More Related