Extreme Programming (XP)

XP, is one of the most popular agile methodologies. XP is a disciplined approach to delivering high-
quality software quickly and continuously. It promotes high customer involvement, rapid feedback
loops, continuous testing, continuous planning, and close teamwork to deliver working software at very
frequent intervals, typically every 1-3 weeks.
The original XP recipe is based on four simple values simplicity, communication, feedback, and courage
and twelve supporting practices:
1. Planning Game
2. Small Releases
3. Customer Acceptance Tests
4. Simple Design
5. Pair Programming
6. Test-Driven Development
7. Refactoring
8. Continuous Integration
9. Collective Code Ownership
10. Coding Standards
11. Metaphor
12. Sustainable Pace
In XP, the Customer works very closely with the development team to define and prioritize granular
units of functionality referred to as "User Stories". The development team estimates, plans, and delivers
the highest priority user stories in the form of working, tested software on an iteration by iteration
basis. In order to maximize productivity, the practices provide a supportive, lightweight framework to
guide a team and ensure high-quality software.
Extreme Programming aims at bringing about efficiency in the coding process and providing customers
with maximum value.
The advantages of Extreme Programming include robustness, resilience, cost savings, lesser risks, and
better overall satisfaction. Extreme Programming (XP) marks a departure from the
conventional programming approach. It stresses importance to individuals and interactions over
processes and tools, working software over documentation, customer collaboration over contract
negotiation, and responding to change over following a plan.
Advantages of XP methodology
Robustness
Extreme Programming leverages the power of simplicity. The design resembles a jigsaw puzzle with
developers working on many small pieces or iterations. The combination of such iterations at the end
gives the end product. This approach creates working software faster with very few defects. Regular
testing at the development stage ensures detection of all bugs, and the use of customer approved
validation tests to determine the successful completion of a coding block ensures implementation of
only what the customer wants and nothing more.
One advantage of this approach is allowing for cost estimates-based software features instead of
developer activity. This allows customers to make intelligent decisions on what needs inclusion and
what needs exclusion depending on the budget. By selecting the important requirement first, the
customer obtains maximum value with the least amount spent, and this can affect a trade-off on the
marginal increase in product utility with the cost to incorporate additional features. This approach also
allows both the user and the customer to "pull the plug" on development at almost any time and still
have highly valuable functional codes, even if incomplete.


Resilience
The traditional approach of programming works best when requirements remain static. In actual life,
requirements keep changing either because of emergence of new business opportunities or simply
because the initial requirement-gathering phase was incomplete. Extreme Programming in-builds
accommodation of such changed requirements through getting user stories at the start of iterations,
and through feedback during the course of iterations.
Cost Savings
Extreme Programming trims unproductive activities to reduce costs and frustration of everyone
involved. It allows developers to focus on coding instead of wasting time on needless paperwork and
meetings and does away with the need for separate testers.
The cost of making changes increases as the software advances in its life cycle, with the cost of making
changes after delivery anywhere between 5 and 100 times more than the costs of making a change at
the design stage. Conventional programming methods make changes based on customer feedback at
the end of the product lifecycle, whereas Extreme Programming allows changes at the development
stage.
Lesser Risks
One of the major advantages of Extreme Programming is that it reduces the risks related to
programming. Conventional programming depends a lot on individual superstars or critical members in
the team. Extreme Programming, by breaking the tasks into modules, spreads the risk and reduces the
dependence on any one architect, project manager, or individual coder.
Employee Satisfaction
Extreme Programming, while reducing the importance of individuals in the development process, also
helps increase employee satisfaction and retention. Extreme Programming is a value-driven approach
that sets fixed work time, with little scope for overtime. The breakdown of project scope into
subcomponents and the constant customer feedback prevents accumulation of much work to be
completed before a tight deadline.






Disadvantages
The biggest disadvantage of Extreme Programming is that it assumes the constant involvement
of the customer. Its success depends on data collection at many stages of the development
process. Many customers might not be available, and many others might dislike such constant
involvement.
Extreme Programming code is a centered approach rather than a design-centered approach, and
the lack of proper documentation creates problems in large products when project members
leave and new members come in later.
Extreme Programming is hard to do. The difficulties to get many developers accept this practice,
and it takes a lot of discipline to keep doing them all. Your customers may not like the idea of so
much involvement. Management may also find problems to get used with the practice that
changes dynamically during the project life cycle.
XP team does not believe the idea of fixed price, fixed scope kind of terms with the customer.
Other processes are more likely to encourage the creation of detailed planning from the
beginning.
XP encourages pair programming. There may be a huge amount of duplication of codes that
clubs with unit test. As a result, it is going to take long time to run and leave the database with
lot of duplicate data.
XP is code centric rather than design centric development. The lack of XP design concept may
not be serious for small programs. But, it can be problematic when programs are larger than a
few thousand lines of code or when many people are associated with the project.
XP does not measure or plan Quality aspect of development. Managers for the big project
believe that quality planning helps properly trained teams produce high-quality products.
Another basic problem is that software today are very large and complex by nature. XP
emphasizes on refactoring during software development process.
Since, XP programming is not structured, it may be difficult to find significant number of defects
for testers by just mere looking at the screen. On the contrary, traditional programming enables
testers to find improved number of defects because it is well documented.








Dynamic Systems Development Method (DSDM)


DSDM is based on nine key principles that primarily revolve around business needs/value, active user
involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration.
DSDM specifically calls out fitness for business purpose as the primary criteria for delivery and
acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the
time.
Requirements are baselined at a high level early in the project. Rework is built into the process, and all
development changes must be reversible. Requirements are planned and delivered in short, fixed-length
time-boxes, also referred to as iterations, and requirements for DSDM projects are prioritized using
MoSCoW Rules.
All critical work must be completed in a DSDM project. It is also important that not every requirement in
a project or time-box is considered critical. Within each time-box, less critical items are included so that
if necessary, they can be removed to keep from impacting higher priority requirements on the schedule.
The DSDM project framework is independent of, and can be implemented in conjunction with, other
iterative methodologies such as Extreme Programming.


There are 9 principles which are essential to any DSDM implementation, ignoring one of them will break
with the frameworks philosophy and significantly increase project risks.
1) Active user involvement Imperative.
2) Teams must be empowered to make decisions.
3) Focus on frequent delivery.
4) Criterion for accepted deliverable (Fitness for Business).
5) Iterative and incremental development Mandatory.
6) All changes during development must be reversible.
7) Requirements are base lined at high level.
8) Testing is integrated throughout the life cycle.
9) Collaborative and co-operative approach.
Project structure
The DSDM project consists of 7 phased steps which are organized and embedded in a rich set of roles
and responsibilities and are supported by several core techniques.
Roles and Responsibilities
Team Organization and Size
7 Phases to Rule Them
-Pre-Project
-Feasibility Study
- Business Study
-Functional Model Iteration
- Design & Build Iteration
-Implementation
-Post-Project








Core Techniques Used in DSDM
Timeboxing
Traditional Project Management uses milestones whereas DSDM uses Timeboxing technique. Is an
interval, usually no longer than 2,4 or 6 weeks, where a given set of tasks should be achieved.
Timebox
Can contain several tasks.
At the end needs to deliver a product.
Are subject to change since tasks are defined, not what to be delivered.
Can change the tasks during time box iteration which allows for rapid response to business
needs.
DSDM drops functionality in favor of delivering in time.
MoSCoW Rules
DSDM projects are concerned to be in time and on budget and users are heavily involved in the
development process. So it is mandatory to keep on watch on what users need the most.
User requirements may change ( during the process) ;
Aware of new technical possibilities
User work environment changes
The DSDM techniques to weight the importance of requirements are the MosCow rules. And the rules
are as follows,
1. Must have: All features classified in this group must be implemented and if they are not
delivered, the system would simply not work
2. Should have: Features of this priority is important to the system but can be omitted if time
constraints endanger.
3. Could have: These features enhance the system with functional items which can easily be
reassigned to a later timebox.
4 .Want to have: These features only serve a limited group of users and are of little value.




Prototyping
Evolutionary prototyping in DSDM projects satisfy 2 principles,
Frequent Delivery
Incremental development
Implements critical functionality first so can discover difficulties early in the development process and
allow having early deliverable to get user feedback.
The necessary feedback-loop is provided by a workshop which is the last important technique in a DSDM
project.
DSDM differentiates on the following for types of prototypes,
1. Business Prototype : Allow assessment of the evolving system
2. Usability Prototype : Check the user interface
3. Performance Prototype : Ensure solution will deliver performance or handle volume
4. Capability Prototype : Evaluate possible options
Advantages
Acceptance of DSDM philosophy before starting work.
The decision making powers of users and developers inside the development team.
The commitment of senior user management to provide significant end-user involvement.
Incremental delivery.
Easy access by developers to end-users.
The stability of the team.
The development team skills.
The size of the development team.
A supportive commercial relationship.
The development technology.



Disadvantages of DSDM:
High cost
Relatively high barrier to entry
Cultural shift in organization





















Feature-Driven Development (FDD)


Basic processes of FDD.
1. Develop Overall Model
The modeling team comprises development members, domain experts and the chief programmers.
Development members are guided by an experienced Chief Architect. Initially a high-level walkthrough
is done followed by a detailed walk-through which gives an overview of the domain.
Small groups should be formed which each group is responsible in composing a model. The Chief
Architect can propose a "strawman" model to make possible the progress of the teams. A member from
each small group presents that groups proposed model for the domain area. The Chief Architect may
also propose further model alternatives. The modeling team selects a proposed model or composes a
model by merging ideas from the proposed models.
Outcome
Class diagrams with Methods and attributes identified
Sequence Diagrams
2. Build Feature List
The team needs to identify the features. Features are rough functions expressed
in client-valued terms using this naming template:
<action> <result> <object>
For example, calculate the total quantity sold by a retail outlet
A feature will not take more than two weeks to complete. When a business activity step looks larger
than two weeks, the step is broken into smaller steps that then become features.
Outcome
Features List
A list of subject areas and list the corresponding business activities
3. Plan By Feature
The project manager, development manager and the chief programmers plan the order that the
features to be implemented. It is decided considering the feature dependencies; load across the
development team and also on the complexity of the features to be implemented.
Chief programmers are the owners of business activities. They are assigned considering the
development sequence , dependencies between features in terms of classes involved , balancing load
across class owners , complexity of the features to be implemented.
The planning team can assign developers as class owners. Developers may own multiple classes.
Outcome
Business activities with completion dates
Chief programmers assigned to business activities
Subject areas with completion dates
The list of classes and the developers that own them
4. Design By Feature
The features that need to be developed can be assigned to the Chief Programmer. The Chief
Programmer selects features for development from the assigned features. He can choose multiple
features which use the same classes.
The Chief Programmer forms a Feature Team by identifying the owners of the classes likely to be
involved in the development of the features which was selected for development. Then the team
produces the Sequence Diagrams for the features. The Chief Programmer refines the
Object Model based on the sequence diagrams.
Outcome
Successfully inspected Design Package.( The design package includes a covering memo, or paper, that
integrates and describes the design package)
5. Build By Feature
The development class owners implement the items necessary for their class to support the design for
the feature. Once the code is developed, carry on unit testing and code inspection. After a successful
code inspection, the code can be build.
Outcome
Successfully code inspected classes and/or methods
Classes that have been promoted to the build.
Usage of FDD
Ideal for systems where their business changes so rapidly and for long time projects
For web design and development projects
To build and design software
For Enterprise using ALM (application lifecycle management) solutions
Advantages of FDD
1. Lads to move to large projects and obtain repeatable success.
2. Practicing the five processes helps to bring new staff in with a shorter ramp-up time.
3. Feature-Driven Development is built around a core set of industry-recognized best practices
Regular Builds - Regular builds ensure there is always an up to date system that can be demonstrated to
the client and helps highlighting integration errors of source code for the features early.
Visbility of progress and results - By frequent, appropriate, and accurate progress reporting at all levels
inside and outside the project, based on completed work, managers are helped at steering a project
correctly.
4. Risk Reduction via iteration of design & build in small chunks.
FDD helps in reducing risks using shorter iterations of designing, understanding of the requirements and
the system- in a clear and distinct way, thereby leading to a state where there are no ambiguities, as the
needs and expectations are already understood very well.
5. Clarity of requirements and better understanding of system to be built is gained through the Develop
Overall Model process. This process includes high-level walkthrough of the scope of the system and its
context. Next, detailed domain walkthroughs are held for each modeling area.
6. Costing the project by feature leads to greater accuracy.
Disadvantages of FDD
1. Not as powerful on smaller projects (ie, one developer, only one person modeling)
2. High reliance on chief programmer. He act as coordinator, lead designer, and mentor.
3. No written documentation.


Recommendation
In comparing all the possible methodology, we believe Extreme Programming is the most suitable. The
nature of project and product that is undertaken by the organization can manage by using this method.
Based on the product and project, customers involvement is considered as priority. Apart from that the
products also require constant update and new feature to stay relevant in market. Constant engaging
the customers could reduce errors during project as well. A better team work and coordination within
the organization can be achieved using this methodology. Cost management is better, as this
methodology do not work on fix price. Price are determined based on the work completed and amount
of effort that is being used.
This methodology could help the organization to have a better relationship with client, managing project
and product better, improve team performance as well as managing the cost of the project in a better
way.