Extreme Programming: Agility Delivered

NCISE - 2009 Extreme Programming: Agility Delivered

( Paper ID – 106)

Author

Praveen Srivastava

E Mail [email protected]

Phone – 080-25246831, 09880657932

Sr. Technical Lead, Motorola India Private Limited.

Associate Member – CSI, India

mailto:[email protected]

mailto:[email protected]

NCISE 2009 - Paper id – 106, Extreme Programming: Agility Delivered

Author - Praveen Srivastava E Mail [email protected]

Objective

Addressing challenges of changed market demands and use of XP to overcome these

Conventional SDLC phases are discussed with respect to established XP practices

Factors responsible for development of new agile methodology and how XP techniques influence those

Extreme programming ( XP) in terms of SDLC phases.

Partial XP - Merits and Demerits of partial XP implementation



Cost of Change Curve



Cost of change curve contd..

This is most popular curve in software engineering,

and shows that cost of fixing a defect rises

exponentially over time.

Defects found in later phases are most undesirable.

But dynamic project requirements causes change in

design leading to code rework and escape defetcs.



Cost of change curve contd..

XP allows the requirements to be added any time

during project cycle thus making above curve

asymptotic.

Most of the XP techniques such as pair

programming, constant re-factoring, constant

integration are based on this fact and help to

minimize other impact of dynamic requirements.



XP Planning

Conventional project planning is dependent upon

four control variables, time, cost, quality and scope

Changing scope gives rise to the concept that

planning need to be more release centric with larger

room for correction whenever needed

XP supports this correction by iterative planning,

done mutually by business and development

making business representative also part of project

team



XP Planning –Release Planning



XP Planning –Release Planning contd.

XP planning is iterative in nature so some times termed as iterative planning also.

User stories are created by business and estimates are done by development.

Business team , based on estimates and other critical factors plan release schedule. Other critical factors include

– Critical requirements

– Estimation risk

– Velocity of the project

User story review, estimation and schedule planning is done iteratively based on unit test results to correct any misjudgment in estimation.

Iteration planning for development is not much different from release

planning



XP Requirement

XP requirement phase is different from traditional requirement. Generally business needs are dynamic by nature and project dependent.

Some businesses ( such as web portals) inherently have changing requirements where as some has ( such as government missile development ) long term objective and frozen requirements.

So, change in requirement during development is inevitable in some cases and impacts the cost of the project adversly.

Agile methodologies including XP attacks the concept of requirement freezing and provides way to implement it



XP Requirement contd.

XP suggests to start the development with basic requirements and add new requirements over a period of time, this approach aligns with another XP practice “Emergent Design”.

Business team write the requirement in the form of a story on a card.

Technical team studies the requirement and provide development estimates.

Business team analyzes the estimate and depending upon importance of the requirement, plan the requirements in releases



XP Requirement – User story



XP Requirement – Onsite customer

Requirement is done by functional expert in the development team called onsite customer. Functional expert basically represents business.

Onsite customer prepares small scale priority for the releases and write small functional tests

Onsite customer is also responsible for reporting the project progress to the management and verify the results of functional tests

Many times business does not want to part with experienced functional expert as onsite customer and this creates a major problem.



XP Design

Generally any design fault escaped beyond design phase is expensive as it needs analysis, possibly design change and a fix , XP suggests to keep design open during development cycle

Design in XP starts with a very simple idea

Design Complexities are added on daily basis during development phase giving rise to the concept of emerging design.

Other XP practice such as pair programming and rotation of the pair programmer ensures that all the team members are updated on the emerging design

Emergent design is communicated among the programmers by code



XP Design contd..



XP Design - Implementation

Design in XP is done parallel to coding and testing It

may starts with half an hour get-together of team.

Sketch pens, notebooks and white boards are only

tools used

XP terms it as design-after-first-test (DAFT)

Flaws in DAFT

– Nothing but Re-design

– It is already existing in form of early prototyping

– Not well suited to multithreaded systems



XP Coding, Testing and Integration

Generally absence of upfront design runs the risk of project steering in wrong direction

XP development strategy primarily revolves around code and focused to mitigate this risk.

XP way for development – Pair programming

– Continuous integration

– Constant re-factoring

Unit tests are written even before code is ready

XP’s emergent design is achieved by constant integration




Integration is done frequently ( with in few hours ) of the development of new code which also ensures that changes are communicated to the team

Emergent design, out of constant integration and re-factoring, is communicated to the team through code

XP introduces a new role of coach. Coach ensures that team is coding in pairing, changing roles, changing partners and constantly re-factoring the code.




Issues

– Pair programming increases cost of quality (COQ)

– According to a study “pair programming increases the code

quality by 15% but takes on average 15% longer

– Wrong pairing leads to problems related to social

dynamics, lack of privacy, lack of “quiet thinking time” and

ergonomics issues.

– Old project metrics does not work to monitor the project

progress.



Partial XP

Many times XP is introduced in organization by initiating projects based on XP but deviates from using all the attributes of XP.

Managers tend to chose convenient attributes of XP which suits lesser effort and reduced cycle time

But partial XP does not work because no-upfront-design-documentation and pair-programming are tightly coupled.

Pair-programming actually compliments the lack of design.

Another tightly coupled XP practices are re-factoring and unit testing. Re-factoring may not result in improved quality of code if not supported by automated unit testing.



Partial XP - Case study

A giant financial institution (FI) having an in-house software department, introduced XP.

The end users of the system were going to be employees of the FI.

Highlights of the project: – No architecture and design needed as no new feature

introduced,

– Users of the system were readily available,

– Programmers were experienced and having good level of co-ordination and

– No formal sign off between development and business department.



Partial XP - Case study contd..

Above project had all the ingredients needed for XP.

Project was done successfully in scheduled time

without pair-programming.

Postmortem of the project revealed, it could do away

with the pair programming because of

– Existing strong functional understanding by the team

members and

– Good knowledge of design by team members by virtue of

its existing system.



Partial XP - Deviations and Complementary XP practices



Partial XP - Recommendations

Generally, it is not a good idea to tailor XP.

But if it is done, project velocity and quality

metrics need to be monitored closely

Under specific circumstances tailored XP can

give good results.

There is no specific guideline for tailored XP,

it varies from organization to organization.



Conclusion

XP critics claim that

– Difficult part of the project development such as scope and schedule, have been transferred to customer.

– Scope is variable and schedule is customer problem are two favorite punch lines of XP, supporting this view.

XP requires a very high level of discipline from team members and that is the reason it is not very successful with big teams and long duration projects.

Despite all this, positive side of XP has gained momentum and more and more companies are adopting agile technologies and tailoring XP as per their needs.



Questions?

Software

Extreme Programming: Agility Delivered