0

INDUSTRIAL EXTREME PROGRAMMING

Course: Software Requirements Specification and Analysis (SE-406)

Submitted by: Group 3 Submitted to:

Shazzad Hossain - 1203 Dr. Kazi Muheymin-Us-Sakib

Sakib Al Hasan - 1209 Professor
Muktadul Islam - 1215 IIT, DU
Sifat Sikder - 1221
Mohammad Momenuzzaman - 1227
Mehzabin Haque - 1233
 1

INDUSTRIAL EXTREME PROGRAMMING

Abstract
The agile movement has received much attention as an alternative direction for
software engineering. Among the agile methodologies, eXtreme Programming (XP) is
the most well known, which is a lightweight development methodology.

Introduction
Extreme programming (XP) is an agile software development framework that aims to
produce higher quality software, and higher quality of life for the development team. XP
is the most specific of the agile frameworks regarding appropriate engineering practices
for software development. Extreme programming stresses teamwork, communication,
feedback, simplicity and problem solving. It uses an object-oriented approach as its
preferred development paradigm and encompasses a set of rules and practices that
occur within the context of four framework activities: planning, design, coding, and
testing.

Industrial Extreme Programming

Industrial Extreme Programming (IXP) is a brand of Extreme Programming or XP
tailored for large organizations where emphasis is placed on coding first and
documentation second. Joshua Kerievsky [Ker05] describes IXP in the following
manner: “IXP is an organic evolution of XP. It is imbued with XP’s minimalist,
customer-centric, test-driver spirit. IXP differs most from the original XP in its greater
inclusion of management, its expanded role for customers, and its upgraded technical
practices.” IXP stemmed from challenges with regard to the implementation of XP in
organizations with 500 or more employees. It is specialized for use for large
organizations and has been in use since 2001 in fields of biotechnology, finance,
engineering and entertainment organizations.

IXP Values
IXP includes all the values that establish a foundation for all work performed as part of
XP, which, as defined by Beck [Bec04a], are — communication, simplicity, feedback,
courage, and respect. Each of these values is used as a driver for specific XP activities,
actions, and tasks.
 2

Communication
Software development is inherently a team sport that relies on communication to
transfer knowledge from one team member to everyone else on the team. In order to
achieve effective communication between software engineers and other stakeholders,
XP emphasizes close, yet informal collaboration between customers and developers,
the establishment of effective metaphors for communicating important concepts,
continuous feedback, and the avoidance of voluminous documentation as a
communication medium.

Simplicity
The purpose of simplicity is to avoid waste and do only absolutely necessary things
such as keep the design of the system as simple as possible so that it is easier to
maintain, support, and revise. To achieve this, XP restricts developers to design only for
immediate needs, rather than consider future needs.

Feedback
Feedback is derived from three sources: the implemented software itself, the customer,
and other software team members. Through constant feedback about their previous
efforts, teams can identify areas for improvement and revise their practices.

Courage
Kent Beck defined courage as “effective action in the face of fear”. An agile XP team
must have the discipline or courage to design for today, recognizing that future
requirements may change dramatically, thereby demanding substantial rework of the
design and implemented code.

Respect
By following each of these values, the agile team inculcates respect among its
members, between other stakeholders and team members, and indirectly, for the
software itself. As they achieve successful delivery of software increments, the team
develops growing respect for the XP process.

IXP Process
IXP, just like XP, uses an object-oriented approach as its preferred development
paradigm and encompasses a set of rules and practices that occur within the context of
four framework activities: planning, design, coding, and testing.
 3

Planning
Quickly determine the scope of the next release by combining business priorities and
technical estimates.

Design
The system should be designed as simply as possible at any given moment. Extra
complexity is removed as soon as it is discovered.

Coding
After planning is done and preliminary design work is done, the team does not move to
code, but rather develops a series of unit tests that will exercise each of the stories that
is to be included in the current release. Once the unit test has been created, the
developer is better able to focus on what must be implemented to pass the test.
Everything is kept as simple as possible, nothing extraneous is added.

Testing
Programmers continually write unit tests, which must run flawlessly for development to
continue. Customers write tests demonstrating that features are finished.

IXP practices
IXP incorporates six new practices that are designed to help ensure that an XP project
works successfully for significant projects within a large organization, which are:

Readiness assessment:
Prior to the initiation of an IXP project, the organization should conduct a readiness
assessment. The assessment ascertains the followings:
1. An appropriate development environment exists to support IXP.
2. The team will be populated by the proper set of stakeholders.
3. The organization has a distinct quality program and supports continuous
improvement.
4. The organizational culture will support the new values of an agile team.
5. The broader project community will be populated appropriately.

Project community
In IXP, the community members and their roles should be explicitly defined and
mechanisms for communication and coordination between community members should
be established.
 4

Project chartering
The IXP team assesses the project itself to determine whether an appropriate business
justification for the project exists and whether the project will further the overall goals
and objectives of the organization. Chartering also examines the context of the project
to determine how it complements, extends, or replaces existing systems or processes.

Test-driver management
An IXP project requires measurable criteria for assessing the state of the project and
the progress that has been made to date. Test-driven management establishes a series
of measurable “destinations” and then defines mechanisms for determining whether or
not these destinations have been reached.

Retrospectives
An IXP team conducts a specialized technical review after a software increment is
delivered. Called a retrospective, the review examines “issues, events, and
lessons-learned” across a software increment and/or the entire software release. The
intent is to improve the IXP process.

Continuous learning
Because learning is a vital part of continuous process improvement, members of the XP
team are encouraged to learn new methods and techniques that can lead to a
higher-quality product.

Modifications to existing XP practices

In addition to the six new practices discussed above, IXP modifies a number of existing
XP practices.
● Story-driven development (SDD) insists that stories for acceptance tests be
written before a single line of code is generated.
● Domain-driven design (DDD) suggests the evolutionary creation of a domain
model that “accurately represents how domain experts think about their subject.”
● Pairing extends the XP pair-programming concept to include managers and
other stakeholders.
● Iterative usability discourages front-loaded interface design in favor of usability
design that evolves as software increments are delivered and users’ interaction
with the software is studied.
IXP makes smaller modifications to other XP practices and redefines certain roles and
responsibilities to make them more amenable to significant projects for large
organizations.
 5

Advantages of IXP
● Close contact with customer
● No unnecessary programming work
● Stable software through continuous and automated testing
● Error frequency decreased because of pair programming
● Teams work on their own time, so no imposing hours
● Changes can be made at a short notice because of freedom
● Code is clear and comprehensible at all times because communication exists
between all layers at all times
● Simplicity being one of the core values of IXP ensures that code written in all
phases is at its simplest form
● Accountability exists in all forms as progress and accomplishments are kept in
check
● Regular and automated testing ensures minimal bugs and glitches

Disadvantages of IXP
● Workload is increased due to increased principles
● Customer participation is necessary for adhesion to principles
● Time investment is relatively larger
● Costing is increased
● Version management is very necessary
● Requires increased amounts of discipline for enforcement
● Code quality assurance is not guaranteed. The simplest code is not necessarily
the best

The XP Debate
All new process models and methods spur worthwhile discussion and in some instances
heated debate. XP has done both. Among the issues that continue to trouble some
critics of XP are:
● Requirements volatility
● Conflicting customer needs
● Requirements are expressed informally
● Lack of formal design

Conclusion
IXP evolved out of many experiences and experiments with XP in large organizations.
Over the past few years, it has helped numerous companies in diverse industries
 6

repeatedly achieve significant successes in software development. IXP owes much of

its wisdom to XP and remains an organic evolution of XP that is tailored to meet the
needs of large organizations

References
1. Roger S. Pressman Software Engineering, A practitioner’s Approach [7th ed]
2. Agile Alliance: What is Extreme Programming?
3. Altexsoft: Extreme Programming
4. Ionel IACOB, EXTREME PROGRAMMING AND RATIONAL UNIFIED
PROCESS – CONTRASTS OR SYNONYMS?