1 / 28

Introduction to eXtreme Programming

Contents. The problemProblems in software developmenteXtreme Programming (XP)ValuesPracticesWhy XP worksBenefits of XPConclusionsResources. Problems in software development. Risks:Schedule slipsBusiness misunderstoodDefect rateProject cancelledSystem goes sourBusiness changes. Schedul

phineas
Télécharger la présentation

Introduction to eXtreme Programming

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. Introduction to eXtreme Programming Remko Popma Azzurri Ltd. http://www.azzurri.co.jp

    2. Contents The problem Problems in software development eXtreme Programming (XP) Values Practices Why XP works Benefits of XP Conclusions Resources

    3. Problems in software development Risks: Schedule slips Business misunderstood Defect rate Project cancelled System goes sour Business changes eg. Netscape 6 No communication after requirements analysis, or, Business needs changes Time pressure, quality sacrificed for short-term speed gain Bigger projects have good chance of being cancelled: low visibility, large budgets/timeframes System delivered, works, but complex and/or fragileeg. Netscape 6 No communication after requirements analysis, or, Business needs changes Time pressure, quality sacrificed for short-term speed gain Bigger projects have good chance of being cancelled: low visibility, large budgets/timeframes System delivered, works, but complex and/or fragile

    4. Schedule slips Many projects are not delivered on time Examples: Word 1.0, Netscape 6 Some deadlines cannot be moved Example: Y2K What if: most business value is delivered on time

    5. Business misunderstood Without direct communication, developers have to guess what the customer wants. Example: The Orthodontics Project What if: an on-site customer steers development

    6. Defect rate The software is put in production, but the defect rate is so high that it isnt used. What if: you have automated testing

    7. Project cancelled Todo: function point http://www.yourdon.com/books/y2k2020/11.dejavu.html Todo: function point http://www.yourdon.com/books/y2k2020/11.dejavu.html

    8. Project cancelled What if: short releases deliver at least some useful working software, reflecting investment to date

    9. System goes sour Software is put into production successfully, but after a couple of years the cost of making changes or the defect rate rises so much that the system must be replaced. What if: the design is simple and the code quality is high

    10. Business changes New laws, market changes: business priorities change What if: the customer can change their mind, substitute functionality, and change priorities

    11. Economics of software development

    12. What if

    13. eXtreme Programming A system of practices that a community of software developers is evolving to address the problems of quickly delivering quality software, and then evolving it to meet changing business needs.

    14. eXtreme Taking proven practices to the extreme If testing is good, let everybody test all the time If code reviews are good, review all the time If design is good, refactor all the time If integration testing is good, integrate all the time If simplicity is good, do the simplest thing that could possibly work If short iterations are good, make them really, really short Take practices that have been proven to be good and take them to the extreme.Take practices that have been proven to be good and take them to the extreme.

    15. XP values Communication Simplicity Feedback Courage

    16. XP practices The Planning Game* Small Releases Metaphor Simple Design* Testing* Refactoring* Pair Programming* Collective Ownership Continuous Integration 40-Hour Week On-Site Customer Coding Standards Open workspace Daily Schema migration

    17. The Planning Game Business writes a story describing desired functionality Stories are written on index cards Development estimates stories Velocity determines number of stories per iteration Business splits and prioritizes stories and determines the composition of releases Velocity is measured and adjusted every iteration Customer steers development Big subject: will gloss over it Release planning & iteration planning Big subject: will gloss over it Release planning & iteration planning

    18. Testing Unit Tests and Functional Tests Test a little, code a little Test-first programming Tests become the specification Tests give confidence in the system Tests give courage to change the system

    19. Unit tests

    20. Pair Programming Two people looking at one machine, with one keyboard and one mouse Two roles: implementation and strategy All production code is written in pairs

    21. Pair Programming Benefits 15% less output than 2 solo programmers Continuous code review: better design, fewer defects Confidence to add to or change the system Discipline to always test and refactor Teach each other how the system works (reduced staffing risks) Learn from partners knowledge and experience (enhances technical skills) http://members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htm (Alistair Cockburn & Laurie Williams) Partner is a safety net: changing the system is not scary http://members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htm (Alistair Cockburn & Laurie Williams) Partner is a safety net: changing the system is not scary

    22. Simple design Do the simplest thing that could possibly work Passes all the tests No duplicate code States every intention Fewest possible classes and methods

    23. Refactoring Design becomes everybodys daily business Continuously improve quality of the code Unit Tests and Pair Programming give courage Result: Fast development speed Code becomes easy to change

    24. Why XP works Light-weight: discipline without bureaucracy Under stress, people do what is easiest All XP practices have short-term benefits as well as long-term benefits Development as a Conversation The code is the documentation XP is fun

    25. Who benefits from XP? get clear requirements & priorities can do a good job can make technical decisions dont work overtime get most business value first get accurate feedback can make informed business decisions can change their mind

    26. Conclusions Use XP on projects with vague or changing requirements with small teams XP works, and is very fast XP is fun to execute At Azzurri, we use XP as much as possible with clients, and exclusively for internal projects

    27. XP books and papers Extreme Programming Explained Kent Beck Refactoring Martin Fowler Planning Extreme Programming Kent Beck et al Extreme Programming Installed Ron Jeffries et al Extreme Programming Examined Giancarlo Succi et al Extreme Programming in Practice Robert C. Martin et al Extreme Programming Explored William C. Wake Extreme Programming Applied Ken Auer et al The Costs and Benefits of Pair Programming Alistair Cockburn et al http://members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htmhttp://members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htm

    28. Web resources www.junit.org www.xprogramming.com www.extremeprogramming.org www.refactoring.com www.pairprogramming.com http://www.martinfowler.com/articles/designDead.htmlhttp://www.martinfowler.com/articles/designDead.html

    29. Thank you Questions?

More Related