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

51. 40-Hour Week - Disadvantages
40-Hours is a magic number
Some may like to work more than 40-Hours

52. 11 – On-Site Customer Just like the title says!
Acts to “steer” the project
Gives quick and continuous feedback to the development team

53. On-Site Customer – Advantages
Can give quick and knowledgeable answers to real development questions
Makes sure that what is developed is what is needed
Functionality is prioritized correctly

54. On-Site Customer – Disadvantages
Difficult to get an On-Site Customer
The On-Site customer that is given may not be fully knowledgeable about what the company
May not have authority to make many decisions
Loss of work to the customer’s company

55. 12 – Coding Standards All code should look the same
It should not possible to determine who coded what based on the code itself

56. Coding Standards – Advantages
Reduces the amount of time developers spend reformatting other peoples’ code
Reduces the need for internal commenting
Call for clear, unambiguous code

57. Coding Standards – Disadvantages
Degrading the quality of inline documentation

58. XP – Advantages Built-In Quality Overall Simplicity Programmer Power
Customer Power
Synergy Between Practices

59. XP – Disadvantages Informal, little, or no documentation Scalability
Contract Issues
Misconception on the cost of change

60. Problems with XP Customer involvement Architectural design
This is perhaps the most difficult problem. It may be difficult or impossible to find a customer who can represent all stakeholders and who can be taken off their normal work to become part of the XP team. For generic products, there is no ‘customer’ - the marketing team may not be typical of real customers.
Architectural design
The incremental style of development can mean that inappropriate architectural decisions are made at an early stage of the process.
Problems with these may not become clear until many features have been implemented and refactoring the architecture is very expensive.

61. Thank You !!!