Lecture By Mr. yasir hafeez

1. Extreme Programming
(XP)

2. Introduction Extreme Programming?
 An agile development methodology XP is “a light-
weight methodology for small to medium-sized
teams developing software in the face of vague or
rapidly changing requirements
 It works by bringing the whole team together in the
presence of simple practices, with enough feedback
to enable the team to see where they are and to
tune the practices to their unique situation?
 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

3. Extreme Programming
 Hence XP is a lightweight (agile) process:
 Instead of lots of documentation nailing down what
customer wants up front, XP emphasizes plenty of
feedback
 Embrace change: iterate often, design and
redesign, code and test frequently, keep the
customer involved
 Deliver software to the customer in short (2 week)
iterations
 Eliminate defects early, thus reducing costs

4. XP MODEL
(from www.extremeprogramming.org)

5. XP emphasizes iteration

6. XP emphasizes communication

7. Test-driven development

8. Four Core Values of XP
 Communication
 Simplicity
 Feedback
 Courage

9. XP 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

10. 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
Advantages
 Reduction in time wasted on useless features
 Greater customer appreciation of the cost of a feature
 Less guesswork in planning
Disadvantages
 Customer availability
 Is planning this often necessary?

11. Small Releases
 Small in terms of functionality
 Less functionality means releases happen more frequently
 Support the planning game
Advantages
 Frequent feedback
 Tracking
 Reduce chance of overall project slippage
Disadvantages
 Not easy for all projects
 Not needed for all projects
 Versioning issues

12. Metaphor
 The oral architecture of the system
 A common set of terminology
Advantages
 Encourages a common set of terms for the system
 Reduction of buzz words and jargon
 A quick and easy way to explain the system
Disadvantages
 Often the metaphor is the system
 Another opportunity for miscommunication
 The system is often not well understood as a metaphor

13. Simple Design
 K.I.S.S (Keep it simple Stupid)
 Do as little as needed, nothing more
Advantages
 Time is not wasted adding superfluous functionality
 Easier to understand what is going on
 Refactoring and collective ownership is made possible
 Helps keeps programmers on track
Disadvantages
 What is “simple?”
 Simple isn’t always best

14. Testing
 Unit testing
 Test-first design
 All automated
Advantages
 Unit testing promote testing completeness
 Test-first gives developers a goal
 Automation gives a suite of regression test
Disadvantages
 Automated unit testing isn’t for everything
 Reliance on unit testing isn’t a good idea
 A test result is only as good as the test itself

15. Refactoring
 Changing how the system does something but not what is done
 Improves the quality of the system in some way
Advantages
 Prompts developers to proactively improve the product as a whole
 Increases developer knowledge of the system
Disadvantages
 Not everyone is capable of refactoring
 Refactoring may not always be appropriate
 Would upfront design eliminate refactoring?

16. Pair Programming
 Two Developers, One monitor, One Keyboard
 One “drives” and the other thinks
 Switch roles as needed
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?
Disadvantages
 Many tasks really don’t require two programmers
 A hard sell to the customers

17. Collective Ownership
 The idea that all developers own all of the code
 Enables refactoring
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
Disadvantages
 Loss of accountability
 Limitation to how much of a large system that an individual can
practically “own”

18. 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
Advantages
 Reduces to lengthy process
 Enables the Small Releases practice
Disadvantages
 The one day limit is not always practical
 Reduces the importance of a well-thought-out architecture

19. 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
Advantages
 Most developers lose effectiveness past 40-Hours
 Value is placed on the developers well-being
 Management is forced to find real solutions
Disadvantages
 The underlying principle is flawed
 40-Hours is a magic number
 Some may like to work more than 40-Hours

20. On-Site Customer
 Acts to “steer” the project
 Gives quick and continuous feedback to the development team
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
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

21. Coding Standards
 All code should look the same
 It should not possible to determine who coded what
based on the code itself
Advantages
 Reduces the amount of time developers spend reformatting
other peoples’ code
 Reduces the need for internal commenting
 Call for clear, unambiguous code
Disadvantages
 Degrading the quality of inline documentation

22. Extreme Programming Roles
 Customer
 Writes User Stories and specifies Functional Tests
 Sets priorities, explains stories
 May or may not be an end-user
 Has authority to decide questions about the stories
 Programmer
 Estimates stories
 Defines Tasks from stories, and estimates
 Implements Stories and Unit Tests
 Coach
 Watches everything, sends obscure signals, makes sure
the project stays on course
 Helps with anything

23. XP Roles continued
 Tracker
 Monitors Programmers’ progress, takes action if things seem to be
going off track.
 Actions include setting up a meeting with Customer,
 Coach or another Programmer to help
 Tester
 Implements and runs Functional Tests (not Unit Tests!)
 Graphs results, and makes sure people know when test results decline.
 Doomsayer
 Ensures that everybody knows the risks involved
 Ensures that bad news isn't hidden, glossed over, or blown out of
proportion

24. XP Roles continued
 Manager
 Schedules meetings (e.g. Iteration Plan, Release Plan), makes
sure the meeting process is followed, records results of meeting
for future reporting, and passes to the Tracker
 Possibly responsible to the Gold Owner.
 Goes to meetings, brings back useful information
 Gold Owner
 The person funding the project, which may or may not be the
same as the Customer

25. Extreme Programming
Activities
 Coding: You code because if you don't code, at the end of the day
you haven't done anything.
 Testing: You test because if you don't test, you don't know when
you are done coding
 Listening: You listen because if you don't listen you don't know
what to code or what to test
 Designing: And you design so you can keep coding and testing and
listening indefinitely (good design allows extension of the system
with changes in only one place)

26. Release Planning Phases
 Exploration Phase: In this phase the customer will provide a
shortlist of high-value requirements for the system. These will be
written down on user story cards.
 Commitment Phase: Within the commitment phase customer and
developers will commit themselves to the functionality that will be
included and the date of the next release.
 Steering Phase: In the steering phase the plan can be adjusted,
new requirements can be added and/or existing requirements can
be changed or removed

27. Exploration Phase
 Iterative process of gathering requirements and estimating the work
impact of each of those requirements.
Write a Story:
Customer has come with a problem; during a meeting, Developer
will try to define this problem and get requirements. Based on the
business problem, a story (user story) has to be written. This is
done by Customer, where they point out what they want a part of
the system to do. It is important that developer has no influence on
this story. The story is written on a user story card.
Roles : Customer , Developer
Artifact : User Stories

28. Exploration Phase
 Estimate a Story: Developer estimates how long it will
take to implement the work implied by the story card.
Developer can analyze or solve the problem. These
solutions are used for estimation and discarded once
everyone gets clear visualization of the problem. Again,
this may not influence the business requirements.
 Split a Story: Design critical complexity has to be
addressed before starting the iteration planning. If
developer isn't able to estimate the story, it needs to be
split up and written again.

29. Commitment phase
 This phase involves the determination of costs, benefits,
and schedule impact. It has four components:
 Sort by Value: Customer sorts the user stories by business
value
 Sort by Risk: Developer sorts the stories by risk.
 Set Velocity: Developer determines at what speed they can
perform the project.
 Choose scope: The user stories that will be finished in the next
release will be picked. Based on the user stories the release
date is determined.

30. Steering phase
 Within the steering phase the developer
and customer can "steer" the process.
That is to say, they can make changes.
Individual user stories, or relative priorities
of different user stories, might change;
estimates might prove wrong. This is the
chance to adjust the plan accordingly.

31. Iteration Planning
 Plans the activities and tasks of the
developers. In this process the customer
is not involved..
Role : Developers
 3 Phases of Iteration Planning

32. Iteration Planning Phases
 Exploration Phase: requirement will be translated to different tasks.
The tasks are recorded on task cards.
 Commitment Phase: The tasks will be assigned to the programmers
and the time it takes to complete will be estimated.
 Steering Phase: The tasks are performed and the end result is
matched with the original user story

33. Exploration phase
 It is about creating tasks and estimating their
implementation time.
 Translate the requirement to tasks: Place on task cards.
 Combine/Split task: If the programmer cannot estimate
the task because it is too small or too big, the
programmer will need to combine or split the task.
 Estimate task: Estimate the time it will take to implement
the task

34. Commitment phase
 Within the commitment phase of the iteration planning
programmers are assigned tasks that reference the different
user stories.
 A programmer accepts a task, each programmer picks a task
for which he or she takes responsibility.
 Programmer estimates the task, because the programmer is
now responsible for the task, he or she should give the
eventual estimation of the task.

35. Commitment phase Cont….
 Set load factor: The load factor represents the ideal amount of
hands-on development time per programmer within one
iteration. For example, in a 40-hour week, with 5 hours
dedicated to meetings, this would be no more than 35 hours.
 Balancing: When all programmers within the team have been
assigned tasks, a comparison is made between the estimated
time of the tasks and the load factor. Then the tasks are
balanced out among the programmers. If a programmer is
overcommitted, other programmers must take over some of
his or her tasks and vice versa.

36. Implementation
 The implementation of the tasks is done during the
steering phase of the iteration planning.
 Get a task card: The programmer gets the task card for
one of the tasks to which he or she has committed.
 Find a Partner: The programmer will implement this task
along with another programmer. This is further discussed
in the practice Pair Programming.
 Design the task: If needed, the programmers will design
the functionality of the task.

37. Implementation Cont…
 Write unit test: Before the programmers start coding the
functionality they first write automated tests. This is
further discussed in the practice Unit Testing.
 Write code: The programmers start to code.
 Run test: The unit tests are run to test the code.
 Refactor: Remove any code smell from the code.
 Run Functional test: Functional tests (based on the
requirements in the associated user story and task card)
are run.

38. XP Artifacts
 Story Cards
 Task Cards

39. User Stories
 A short description of the behavior of the system from
the point of view of the Customer
 Use the Customer’s terminology without technical jargon
 One for each major feature in the system
 Must be written by the users
 Are used to create time estimates for release planning
 Replace a large Requirements Document

40. User Stories continued
 Drive the creation of the acceptance tests
 Must be one or more tests to verify that a story has been
properly implemented
 Should only provide enough detail to make a reasonably low
risk estimate of how long the story will take to implement.
 Written by the Customer, not the Programmers, using the
Customer’s terminology
 More “friendly” than formal Use Cases

41. User Stories continued
 User stories have three crucial aspects:
 Card
 Enough information to identify the story
 Conversation
 Customer and Programmers discuss the story to elaborate on
the details
 Verbal when possible, but documented when required
 Confirmation
 Acceptance tests to confirm that the story has been properly
implemented

42. User Story Examples
 A user wants access to the system, so
they find a system administrator, who
enters in the user's First Name, Last
Name, Middle Initial, E-Mail Address,
Username (unique), and Phone Number.
 Risk: Low Cost: 2 points

44. Research Issues
 What kind of projects can benefit from XP? What
projects are “too big” and therefore outside the
scope of XP?
 How do we reconcile past research, which suggests
that the lack of a formal specification is a recipe for
project disaster?
 What is the effect of the lack of focus, in general,
with a formal requirements engineering process?
 XP requires customers that can write user stories,
assist in planning releases, perform acceptance
tests, and be available to answer questions on-site
with the developers. Ideally, this is one person who
can represent a group of users.

45. Research Issues
 What are the “ideal” characteristics that this person
must possess? How are different, and potentially
conflicting, stories from multiple “customers”
handled?
 What are the implications of not having a formal
document (such as an SRS) to serve as a binding
contract?
 How is change managed after release? How is the
potential impact of changes assessed? Can the
“cost of change” curve truly be flattened with XP?
 Does the use of XP indeed result in project
“success”? Are the success factors for XP
implementation different than for the traditional
methodologies?