This document provides an overview of Extreme Programming (XP), an agile software development methodology. It discusses XP's history and features, which include short 2-week development cycles, pair programming, test-driven development, and frequent refactoring. The core principles of XP are also examined, such as incremental planning, small releases, simple design, and sustainable pace. Various phases of the XP process are outlined, from exploration to productionizing. Requirements are captured as scenarios and prioritized by the customer. Automated testing is a key practice in XP. Both advantages like collective code ownership and disadvantages like its unsuitability for large projects are noted.

1. Agile Extreme
programming
XP

2. Agenda
• Introduce team
• Agile method(brief)
• XP history
• XP with other methods
• XP features
• XP release cycle
• XP principles
• XP values
• The Phases of XP
• Requirements scenarios
• XP testing
• XP advantages and disadvantages
• summery

3. Team members
• Mahmoud Sammy NoorEdeen
• Mohamed Abdelrahman
• Yasmeen Magdy
• Yara Osama
• Hend Ramadan

4. Agile method
• Focus on software rather than it’s design &
documentation(Working software over comprehensive documentation)
• Involve customer in development approach
• Individuals and interactions over processes
• and tools
• Rely on incremental approach(change over plan)
• Deliver software quickly to customers

5. Agile method continue…
• Not fit for larger projects
• Rely on team members understanding
aspects of system without documentation
• All development stages are
interleaved( (متداخله

8. 8
Cost of Errors Increases
Through a Project’s Lifetime
Project Phase
Cost of Errors

9. Extreme Programming (XP)
Features
• 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.

10. .

11. • The project is divided into iterations.
(Divide your development schedule into about a dozen عشرات iterations of 1 to 3
weeks in length. One week is the best choice even though it seems very
short. Keep the iteration length constant through out the project)
• Don't schedule your programming tasks in advance. Instead have
an iteration planning meeting at the beginning of each iteration to plan
out what will be done

12. XP principles
Incremental
planning
Test-first
development
Simple design
Small
releases
Refactoring
Continuous
integration
Pair
programming
Sustainable
Collective
ownership
pace

13. Incremental planning
(requirements are recorded on
story cards and determined by
time and priority)

14. Small releases
The minimal useful first

15. • simple design

16. Test first
development

17. All developers are expected to refactor the code continuously as soon as
possible code improvements are found (i.e. put comments)

18. .
Developers work in pairs checking each
other work and provide support to
always do the code work

19. Collective ownership
The pairs of developers work on all areas of the system, so
that no islands of expertise develop all developers take
responsibility for all the code any one can change any thing

20. Metaphor
Names within code and other work artifacts are chosen to be descriptive of the system being created.

21. Coding Standard
Each team member follows the team standard for format and appearance of the artifacts.

22. Whole Team
The team works together in a lab space or open area where collaboration and communication are maximized.

23. As soon as the work on task is complete , it is integrated into the whole
system

24. Large amount of
overtime are not
acceptable
Sustainable pace

25. On-site customer(representative of the end user of system)

26. The Values of Extreme
Programming

27. The Values of Extreme Programming
• Simplicity:
do what is needed and asked for, but no more
• Communication:
Everyone is part of the team and we communicate face to face daily
• Feedback:
We demonstrate our software early and often then listen carefully and
make any changes needed
• Respect
Everyone gives and feels the respect they deserve as a valued team
member.
• Courage
We will tell the truth about progress and estimates.

28. Difference between Values and
practices
• Values are more important than practices
aspect that can change to adapt to people (people over
processes)
• they are really a part of the methodology.

29. The Phases of XP

31. Phase description
Exploration Project inception, high-level user requirements, technical
prototyping
planning Prioritization of work , break down into releases and first plan
iterations Testing and development of the system includes iterations
planning
Where low level work break down occurs.
End users may work here at refining interface ensuring usability
productionizing Deployment of software into the customer’s production
environment
maintenance Ongoing maintenance ,patches and enhancement

32. Requirements scenarios

33. Requirements scenarios
Continue…
Customer
making decisions
on requirements
User
requirements are
expressed as
scenarios or user
stories.
The customer
chooses the
stories based on
their priorities and
the schedule
estimates.
the development
team breaks them
down into
implementation
tasks

34. XP and change

35. • software engineering is to design for
change
• it proposes constant code improvement
(refactoring) to make changes easier when
they have to be implemented.

36. XP testing features

37. Test-first
development
User involvement in test
development and validation
.
Incremental
Automated test harnesses are
used to run all component tests
each time that a new release is
built.
test
development
from
scenarios

38. XP testing difficulties

39. XP testing difficulties
continue..
• Programmers prefer programming to testing and
sometimes they take short cuts when writing tests.
• Some tests can be very difficult to write incrementally
• It difficult to judge the completeness of a set of tests.
Although you may have a lot of system tests, your test
set may not provide complete coverage

40. XP advantages
• Individuals are not held responsible for problems with the
code. Instead, the team has collective responsibility for
resolving these problems.
• It acts as an informal review process because each line
of code is looked at by at least two people.
• It helps support refactoring

41. XP disadvantages
• You may have difficulty to get many developers
accept this practice
• Your customers may be busy
• XP is code centric rather than design
centric development(not fit for large
projects)

42. summery

43. notice
• Note that CRC not in XP
• In the summery slide

44. Extreme programming(XP)
Reference
• http://www.extremeprogramming.org
• http://www.xprogramming.com/xpmag/wha
tisxp.htm
• http://www.agilemanifesto.org/
• http://www.poppendieck.com/
• The Pragmatic Programmer: From Journeyman to Master,
by Andrew Hunt and David Thomas

46. Thank you for watching
BEST WISHES