Intro SWE Chapter 5 (A) Part Three
Planning
Determine the features to be included in the next release, using business priorities and technical estimates.
Short releases (Frequent releases)
Release new versions in a very short cycle. Typical release times for XP are two to four weeks.
Small releases allows to:
1. Receive frequent feedback
2. Detect bugs earlier
3. Monitor how the product works easil
Metaphor (Easy to understand)
In Extreme Programming (XP), the metaphor is a way to conceptualize and describe the software system being
developed. It involves using a simple and relatable analogy or story that team members, stakeholders, and users
can understand easil
Simple design (Avoid Complexities)
Try to keep the design of the system as simple as possible. Eliminate unnecessary complexity as soon as you
discover it. Do not complicate the design based on things that might be needed in the future but choose the
simplest solution that works now. The design may be changed in the future, if necessary
Test-driven development (Test as much as possible)
Ensure that testing is done continuously and is automated as much as possible.
✓ Write unit tests for all code.
✓ Write the tests before you write the actual code.
✓ Keep running the tests all the time.
✓ Ask customers to write functional acceptance tests to verify when the features are finished.
✓ Continue to keep these tests running after they run the first time.
Design improvement (refactoring - cleaning up your code)
Practice refactoring, which involves a restructuring of the system without changing its behavior, aiming to remove
redundant code, improve communication, and simplify or add needed flexibility.
Pair programming (two developers sit together and work on the same code)
In pair programming, two developers sit together and work on the same code on the same system. One
system. One software developer writes the code, and the other reviews it, simultaneously. Every hour the roles
are switched back and forth. This ensures that everyone knows the ins and outs of the whole system
development process. Essentially, all code is reviewed as it is written
Collective ownership (Everyone is equally responsible for the design of the software)
Establish ownership of the code by the whole team. Anyone can change any piece of code in the system at
any time. Because unit test is emphasized along with continuous integration, you can be relatively confident that
the changes do not destabilize other pieces of the system.
Continuous integration:(Immediately test code changes when they are added into the larger
codebase)
Integrate the system and build it many times a day, every time a task is completed. This way, the development
organization always has a working system and can detect integration errors immediately. The assumption is
that the system builds are not like the large software projects that may take half a day to a whole day to complete
Sustainable pace (40-hour week)
The Extreme programming methodology is true to its name.
It expects developers to be pushed to their limits by working fast, being efficient, and writing high-quality code.
To prevent burnout, teams are only allowed to work less than 45 hours a week.
On-site customer (A customer sits with the team full-time
Include a real customer on the team, always available to answer questions. This allows development to work
without a completely prespecified set of requirements. The chance of project success increases dramatically for
those fortunate projects that have full commitment from consumers
12. Coding standards (the whole team should understand the code)
The whole team should adhere to the same standards. And that means sticking to the
same programming practices, such as using the same format or programming styles. Before the team begins the
project, these standards must be defined and agreed upon.
It helps keep the code uniform so that anyone in the team can:
• Read the code quickly
• Detect problems with ease
Extreme Programming (XP)
The Planning Game
The goal of the planning game is to maximize the value of the software produced. The players include
development personnel and customers, and the artifacts are story cards and task cards.
Businesspeople and customers decide on the following
Scope, Priorities, Release scope and Release dates
The technical staff must make decisions on the following
Estimates:, Consequences and Process.
Two major artifacts in XP are
User Story Cards and Task Cards
User Story Cards
It is a document that describes the user’s requirement.
• Customer designs or writes a user card.
• It describes the system from the customer’s point of view.
• A user card is simple and not much technical language.
• A user card should be detailed enough so that the developer can estimate how long it will take for a
particular story to get designed, tested, and implemented.
• One feature description requires one user card in the system. In other words, one user card for each
requirement.
• The estimates for the feature delivery are done using the user story cards
The Planning Game
Task Cards
• A Task Card is created by the Development team to implement the task in an organized manner. It will have the
following task details against a particular user story-
• The list of tasks required for the implementation of a User Story is called a Task Card.
• Moreover, only one task card gets designed and issued against one user story.
• In addition to that, the Task cards work as the base for task assignments and providing an estimate to complete
a task.
How to play the planning game?
Step 1: Creation or selection of the story
At this stage, the customer must create certain user story or select it from his list. Such stories will be
analyzed and prioritized during the Planning Game. They will formulate the basis of the future project’s plan.
How to play the planning game?
Step 2: Story estimation
This stage of the Planning Game is conducted by the team of developers. They must estimate the story in
accordance with the criteria of time and costs required for its realization
How to play the planning game?
Step 3: Prioritization of stories
This is the beginning of the project’s plan. At this stage of the Planning Game, the customer places the estimated
user story into the plan. All stories are prioritized in accordance with his requirements to the final product.
How to play the planning game?
Step 4: The process is repeated
After one story is estimated and prioritized in the project’s plan the process is repeated until the plan is
completed.
As you can see, Planning Game is a simple method that allows you to create the plan of project realization.
However, it may have some problems. Usually, they appear when the customer does not understand why the
realization of a certain task requires so much time or costs. Such questions must also be discussed during the
Planning Game. The team must explain to the customer all the necessary expenses
Release Planning (What should be released?)
1. In Exploration phase,
The customer collects user stories and writes them on the user story cards.
• The developer estimates the required man-hours for each user story and writes the estimated value on the story card.
• If a user story cannot be estimated, it will be re-decomposed by the customer and then estimated by the developer.
Release Planning (What should be released?)
2. In Commitment phase,
• Customers prioritize user stories based on business value, and the developers prioritize user stories based on risk, and
confirm the development velocity.
• Finally, the customer chooses the user story to be completed for the next release.
Release Planning (What should be released?)
3. In Guidance/Steering phase,
• Developers and customers can adjust and modify the plan. For example, the priority of user stories can be changed,
and the deviations of estimates exist. This is an opportunity to adjust the plan accordingly
Iteration Planning (Start working on requirements)
1. In Exploration phase,
The team discusses each user story and breaks it down into tasks, and then estimates the working hours
for the tasks.
Extreme Programming (XP)
Iteration Planning (Start working on requirements) 2. In Commitment phase,
Each developer voluntarily claim tasks and makes a final estimate of the tasks he is responsible for, and the
team should evaluate whether they are overloaded. One or more developer is responsible for one task.
Extreme Programming (XP)
Iteration Planning (Start working on requirements) 3. In Guidance/Steering phase,
In each subsequent iteration, developers implement each task, record the status and readjusting to the plan.