Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Extreme programming (xp)


Published on

learn Extreme programming (xp)

Published in: Education
  • Be the first to comment

Extreme programming (xp)

  1. 1. Agile Extreme programming XP
  2. 2. Agenda • Introduce team • Agile method(brief) • XP history • XP with other methods • XP features • XP release cycle • XP principles • XP values • The Phases of XP • Requirements scenarios • XP testing • XP advantages and disadvantages • summery
  3. 3. Team members • Mahmoud Sammy NoorEdeen • Mohamed Abdelrahman • Yasmeen Magdy • Yara Osama • Hend Ramadan
  4. 4. Agile method • Focus on software rather than it’s design & documentation(Working software over comprehensive documentation) • Involve customer in development approach • Individuals and interactions over processes • and tools • Rely on incremental approach(change over plan) • Deliver software quickly to customers
  5. 5. Agile method continue… • Not fit for larger projects • Rely on team members understanding aspects of system without documentation • All development stages are interleaved( (متداخله
  6. 6. 8 Cost of Errors Increases Through a Project’s Lifetime Project Phase Cost of Errors
  7. 7. Extreme Programming (XP) Features • New versions may be built several times per day; • Increments are delivered to customers every 2 weeks; • All tests must be run for every build and the build is only accepted if tests run successfully.
  8. 8. .
  9. 9. • The project is divided into iterations. (Divide your development schedule into about a dozen عشرات iterations of 1 to 3 weeks in length. One week is the best choice even though it seems very short. Keep the iteration length constant through out the project) • Don't schedule your programming tasks in advance. Instead have an iteration planning meeting at the beginning of each iteration to plan out what will be done
  10. 10. XP principles Incremental planning Test-first development Simple design Small releases Refactoring Continuous integration Pair programming Sustainable Collective ownership pace
  11. 11. Incremental planning (requirements are recorded on story cards and determined by time and priority)
  12. 12. Small releases The minimal useful first
  13. 13. • simple design
  14. 14. Test first development
  15. 15. All developers are expected to refactor the code continuously as soon as possible code improvements are found (i.e. put comments)
  16. 16. . Developers work in pairs checking each other work and provide support to always do the code work
  17. 17. Collective ownership The pairs of developers work on all areas of the system, so that no islands of expertise develop all developers take responsibility for all the code any one can change any thing
  18. 18. Metaphor Names within code and other work artifacts are chosen to be descriptive of the system being created.
  19. 19. Coding Standard Each team member follows the team standard for format and appearance of the artifacts.
  20. 20. Whole Team The team works together in a lab space or open area where collaboration and communication are maximized.
  21. 21. As soon as the work on task is complete , it is integrated into the whole system
  22. 22. Large amount of overtime are not acceptable Sustainable pace
  23. 23. On-site customer(representative of the end user of system)
  24. 24. The Values of Extreme Programming
  25. 25. The Values of Extreme Programming • Simplicity: do what is needed and asked for, but no more • Communication: Everyone is part of the team and we communicate face to face daily • Feedback: We demonstrate our software early and often then listen carefully and make any changes needed • Respect Everyone gives and feels the respect they deserve as a valued team member. • Courage We will tell the truth about progress and estimates.
  26. 26. Difference between Values and practices • Values are more important than practices aspect that can change to adapt to people (people over processes) • they are really a part of the methodology.
  27. 27. The Phases of XP
  28. 28. Phase description Exploration Project inception, high-level user requirements, technical prototyping planning Prioritization of work , break down into releases and first plan iterations Testing and development of the system includes iterations planning Where low level work break down occurs. End users may work here at refining interface ensuring usability productionizing Deployment of software into the customer’s production environment maintenance Ongoing maintenance ,patches and enhancement
  29. 29. Requirements scenarios
  30. 30. Requirements scenarios Continue… Customer making decisions on requirements User requirements are expressed as scenarios or user stories. The customer chooses the stories based on their priorities and the schedule estimates. the development team breaks them down into implementation tasks
  31. 31. XP and change
  32. 32. • software engineering is to design for change • it proposes constant code improvement (refactoring) to make changes easier when they have to be implemented.
  33. 33. XP testing features
  34. 34. Test-first development User involvement in test development and validation . Incremental Automated test harnesses are used to run all component tests each time that a new release is built. test development from scenarios
  35. 35. XP testing difficulties
  36. 36. XP testing difficulties continue.. • Programmers prefer programming to testing and sometimes they take short cuts when writing tests. • Some tests can be very difficult to write incrementally • It difficult to judge the completeness of a set of tests. Although you may have a lot of system tests, your test set may not provide complete coverage
  37. 37. XP advantages • Individuals are not held responsible for problems with the code. Instead, the team has collective responsibility for resolving these problems. • It acts as an informal review process because each line of code is looked at by at least two people. • It helps support refactoring
  38. 38. XP disadvantages • You may have difficulty to get many developers accept this practice • Your customers may be busy • XP is code centric rather than design centric development(not fit for large projects)
  39. 39. summery
  40. 40. notice • Note that CRC not in XP • In the summery slide
  41. 41. Extreme programming(XP) Reference • • tisxp.htm • • • The Pragmatic Programmer: From Journeyman to Master, by Andrew Hunt and David Thomas
  42. 42. Thank you for watching BEST WISHES