AWB - 11 - Extreme Programming

369 Agile White Book – AXA Emerging Markets EMEA-LATAM

Chapter 11 EXTREME PROGRAMMING

V1.0


Contents DIAGRAM ........................................................................................................................................................................................................ 372 EXTREME PROGRAMMING AT A GLANCE .......................................................................................................................................................... 373

WHY DO YOU NEED XP? ....................................................................................................................................................... 374

UNDERSTAND THE IRON TRIANGLE AND RISKS ........................................................................................................................... 375 KNOW THE CORE OF EXTREME PROGRAMMING ........................................................................................................................................................ 379

VALUES.............................................................................................................................................................................. 380

PRINCIPLES ......................................................................................................................................................................... 382 BEST PRACTICES ................................................................................................................................................................................................ 383

TEST DRIVEN DEVELOPMENT ................................................................................................................................................. 384

ACCEPTANCE TESTS ............................................................................................................................................................. 387

PLANNING GAME ................................................................................................................................................................ 388

WHOLE TEAM TOGETHER ..................................................................................................................................................... 389

PAIR PROGRAMMING ........................................................................................................................................................... 390

CONTINUOUS INTEGRATION .................................................................................................................................................. 391

DESIGN IMPROVEMENT (REFACTORING).................................................................................................................................. 392

SMALL RELEASES ................................................................................................................................................................. 394

SIMPLE DESIGN ................................................................................................................................................................... 395

SYSTEM METAPHOR ............................................................................................................................................................ 396

COLLECTIVE CODE OWNERSHIP .............................................................................................................................................. 398

CODING STANDARD AND CONVENTIONS .................................................................................................................................. 399

SUSTAINABLE PACE .............................................................................................................................................................. 400

SPIKE TO REDUCE RISK .......................................................................................................................................................... 401 XP OVERALL CHARACTERISTICS .............................................................................................................................................................................. 402

SCRUM AND XP .................................................................................................................................................................. 403 TAKE AWAY .................................................................................................................................................................................................. 404


Extreme Programming

Extreme programming is a methodology which

helps avoiding large, up-front design approaches

found in many software projects. It focuses on short

development cycles with high-quality and regular

potential software increments to the customer. It

also reinforces team working, good programming

practices and can be fully integrated into Scrum.


Diagram

EXTREME PROGRAMMING

I know the Extreme Programming benefits.

I know the XP essence and good practises.

I know the techniques for continuous improvement.

XP

BENEFIT

S

KNOW THE

XP ESSENCE

- Values

- Principles

- Project

variables

PRACTISES &

CONCEPTS

- Spiking

- Small Release

- Team practises

- Code practises

LEARN ABOUT

IMPROVEMENT

TECHNIQUES

- Refactoring

- Test-driven dev.

- Continuous integration

- Continuous deployment


EXTREME PROGRAMMING at a glance

Extreme programming (XP) is an Agile software development methodology which helps improve

software quality and responsiveness to changing customer requirements. It offers quick

feedback with frequent releases and short development cycles. This intends to improve

productivity and introduce checkpoints where new customer requirements can be accepted and

implemented.

XP includes practices and values which are compatible with the ones found in Agile. It

integrates a set of widely used and disciplined engineering tools, such as Unit Testing,

Continuous Integration, Refactoring and regular and responsible communication between

Business and IT.

Most of the concepts and practices found in Scrum are also used in here, such as Release

Planning, Estimation, Sprints with Customer Reviews, Daily meetings and User Stories

to capture requirements, so you will find XP familiar.

XP mainly focuses on keeping things simple and try to reduce complexity everywhere.



WHY DO YOU NEED XP?

We have seen in many traditional initiatives a common set of problems that make projects less

flexible and add several risks, such as:

- Business does not clearly understand requirements. - Schedule slips. - Business pressure on development teams reduces code quality. - Increase defect rate and lack of code standards. - Increase technical debt/unmaintainable codebase. - Lack of motivation in teams. - Lack of Team commitment.

These problems become critical but are not fully considered in traditional methodologies.

As I see, all these problems are tied up very closely and a complex solution that involves the

Team and technical approach is needed in order to:

Reduce project risk. Improve responsiveness to business changes.

Improve productivity throughout the life of a system. Add fun to building software teams and keep people motivated.


As Time is a strong variable in here, it

influences the dependencies between this

and the others.


UNDERSTAND THE IRON TRIANGLE AND RISKS

The heart of XP contains four main variables (Cost, Time, Quality and Scope) that are used

during the product development cycle, where Time is a prevailing element.

This is a huge difference with traditional methodologies where other parameters are used.

Cost – Indicates the amount of money to be spent in the initiative, people and

resources available (computers, equipment, logistic, etc.).

Time - Establishes when the product is expected to be released and its milestones or

intermediate goals.

Quality - The accuracy of the system as defined by the client and how well tested it

is.

Scope - What and how much functionality is included in the product and when.



The previous idea is to provide a clear relationship between them to help predict different

behaviours during a project lifecycle.

Let’s me show you some examples:

- If Quality is increased, then Time needs to increase as more testing is needed. - If Quality is decreased, then short-term time is reduced to a certain degree as

the number of functional tests are reduced (but technical debt is also increased.) - If Cost is increased (taking on board more developers) then it could mean less time

but also the opposite effect which is more Time (i.e. more people late in a project can increase overhead of communication).

- If Cost is decreased, then Time increases dramatically. - If Scope is increased, then more Time is needed as there is more work to do. - If Scope is decreased Time is reduced.

If for example, Scope is increased (more features are “pushed” into the team) and Quality and

Cost are held (same people and other resources), then Time must be increased in order to get

predicted results. There is a special situation here that arises when Scope is increased and

Time is fixed; XP prevents this situation by clearly stating that:

Business can control Cost, Quality and either Time OR Scope. The remaining variable is owned by development.



There are other risks associated that can jeopardise the whole project. Let’s take a look first at

these threats and see later how we can help diminish them:

- Change in Requirements There is a spread idea that requirements can be frozen or fixed in advance. We

believe that there are changes in almost all the cases as a result of:

o Users needing one or more changes as they learn a better way to solve a problem.

o The problem changes as clients discover what they want and get it by only seeing working software.

o There are market variations which make rules to change in an unpredictable way.

o Elements are immature, imprecise or not fully understood.

- Technology Two areas generally related to the Development Team but that compromises

everyone:

o New or not well-known technologies/tools. o People with lack of a required new skill. o Technical debt, where poor software architecture and

development exacerbates the time to market.

- Performance

Products that have problems regarding expected response time or work load.



In order to target the previous areas and bring a sustainable solution, XP provides guidelines for

Business and IT people:

Business people (Stakeholders, Product Owners, etc.)

o Are part of the Team. o Give frequent feedback based on working software increments. o are involved and writes requirements from their perspective. o Define Scope (what the system have to do). o Set Priorities (which requirements are more important). o Define the Release contents and when timeline.

(What makes up each release and when to deploy it).

Development Team

o Understands all requirements well. o Decides what is needed in order to consider a requirement

complete. o Estimates and decides what to take on board (Pull system). o Decides how to build a product in terms of technical

architecture. o Evaluates the consequences (what the implications of making a

particular decision are.) o Feel proud and responsible for their work.


KNOW the core of Extreme Programming

XP uses Values, Principles and Best Practises to establish some clear boundaries and allow

people work in harmony with personal and corporate values while staying aligned to clear beliefs.

That helps reduce risks and establish a concrete way of work.


Extreme Programming - values

VALUES

Values are a vital part to understand why XP works; people clearly need to interiorise them in

order to get its day-to-day benefits.

Simplicity

Teams will do everything needed and requested but nothing else. This helps maximize

the value created for the investment made. Small and simple steps should be taken

towards a goal and clear measures established to mitigate failures as they happen. People

should create something they are proud of and maintain it long term at a reasonable cost.

Communication

Everyone is part of the Team and daily face to face communication is a need. People

work together on everything from requirements to code.

Feedback

All iterations commitments are taken seriously by delivering working software.

Software is early and often demonstrated and requested changes are carefully listened from

clients. People will talk about the project and adapt its process to it, not the other way

around.

Respect

Everyone gives and feels the respect they deserve as a valued team member. People give

value even if it's simply enthusiasm. Developers respect the expertise of the customers and

vice versa. Management respects the right from people to accept responsibility and

receive authority over their own work.


Values need to be shared in order to avoid

creating a dysfunctional system!

Extreme Programming – values

Courage

People tell the truth about progress and estimates. They don't document excuses for

failure because they plan to succeed. Individuals don't fear anything because no one ever

works alone. People adapt to changes whenever they happen.

If people continuously give importance to different things, they won't converge on an agreement

but each will undermine the efforts of the others.


Extreme Programming - principles

PRINCIPLES

There are 3 principles that form the core of XP and are based on the values described above; they

are intended to foster decisions during the product development lifecycle. Principles are more

concrete than values and easily translated to guidance in practical situations.

Feedback

We believe in frequent and prompt feedback. It means that a minimal delay between

an action and its feedback is critical to learn and make changes. The customer should have

a clear insight into the system that is being developed, and should be able to give feedback

and steer the development as needed. As we will see later, Unit testing contributes to this

principle.

Assuming simplicity

XP treats every problem as if its solution were "extremely simple". Traditional software

development methodologies try to plan for the future and to code for reusability. Extreme

programming rejects these ideas.

Embracing change

People should never be working against changes but embracing them. If something has

changed dramatically, people need to embrace this and plan the new requirements for the

next iteration.


All of these things allow me

to do my job better!

Best practices We finally have 12 engineering practises that help bring the whole team together, support

frequent feedback and enable people see where they are.


Best practices

TEST DRIVEN DEVELOPMENT

Quality assurance is essential when creating software and Testing is a core technique in XP to accomplish it. Despite its name, Test Driven Development is a programming practice, not a testing technique. It is more about setting concrete, detailed expectations in advance, and allowing those expectations of code behaviour to guide the implementation than it is about testing. Let’s start with Unit Test…

A Unit Test is a piece of code that is automated and test functionality such as a class, method, function, etc. We will also see another type of test called Acceptance Test which is used to check client expectations such as requirements. One main difference is that Unit Tests are always written before the implementation is coded.

A common test-driven development sequence looks something like the following:

Create a Unit Test that exercises the functionality that you intend to develop.

Compile your Unit Test. It will fail to compile, because the code you’re trying to test does not exist yet.

Write just enough functionality to allow the Unit Test to pass.

Run your test(s). It will fail, because you haven’t actually implemented the class.

Write your class implementation.

Run your test again until it passes.


You should follow these three laws:

- Not to write production code unless you’ve first written a failing unit test.

- Not to write more of a unit test than is sufficient to fail.

- Not to write more production code than is sufficient to make the failing unit test pass.

Best practices

Because most of the TDD tools use a red signal when a test doesn’t work, and green when it does, we refer to this flow as Red-Green-Refactor.

Extracted from thealmightyjenny.com

We have seen that test-driven development gives developers the confidence to make changes to the product, because they know that the tests will tell them if they have broken anything and where. We found this as one of the most effective feedback mechanisms that the development team can have for guaranteeing stability and high quality. This approach also helps people think about conditions in which code could fail. XP says that a specific implementation is finished when the developer can’t come up with any further realistic condition on which the code may fail.


Best practices

You should always have in mind that a coding task in XP is split in very small steps, starting always with the tests. The following is our recommendation when coding a requirement:

Read the User Story (requirement) and analyse what is needed in order to consider it as done.

Write a Unit Test first, thing which will help you think of the solution before implementing a single piece of the solution.

Implement just enough code to make the tests run.

Refactor/Simplify the code if necessary.

Integrate the changes into the codebase and, if problems occur, resolve them. If the issues cannot be resolved, start over.


Best practices

ACCEPTANCE TESTS

A requirement in XP is written by following information contained in a User Story and a further communication with the client. A User Story has one or more sentences of what the user need in the everyday language of the business, all captured in a card.

One very positive aspect about them is that they have a list of what is needed in order to consider the requirement complete (Acceptance Criteria). It is here where a second kind of test called Customer Tests or technique Acceptance Test-Driven Development (ATDD) comes into play.

ATTD focuses on testing the functionality from the user’s point of view to ensure that the system implements the expected requirement and behaviours (i.e. Insurance was cancelled and client notified). When using them, Business and IT collaborate to produce testable requirements to make sure they are fulfilling the clients’ requirements. Check Chapter 4 (Agile Requirements) for more details.


Best practices

PLANNING GAME

Business and development work together to produce the maximum business value as rapidly as possible.

The planning game happens at various scales and its rules are:

Business comes up with a list of desired requirements for the product. Each feature is written as a User Story.

Development estimates how much effort each User Story will take, and how much effort the Team can produce in a given cycle.

Business then decides which stories to implement in what order, as well as when and how often to produce a product release.

Development Team analyses its capacity and sees what to take on board.


Best practices

WHOLE TEAM TOGETHER

In XP, the Development Team has continuous access to the customer who will actually be using the product or sit together to answer questions straight away.

A customer representative (i.e. Product Manager) can be designated or, if Scrum is used, the Product Owner will be the vital link. We strongly recommend an open space office in order to encourage full communication.


Best practices

PAIR PROGRAMMING

Pair programming is a method of programming in which two people work and share knowledge together. One person, temporarily types at the keyboard and the other reviews each line of code as it is typed, checking for errors and thinking about the overall design.

Some benefits you can expect are better code (simpler design, fewer bugs, more maintainable), higher morale (more fun!), shared knowledge throughout your team (both specific product and general programming knowledge), better time management, higher productivity. It also reduces the truck factor (“Number of people on your team who have to be hit with a truck before the project is in serious trouble”).

This is the ABC´s of pair programming that you should not forget:

All production code must be developed by the pair.

Both parties contribute to the solution switching roles frequently.

Change pairs frequently one to three times a day.

Develop at a comfortable computer that accommodates the people side by side.

End Pairing when people are tired. There is a suggestion here that no more than 2/3 of a day

should people be pairing.

There are some games that can be played to encourage pairing and make the activity more enjoyable. Pairing is also a great tool when you have senior and junior people working together as they make sure that knowledge is shared and the best possible code is produced.

Remote pairing can also be done but you need to double check that the tools to support a fluent communication are available (Check chapter 13 for more information about distributed Teams).


Best practices

CONTINUOUS INTEGRATION

Continuous Integration (CI) is a practise coming from Extreme Programming (XP) that uses a tool which helps developers integrate code and Unit Tests into a shared repository several times a day. Each time a developer checks-in their modifications/additions, the product is compiled, verified and tested by an automated build, allowing teams to detect problems early. By integrating regularly, people can detect errors quickly, and locate them more easily. Unit Tests are also run 100% before and after integration.

Inspired by simple-talk.com

We have seen that infrequent integration leads to serious problems on software products. Weak integration process leads to long development paralysis which means that people have long time periods where they could be working on important features instead of endlessly trying to find bugs. Continuous Integration requires members to:

Check in frequently.

Try not to check-in broken code.

Avoid checking-in untested code.

Never check-in when the build is broken.

Never go home after checking-in, wait until the product is fully built.

Make sure the build is self-testing.

You can also use Continuous Deployment, which is the practice of potentially releasing a good build to users, every time a change is made. By adopting both Continuous Integration and Continuous Deployment, you not only reduce risks and catch bugs quickly, but also move rapidly to working software and getting continuous feedback from customers.


Best practices

DESIGN IMPROVEMENT (REFACTORING)

As we mentioned before, XP advocates developing only what is needed today, and implementing it as simply as possible. One of the drawbacks with this approach is the need for constant maintenance. It is here where a technique called refactoring is used to improve or remove duplicated code generated during a coding session.

Refactoring is also a great lesson in understanding an unfamiliar code. It is basically a number of transformations that preserve code behaviour while focusing on simplicity. As automated tests are widely used, refactoring is simplified as changes can always be verified.

The steps to refactoring code are:

Run the Unit Test(s) associated to the functionality you want to refactor.

Improve/Simplify the code.

Run Unit Test(s) again and make sure they all pass and performance is good.


Best practices

As you can see, the process of writing Unit Test solidifies your understanding and expectations of the code before started working on it. The following are some of the common techniques used during refactoring:

Extract Method

Allow define a new method based on a selection of code already

existing in a method.

Encapsulate field Turns a public field into a private one by encapsulating it as a

property.

Extracts interface Defines a new interface type based on a set of existing type

members.

Reorder

parameters

Provides a way to reorder member arguments.

Remove

Parameters

Removes a given argument from the current list or parameters.

Rename Renames a code token (method, field, local variable, etc.)

throughout a project.

Promote Local

Variable to

Parameter

Moves a local variable to the parameter set of the defining method.

Check “Additional Resources” section for more information about different techniques to refactor software.


Best practices

SMALL RELEASES

In XP, delivery of the software is done via frequent releases of working software that creates concrete business value. The small releases help the customer to gain confidence in the progress of the project and keep everyone aligned with the current progress.

A small release is also cheaper than having big chunks delivered every few months as they allow people to see a working piece of software and get the return of investment more quickly. It also helps maintain the concept of the whole team as the customer can now come up with suggestions on the product based on real hands-on experience.

The idea is simple… code and small releases mean that you are traveling light: low up-front investment, and not much to slow you down when needing a change. Remember that not all the releases need to be public but can be available if needed.

A roadmap can also be used as an invaluable tool to associate specific releases with times and help align everyone´s expectations. Check Chapter 6 for more details.


Whenever a new piece of code is written, we ask… 'is there a simpler way to introduce the same functionality?'

Best practices

SIMPLE DESIGN

In XP a "simple is best" approach to software design is always favoured

A good trick for simple design is to think that everything in the system to be designed from the beginning will have little or no change throughout the development life cycle. Having in mind this idea, keep developers away from trying to predict the future and forces the design to be just enough to meet what is known about the system today.

It does not mean that no design is needed during the Release/Sprint Planning but that it needs to be “barely” sufficient. The detailed design starts during the first sprint and evolve in the subsequent iterations.

For this process to work, XP uses incremental an iterative software development. Iterative means that you write loads of stuff that works but is a complete mess and then start refining it. Incremental means that you write Part A and then add part B until the whole system has all the desired characteristics.


Best practices

SYSTEM METAPHOR

A system metaphor is a story that everyone involved (Business, IT, etc.) can tell about how the system works. XP uses a metaphor instead of a formal and detailed architecture, which means, a simple shared tale of how the system works. This story typically involves a handful of classes and patterns that shape the core flow of the system being built. Albert Einstein said "Explain it to me like I was a four-year-old kid". Metaphors create a way for everyone to share a common vision of what the system is.

If a customer tells the Development Team that the system needs an Insurance shopping cart feature (a metaphor), they should not have the need to initially go into significant detail as everyone knows what it is.

You don’t need the fine detail in order to clearly understand what it entails. System Metaphors generally help everyone:

- Define a common vision.

- Create a shared vocabulary.

- Think of the whole system and proactively bring new ideas.


Best practices

One of the usual techniques to create a metaphor is by organising a brain storming session, it means, a fixed-time meeting where everyone brings ideas about the system. Before the session, ask people to think of the whole system and have the most important objects in mind as well as its patterns and interactions.

Follow these rules for a successful brainstorming session:

- Do not criticise ideas.

- Encourage people to get huge number of ideas (and after the session focus on quality).

- Hunt for wild ideas and have fun.

- Give opportunity to everyone to participate.

- Encourage building on each other´s ideas.

Have in mind that metaphors only describe the logical architecture of the system in order to keep it simple to understand. This is, in the case of an object oriented system, the most important classes and objects and how they interact.


As a general rule, anyone can “touch” anything but we (the whole Team) are responsible for the results. This transforms us from being a group of individuals to a Team of highly committed people.

Best practices

COLLECTIVE CODE OWNERSHIP

In traditional development you divide an application in functional areas and assigning ownership of components or subsystems to specific individuals. The main issue with this approach is that creates bottlenecks which obstruct development when the component or subsystem owners are flooded with work. The result is a queue that affects other team members and creates a huge chain of delays, making more pressure on individuals and placing them in difficult situations.

XP uses the concept of Collective Code Ownership to eliminate bottlenecks, remove silos and share knowledge. In here, any developer has the right to change or enhance any piece of code within the application. It also motivates everyone to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, improve design or refactor.

Collective code ownership also encourages the transfer of knowledge among all people in the Team. As information is spread across and communication improves, the risk of people with specific skills not being unavailable and affecting the Team becomes lower.


Best practices

CODING STANDARD AND CONVENTIONS

XP projects use guidelines and rules for naming and formatting code. This specifies a style and format for source code, within the chosen programming language, as well as various specific constructs and patterns that should be avoided in order to reduce the probability of defects. The first step is for the Team to explicitly agree on a set of code conventions specified by the language or created by them. This means that each person chooses the names of classes, methods, variables etc. and makes sure they comply with the “rules”. Using them assures a more consistent product so that it is easier to read, understand, extend, refactor, etc. It also facilitates the journey to new members through the product. We recommend applying the following 2 guidelines:

- Create the minimal set of standards you can live with.

- Focus on consistency and consensus over perfection.

One way you can start a coding standard is by selecting an industry-standard style guide for the language. This will make sure you focus on the design and forget about the formatting.

When we talk about code-standards we are talking about the followings:

- Tools and IDE related.

- File and directory naming.

- Build conventions

- Error handling and assertions

- Approach to events and logging

- Practical cases conventions (i.e. how to deal with null references)

As a general rule, if developers find some part of the product that doesn’t follow the standards, they should refactor it accordingly.


Best practices

SUSTAINABLE PACE

Projects are usually extensive with overtime and many superhuman efforts to deliver by a promised due date. The result is an exhausted Team, less productive and a lower quality product.

The assumption in XP is that software development is not a sprint but a marathon. While a sprinter will easily beat a marathon runner over a very short distance, the second will always win in the long run. The idea is that Teams do not take on more work than they have proven to be capable of completing, which will ensure a cadence and help people perform best, most creatively, estimate and predict the future better.


What is the simplest thing we can program that

will convince everyone we are on the right

track?

Best practices

SPIKE TO REDUCE RISK

A spike is a commonly-used technique to reduce risks in projects. A spike is basically a User Story that cannot be estimated until a development team runs a time-boxed investigation. They may be used for a number of reasons:

- The team may not have knowledge of a new domain and can be useful for familiarising the team with a new technology or domain.

- The User Story (requirement) may be too big to be estimated appropriately and can help analyse how to split the story into estimable pieces.

- The User Story may contain significant technical risk, and the team may have to do some research or prototyping to gain confidence in a technological approach.

- The User Story may contain significant functional risk and were not clear how the system needs to interact with the user.

A Spike should always be wrapped into a Product Backlog Item and a maximum number of hours should be specified. Remember that the output of a spike story is an estimate for the original story.


XP overall characteristics

Let’s review the main Extreme Programming characteristics used in product during the product

lifecycle:

- Planning game is used; constant feedback and embracing change are day-to-day activities.

- Highly interactive small teams are in place (2-12 persons). - Open space offices are the right environment. - IT and Business cooperate and communicate in a regular and honest way. - Interactions such as workshops or demos are encouraged and frequent. - User Stories, Refactoring and Code Standards are heavily used. - Tools to support Continuous Integration and Change Management (code

repository) are in place. - XP Values and Principles are always present and widely used.


All of these things together

work very well for us!

XP overall characteristics

SCRUM AND XP

While Scrum manages the steps to develop a product, XP focuses on keeping the quality of

the software. Scrum uses a fix number of meetings and practises, such as Sprints, Sprint

Planning, Daily Scrum, Retrospectives, etc. and a number of roles that are defined in the

framework. When used along with XP, all their practises are added into the day-to-day (simple

design, Continuous Integration, Pair Programming, Code repositories, etc.) in order to get the best

of the two worlds.


TAKE AWAY

REMEMBER

Business is heavily involved and working with IT

Fast and collaborative short lifecycles and feedback loops are a characteristic.

Business value is the trading currency.

Extreme Programming Values and Practises are needed in order to implement it.

Engineering Practices are used by teams & sharing information is a day-to-day experience.

DEEPEN YOUR KNOWLEDGE

Extreme Programming Organisation

Refactoring Techniques(I)

Refactoring Techniques (II)

Ping pong pairing game

BENEFITS

Encourages communication between Business and IT.

Focuses on small releases and constant feedback.

Offer clear and very productive engineering practises.

Reassures simplicity in everything done.

http://www.extremeprogramming.org/

http://www.integralist.co.uk/posts/refactoring-techniques/

http://en.wikipedia.org/wiki/Code_refactoring

http://c2.com/cgi/wiki?PairProgrammingPingPongPattern

AWB - 11 - Extreme Programming

Technology

Transcript of AWB - 11 - Extreme Programming