eXtreme programming (XP) - An Overview

1. <eXtreme Programming (XP)>
An Overview
08 April 2014

2. 01 What is XP?
02 Why XP?
03 How and Who? : Roles and Practices in XP
04 Q & A

3. − Extreme Programming was created by Kent Beck, Ward Cunningham & Ron Jeffries in 1996.
What is Extreme Programming (XP) ?
Kent Ward Ron

4. “XP is a style of software development focusing on excellent application of
programming techniques, clear communication, and teamwork which allows us to
accomplish things we previously could not even imagine.”
-Extreme Programming Explained: Embrace Change, Second Edition
− "Extreme" means the practices get "turned up" to a much higher "volume"
than on traditional projects.
What is Extreme Programming (XP) ?

5. − Problems:
− Freeze all the requirements before starting design & development
− Resist changes: It will lengthen schedule
− Build a change control process to ensure that proposed changes are looked at carefully
and no change is made without intense scrutiny
− Increase the delay in Delivery and the Delivered product is obsolete on release
Why Extreme Programming (XP) ?

6. − XP recognizes that:
− All requirements will not be known at the beginning
− Requirements will change
− Use tools to accommodate change as a natural process
− Do the simplest thing that could possibly work and refactor.
− Emphasize values and principles rather than process
Why Extreme Programming (XP) ?

7. − Some other Benefits:
− As a Programmer:
− Get clear requirements & priorities
− Do a better job & make technical decisions
− Don’t work overtime
− Get accurate & timely feedback
− Customers:
− Get highest valued business item first
− Make informed business decisions
− If there is any need of change that can be communicated and implemented
Why Extreme Programming (XP) ?

8. − Simplicity:
The Values of Extreme Programming

9. − Communication
The Values of Extreme Programming

10. − Feedback
The Values of Extreme Programming

11. − Respect
The Values of Extreme Programming

12. − Courage
The Values of Extreme Programming

13. − The Whole Team:
− Cross-functional team which can fulfill all the team’s roles.
− XP teams sit together in an open workspace.
− At the beginning of each iteration, the team meets for a series of activities: an
iteration demo, a retrospective, and iteration planning.
− This self-organization is a hallmark of agile teams.
Roles in XP

14. − On-Site Customer:
− On-site customer — often just called customer — is responsible for defining the software
the team builds.
− Typically, product managers, domain experts and business analysts play the role of the
on-site customer.
− Customers:
− Evangelize the project’s vision
− Identify features and stories
− Coordinating with Team and playing the planning game
− Customers themselves act as living requirements documents and providing it as needed
− Customers help communicate requirements by creating mock-ups, reviewing work in
progress, and creating detailed customer tests that clarify complex business rules.
Roles in XP

15. − Coach:
− A coach’s enables the team to succeed.
− Coaches help the team by arranging for a shared workspace and making sure that the
team includes the right people.
− Coach help in setting up conditions for energized work, and assist the team in creating
an informative workspace.
− Coaches help the team to interact with the rest of the organization. Coaches take
responsibility for any reporting needed.
− Coaches also help the team members maintain their self-discipline
Roles in XP

16. Fine scale feedback:
• Planning game
• Pair programming
• Test driven development
• Whole team
Shared understanding:
• Coding standard
• Collective code ownership
• Simple design
• System metaphor
Continuous process:
• Continuous integration
• Design improvement
• Small releases
Programmer welfare:
• Sustainable pace
Practices in XP

17. − The Planning Process : The main planning process within extreme programming is
called the Planning Game.
− It is a meeting that occurs once per iteration, typically once a week.
− The desired features of the software, which are communicated by the customer, are
combined with estimates provided by the programmers to determine what the most
important factors of the software are.
− Business writes a story describing desired functionality
− Stories are written on index cards
− Development estimates stories
− Velocity determines number of stories per iteration
− Business splits and prioritizes stories and determines the composition of releases
− Velocity is measured and adjusted every iteration
− Customer steers development
Practices in XP

18. − Pair Programming :
Practices in XP

19. − Pair Programming - All code is written by two programmers working at the same machine.
− Two roles: implementation(Driver) and strategy(Navigator)
− Driver has control over the workstation and is thinking mostly about the coding in detail.
− Navigator is more focused on the big picture, and is continually reviewing the code that
is being produced by Driver.
− Benefits:
− Continuous code review: better design, fewer defects
− Collective code ownership
− Discipline to always test and refactor
− Learn from partner’s knowledge and experience (enhances technical skills)
"Don't be afraid of Pair-Programming. You are not as good as you think , but your not as bad as you fear” - Ron
Jeffries
Practices in XP

20. − Test Driven Development – Testing is done consistently throughout the process.
− Unit Testing
− Test Driven Development (TDD)
− Acceptance Test Driven Development (ATDD)
− Programmers design the tests first and then write the software to fulfill the requirements
of the test.
− XP says that the programmer is finished with a certain piece of code when he or she
cannot come up with any further condition on which the code may fail.
− The customer also provides acceptance tests at each stage to ensure the desired results
are achieved.
Practices in XP

21. − Whole Team (On-Site Customer) - The XP project is directed by the customer who is
available all the time to answer questions, set priorities and determine requirements of the
project.
− And also defines the tests for “Acceptance Test driven development” (ATDD).
− Within XP, the "customer" is not the one who pays the bill, but the one who really uses
the system.
Practices in XP

22. − Continuous Integration (CI) - The XP team integrates and builds the software system
multiple times per day to keep all the programmers at the same stage of the development
process at once.
− It ensures that team is always working on the latest version of the software.
− Continuous integration will avoid delays later on in the project cycle, caused by
integration problems.
− There are various tools, some of these are:
− Hudson
− Jenkins
− Cruise Control
− Bamboo
Practices in XP

23. − Design Improvement (Refactoring) - XP programmers improve the design of the
software through every stage of development instead of waiting until the end of the
development and going back to correct flaws.
− XP advocates to refactor your code by changing the architecture, making it simpler and
more generic without changing the functionality.
− Continuously improve quality of the code
− Improves Performance & Readability
− Inbuilt practices of Unit Testing/TDD and Pair Programming give courage
Practices in XP

24. − Small Releases (Continuous Delivery) – The software is developed in small stages
that are updated frequently.
− It helps the customer to gain confidence in the progress of the project.
− It helps maintain the concept of the whole team as the customer can now come up with his
suggestions on the project based on real experience.
Practices in XP

25. − Coding Standard - The programmers all write code in the same way. This allows them to
work in pairs and to share ownership of the code.
− Coding standard is an agreed upon set of rules that the entire development team agree to adhere to
throughout the project.
− The standard specifies a consistent style and format for source code, within the chosen programming
language, as well as various programming constructs and patterns that should be avoided in order to
reduce the probability of defects.
Practices in XP

26. − Collective Code Ownership - Every line of code belongs to every programmer working on
the project, so there are no issues of proprietary authorship to slow the project down, in turn,
means that everybody is allowed to change any part of the code.
− Pair programming contributes to this practice.
− Collective ownership speeds up the development process, because if an error occurs in the code any
programmer may fix it.
Practices in XP

27. − Simple Design :
− Do the simplest thing that could possibly work
− Programmers should take a "simple is the best" approach to software design.
− Refactoring should also be used, to make complex code simpler.
− The software should include only the code that is necessary to achieve the desired results
communicated by the customer at each stage in the process.
− The emphasis is not on building for future versions of the product
− No duplicate code.
− Fewest possible classes and methods
Practices in XP

28. − System Metaphor - All members of an XP team use common names and descriptions to
guide development and communicate on common terms.
− It's a naming concept for classes/methods that should make it easy for a team member to guess the
functionality of a particular class/method, from its name only.
− It is a story that everyone - customers, programmers, and managers - can tell about how the system
works.
Practices in XP

29. − Sustainable Pace (40-Hour Week) - The XP team does not work excessive overtime to
ensure that the team remains well-rested, alert and effective.
− Key enabler to achieve sustainable pace is frequent code-merge, continuously integrated and always
executable & test covered high quality code.
− The intense collaborative way of working within the team drives a need to recharge over weekends.
Practices in XP

30. References:
http://xprogramming.com/book/whatisxp/
http://en.wikipedia.org/wiki/Extreme_programming
http://www.extremeprogramming.org/values.html
http://en.wikipedia.org/wiki/Extreme_programming_practices
Resources:
http://www.junit.org
http://www.xprogramming.com
http://www.extremeprogramming.org
http://www.refactoring.com
http://www.pairprogramming.com
Book: Scrum & XP from Trenches
References & Resources

31. Gurtej Pal Singh
Gurtej.singh@globallogic.com
Cell # +91-99991-79795
Extn. # 2778
</eXtreme Programming (XP)>