XP II

Determine either how many stories can be

XP Model implemented before a given date (if planned by
time) or how long a set of stories will take to
from www.extremeprogramming.org finish (if planned by scope)

planned in detail just before each iteration begins

and not in advance.
A release planning meeting was called as a planning game
In the meeting, the development team estimate each user story and how long ideal programming
weeks. The customer then decides what story is the most important or has the highest priority
to be completed.
XP emphasizes iteration determine if the iteration
is over booked or not.

Iteration (2-3weeks )

Tasks
Only add what you
The user stories and failed tests are broken need for it , NO extra
down into the programming tasks (index
cards) which has 1-3 ideal programming days
 XP emphasizes communication CRC cards: Class, Responsibilities, and
Collaboration (CRC) Cards to design the
system as a team
Development

The pairs of developers work on all areas of the system

Collective Code Ownership : Encourages everyone to contribute new ideas to all segments of the project.
 Test-driven development Any developers can change any line of
code: adding functionality, fixing bugs,
improving designs, refactoring

Collective Code Ownership

 As a
li
book brarian, I
s w
Temp by public ant to be
ck l a te - a t i on
ove and
ba As year. able to se
l a yer, m a < a rc h
a m e P cket to s left ( so t
ha t <
user> for
s a G R o pr es bene I
A
n
y
t m when I fit> ) want <
a
I w forth oids funct
ast e r ional
and arrows. oid the ity>
t
righ t I can a
v As a ROLE (who), I
a
so th want
TASK (what) so that
GOAL (why)
❑ Schedule small features (User stories written on cards) to be completed during the
current completed iteration
❑ Programmers will focus their attention on the tasks at hand
❑ List of tasks is updated regularly
 XP Assignment Storycard in pdf 1
TH Bui 22/11/2020 29/11/2020

1. Choose any story that you have experienced before

2. Break down the user story into small tasks and assign them to someone
3. Assume estimate for each task and count them in total
● Independent: Stories should be as independent as possible. When thinking of independence it is
often easier to think of “order independent.” In other words, stories can be worked on in any order.
Why is this important? It allows for true prioritization of each and every story.
● Negotiable: A story is not a contract. A story IS an invitation to a conversation. The story captures the
essence of what is desired. The actual result needs to be the result of collaborative negotiation
between the customer, developer and tester (at a minimum).
● Valuable: If a story does not have discernable value it should not be done. Period. Hopefully, user
stories are being prioritized in the backlog according to business value, so this should be obvious.
● Estimable: A story has to be able to be estimated or sized so it can be properly prioritized. A value
with high value but extremely lengthy development time may not be the highest priority item because
of the length of time to develop it. What happens if a story can’t be estimated? You can split the story
and perhaps gain more clarity.
● Small: Obviously stories are small chunks of work, but how small should they be? The answer
depends on the team and the methodology being used.
● Testable: Every story needs to be testable in order to be “done.” Thinking this way encourages more
collaboration up front, builds quality in by moving QA up in the process, and allows for easy
transformation to an acceptance test-driven development (ATDD) process.
 Business (Customer) Technical (Programmer)

Estimate how long each user story will

Define the scope of the release
take

Define the order of delivery (which Communicate technical impacts of

stories are done first) implementing requirements

Break down user stories into tasks and

Set dates and times of release
allocate work

🡪 Bring benefits like :

⮚ Reduction in time, wasted on useless features
⮚ Greater customer appreciation of the cost of a feature
⮚ Less guesswork in planning
❑ Also called as Short Releases
❑The only way to ensure that you are
developing the software the customer expects!
❑ Every release could be used as a checkpoint
to measure the estimation accuracy.
❑ A functional system is produced after a few months
❑ System is released before the whole problem is solved
❑ Releases:
❑ New releases regularly (daily to monthly)
❑ The smallest useful feature set is identified for the first release
❑ Releases are performed as early and often as possible
❑ Each release: a few new features added each time.
🡪 Bring benefits like :
⮚ Frequent feedback
⮚ Tracking
⮚ Reduce chance of overall project slippage
❑ Product Roadmap = visual overview of a product’s releases
▪Product roadmap = sequence of releases
▪ Release = sequence of iterations
▪ Iteration = set of user stories / features
❑ Story Map (developed by Jeff Patton)
❑ Helps select and group features for a release
▪ Backbone – essential functionality
▪ Walking skeleton – smallest system that could possible
work
▪ Optional features
A good metaphor is a powerful aid in unifying the
technical and business teams

The team evolves its own form of “tribal

language”, used to describe user stories and
development

- To describe how the system should work

- These analogies express the functionality of the system
- Provides a simple way to remember naming conventions
“Metaphor is something you start using when your mother
asks what you are working on and you try to explain her the
details.”
How you find it is very project-specific.
Use your common sense or find the guy on your team who
is good at explaining technical things to customers in a way
that is easy to understand.
🡪 Bring benefits like :
⮚ Encourage a comment set of terms for the system
⮚ Reduction of buzz words and jargon
⮚ A quick and easy way to explain the system
https://www.researchgate.net/publication/224256383_Making_Metaphors_that_Matter
 1. Only do what you need to do now!
2. Don't add anything because you
think you might need it!
❑XP definition from the value “simplicity”:
▪ Runs all the tests
▪ Contains no duplicate code
▪ States the programmer’s intent for all the code
clearly
▪ Contains the fewest possible classes and methods

🡪 Bring benefits like :

⮚ Time is not wasted adding superfluous functionality
⮚ Easier to understand what is going on
⮚ Refactoring and collective ownership is made possible
⮚ Help keep programmers on track
Refactoring is the disciplined technique for restructuring
an existing body of code, altering its internal structure
without changing its external behavior
WHY?

Because your code should be the

simplest thing that could possibly work
🡪 Bring benefits like :
⮚ Prompt developers to proactively improve the product as a whole
⮚ Increase developer knowledge of the system.
 WHEN?

1) Lack of tests
2) Name not from domain
3) Name not expressing intent
4) Unnecessary if
5) Unnecessary else
6) Duplication of constant
7) Method does more than one thing
8) Primitive obsession
9) Feature envy
10) Method too long (> 6 lines)
 - Add a test, get it to fail, and write code to pass the test –
- Remove duplication

🡪 Bring benefits like :

⮚ Unit testing promote testing completeness
⮚ Test-first gives a suite of regression test
⮚ Automation gives a suite of regression test
 if you can't do these,
you probably shouldn't start writing any code
❑Think about what you want to do.
❑Think about how to test it.
❑Write a small test. Think about the desired API.
❑Write just enough code to fail the test.
❑Run and watch the test fail. Now you know that your test is going to be
executed
❑Write just enough code to pass the test (and pass all your previous tests).
❑Run and watch all of the tests pass. If it doesn't pass, you did something
wrong, fix it now since it's got to be something you just wrote.
❑Refactor the code
❑Run the tests again
❑Repeat the steps above until you can't find any more tests that drive writing
new code.
 Any person can change the application code
at anytime

The catch: If you own all the code, you are responsible
for all the code as well

🡪 Bring benefits like :

⮚ Help mitigate the loss of a team member leaving
⮚ Promote developers to take responsibility for the system as a whole rather
than parts of the system
 The longer the time period between integrations, the more
conflicts you'll see, and the effort to integrate will increase.

The process: developers work on tasks until complete, integrate

them, run tests, fix problems

🡪 Bring benefits like :

⮚ Reduce lengthy process
⮚ Enable the small release practice
 You cannot maintain quality with overtime- heavy teams!

Each country or culture has differing acceptance of reasonable

working hours

🡪 Bring benefits like :

⮚ Most developers lose effectiveness past 40-hour
⮚ Value is placed on the developers well-being
⮚ Management is forced to find real solutions
 The customer must be on the project full-time for the
duration and be located on-site with the team
The customer could include users, business experts, and
any other customer-side resource

🡪 Bring benefits like :

⮚ Give quick and knowledgeable answers to real development questions
⮚ Make sure that what is developed, what is needed
⮚ Functionality is prioritized correctly
 Mandatory — Those standards to be adhered to by all team
members.

Guidelines — Those considered best or good practice and often

describe the general approach toward development.

Recommendations — These rules are considered good practice and

should be used at all times unless there are exceptional circumstances
where
🡪 Bring benefits like valid
: justification can be given
⮚ Reduce the amount of time developers spending on reformatting other
people’s code
⮚ Reduce the need for internal commenting
⮚ Call for clear, unambiguous code
Types of coding standards:
✔ Formatting
✔ Codestructure
✔ Naming conventions
✔ Errorhandling
✔ Comments
❑ In XP, programmers work in pairs, sitting together to develop
code.
❑ This helps develop common ownership of code and spreads
knowledge across the team.
❑ It serves as an informal review process as each line of code is
looked at by more than 1 person.
❑ It encourages refactoring as the whole team can benefit from
this.
❑ Measurements suggest that development productivity with pair
programming is similar to that of two people working
independently.
❑ In pair programming, programmers sit together at the same
workstation to develop the software.
❑ Pairs are created dynamically so that all team members work
with each other during the development process.
❑ The sharing of knowledge that happens during pair programming
is very important as it reduces the overall risks to a project when
team members leave.
❑ Pair programming is not necessarily inefficient and there is
evidence that a pair working together is more efficient than 2
programmers working separately.
🡪 Bring benefits like :
⮚ It supports the idea of collective ownership and responsibility for the
system.
✔ 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, which is a process of software
improvement.
✔ Where pair programming and collective ownership are used, others
benefit immediately from the refactoring so they are likely to
support the process.
Why XP is not popular?

● It is software engineering centric

● It requires high investment
○ Rockstar developers
○ Trainings
○ Infrastructure (some automation solutions is ???
○ Culture

● It is irrational (to business people)

○ Unit tests, Test First Development, Story Points, Pair Programming

● It is too difficult
○ Test First Development, Refactoring, Simple & Emergent Design