1 / 40

Extreme Programming

Extreme Programming. Alexander Kanavin Lappeenranta University of Technology. Some background. Lightweight vs heavyweight methodologies Software Engineering Institute Capability Maturity Model (SEI CMM) Extreme Programming. Basic ideas.

anja
Télécharger la présentation

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. Extreme Programming Alexander Kanavin Lappeenranta University of Technology

  2. Some background • Lightweight vs heavyweight methodologies • Software Engineering Institute Capability Maturity Model (SEI CMM) • Extreme Programming

  3. Basic ideas • Was put together as a response to the increasing difficulty of practicing heavyweight methodologies, especially in medium and small projects • Has very few rules and practices

  4. Rules • Fall into four categories • Planning • Design • Coding • Testing

  5. Rules for planning • User stories are written • Release planning creates the schedule • Make frequent small releases • The project velocity is measured • The project is divided into iterations • Iteration planning starts each iteration

  6. Rules for planning 2 • Move people around • A stand-up meeting starts each day • Fix XP when it breaks

  7. Planning - user stories • Like use cases • Written by the customers as things that the system needs to do for them • Used for time estimation and release planning • Avoid specifics (GUI layouts and such

  8. Release planning meeting • Creation of a release plan document • Planning of individual iterations • Estimation of user stories in terms of ideal programming weeks

  9. Release plan • Specifies exactly which user stories are going to be implemented for each system release and dates for the releases • Stories are translated into acceptance tests

  10. Make frequent small releases • For valuable feedback • Important features are introduced early - more time to fix them

  11. Project velocity • How many user stories were finished during the iteration • Allows estimation for future iterations

  12. Iterative development • Don’t schedule tasks in advance • Don’t look ahead and add anything that’s not scheduled for this iteration

  13. Iteration planning meeting • Customer chooses user stories from the release plan, that are most valuable to him • These are translated into the programming tasks (1 to 3 ideal programming days) • Project velocity is used to estimate if the iteration is overbooked or not.

  14. Move people around • Avoiding knowledge loss and coding bottlenecks • Everyone knows enough about every part of the system

  15. Daily stand up meeting • Everyone stands up in a circle • Prevents it from dragging on for too long • Communications of problems, solutions and promotion of team focus

  16. Design rules • Simplicity • Choose a system metaphor • Use CRC cards for design sessions • Create spike solutions to reduce risk • No functionality is added early • Refactor whenever possible

  17. Simplicity • Needs no explanation • Keeping a design simple is hard work, however

  18. Choose a system metaphor • Allows consistent naming of classes and methods • Being able to guess how something is named is important (time saver)

  19. CRC cards • Class, Responsibilities and Collaboration • Used to represent objects • Class written on top • Responsibilities on the left • Collaborating classes to the right of each responsibility

  20. Spike solution • A very simple program to explore potential solutions • Throw-away program

  21. Never add functionality early • Avoid the tempation • Concentrate on what is scheduled for today only

  22. Refactoring • Rewriting a piece of program so that it does the same thing, but does it better • Removing redundancy, elimination of unused code, getting rid of obsolete designs • Helps keep the design simple and keeping code clean and concise

  23. Coding rules • The customer is always available • Code must be written to agreed standards • Code the unit test first • All code is pair programmed • Only one pair integrates code at a time • Integrate often

  24. Coding rules 2 • Use collective code ownership • Leave optimization till last • No overtime work

  25. Customer is always available • To write user stories • To select user stories • Developers need to talk with the customer to get enough detail to complete a programming task • Functional testing

  26. Coding standards • Self-explanatory

  27. Code the unit test first • It’s easier to create code after creating tests • Tests define the requirements

  28. Pair programming • Sitting side by side in front of the monitor • One person types and thinks tactically • The other one thinks strategically

  29. Sequential integration • Solves problems of parallel integration • Using a physical token or a dedicated computer

  30. Integrate often • Every few hours, not more than a day • Helps detect compatibility problems early, promotes communication

  31. Collective code ownership • Everyone contributes ideas to all parts of the project (or fixes bugs or refactors) • No one becomes a bottleneck • The architecture is distributed among the team

  32. Optimize last • Don’t try to guess what the bottleneck is going to be • Make it work right, then make it work fast

  33. No overtime • If it requires overtime, it will be late no matter what • Use a release planning meeting to change the timing

  34. Testing • All code must have unit tests • All code must pass unit tests before it can be released • When a bug is found tests are created • Acceptance tests are run often and the results are published

  35. Unit tests • Enables collective code ownership • Enables refactoring • Enables frequent integration

  36. Unit testing framework • A development tool, not a testing tool • Helps formalize requirements, clarify architecture, debug, optimize and test • Example: Junit - a unit testing framework for Java,

  37. When a bug is found • Create an acceptance test and unit tests to guard against it coming back

  38. Acceptance tests • Created from user stories • Black box system tests • Customer verifies the correctness of the tests

  39. Weaknesses of XP • Outstanding abilities of the team • Having customer on site • Doesn’t work in a large environment, with no contracting customer, few experts or simultaneous hardware development

  40. Going further • http://www.extremeprogramming.org • Books: Amazon, Books.ru

More Related