Your SlideShare is downloading. ×
Twelve practices of XP_Se lect5 btech
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Twelve practices of XP_Se lect5 btech

112
views

Published on

Published in: Education, Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
112
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Twelve practices of XP• 1. Pair programming• 2. Refactoring• 3. Simple design• 4. Collective code ownership• 5. Continuous integration• 6. On-site customer• 7. Small releases• 8. 40-hour week• 9. Coding standard• 10. System metaphor (Imagine)• 11. The planning game• 12. Testing
  • 2. 1. Pair programming • In XP, pairs of developers write all production code. This approach may sound inefficient. • Pair programming provides many benefits: • All design decisions involve at least two brains. • At least two people are familiar with every part of the system. • There is less chance of both people neglecting tests. • Changing pairs spreads knowledge throughout the team. • Code is always being reviewed by at least one more person. • Research also is showing that programming in pairs is actually more efficient than programming alone.
  • 3. 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
  • 4. University of Utah Experiment: Pairs spent 15% moretime on the program than individuals
  • 5. University of Utah Experiment: Code written by pairspassed more test cases than code written byindividuals
  • 6. University of Utah Experiment: Pairs consistentlyimplemented the same functionality produced byindividuals in fewer lines of code
  • 7. University of Utah Experiment: Learning how toprogram in an environment where there are rapidlytangible results is fun and allows one to learn faster
  • 8. 2. Refactoring• Refactoring is the technique of improving code without changing functionality.• Refactoring lets you incorporate that learning into your code without breaking the tests. That means it will survive longer.
  • 9. 3. Simple design • XP says design should not be done all at once. We always try to use the simplest design that could possibly work at any point, changing it as we go to reflect emerging reality. • What is the simplest design that could possibly work? • Runs all the tests • Contains no duplicate code • States the programmers intent for all code clearly • Contains the fewest possible classes and methods • Dont include extra features that arent being used. We call such things YAGNI, which stands for "You Arent Going to Need It."
  • 10. 4. Collective code ownership• Any person on the team should have the authority to make changes to the code to improve it.• Everybody owns all the code, meaning everybody is responsible for it.• Saying that everybody owns all the code isnt the same as saying that nobody owns it.• XP says, "You break it, you fix it." We have unit tests that must run before and after each integration. If you break something, its your responsibility to fix it.
  • 11. 5. Continuous integration • Frequent code integration helps you to avoid integration nightmares. • XP teams integrate their code several times a day, after they get all the unit tests for the system to run. • Traditional approaches tend to work like this: code a lot, do integration, then spend a significant amount of time fixing the problems. • When you integrate frequently, the cause of failure for any particular integration is more obvious. • Fixing is easier, takes less time, and keeps the team moving at maximum speed.
  • 12. 6. On-site customer• An XP team needs to have a customer available on site to clarify stories and to make critical business decisions.• Developers arent allowed to do that alone. It eliminates wait for decisions.• The idea is that communicating face to face minimizes the chances of misunderstanding, unlike writing all the requirements down in a static document.• We have found that having the customer on site is the best possible situation. Atleast the customer must be available whenever needed to answer questions and to provide.
  • 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.
  • 14. 7. Small releases• Releases should be as small as possible while still delivering enough business value to make them worthwhile.• This provides value to the customer as early as possible.• Small releases also will provide concrete feedback to developers on what meets customer needs and what doesnt. The team then can include these lessons in its planning for the next release.
  • 15. 8. 40-hour week• Kent Beck says that he wants to be "...fresh and eager every morning, and tired and satisfied every night."• Tired developers make more mistakes, which will slow you down more in the long run than keeping a "normal" schedule will.• Even if developers could function well for longer periods.
  • 16. A Day In XP
  • 17. 9. Coding standard• Without coding standards, it is harder to refactor code, harder to switch pairs as often as you should, and harder to go fast.• The goal should be that no one on the team can recognize who wrote which piece of code.• Make sure your code communicates clearly.• Dont spend too much time. Create the simplest standard that could possibly work.
  • 18. 10. System metaphor (Imagine)• A sort of map that lets developers see where new pieces will fit.• The metaphor gives the team a consistent picture they can use to describe the way the existing system works, where new parts fit, and what form they should take.• It is important to remember that having everyone understand how the system fits together.
  • 19. 11. The planning game• The main idea behind this practice is to make a rough plan quickly and refine it as things become clearer.The development team determines:• Estimates of how long it will take to develop a module• Cost implications of using various technology options• Team organization• The "risk" of each module• Order of module development within an iteration (doing risky items first can ease risk)
  • 20. 11. The planning gameThe customer determines:• Scope• Release dates• Priority (which features get developed first, based on business value)• Planning happens often. This provides frequent opportunity for either the customer or the developers to adjust the plan as they learn new things.
  • 21. 12. Testing Unit testing • Developers write the unit tests as they write code. • Unit tests tell developers whether the system "works" at any point in time. • Developers write unit tests for every method that could possibly break, before they write the code for those methods. Then they write just enough code to get the test to pass. • Unit tests give developers confidence that their code works. It leaves a trail for other developers to understand the original developers intent. • Unit tests also give developers courage to refactor the code, because a test failure tells the developer immediately if somethings broken. • Unit tests should be automated and give a clear pass/fail result.
  • 22. TestingAcceptance testing• The customer writes acceptance tests after they define module.• Acceptance tests tell the team whether the system does what users want it to do.• Customers are responsible for making sure each story has acceptance tests to validate it. The customer can write the tests himself or recruit other members of his organization to write them, or combine the two approaches.• Acceptance tests should ensure developers are not breaking any existing features as they implement new ones.• Customers will need some help from the development team to write acceptance tests.
  • 23. Advantages/Disadvantages ADVANTAGES• Customer focus increase the chance that the software produced will actually meet the needs of the users• The focus on small, incremental release decreases the risk on your project: – by showing that your approach works and – by putting functionality in the hands of your users, enabling them to provide timely feedback regarding your work.• Continuous testing and integration helps to increase the quality of your work• XP is attractive to programmers who normally are unwilling to adopt a software process, enabling your organization to manage its software efforts better.
  • 24. Advantages/Disadvantages DISADVANTAGES• XP is geared toward a single project, developed and maintained by a single team.• XP is particularly vulnerable to "bad apple" developers who: – dont work well with others – who think they know it all, and/or – who are not willing to share their "superior” code• XP will not work in an environment where a customer or manager insists on a complete specification or design before they begin programming.• XP will not work in an environment where programmers are separated geographically.• XP has not been proven to work with systems that have scalability issues (new applications must integrate into existing systems).