Concepts based presentation to clear one of the major concept of software engineering.

1. Muaaz Hasan Zubairi
University of Management and Technology Lahore
XP(Extreme Programming)

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

3. 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

4. Extreme Programming empowers your
developers to confidently respond to
changing customer requirements, even
late in the life cycle.

5. 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.

6. Major principles of the model
Extreme Programming improves a
software project in five essential ways;
communication, simplicity, feedback,
respect, and courage.

7. Extreme Programmers constantly communicate
with their customers and fellow programmers.
They keep their design simple and clean. They
get feedback by testing their software starting on
day one. They deliver the system to the
customers as early as possible and implement
changes as suggested. Every small success
deepens their respect for the unique
contributions of each and every team member.
With this foundation Extreme Programmers are
able to courageously respond to changing
requirements and technology

8. The most surprising aspect of Extreme
Programming is its simple rules. Extreme
Programming is a lot like a jig saw puzzle.
There are many small pieces. Individually
the pieces make no sense, but when
combined together a complete picture can
be seen. The rules may seem awkward
and perhaps even naive at first, but are
based on sound values and principles.

9. Major factor of agility which is handled
by this model
Welcome changing requirements, even late
in
development. Agile processes harness
change for the customer's competitive
advantage.
Business people and developers must work
together daily throughout the project.
Simplicity--the art of maximizing the amount
of work not done--is essential.

10. Human Factors
Software Engineering Methods
the value of communication is expressed
by the practices pair programming.
It is also explained how the “40-hour
week” (or, sustainable pace, or no
extended overtime) is based on the
assumption that tired programmers make
more mistakes.

11. Working in Teams:
It is explained that a team using agile
processes probably functions better as a
democratic team, since there are no
layers in between the manager and the
engineers, and communication, valued by
many of the agile processes, is enhanced.

12. practice of collective ownership
ensures the democratic approach.
Particularly, with respect to XP teams, the
human related
topic of small ego that is necessary for
any democratic is emphasized. In
addition, it is
discussed how the XP practices may
increase trust among team members.

13. Software as a Product
examines the human aspect of software
engineering from the perspective of the
customers - the people that use software
products. It
focuses on how users and developers deal
with defining software requirements in a way
that
fulfill customers’ needs. Indeed, the process
of defining customer’s requirements is
viewed
in this lesson as a process in which both the
customer and the developers participate.

14. If a software team wishes to produce the
software that the customer needs, the
customer should be able to give the
developers on going feedback. For this
purpose the customer should be on-site.

15. Learning Processes in Software
Engineering:
There is a lot of learning like how to
communicate with different people.
How to work together.

16. Pros and cons
Done well, XP gets a team to gel more than
anything.
It builds true competency in all team members.
It makes for an enjoyable and honest work day.
It gets people out of their cubes and talking to
one another.
It teaches developers about how to write quality
code and how to improve their notions of design;
it helps them to improve estimates. It improves
the resumes of developers.

17. It gives management many tools, including
predictability, flexibility of resources,
consistency, and visibility into what's really
going on.
It gives customers the ability to see whether
or not a company can deliver on its promises.
A personal favorite: you don't spend a lot of
time in stupid, wasteful meetings, and you
don't produce a lot of useless documents that
no one reads and that aren't trustworthy
anyway.

18. When should Extreme
Programming be Used?
Extreme Programming (XP) was created in
response to problem domains whose
requirements change. Your customers may
not have a firm idea of what the system
should do. You may have a system whose
functionality is expected to change every few
months. In many software environments
dynamically changing requirements is the
only constant. This is when XP will succeed
while other methodologies do not.

19. XP was also set up to address the problems
of project risk. If your customers need a new
system by a specific date the risk is high. If
that system is a new challenge for your
software group the risk is even greater. If
that system is a new challenge to the entire
software industry the risk is greater even
still. The XP practices are set up to mitigate
the risk and increase the likelihood of
success.

20. XP is set up for small groups of
programmers. Between 2 and 12, though
larger projects of 30 have reported success.
Your programmers can be ordinary, you don't
need programmers with a Ph.D. to use XP.
But you can not use XP on a project with a
huge staff. We should note that on projects
with dynamic requirements or high risk you
may find that a small team of XP
programmers will be more effective than a
large team anyway.

21. Phases of extreme programming
1) Planning
The first phase of Extreme Programming life
cycle is planning, where customers or users meet
with the development team to create ‘user
stories’ or requirements. The development team
converts user stories into iterations that cover a
small part of the functionality or features
required. A combination of iterations provides
the customer with the final fully functional
product.
The programming team prepares the plan, time,
and costs of carrying out the iterations, and
individual developers sign up for iterations.

22. Designing
An iteration of XP programming starts with designing.
The guiding principles of this stage are:
Thrust on simplicity by expressing a thing only once and not
adding functionality in anticipation.
Using systems metaphor or standards on names, class names and
methods, and agreeing on uniform styles and formats to ensure
compatibility among the work of different team members
Using Software Class Responsibilities and Collaboration (CRC)
Cards that allow for a departure from the traditional procedural
mindset and make possible object oriented technology. Such
cards allow all members of the project team to contribute ideas,
and collate the best ideas into the design
Creating spike solutions or simple programs that explore potential
solutions for a specific problem, ignoring all other concerns, to
mitigate risk

23. Coding
Coding constitutes the most important phase in the Extreme Programming life
cycle. XP programming gives priority to the actual coding over all other tasks
such as documentation to ensure that the customer receives something
substantial in value at the end of the day.
Standards related to coding include:
Developing the code based on the agreed metaphors and standards, and
adopting a policy of collective code ownership.
Pair programming or developing code by two programmers working together
on a single machine, aimed at producing higher quality code at the same or
less cost.
Strict adherence to 40-hour workweeks with no overtime. This ensures the
developers work in the peak of their mental and physical faculties.
Frequent integration of the code to the dedicated repository, with only one pair
integrating at a time to prevent conflicts, and optimization at the end.

24. Testing
Extreme program integrates testing with the
development phase rather than at the end of
the development phase. All codes have unit
tests to eliminate bugs, and the code passes
all such unit tests before release.
Another key test is customer acceptance
tests, based on the customer specifications.
Acceptance test run at the completion of the
coding, and the developers provide the
customer with the results of the acceptance
tests along with demonstrations.

25. Listening
The basis of extreme programming is a continuous
mechanism of customer involvement through feedback
during the development phase. Apart from the customer,
the developer also receives feedback from the project
manager.
The basis of feedback is the customer acceptance tests.
Each feedback of the customer that specifies revised
requirement becomes the basis of a new design, and the
process of design-coding-tests-listening repeats itself. If
the customer remains satisfied with the test results the
iteration ends there, and the design for the new iteration
starts, which again follows the design-coding-testing-
listening cycle.

26. Extreme programming Vs Spiral
Model
Agile Programming is quite similar to the
Spiral software development methodology
except that Agile has shorter iteration times.
Agile Programming is particularly effective on
smaller projects (say, 10 or fewer team
members), non-critical projects (in other
words, not projects such as medical or
weapons systems), and non-distributed
systems (in other words, when all team
members are in one physical location).

27. Scrum vs xp
Scrum teams do not allow changes into their
sprints. Once the sprint planning meeting is
completed and a commitment made to
delivering a set of product backlog items,
that set of items remains unchanged through
the end of the sprint. XP teams are much
more amenable to change within their
iterations. As long as the team hasn’t started
work on a particular feature, a new feature of
equivalent size can be swapped into the XP
team’s iteration in exchange for the unstarted
feature.

28. Scrum doesn’t prescribe any engineering
practices; XP does. I love the XP
engineering practices, particularly things
like test-driven development, the focus on
automated testing, pair programming,
simple design, refactoring, and so on.