Extreme Programming (XP)

1

• Extreme Programming (XP)

2
What we will cover?

• Extreme Programming
• Objectives of the next lecture

3
Extreme Programming

• The first Extreme Programming project was started
  March 6, 1996 1.
• 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 1.

4
Cont.

• 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.
• Extreme Programming empowers your developers to
  confidently respond to changing customer
  requirements, even late in the life cycle.

5
Cont.

• Extreme Programming, or as it is more commonly
  known XP, was originally designed as a way of
  supporting small development teams working within
  uncertain and changing requirements.
• It was a response to many of the more traditional
  heavyweight approaches that are often overkill
  for small software developments.
• However, it was not an attempt to throw
  everything away and just program (which is a
  common misinterpretation of XP). Rather, XP was
  designed as an approach based on software
  engineering principles, but focused on the timely
  delivery of software that meets users
  requirements.

6
Cont.

• Extreme Programming also places great emphasis on
  the software development team and team work
• Extreme Programming emphasizes teamwork.
  Managers, customers, and developers are all equal
  partners in a collaborative team.
• Extreme Programming implements a simple, yet
  effective environment enabling teams to become
  highly productive. The team self-organizes around
  the problem to solve it as efficiently as
  possible.

7
Cont.

• The team, in turn, incorporates management,
  technical personnel and end users all cooperating
  towards the common good.
• It takes as one of its aims that teams
  communicate and constantly pay attention to all
  the details necessary to make sure that the
  software being developed matches the user
  requirements, to help to produce quality
  software.

8
XPs basic principles

• Communication it is good to talk (particularly,
  between users and developers).
• Simplicity keep it simple and grow the system
  as and when required.
• Feedback let users provide feedback early and
  often.
• Courage to go with such an approach.

9
XPs Key ideas

• The previous four basic principles have led to
  the following key ideas presented within XP
• Code in pairs. This is probably the thing that
  people first hear with relation to XP. The idea
  is that all software is developed in pairs (i.e.,
  with two programmers at one screen). The concept
  is that if code reviews are good, because they
  force at least one other person to consider your
  code, then constantly working in pairs results in
  constant reviewing of code and feedback between
  the two developers.

10
Cont.

• Stay in contact with the customer. For example,
  place a customer representative in the team, so
  that you have access to them all of the time.
  Meet regularly with the customer to give
  information and receive feedback.
• Create tests before coding then test heavily.
  Developers should write the unit tests before the
  code to be tested. Part of the argument is that
  if you cant write the test (i.e., dont know
  what the inputs and outputs should be), then you
  shouldnt be writing the code. You should then
  automate testing so that you can regularly re-run
  the tests to make sure that nothing that has been
  done breaks earlier results.

11
Cont.

• Short iterations. Each iteration should be
  relatively short allowing for rapid and frequent
  feedback. Thus, a minimal system may be produced
  and possibly even put into production quickly and
  the system will grow in whatever directions prove
  most valuable.
• Keep it simple. Start projects with a simple
  design that can evolve later as required by
  future iterations. This removes unnecessary
  complexity from early iterations. It also removes
  the need to code in additional functionalities
  believed to be required by future iterations, but
  which may actually never be needed.

12
Cont.

• Dont anticipate code for current needs. That
  is, dont over-engineer solutions based on what
  they may one day need to do, rather focus on what
  they need to do now and leave tomorrows
  functionality to tomorrow.
• Collective ownership. Everyone within the team
  owns the software and has responsibility for it.
  When something goes wrong, no one should ever
  consider it not to be his or her problem because
  Bill wrote that piece of code. In turn, XP does
  not support a culture of blame and recrimination
  everyone is responsible for all the code. As a
  result of this, everyone is responsible for
  fixing a problem when they find it rather than
  ignoring it.

13
The XP Project Lifecycle

• We had briefly considered, last lecture, the
  primary goals and principles of XP, but what is
  XP? Is it just programming in pairs? No,
• XP does provide a software development lifecycle
  model as well as guidelines on the organization
  of a software development team. The XP lifecycle
  is presented in Figure 4.1.

14
Fig. 4.1 XP lifecycle

15
User Stories

• User stories are similar in some respects to Use
  Cases in that they aim to capture how the user
  will use the system.
• However, they are written by the users themselves
  and not by the development team.
• Note that the users should not be limited to
  describing just the user interface. Rather the
  user stories should describe how the user would
  use the system to accomplish something.

16
Cont.

• It is worth noting that User Stories are not
  detailed requirements. These will be obtained
  during the iterations, when and if the aspect of
  the system covered by a particular user story is
  to be implemented.

17
User stories characteristics

• User stories should be
• Only detailed enough to allow a reasonable
  estimate to be made of the time taken to
  implement them under ideal conditions for the
  planning meeting.
• Short (e.g., about three sentences long)
• Use the terminology of the user and not the
  terminology of the software development team.
• Fed into the release-planning meeting and to the
  creation of the user acceptance tests.

18
Architectural Spike

• A Spike in XP terms is an attempt to reduce the
  risk associated with an unknown area of the
  system, technology or application domain.
• A Spike may involve some investigation, research
  and possibly some software to evaluate or
  elucidate the problem.
• At this stage research and analysis of the
  architecture to use should be carried out and fed
  into the release planning meeting. Other spikes
  are used during the project-planning phase to
  determine unresolved issues.

19
Release Planning

• A release-planning meeting is used to create the
  release plan, which lays out the overall project.
  
• That is, the release plan indicates which user
  stories will be implemented and in which release
  this will happen.
• It also indicates how many iterations are planned
  and when each iteration will be delivered.
• This is done by negotiation between the
  interested parties using estimates derived from
  the user stories.
• The estimates are produced by the technical
  members of the team potentially with input from
  the users.

20

• The users prioritise the user stories possibly
  with input from the technical team members.
• From this, the timescales for the project, the
  delivery dates of various iterations, and the
  final system delivery are all negotiated.
• If it is found that management or users are
  unhappy about the proposed delivery dates, then
  one or more of the features of the system, the
  resources available or the time taken must be
  modified until all participants are happy
• Note that individual iterations are planned just
  before the iteration commences, not in advance.

21
Iterations

• Each iteration within the project adds to the
  agility of the development team.
• That is, at the start of each iteration changes
  can be made to what will be done and when it will
  be done.
• The shorter the iteration, the quicker the
  development team can respond to changes (indeed
  within XP it is recommended that iterations last
  only a matter of weeks).

22
Cont.

• At the beginning of each iteration, an Iteration
  Planning meeting is held to determine exactly
  what will happen within that iteration (such as
  what programming tasks there will be and when
  they will be done).
• Such just-in-time planning is considered an easy
  way to stay on top of changing user requirements.

23
Cont.

• If, however, it looks like the iteration will not
  manage to achieve all that was planned for it,
  then further iteration planning meetings should
  be called during the iteration to respond to
  these concerns.
• These meetings might need to re-estimate current
  and future tasks and determine what can and cant
  be achieved.
• The overriding concern here should be to
  concentrate your efforts on completing the most
  important tasks as chosen by your users rather
  than having several unfinished tasks chosen by
  the developers.

24
Acceptance Testing

• The acceptance tests are created from the user
  stories, written at the start of the project.
• Each iteration implements one or more user
  stories these stories will be translated into a
  series of acceptance tests during the iteration.
• To do this, the customer must specify scenarios
  to test whether a user story has been correctly
  implemented.

25
Cont.

• A story is not limited to one acceptance test and
  may be related to many acceptance tests
  (depending on the complexity of the scenario).
• Interestingly, it is the users who assess the
  results of the acceptance tests and reviewing
  test scores to decide which failed tests are of
  highest priority.
• Acceptance tests are also used as regression
  tests prior to a production release.

26
Cont.

• Thus, Acceptance tests should be automated so
  they can be run often.
• Indeed in each iteration, all previous Acceptance
  tests should be run to ensure that nothing has
  been broken.
• Indeed, contrary to some popular misconceptions,
  XP has Software QA at its heart and encourages
  the QA team to be very closely related to the
  development team.

27
Release

• XP promotes the concept of small releases and
  release often. The release planning meeting
  should identify meaning chucks of system
  functionality that makes business sense in
  relation to the users and to the state of the
  system at various intervals.
• These meaningful releases should be made
  available to users when available. This will
  allow early and frequent feedback from the users
  rather than relying on the big bang approach and
  then worrying about the consequences.

28
Why is XP Controversial

• XP has had some mixed receptions in the press
  and within the wider developer community. Why is
  this? In the following brief section, we will try
  to answer some of the issues that have been
  raised about XP.

29

• XP is a hackers paradise or at the very least
  encourages hacking. Some people believe that XP
  is all about programming with little or no
  emphasis on design, documentation or indeed
  testing. Yet, the reality is that XP tries to
  focus the developer on their core activity
  (writing code) and not to get bogged down in less
  relevant tasks. However, the key here is less
  relevant tasks. XP does not mean that there is
  no need to document, or to design or indeed to
  test. In fact testing is considered to be
  extremely important within XP and design and
  documentation should be carried out but when,
  where and as required, rather than just
  mindlessly created.

30

• XP Programmers get to work in pairs! So that
  means that we now need double the number of
  programmers and that one programmer can just ride
  along on the coat tails of the other programmer?
  Yes? Well no! The idea is that two programmers
  working on the code together will produce more
  effective code, quicker and with less bugs in,
  because they are monitoring what each other are
  doing, and are both analyzing the problem i.e.,
  two heads are better than one.

31

• XP doesnt force team members to specialize and
  become analysts, architects, programmers, testers
  and integrators every XP programmer
  participates in all of these critical activities
  every day. Actually this is true, but is not
  necessarily a bad thing, particularly in small
  software development teams where it can be very
  useful to have everyone familiar with all aspects
  of the development process.

32

• XP doesnt conduct a complete up-front analysis
  and design of the system. Rather an XP project
  starts with a quick analysis of the entire
  system, and XP programmers continue to make
  analysis and design decisions throughout
  development. This is particularly troublesome for
  those entrenched in more traditional (and
  particularly waterfall based) development models.
  But then the point of XP is that it is agile, and
  that what might be thought to be needed upfront
  may change during the lifetime of the project!

33

• XP does not encourage the creation and
  maintenance of implementation documentation. code
  is not self documenting and some documentation is
  always, and will always, be needed.

34

• XP is not a complete methodology. It is a lot
  like a jigsaw puzzle. There are many small
  pieces. Individually, the pieces make no sense,
  but when combined together a complete picture can
  be seen. This is a significant departure from
  traditional software development methods, indeed
  XP is not really a fully fledged development
  method, rather it is a development philosophy
  with proposed procedures, approaches and
  strategies.

35
Objectives of the next lecture

• Next lecture will
• Discuss another agile method called DSDM.

36
References

• 1 http//www.extremeprogramming.org/

37
Questions