IXP

Joshua Kerievsky [Ker05] describes Industrial

Extreme Programming (IXP) as an organic evolution
of XP.
It is customer-centric, test-driven spirit.
Readiness assessment. (1) an appropriate
development environment exists to support IXP,
(2) Proper set of stakeholders,
(3) distinct quality program and continuous
improvement,
(4) New values of an agile team, and
(5) broader project community
 IXP
Project community
people on the team must be well-trained, adaptable
and skilled, and have the proper temperament to
contribute to a self-organizing team.
Community have technologist and customers who are
central to the success of a project as well as many
stakeholders (e.g., legal staff, quality auditors,
manufacturing or sales types)
members and their roles should be defined and
mechanisms for communication and coordination
between community members should be established.
 IXP The IXP team assesses the project itself to determine

Project Chartering whether it gives justification for business and

whether the project meet overall goals and objectives of the
organization.
Chartering also examines the context of the project to find
how it complements, extends, or replaces existing systems or
processes.
Test-driven management establishes a series of measurable
“destinations” [Ker05] and then defines mechanisms for
determining whether or not these destinations have been reached.

appended to XP
to create IXP?
?

uote:
“Ability is what
you’re capable of
doing. Motivation
determines what
you do. Attitude
determines how
well you do it.”
Lou Holtz

pre75977_ch03.qxd 11/27/08 3:24 PM Page 77

organization. Chartering also examines the context of the project to deter-

mine how it complements, extends, or replaces existing systems or
Retrospectives. An IXP team conducts a
specialized technical review after a software
increment is delivered. Called a
retrospective,
review examines “issues, events, and
lessons-learned” across a software
increment and/or the entire software release.
Intent is to improve IXP process.
 THE XP DEBATE
Stephens and Rosenberg argue that many XP practices
are worthwhile, but others have been overhyped,And
problematic.
Issues that continue to trouble some critics of XP are
Requirements volatility. As customer is an active member
of the XP team, changes to requirements are requested
informally,
the scope of the project can change and earlier work may
have to be modified to accommodate current needs.
Proponents argue that this happens regardless of the
process that is applied and that XP provides mechanisms
for
controlling scope creep.
 XP DEBATE
Conflicting customer needs. Many projects have multiple
customers, each with his own set of needs.
In XP, the team itself is asked with assimilating the
needs of different customers, a job that may be beyond their
scope of authority.
Requirements are expressed informally. User stories and
acceptance tests are the only explicit manifestation of
requirements in XP.
Critics argue that a more formal model or specification is
often needed to ensure that omissions,inconsistencies, and
errors are uncovered before the system is built.
Proponents counter that the changing nature of requirements
makes such models and specification obsolete almost as soon
as they are developed.
 XP DEBATE
Lack of formal design. XP deemphasizes the need
for architectural design and in many instances,
suggests that design of all kinds should be
relatively
informal.
Critics argue that when complex systems are
built, design must be emphasized to ensure that
the overall structure of the software will exhibit
quality and maintainability.
XP proponents suggest that the incremental
nature of the XP process limits complexity
 Other AGILE Process Models
Adaptive Software Development (ASD)
• Scrum
• Dynamic Systems Development Method
(DSDM)
Crystal
• Feature Drive Development (FDD)
• Lean Software Development (LSD)
• Agile Modeling (AM)
• Agile Unified Process (AUP)
Adaptive Software Development (ASD) has been
proposed by Jim Highsmith as a technique for
building complex software and systems
During speculation, the project is initiated and
adaptive cycle planning is conducted.
Adaptive cycle planning uses project initiation
information—the customer’s mission statement,
project constraints (e.g., delivery dates or user
descriptions), and
basic requirements—to define the set of release
cycles (software increments) that will be
required for the project.
Motivated people use collaboration in a way that
multiplies their talent and creative output
beyond their absolute numbers.
This approach is a recurring theme in all agile
methods. members of an ASD team begin to
develop the components that are part of an
adaptive cycle, the emphasis is on “learning” as
much as it is on progress toward
a completed cycle.
 ASD’s

overall emphasis on the dynamics of self-

organizing teams, interpersonal
collaboration, and individual and team
learning yield software project teams that
have a much higher likelihood of success.
 Scrum
Scrum (the name is derived from an
activity that occurs during a rugby match
is an agile software development
This method was conceived by Jeff
Sutherland and his development team in
the early 1990s.
Scrum uses a set of software process
patterns that have proven effective for
projects with tight timelines, changing
requirements, and business criticality
Scrum principles are consistent with the
agile manifesto
used to guide development activities
within a process that follows framework
activities:
Requirements, analysis, design,
evolution, and delivery
 Within each framework activity, work
tasks occur within a process pattern
called a sprint.
 The work conducted within a sprint
(the number
 of sprints required for each framework
activity will vary depending on product
complexity and size)
 It is adapted to the problem at hand
and is defined and modified in real
time by the Scrum team.
The overall flow of the Scrum process is
Scrum uses a set of software process
patterns that are effective for projects with
tight timelines, changing requirements, and
business criticality.
Backlog—a list of project requirements that
provide business value for the customer.
Items can be added to the backlog at any
time (this is
how changes are introduced).
The product manager assesses the backlog
and
 the sprint allows team members to work
in a short-term, but stable environment.
Scrum meetings—are short (typically 15
minutes) meetings held daily by the
Scrum team.
Three key questions are asked and
answered by all team members
• What did you do since the last team
meeting?
• What obstacles are you encountering?
A team leader, called a Scrum master,
leads the meeting and assesses the
responses from each person.
The meeting helps the team to find
potential problems as early as possible.
Also, daily meetings lead to “knowledge
socialization and thereby promote a self-
organizing team structure.
Demos—deliver the software increment
to the customer so that functionality
that
has been implemented
can be demonstrated and evaluated by
the customer.
demo may not contain all planned
functionality, but rather those
functions that can be delivered within
the time-box that was established
 Beedle and his coleagues states thatThe
Scrum process patterns enable a
software team to work successfully in a
world where the elimination of
uncertainty is impossible.
 Dynamic Systems Development Method
(DSDM)
The Dynamic Systems Development Method
(DSDM) [Sta97] is an agile software
development approach
It“provides a framework for building and
maintaining systems which meet tight time
constraints through the use of incremental
prototyping in a controlled project
environment”
 DSDM is an iterative software
process in which each iteration
follows the 80 percent rule.
 only enough work is required for
each increment to facilitate
movement to the next increment.
 The remaining detail can be
completed later when more business
requirements are known or changes
have been requested and
The DSDM Consortium(www.dsdm.org) is
a worldwide group 0f members
The consortium has defined an agile
process model, called the DSDM life
cycle that defines three different
iterative cycles, preceded by two
additional life cycle activities:
Feasibility study—establishes the basic
business requirements and constraints
associated with the application to be
built
It assesses whether the application is a
viable candidate for the DSDM process.
Business study—Set functional and
information requirements that allow the
application to provide business value
defines the basic application architecture
and
Functional model iteration—produces a
set of incremental prototypes
It demonstrate functionality for the
customer. All DSDM prototypes are
intended to evolve into the deliverable
application.
The intent of iterative cycle is to gather
additional requirements by eliciting
feedback from users as they exercise
the prototype.
Design and build iteration—revisits
prototypes built during functional model
iteration
Is to ensure that each has been
engineered in a manner that will enable
it to provide operational
. operational business value for end users

Implementation—places the latest

software increment into the operational
environment.
DSDM can be combined with XP
(Section 3.4) to provide a combination
approach
that defines a solid process model (the
DSDM life cycle) with the nuts and bolts
practices (XP) that are required to build
software increments.
Crystal
Alistair Cockburn and Jim Highsmith
created the Crystal family of agile
methods
To achieve maneuverability, Cockburn
and Highsmith have defined a set of
methodologies, each with core elements
that are common to all, and roles,
process patterns, work products, and
practice that are unique to each.
The Crystal family is
a set of example agile processes that
have been proven effective for different
types of projects.
The intent is to allow agile teams to
select the member of the crystal family
that is most appropriate for their
project and environment.
Feature Driven Development (FDD) was
originally conceived by Peter Coad and his
colleagues as a practical process model for
object-oriented software engineering.
(1)emphasizes collaboration among people on
an FDD team
(2)manages problem and project complexity
using feature-based decomposition
(3) followed by the integration of software
increments, and
(4)communication of technical detail using
verbal,graphical, and text-based means.
 As features are small blocks of
deliverable functionality,
 Users can describe them more easily;
understand how they relate to one
another more readily;
 better review them for ambiguity,
error, or omissions.
 • Features can be organized into a
hierarchical business-related
grouping.
 •the team develops operational
 As features are small, their design and
code representations are easier to
inspect effectively.
 Project planning, scheduling, and
tracking are driven by the feature
hierarchy.
Coad and his colleagues suggest the
following template for defining a
feature:
<action> the <result> <by for of to>
a(n) <object>where an <object> is “a
person, place, or thing (including
roles, moments in time or intervals of
time, or catalog-entry-like
descriptions).”
Examples of features for an
e-commerce application might be:
 Add the product to shopping cart
 Display the technical-specifications of
the product
 Store the shipping-information for the
customer