1 / 61

Extreme Programming(XP)

Extreme Programming(XP). Waterfall Methodology(Revision). Introduction. Most Software projects Fail It cost huge amount of money before it fails. Introduction. Extreme Programming is one of several popular Agile Processes.

bcole
Download Presentation

Extreme Programming(XP)

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(XP)

  2. Waterfall Methodology(Revision)

  3. Introduction • Most Software projects Fail • It cost huge amount of money before it fails

  4. Introduction • Extreme Programming is one of several popular Agile Processes. • It has already been proven to be very successful at many companies of all different sizes and industries world wide. • Extreme Programming is successful because it stresses customer satisfaction. • Instead of delivering everything you could possibly want on some date far in the future this process delivers the software you need as you need it. 

  5. What is Extreme Programming? • An agile development methodology • Created by Kent Beck in the mid 1990’s • A set of 12 key practices taken to their “extremes”

  6. Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements • As a type of agile software development, it advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

  7. Extreme programming(Sommerville) • Perhaps the best-known and most widely used agile method. • Extreme Programming (XP) takes an ‘extreme’ approach to iterative development. • 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. The XP release cycle

  9. Extreme programming practices 1

  10. Extreme programming practices 2

  11. Requirements scenarios • In XP, user requirements are expressed as scenarios or user stories. • These are written on cards and the development team break them down into implementation tasks. These tasks are the basis of schedule and cost estimates. • The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates.

  12. Story card for document downloading

  13. XP and change • Conventional wisdom in software engineering is to design for change. It is worth spending time and effort anticipating changes as this reduces costs later in the life cycle. • XP, however, maintains that this is not worthwhile as changes cannot be reliably anticipated. • Rather, it proposes constant code improvement (refactoring) to make changes easier when they have to be implemented.

  14. Testing in XP • Test-first development. • Incremental test development from scenarios. • User involvement in test development and validation. • Automated test harnesses are used to run all component tests each time that a new release is built.

  15. Task cards for document downloading

  16. Test case description

  17. Test-first development • Writing tests before code clarifies the requirements to be implemented. • Tests are written as programs rather than data so that they can be executed automatically. The test includes a check that it has executed correctly. • All previous and new tests are automatically run when new functionality is added. Thus checking that the new functionality has not introduced errors.

  18. Pair programming • In XP, programmers work in pairs, sitting together to develop code. • This helps develop common ownership of code and spreads knowledge across the team. • It serves as an informal review process as each line of code is looked at by more than 1 person. • It encourages refactoring as the whole team can benefit from this. • Measurements suggest that development productivity with pair programming is similar to that of two people working independently.

  19. What is Extreme Programming? • An agile development methodology • Created by Kent Beck in the mid 1990’s • A set of 12 key practices taken to their “extremes” • A mindset for developers and customers • A religion?

  20. The 12 Practices • The Planning Game • Small Releases • Metaphor • Simple Design • Testing • Refactoring • Pair Programming • Collective Ownership • Continuous Integration • 40-Hour Workweek • On-site Customer • Coding Standards

  21. 1 - The Planning Game • Planning for the upcoming iteration • Uses stories provided by the customer • Technical persons determine schedules, estimates, costs, etc • A result of collaboration between the customer and the developers

  22. The Planning Game – Advantages • Reduction in time wasted on useless features • Greater customer appreciation of the cost of a feature • Less guesswork in planning

  23. The Planning Game – Disadvantages • Customer availability • Is planning this often necessary?

  24. 2- Small Releases • Small in terms of functionality • Less functionality means releases happen more frequently • Support the planning game

  25. Small Releases – Advantages • Frequent feedback • Tracking • Reduce chance of overall project slippage

  26. Small Releases – Disadvantages • Not easy for all projects • Not needed for all projects • Versioning issues

  27. 3 – Metaphor • The oral architecture of the system • A common set of terminology

  28. Metaphor – Advantages • Encourages a common set of terms for the system • A quick and easy way to explain the system

  29. Metaphor – Disadvantages • Often the metaphor is the system • Another opportunity for miscommunication • The system is often not well understood as a metaphor

  30. 4 – Simple Design • K.I.S.S. • Do as little as needed, nothing more

  31. Simple Design – Advantages • Time is not wasted adding not required functionality • Easier to understand what is going on • Refactoring and collective ownership is made possible • Helps keeps programmers on track

  32. Simple Design – Disadvantages • What is “simple?” • Simple isn’t always best

  33. 6 – Testing • Unit testing • Test-first design • All automated

  34. Testing – Advantages • Unit testing promote testing completeness • Test-first gives developers a goal • Automation gives a suite of regression test

  35. Testing – Disadvantages • Automated unit testing isn’t for everything • confidence on unit testing isn’t a good idea • A test result is only as good as the test itself

  36. 6 – Refactoring • Changing how the system does something but not what is done • Improves the quality of the system in some way

  37. Refactoring – Advantages • Prompts developers to proactively improve the product as a whole • Increases developer knowledge of the system

  38. Refactoring • Refactoring is the process of code improvement where code is reorganised and rewritten to make it more efficient, easier to understand, etc. • Refactoring is required because frequent releases mean that code is developed incrementally and therefore tends to become messy. • Refactoring should not change the functionality of the system. • Automated testing simplifies refactoring as you can see if the changed code still runs the tests successfully.

  39. Refactoring – Disadvantages • Not everyone is capable of refactoring • Refactoring may not always be appropriate • Would upfront design eliminate refactoring?

  40. 7 – Pair Programming • Two Developers, One monitor, One Keyboard • One “drives” and the other thinks • Switch roles as needed

  41. Pair Programming – Advantages • Two heads are better than one • Focus • Two people are more likely to answer the following questions: • Is this whole approach going to work? • What are some test cases that may not work yet? • Is there a way to simplify this?

  42. Pair Programming – Disadvantages • Many tasks really don’t require two programmers • A hard sell to the customers • Not for everyone

  43. 8 – Collective Ownership • The idea that all developers own all of the code • Enables refactoring

  44. Collective Ownership – Advantages • Helps mitigate the loss of a team member leaving • Promotes developers to take responsibility for the system as a whole rather then parts of the system

  45. Collective Ownership - Disadvantages • Loss of accountability • Limitation to how much of a large system that an individual can practically “own”

  46. 9 – Continuous Integration • New features and changes are worked into the system immediately • Code is not worked on without being integrated for more than a day

  47. Continuous Integration - Advantages • Reduces to lengthy process • Enables the Small Releases practice

  48. Continuous Integration – Disadvantages • The one day limit is not always practical • Reduces the importance of a well-thought-out architecture

  49. 10 – 40-Hour Week • The work week should be limited to 40 hours • Regular overtime is a symptom of a problem and not a long term solution

  50. 40-Hour Week – Advantage • Most developers lose effectiveness past 40-Hours • Value is placed on the developers well-being • Management is forced to find real solutions

More Related