1 / 12

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.

vesta
Download Presentation

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. 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

  8. 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

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

  10. 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

  11. 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

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

More Related