1 / 34

XP (not Microsoft) e X treme P rogramming

XP (not Microsoft) e X treme P rogramming. Can KOMAR can.komar@boun.edu.tr. Contents. Introduction Why XP? Values of XP Overview of XP Practices of XP Discussion. What is XP?. XP is a specific instantiation of an agile process XP combines best practices in a different way

tamar
Télécharger la présentation

XP (not Microsoft) e X treme P rogramming

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. XP (not Microsoft)eXtreme Programming Can KOMAR can.komar@boun.edu.tr

  2. Contents • Introduction • Why XP? • Values of XP • Overview of XP • Practices of XP • Discussion eXtreme Programming

  3. What is XP? • XP is a specific instantiation of an agile process • XP combines best practices in a different way • XP is a different approach to development • XP provides a core process model • XP is not intended to be a complete framework eXtreme Programming

  4. Cost of Change Req Analysis Design Code Test O&M Cost of Change Req Analysis Design Code Test O&M Traditional View XP View eXtreme Programming

  5. 4 Values of XP • Simplicity • KISS  Implement the simplest that works • Communication • Use all means that enable better communication • Feedback at various levels • minutes  unit tests, days  functional tests, weeks  early production • User stories determine the scope • Courage • Refactor when needed • Throw away code when no longer needed eXtreme Programming

  6. Project Overview http://www.extremeprogramming.org eXtreme Programming

  7. Iteration Overview http://www.extremeprogramming.org eXtreme Programming

  8. Development Overview http://www.extremeprogramming.org eXtreme Programming

  9. On-site Customer CodingStandards Metaphor Refactoring AcceptanceTests Pair Programming ReleasePlanning Unit Tests ContinuousIntegration CollectiveOwnership Simple Design SustainablePace Small Releases “Circles of Life” Customer – Team – Developer Pair – Team – Customer eXtreme Programming

  10. On-site Customer AcceptanceTests ReleasePlanning Small Releases “Circles of Life” CodingStandards Metaphor Refactoring Customer – Team – Developer Pair – Team – Customer Pair Programming Unit Tests ContinuousIntegration CollectiveOwnership Simple Design SustainablePace eXtreme Programming

  11. On-Site Customer(s) • Empowered to determine requirements, define functionality, set priorities, and answer questions for the programmers • Daily, face-to-face customer interaction should… • reduce the amount of hard-copy documentation • and the high cost associated with its creation and maintenance eXtreme Programming

  12. Release Planning • a.k.a. “Planning Game” • Requires the XP "customer" to define the business value of desired features • User Stories • Programmers (not just PM) provide cost estimates for those features • Using this information, customer and developers perform a cost/benefit analysis of each feature • enables them to make intelligent decisions about which features to implement and which to defer eXtreme Programming

  13. User Story #1 Story 1 A person registers with the agency by providing personal information, information,about the kind of person they are seeking, an alias to conceal Their true identity, and confidential contact details. eXtreme Programming

  14. User Story #2 Story 2 A selection of matching clients is displayed, and an email may be sent to any one of them. A charge will be made for this service. eXtreme Programming

  15. Small Releases • Put a simple system into production quickly, then release new versions on a very short cycle • For example • Release might be 2-3 months • Each release might have multiple 2-4 week iterations • Helps establish a “rhythm” • Customer and team knows when feedback will occur • Allows the real business value of the product to be evaluated in a real-world environment eXtreme Programming

  16. Test-Driven Development • a.k.a. “Test First”, “Test Infected” • ACCEPTANCE TESTS: Customers are asked to provide acceptance tests in advance of the development of the system. (automated?) • UNIT TESTS: Programmers write tests first based on user stories (requirements) and then create software that fulfills the requirements reflected in the tests. • AUTOMATE, AUTOMATE, AUTOMATE (JUnit, XUnit) • By coding to meet test requirements, we ensure that mandatory features are provided eXtreme Programming

  17. Refactoring Pair Programming Unit Tests Simple Design “Circles of Life” On-site Customer CodingStandards Metaphor Customer – Team – Developer Pair – Team – Customer AcceptanceTests ReleasePlanning ContinuousIntegration CollectiveOwnership SustainablePace Small Releases eXtreme Programming

  18. Refactoring • Programmers restructure system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility • Small steps • Code, test, refactor, test, code, test, refactor • Beck suggests short cycle (10 minutes) • Typical goal of refactoring is to move toward a design pattern eXtreme Programming

  19. Refactoring while( no_matches < 20) { find_another_match(); }  Const int max_matches = 20; While(no_matches < max_matches) { eXtreme Programming

  20. Pair Programming • All production code written with 2 programmers at 1 machine • One tactical, one strategic • Pairing should be dynamic • Members in pair switch roles every 30-60 minutes • Change pairs each task • Experiments showing effectivenes eXtreme Programming

  21. Pair Programming • What does it buy you? • Continuous Code Review • Continuous requirements & domain knowledge reinforcement • Continuous skills training (Java, Design Patterns, Refactoring, CM or IDE tools, etc.) • Developers have more trouble with this concept than managers • Need to try it a few times to see if it works • Takes time to get acclimated • More intense development experience eXtreme Programming

  22. Simple Design • Based on philosophy that highest business value is derived from the simplest program that will meet current requirements. • Don’t over-engineer a solution! • While many preach K.I.S.S., this concept is one of the hardest to apply! • 2 common philosophies of XP teams: • DTSTTCPW - Do The Simplest Thing That Could Possibly Work • YAGNI - You Aren't Gonna Need It eXtreme Programming

  23. Unit 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 eXtreme Programming

  24. Unit Tests eXtreme Programming

  25. CodingStandards Metaphor ContinuousIntegration CollectiveOwnership SustainablePace “Circles of Life” On-site Customer Refactoring Customer – Team – Developer Pair – Team – Customer AcceptanceTests Pair Programming ReleasePlanning Unit Tests Simple Design Small Releases eXtreme Programming

  26. Coding Standards • Programmers write all code in accordance with rules emphasizing communication throughout the code • Goal: Self-documenting code • Because the “common language” is the code • More than Javadoc; good Javadocs with clear inline comments eXtreme Programming

  27. Metaphor • The XP concept of “architecture” • Guide all development with a single shared story of how the whole system works • Defines a "system of names" and guides the team's development and communication eXtreme Programming

  28. Continuous Integration • Integrate & build the system several times a day • Integrate every time a task is completed • Let’s you know every day the status of the system eXtreme Programming

  29. Collective Ownership • Any programmer can change any code anywhere in the system at any time • This works best if using Coding Standards, Test-Driven Development and Pair Programming (Synergy) • Gives the team more flexibility for vacation, sick leave, turn over • Progress doesn’t stop on a component because one of the team members is not present eXtreme Programming

  30. Sustainable Pace • Tired programmers often write lower-quality code • Minimizing overtime and keeping programmers fresh will produce higher-quality code in less time • Set 40-45 hours as a rule • Based on team preference • Corollary: Never work overtime a second week in a row • Avoid burnout eXtreme Programming

  31. A Day In XP eXtreme Programming

  32. References • http://www.extremeprogramming.org • http://www.xprogramming.com • http://www.junit.org • http://www.refactoring.com • http://www.pairprogramming.com • 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 eXtreme Programming

  33. Discussion • Is pair programming a good idea? Under what conditions can it be or vice versa? • Do you really believe XP can solve dynamic requirements problem? • Do you think involving the customer into the development area is a good idea? • What are the (possible) pros and cons of XP? • If you were a project manager what would you consider before adopting XP? eXtreme Programming

  34. Thank you… Any questions?

More Related