|| Jai Sri Gurudev |

Sri Adichunchanagiri Shikshana Trust (R)

SJB INSTITUTE OF TECHNOLOGY

Study material
Notes
Subject Name: Agile Technology
Subject Code: 21CS641
By

Faculty Name: Vijayalaxmi Joshi

Designation: Assistant Professor
Semester: VI

Department of Computer Science & Engineering

Aca. Year: Even Sem /2023-24
Module 2
 The XP Lifecycle
• One of the most astonishing premises of XP is that you can eliminate
requirements, design, and testing phases as well as the formal documents
that go with them.
• “These XP folks obviously don’t know what they’re talking
about,” they say. “Just last month I was on a project that failed
due to inadequate requirements and design. We need more
requirements, design, and testing, not less!”
• That’s true. Software projects do need more requirements,
design, and testing—which is why XP teams work on these
activities every day. Yes, every day. You see, XP emphasizes
face-to-face collaboration. This is so effective in eliminating
communication delays and misunderstandings that the team no
longer needs distinct phases. Using simultaneous phases, an
XP team produces deployable software every week. In each
iteration, the team analyzes, designs, codes, tests, and
deploys a subset of features.
• Although this approach doesn’t necessarily mean that the
team is more productive,* it does mean that the team gets
feedback much more frequently.
• As a result, the team can easily connect successes and
failures to their underlying causes.
• The amount of unproven work is very small, which allows the
team to correct some mistakes on the fly, as when coding
reveals a design flaw, or when a customer review reveals that
a user interface layout is confusing or ugly.
• Any information you learn in one phase can change the way
you think about the rest of the software. If you find a design
defect during coding or testing, you can use that knowledge
as you continue to analyze requirements and design the
system in subsequent iterations.
• XP teams perform nearly every software development activity
simultaneously. Analysis, design, coding, testing, and even
deployment occur with rapid frequency. That’s a lot to do
simultaneously. XP does it by working in iterations: week-long
increments of work. Every week, the team does a bit of
release planning, a bit of design, a bit of coding, a bit of
testing, and so forth.
• They work on stories: very small features, or parts of
features, that have customer value. Every week, the team
commits to delivering four to ten stories.
• Throughout the week, they work on all phases of
development for each story. At the end of the week, they
deploy their software for internal review.
 Planning
• Every XP team includes several business experts—the
on-site customers—who are responsible for making
business decisions.
• The on-site customers point the project in the right
direction by clarifying the project vision, creating
stories, constructing a release plan, and managing
risks.
• Programmers provide estimates and suggestions,
which are blended with customer priorities in a
process called the planning game.
• Together, the team strives to create small, frequent
releases that maximize value.
• The planning effort is most intense during the first
few weeks of the project. During the remainder of
the project, customers continue to review and
improve the vision and the release plan to account
for new opportunities and unexpected events.
• In addition to the overall release plan, the team
creates a detailed plan for the upcoming week at the
beginning of each iteration. The team touches base
every day in a brief stand-up meeting, and its
informative workspace keeps everyone informed
about the project status.
 Analysis
• Rather than using an upfront analysis phase to define
requirements, on-site customers sit with the team full-time.
On-site customers may or may not be real customers
depending on the type of project, but they are the people
best qualified to determine what the software should do.
• On-site customers are responsible for figuring out the
requirements for the software. To do so, they use their own
knowledge as customers combined with traditional
requirements-gathering techniques. When programmers need
information, they simply ask. Customers are responsible for
organizing their work so they are ready when programmers
ask for information.
• They figure out the general requirements for a story before
the programmers estimate it and the detailed requirements
before the programmers implement it.
• Some requirements are tricky or difficult to understand.
Customers formalize these requirements, with the assistance
of testers, by creating customer tests: detailed, automatically
checked examples.
• Customers and testers create the customer tests for a story
around the same time that programmers implement the story.
To assist in communication, programmers use a ubiquitous
language in their design and code.
• The user interface (UI) look and feel doesn’t benefit from
automated customer tests. For the UI, customers work with
the team to create sketches of the application screens. In
some cases, customers work alongside programmers as they
use a UI builder to create a screen. Some teams include an
interaction designer who’s responsible for the application’s UI.
 Testing
• XP includes a sophisticated suite of testing practices. Each member of the
team—programmers ,customers, and testers—makes his own contribution
to software quality. Well-functioning XP teams produce only a handful of
bugs per month in completed work.
• Programmers provide the first line of defense with test-driven
development. TDD produces automated unit and integration tests. In
some cases, programmers may also create end-to-end tests. These tests
help ensure that the software does what the programmers intended.
• Customers review work in progress to ensure that the UI works the way
they expect. They also produce examples for programmers to automate
that provide examples of tricky business rules.
• testers help the team understand whether their efforts are in fact
producing high quality code. They use exploratory testing to look for
surprises and gaps in the software. When the testers find a bug, the team
conducts root-cause analysis and considers how to improve their process
to prevent similar bugs from occurring in the future. Testers also explore
the software’s nonfunctional characteristics, such as performance and
stability. Customers then use this information to decide whether to create
additional stories.
• The team doesn’t perform any manual regression testing. TDD
and customer testing leads to a sophisticated suite of
automated regression tests. When bugs are found,
programmers create automated tests to show that the bugs
have been resolved.
• This suite is sufficient to prevent regressions. Every time
programmers integrate (once every few hours), they run the
entire suite of regression tests to check if anything has broken.
• The team also supports their quality efforts through pair
programming, energized work, and iteration slack. These
practices enhance the brainpower that each team member has
available for creating high-quality software.
 Deployment
• XP teams keep their software ready to deploy at the end of
any iteration. They deploy the software to internal
stakeholders every week in preparation for the weekly
iteration demo. Deployment to real customers is scheduled
according to business needs.
• As long as the team is active, it maintains the software it has
released. Depending on the organization, the team may also
support its own software
• In other cases, a separate support team may take over.
• Similarly, when the project ends, the team may hand off
maintenance duties to another team.
• In this case, the team creates documentation and provides
training as necessary during its last few weeks.
 The XP Team
Team software development is different. The same information is spread out
among many members of the team. Different people know:
• How to design and program the software (programmers, designers, and architects)
• Why the software is important (product manager)
• The rules the software should follow (domain experts)
• How the software should behave (interaction designers)
• How the user interface should look (graphic designers)
• Where defects are likely to hide (testers)
• How to interact with the rest of the company (project manager)
• Where to improve work habits (coach)
• All of this knowledge is necessary for success. XP acknowledges this reality by
creating cross functional
• teams composed of diverse people who can fulfill all the team’s roles.
• The Whole Team
• On-Site Customers
• The product manager
• Domain experts
Most software operates in a particular industry, such as finance, that has its
own specialized rules for doing business. To succeed in that industry, the
software must implement those rules faithfully and exactly. These rules are
domain rules, and knowledge of these rules is domain knowledge.
Most programmers have gaps in their domain knowledge, even if they’ve
worked in an industry for years. In many cases, the industry itself doesn’t
clearly define all its rules. The basics may be clear, but there are nitpicky
details where domain rules are implicit or even Contradictory.
The team’s domain experts are responsible for figuring out these details and having the
answers at their fingertips. Domain experts, also known as subject matter experts,
are experts in their field. Examples include financial analysts and PhD chemists.
Domain experts spend most of their time with the team, figuring out the details of
upcoming stories and standing ready to answer questions when programmers ask.
For complex rules, they create customer tests (often with the help of testers) to
help convey nuances.
• Interaction designers
The user interface is the public face of the product. For many users, the UI is
the product. They judge the product’s quality solely on their perception of
the UI.
Interaction designers help define the product UI. Their job focuses on
understanding users, their needs, and how they will interact with the
product. They perform such tasks as interviewing users, creating user
personas, reviewing paper prototypes with users, and observing usage of
actual software.
• Business analysts
• On non agile teams, business analysts typically act as liaisons between the
customers and developers, by clarifying and refining customer needs into
a functional requirements specification.
• On an XP team, business analysts augment a team that already contains a
product manager and domain experts. The analyst continues to clarify and
refine customer needs, but the analyst does so in support of the other on-
site customers, not as a replacement for them. Analysts help customers
think of details they might otherwise forget and help programmers
express technical trade-offs in business terms.
• Programmers
• A great product vision requires solid execution. The bulk of the XP
team consists of software developers in a variety of specialties. Each of
these developers contributes directly to creating working code. To
emphasize this, XP calls all developers programmers. If the customers’
job is to maximize the value of the product, then the programmers’ job is to
minimize its cost. Programmers are responsible for finding the most effective way
of delivering the stories in the plan. To this end, programmers provide effort
estimates, suggest alternatives, and help customers create an achievable plan
by playing the planning game.
• Programmers spend most of their time pair programming. Using test-
driven development, they write tests, implement code, refactor, and
incrementally design and architect the application.
• Designers and architects
Everybody codes on an XP team, and everybody designs. Test-driven development
combines design, tests, and coding into a single, ongoing activity.
Expert designers and architects are still necessary. They contribute by guiding the
team’s incremental design and architecture efforts and by helping team members
see ways of simplifying complex designs. They act as peers—that is, as
programmers—rather than teachers, guiding rather than dictating.
• Technical specialists
In addition to the obvious titles (programmer, developer, software engineer), the XP
“programmer” role includes other software development roles. The programmers
could include a database designer, a security expert, or a network architect. XP
programmers are generalizing specialists. Although each person has his own area
of expertise, everybody is expected to work on any part of the system that needs
attention
• Testers
Testers help XP teams produce quality results from the beginning. Testers apply their
critical thinking skills to help customers consider all possibilities when
envisioning the product. They help customers identify holes in the requirements
and assist in customer testing
• Testers also act as technical investigators for the team. They use
exploratory testing to help the team identify whether it is successfully
preventing bugs from reaching finished code. Testers also provide
information about the software’s nonfunctional characteristics, such as
• performance, scalability, and stability, by using both exploratory testing
and long-running automated tests.
• Coaches
• XP teams self-organize, which means each member of the team figures
out how he can best help the team move forward at any given moment.
XP teams eschew traditional management roles.
• Instead, XP leaders lead by example, helping the team reach its potential
rather than creating jobs and assigning tasks. To emphasize this difference,
XP leaders are called coaches.
The programmer-coach
• Every team needs a programmer-coach to help the other programmers
with XP’s technical practices. Programmer-coaches are often senior
developers and may have titles such as “technical lead” or “architect.”
They can even be functional managers. While some programmer-coaches
make good all-around coaches, others require the assistance of a project
manager.
• Programmer-coaches also act as normal programmers and participate fully
in software development.
The project manager
• Project managers help the team work with the rest of the
organization. They are usually good at coaching non
programming practices. Some functional managers fit into this
role as well.
• However, most project managers lack the technical expertise
to coach XP’s programming practices, which necessitates the
assistance of a programmer-coach. Project managers may also
double as customers
 The Project Community
• Stakeholders
• The executive sponsor
• Full-Time Team Members
 The product manager
• The product manager has only one job on an XP project, That
job is to maintain and promote the product vision. In practice,
this means documenting the vision,
• sharing it with stakeholders, incorporating feedback,
generating features and stories, setting priorities for release
planning, providing direction for the team’s on-site customers,
reviewing work in progress, leading iteration demos, involving
real customers, and dealing with organizational politics.
 XP Concepts
• Refactoring is the process of changing the structure of code—rephrasing
it—without changing its meaning or behavior. It’s used to
• improve code quality, to fight off software’s unavoidable entropy, and to
ease adding new features.
 Technical Debt
• Technical debt is the total amount of less-than-perfect design and
implementation decisions in your project.
• This includes quick and dirty hacks intended just to get something working
right now! and design decisions that may no longer apply due to business
changes.
• Technical debt can even come from development practices such as an
unwieldy build process or incomplete test coverage.
• The bill for this debt often comes in the form of higher maintenance costs.
There may not be a single lump sum to pay, but simple tasks that ought to
take minutes may stretch into hours or afternoons. You might not even
notice it except for a looming sense of dread when you read a new bug
report and suspect it’s in that part of the code.
 Time boxing
• Recognizing the point at which you have enough information is not easy. If
you use timeboxing, you set aside a specific block of time for your
research or discussion and stop when your time is up, regardless of your
progress.
• This is both difficult and valuable. It’s difficult to stop working on a
problem when the solution may be seconds away. However, recognizing
when you’ve made as much progress as possible is an important time-
management skill. Time boxing meetings, for example, can reduce wasted
• Discussion.
 The Last Responsible Moment
• XP views a potential change as an opportunity to exploit; it’s the chance to
learn something significant. This is why XP teams delay commitment until
the last responsible moment.*
• If commitments are delayed beyond the last responsible moment, then
decisions are made by default, which is generally not a good
• approach to making decisions.” By delaying decisions until this crucial
point, you increase the accuracy of your decisions, decrease your
workload, and decrease the impact of changes
 Stories
• Stories represent self-contained, individual elements of the
project. They tend to correspond
• to individual features and typically represent one or two days
of work. Stories are customer-centric, describing the results in
terms of business results.
• They’re not implementation details, nor are they full
requirements specifications.
• They are traditionally just an index card’s worth of
information used for scheduling purposes
 Iterations
• An iteration is the full cycle of design-code-verify-release practiced by XP
teams. It’s a time box that is usually one to three weeks long.
• Each iteration begins with the customer selecting which stories the team
will implement during the iteration, and it ends with the team producing
software that the customer can install and use.
• The beginning of each iteration represents a point at which the customer
can change the direction of the project. Smaller iterations allow more
frequent adjustment. Fixed-size iterations provide a well-timed rhythm of
development.
 Velocity
• Velocity is a simple way of mapping estimates to the calendar.
• It’s the total of the estimates for the stories finished in an iteration.
• In general, the team should be able to achieve the same velocity in every
iteration. This allows the team to make iteration commitments and predict
release dates.
• The units measured are deliberately vague; velocity is a technique for
converting effort estimates to calendar time and has no relation to
productivity
 Theory of Constraints
• Theory of Constraints says, in part, that every system has a single
constraint that determines the overall throughput of the system.
• Regardless of how much work testers and customers do, many
• software teams can only complete their projects as quickly as the
programmers can program them. If the rest of the team outpaces
the programmers, the work piles up, falls out of date and needs
reworking, and slows the programmers further.
• Therefore, the programmers set the pace, and their estimates are used for
planning. As long as the programmers are the constraint, the customers
and testers will have more slack in their schedules, and they’ll have
enough time to get their work done before the programmers need it.
 Mindfulness
• Agility—the ability to respond effectively to change—requires that
everyone pay attention to the process and practices of development. This
is mindfulness