Extreme Programming

Extreme Programming (XP) an agile software development method, used to develop functions
for software projects. XP is most commonly, due to its resilient behavior which welcomes
requirement changes at any stage, moreover XP focuses on software that is rich in quality,
specifically to the functions/technologies that are needed to day at this time not the future.
The XP practices are the primary reason for the success of this methodology. Twelve XP
methodology commandments that has to be followed are the practices, which includes :

The Planning Game

Development team and the system owners gather around to discuss the features of the
required system that will impose maximum effect on the business. The customer
requirements are later written down informally into an Index Card given to the Customer, the
details/text/requirements written in the Index Card are known as User Stories, after collecting
the User Stories, the development team will review the user stories and the User Stories will
be arranged in order according to the main functionality or the risky functionality, usually
this type of User Stories will be listed on top the list. If the user story is too long the story
will be broken down into smaller stories. At the same time, the estimated lead time/complete
time, resources and etc. will be estimated for each and every story in the list, but if there are
any story that the development team cant confidently estimate the lead/completion time , a
spike solution is done, a small prototype which is done to experiment the estimated time,
performance of the function or different strategies in creating the function. After the task is
complete, the Development team will meet with the business owners to inform the list of task
that will be done according the story list for confirmation and negotiation, customer will
confirm the should have functions and could have functions of the system, if extra
requirements are added obviously the User Story is reviewed again and the time and
resources will be estimated again. After it is done the user chooses to have small releases of
the system as per listed in the story list or the users chooses a specific functions that has to be
done first and released.
2. Small Releases

XP Methodology practices small releases every 2-3 weeks, this means that a set of functions
based on the Customers need, the functions are developed and are released 2-3 weeks and
before release the set of functions are reviewed by the customer, and it there is any changes
or new requirement requested by the customer the specific set of functions will repeat the
iteration process until gaining approval from the customer.
3.Metaphor
Metaphor contains system names and descriptions that helps to guide the development team to
understand how the system works
Example:
A payroll system is complete project whereas the money(to calculate the pay) is a part of the
payroll system. This shows the developers that money is a part of the payroll system.

4. Simple Design
The XP methodology focuses more attention on design the application in a simple way, the
practice of Keep It Simple is followed by all developers, the development team are trained not
to predict the future requirement but focus more on the requirements that are needed now,
because requirements change time to time, ex:
Requirements which are futuristic is developed and releases but there is high chance for the
requirement to be obsolete in the nearest time, week or month, it is not guaranteed.

5. Testing
The test- driven approach used in the XP programming is a technique that is very effective in
many sense, test-driven typically means that the test unit of the software is already written, It
means that the areas/code which might go wrong during development is already identified,
reflecting to this data the software is developed based on the test-driven data.
Types of Test:
(1) Unit Testing
a. The developer has to pass all the test cases (test driven data) 100% and including
his own test cases, before integrating the code into the code base. This is done to
make sure that the developed function from this developer doesnt override any
other developers codes during implementation of the functions.
(2) Functional Testing
a. The developed functions are tested before release to ensure the function meets the
requirement and are fully functional. If the functional meets the requirements, the
function is declared complete.
(3) Automated Testing
a. When developers/programmers release their codes into the code base, all the
codes are integrated and tested to ensure that all the codes are 100% running all
the time. This gives the developers are broader view on their performances.

6. Refactoring
Refactoring is practices of improving the code structure in codebase to be more readable and
expressible to developers to reduce errors and improve the source code maintainability.
7. Pair Programming
The programmers are allocated to develop a specific function, because two brains are better than
one, this technique allows one programmer to write the codes and another one to review the
codes, and at the end of the a high quality codes are written by the programmers.
8. Collective Code Membership

All codes written and produced belongs to all the team members, one has rights to change or
improve certain parts of the codes in codebase anytime. This allows users to implement new
ideas to the project.
9. Continuous Integration
Software systems are produced and they are integrated several times a day. This allows early
detection of compatibility problems. The changes has to be made in the codebase to avoid
repetitive testing again.
10. 40 Hour Week
Programmers only work for 40 hours a week and there is no need of overtime, if the need of
overtime rises, it indicates that there problems in the XP Process.
11. On-Site Customers
A representative from the customers side or a group of customer itself will be made available at
the development area of the system, this is to allow customer to have a look at the functions
developed and customers area permitted to try the functions by themselves, moreover by having
a customer onsite , allows the developers to ask questions regarding and doubt that occurs during
the development. This technique reduces the need of documentation that has to be provided to
the customer.
12. Coding Standards
All developers involved in the XP process uses the same Coding standards which makes easy to
work in pairs and to share ownership of the codes.

XP Processes

Planning:
During the exploration phase the customer defines the requirements or how he/they want the
system to perform and to have. The customer writes User Stories onto index cards. The story
represents the functionality that he wants. The developers estimates duration to accomplish the
needed functions, therefore the users are advised to write the User Stories in more detail without
having technical details in the story. The user stories are used as a key data in functional testing,
between the user and the developer to check whether the system has been built according to the
user stories. If the user story is not good enough to estimate the finish time, a spike (prototype) is
develop to experiment the time needed to develop, the performance and etc.
After the development team has the done with the estimation for the User Stories, a Commitment
Schedule meeting is arranged. Based on the load factor which represents the actual needed time
between (calendar time) the estimated time needed to accomplish the task. The load factor is
adjusted accordingly when spike solutions are created during the exploration phase.
After the commitment schedule is confirmed, the customer chooses the scope of release in one of
two possible ways:
(a) The release is done and released based on a specific date
a. Functions are released based on the load factor.
(b) The customer chooses a set of functions
a. Customer chooses the specific set of functions, the developers selects chosen
functions in calendar time and sum up the estimation to get the time needed to
complete the set of stories (functions).
Development
The task of splitting the stories are done first, the stories are splitted in to two categories ,
foundation stories and dependent stories. During this stage the developers takes responsibilities
by selecting the stories to be developed. If the developer is over booked , the developer has to
give up some of the chosen stories to be developed by giving it to other under-booked or
developers or shifted to the next iteration.
After the above process, the actual coding begins and the functions are implemented and the
functions undergoes functional testing and etc. and are shown to the customers for reviewing the

system to gain approval. If customer wants to add on, the set of functions undergoes the iteration
again and reviewed by customer, if it satisfies the customer the set of functions are Released.

Dynamic Systems Development Method

Dynamic System Development Method is a method that is grouped under the agile development
methodology; in short its called as DSDM. DSDM is a framework used to develop softwares.
The primary aim of this methodology is to produce/develop systems is released within the time,
and within the proposed/given budget.
The nine main practices that are keenly followed by the development to accomplish and develop
a successful system is listed as below:
(1) Active User Involvement:
The active user/customer involvement during the project, because due to a couple of
knowledgeable users who takes part with the development team ensures that there is no
misunderstanding on what the system should do, which eases the chance of passing the
acceptance test at the end.
(2) Teams Must Be Empowered To Make Decisions:
To enable the project/development to accelerate fast, participants has to be given a minimal
authority to make decisions on their own:
Ex: Participants are allowed to prioritize the requirements and the features of a system by their
own.
(3) Focus On Frequent Delivery:
The development team has to deliver the sub-products frequently in order to maintain the correct
phase of the project and also by completing and delivering the sub-products, the errors in the
sub-products can be easily identified and it much more easier than completing the whole system
and then solving the errors.

(4) Fitness for Business Purpose is Essential for Acceptance of Deliverables:

This practice is done to make sure the features of the system or the system itself is developed in
the best quality and the right method. Moreover the system built has to be fit for the business,
this means that the system developed should be useful for the business purpose rather than
having advance features that dont relate to the business purpose.
(5) Iterative and Incremental Development is Mandatory:
With each releases adding new features to complete the whole system, it is accepted that all
requirements will change time to time.
(6) Changes during Development are Reversible:
Due to the requirement changes during the development phase, there might be errors in the
configuration of the system, because some requirements that are only realized might be higher in
priority than the previously identified requirements, but since DSDM advises small increments
the amount of previous work loss is limited.
(7) Requirements Base-lined as High Level:
All the requirements collected at the early stage is categorized as a high level scope for the
project. Detailed requirements area gathered during the iterative stage of the project.
(8) Testing Throughout The Life Cycle:
Testing is made from the beginning of the development phase, ex:
-

Functional Testing (Users)

Acceptance Testing (Users)
Technical Purpose Testing (Developers Side)

This is done to ensure that the system or features developed meets the requirement of the users,
by implementing testing throughout the lifecycle improves the quality of the system produced as
it moves on.
(9) Collaborative and Co operative between developers and system owners:

To develop a system that is really successful does need the co-operation not only from the
developers and certain users, but also the whole organization. The method of gathering
information can completed with ease.
DSDM Life Cycle

Pre-Project Stage:
The project begins at the Pre-project stages, where the feasibility and business study is done
sequentially.
Feasibility Study:
-

In this phase the possibility of building this system is studied, which includes the
budget, the team, the resources, the functions proposed and etc. During the feasibility
study a report is generated which contains the details about the proposed system and
the data collected.

Business Study
-

To study the overall business process of the requested system, to understand the
business processes and the user that will be affected or using the system after the
system is completed. By combining both of the above data, a business area definition
report is generated which will produce the system architecture definition and
development plan which consist of prototyping strategy, testing strategy, and

configuration management plan.

All the business process are written and it is overlooked into if the technical
capabilities are available to meet the requirements, later on the requirements are
prioritized based on their impact, to the business.

Functional Model Iteration:

The requirements from the above studies are finalized and prioritized and are built into a
functional prototype wherein a model of another requirement another is built incrementally:
Identifying Functional Prototype:
-Based on the listed requirements, the key functionalities are identified.
Agree Schedule:
-

A schedule is formed to build the finalized functionalities. Tasks are allocated among
teams and the deadlines for the functionalities to be built are all informed.

Create Functional Prototype:

-

Based on the selected functionalities, a functional prototype is built. A unit test is also
done in order to identify error before demonstrating to the end users.

Review Prototype:
-

The functional prototype is demonstrated to the users. The comments given by the
end users are taken note and areas to be improved are also taken note.

Design and Build Iteration:

After the completion of the above stage, a high standard system is built based on the prototype
built in the Functional Model Iteration.
Identify Design Prototype:
-

Once all the requirements are added to the prototype which includes the
approval/confirmation from the user, a final system is built based on the prototype.

Agree Schedule:
-

A schedule is formed, and the task are all identified and allocated to the respective
teams.

Create Design Prototype:

-

The system is designed and given to the testers and end user for testing, the end users
will review the system and comment on how the system could be improved further.

Review Design Prototype:

-

The reviews are taken note and corrections and improvements(if any) are done.

Implementation:
System is implemented to the live environment and end users are allowed to operate the systems.
Training for end users on operating system is also conducted. Feedbacks and reviews are still
collected from end users, the feedbacks are analyzed to identify if the built system meets the
business requirement and provides solutions for previous business problems. Business review
here means that, to identify if the system meets the business needs, and it is taken note and any
other new functionality that will impact the business is also taken note and are queued for the
next round of iterations.

SCRUM Methodology
Scrum is a framework used to organize a SCRUM development team, to ensure the work is
completed with a high quality output. Scrum methodology focuses more on business values in
providing what the functions which is required for a business. Moreover Scrum welcomes
requirement changes, this proves that Scrum methodology is flexible which allows functions to

be changed or added before shipping/releasing the fully functional system that meets the
customer requirements.

SCRUM Process
Product Backlog
Product Backlog is an artifact which is important for this methodology. The Product
Owner (proxy for the company), the product owners is responsible to gather inputs
from the customer or the end users which includes stake holders in what the
system/product should do. In some cases product owners and customer might be
the same person. The role of the product owner is to typical collect the data from
the customer and translating them in to product visions. This product visions are
added in to the Product Backlog, this means that the product backlog is everything
that has to be done in the system. The product owner has to prioritize the
requirements in the product backlog from the highest to the lowest. The product
backlog will be regularly updated by the product owner to reflect changes in the
needs of the customers, announcements by the competition, new ideas or insight
and technical hurdles.
Deliverables : Product Backlog

Sprint
A Sprint Planning Meeting takes place at the beginning of each sprint. A sprint is
between 2-4 weeks. The sprint planning meeting is divided in to 2 parts. The first
part of the SCRUM meeting is the Product Owner, SCRUM Master and the SCRUM
development team will meet to review the product backlog, to discuss the goals and
the contents in the product backlog. The second part of the meeting the Scrum
development team selects the items from the Product Backlog to commit to
complete, rather than having the product owner to assign it to them. Items are
chosen from the top of the product backlog ( highest priority ), but at sometimes a
slightly lower priority item is also pulled if the item can be completed as a part of
the high priority item.
After the commitment on the items from the Sprint Planning Meeting, the SCRUM
development team will estimate how much a SCRUM development team which will
have around 5-7 group members which consist of programmer, tester, GUI
designers and etc. estimates how much time each member will work to finish the
committed work. After the commitment in the product backlog is done, the SCRUM

development team breaks down the item committed from the Product Backlog into
smaller task among the team are recorded into a document called as Sprint
Backlog. Before the breakdown of the task, there will be a discussion between the
product owner and the team to clarify points, verify tradeoffs and breakdown
smaller backlogs in to smaller pieces, at the end of the meeting the team produces
a list of all task and who are committed to complete the task. A visual task tracking
tool , which consist of Not Yet Started , In Progress , To Verify columns are
made when the sprint commence to keep track on the task.
When the sprint commences the product owner cant add new request during the
sprint. If the product owner wishes to add new requirements, s/he has to wait till the
next SPRINT commences, but if the external circumstances appears for example the
change of priority , the product owner has the right to terminate the sprint, which
means the SCRUM development team stops all the work and restart from the
SPRINT Planning Meeting.
Deliverables: Sprint Backlog
Daily Scrum Meeting
Daily SCRUM is a daily meeting which is 15 minutes long, this daily scrum is
attended by the Product owner, Stakeholders , The SCRUM development team and
anyone interested to attend, the purpose of this daily scrum is to allow the team
member to report to other fellow team members in their group on what they have
done yesterday?, what will be done today? and the obstacles in their way?, the will
be no discussion allowed during the SCRUM meeting . The product owners and
stakeholders are not allowed to ask questions or opening discussions during the
SCRUM meeting, if there is any discussion or questions it should be after the
meeting. After the meeting is done, the team members update the SCRUM burned
down chart on the remaining time to complete the committed task. The sprint
burndown chart is keep track on the progress of the backlog, it shows each day how
much work is done and the remaining time, until the commitment is done indicated
by the arrow pointing downwards to zero. If the curve is not tracking downwards or
towards the completion at the end of sprint , the development team has to pick up
pace in doing the task or simplify or pare down the things on what its doing. The
Sprint date is never extended it ends on the assigned date but if the team has not
completed the task they have to stand up at the end of the sprint and acknowledge
that they did not meet their commitment. To avoid this teams are advised to make
clear assumption before the beginning of the sprint, they will be no excuse on
pushing the unfinished backlogs in to the next sprint.

Deliverable: Sprint Burn down Chart

Sprint Review

Sprint review is done at the end of the sprint , where the built functions are
demonstrated to the product owners, stakeholders and anyone who are interested
to attend the demonstration event. There will be no power points, its typically on
demoing the functions and to get feedback. After the sprint review the scrum
development team and the scrum master sit together for a SCRUM Retrospective
Meeting, where they discuss what is working?, what is not working ? and what could
have been better?

Deliverables:
-

- Updated Product Backlog

Updated Sprint Backlog

Starting Next Sprint

Following the Sprint Review the product manager gather the input/feedbacks and
updates, modifies and delete necessary backlogs in the product backlog, and the
cycle begins with the next Sprint Planning Meeting.
An additional practice that most team find useful is to have a prioritization meeting
towards the end of each sprint to review the Product Backlog for the upcoming
Sprint with the product owner.

Release Planning
Sprints continues until the product owner decides the product is almost ready for
release, where at this stage the testing and integration is done for the launch. If the
teams has followed the right ethics during the development phase there will be less
cleanup required before the official launch. Some sprint is date-driven a specific
date is chosen and teams work very hard it to complete as much sprint as possible
to release the products on the date. A release plan is developed for example the
backlog is divided according to the date given, for example if a version 1 would be
released on 1 January 2015 , the development team will split the backlog
accordingly and multiple sprint will be done to complete the expected functionalities
that has to be released on the date.