1

Extreme Programming

Sven Rosvallsven-e@lysator.liu.se

Extreme Programming (XP) is a rebellious new development methodology that has got a lot of press recently. But is it so "extreme" as the name indicates? And what makes it so "extreme"?This talk aims at giving a quick introduction to XP and what is so special. XP has a strong focus on human communication, simplicity and testing. There are lots of work for testers in an XP environment. We will see how testing can drive the whole development process. Testers are now in charge instead of being given the end result from developers during the hectic final stages of the project

2

Values of XP

• Communication• Simplicity• Feedback• Courage

•Communication between team members, management and customers.•Do the simplest thing that could possibly work. Don’t do anything more. Do only what you need today. Tomorrows complexity will be dealt with tomorrow.•Feedback on the state of the system (testing). Feedback from customers. Feedback on project progress.•Courage to do radical, needed changes.These values go hand in hand.•Communication spreads courage to the whole team.•It is easier to be courageous with a simple system.•Feedback gives courage because you know how the system performs.

3

Why is XP popular?

Waterfall model doesn’t work:• Relies on getting specifications right• Customer changes his mind• New technology• Late system testing• Poor visibility of progress

•It is impossible to get specifications right before you have a complete system.•Customers always change their mind. They might not know in advance what they really need. Competitors may have added features.•The world changes. New technology is introduced. Not only new tools and operating systems our project is based on. There may be smaller upgrades with subtle changes that may break or improve our system.•System Testing cannot start until we have a system. All pieces must be integrated. Customers can only get a feel for it is how to work with the system at this point.•Progress reports say. “Analysis Phase complete”. Customer says “Good, but what does Analysis Phase really mean?” Think of the Emperors new clothes.

A lot has changed since the Waterfall model first saw the light. Many methodologies have improved things but not enough.

4

What is XP?

• Customer focused• Iterative, frequent releases• Test intensive (Testing first)• Lightweight software development

methodology

•The customer pays us. Give him respect and keep him happy. Keep him informed on progress. Show early releases. Let customer participate in planning and design.•XP is the first truly iterative development methodology I have seen that does not compromise quality. A system is delivered early and frequently to give visibility into progress and what is developed.•Testing is a crucial practice in XP. Automated as much as possible.

•Test cases define what is to be developed and communicates functionality better than specifications to developers and to customers. It is easier to verify that a test case is satisfied than a requirement in a specification document. •Testing drives development. No development task is complete without passing its tests. •Testing assures that no code change breaks anything else.•Testing can start early because we have a system ready from the start.

•XP is a lightweight methodology in that thick documentation is avoided and replaced by other means. XP is ideal for 5-15 people in a project. Bigger projects can often be broken down into manageable sub-projects.

5

When not to do XP

• Company culture• Expensive integration/testing• Big projects• Uninterested Customer• Required up-front design

XP requires communication. There may be “heroes” who want to be seen as indispensable experts and are afraid of sharing their knowledge.Some companies value their workers by how many hours they work, not what they do. There are also many managers who think meetings are waste of useful time and want people to work instead of talking to each other.Integration and regression testing can be very expensive. Every developer won’t have access to his own mainframe or moon-lander. But centralised builds on a dedicated test machine and testing with reports made available to all team members can often be an acceptable replacement. Simulators at various scales can also do great jobs.If integration or regression testing takes too long, it takes too long to get feedback on recent changes. This can sometimes be solved by breaking down the system in manageable pieces that can be integrated and tested on their own. Regular large scale integration and testing will catch any problems at this level reasonably fast.If Quality Assurance takes two months before releasing, this slows down the feedback loop badly. Instead QA should trust the automatic testing being performed.Big projects causes problems with communications. This can be solved by dividing the project into smaller pieces. One group delivers a module to another, who act like customers.The customer may not be interested in giving feedback and prioritising the development. He may just want something delivered and installed. You will have problems with this kind of customer in waterfall projects too.There may exist a requirement for up-front design. Maybe because of tradition, maybe because management or customers want to see that the developers understand the problems in the project.There are still useful practices in XP that can be used in any project.

6

XP PracticesOnsite

Customer

Metaphor

40hWeek

PlanningGame

Refactoring

SimpleDesign

PairProgramming

Testing

ShortReleases

CodingStandards

CollectiveOwnership

ContinuousIntegration

•Customer on site to ask for clarifications, planning, testing, etc.•Everybody in the team uses the same Metaphor. (Mental Model)•Short Releases so that new features can be tested quickly. Typically every 2-4 weeks.•Testing can start immediately because we have a (small) system after the first release. (I.e. 2-4 weeks.)•Simple Design. Don’t do more than what is needed now. No need for up-front complex design of things that might not ever be used. It is easier to change a simple design than a complex design when the customer may change his.•Refactoring is required when the Simple Design must be improved. We may have gained experience on how to design after having tested the feature with the simple design. The refactored design can be verified with the test suite, which has been proven before.•Pair Programming. Two brains works much more efficiently than two individuals. They inspire and review each other all times. Tests are also designed in pairs.•Collective Ownership. Don’t rely on individual to help you out. Do all changes you need for your feature yourself (in pairs) in any module.•Continuous Integration. Integrate your new feature and test it now.Testing is a development tool, even drives development.

7

XP PracticesOnsite

Customer

Metaphor

40hWeek

PlanningGame

Refactoring

SimpleDesign

PairProgramming

Testing

ShortReleases

CodingStandards

CollectiveOwnership

ContinuousIntegration

All practices work together:•We can plan short releases because the customer is with us defining what is needed now and the customer has seen a working system and agrees on the system metaphor.•Anyone on the team can add code to refactor or add a new feature because we have a common coding standard, simple design, work in pairs and have a test suite.•We can refactor with confidence because we have a test suite to verify that we haven’t broken anything.•We can test frequently because we continually integrate small increments.•We stick to a simple design because we only need to implement what new test cases tell us to implement.

8

XP vs. Waterfall ActivitiesReq. Analysis Impl. Integr. Review Test Delivery

Customer X X X X X

Planning X X X

Metaphor X X X X X

Simple Design

X X

Refactoring X X

Cont. Int. X X X X

Testing X X X X X X

Short Rel. X X X

Coll. Own. X X X

Pair Prog. X X X

Code Std X X

This table shows a cross-relation between XP and Waterfall models. It shows which XP activities are supporting which Waterfall activities.We see here that all Waterfall activities are well covered, even though XP does them in a different way.Note that testing is an essential activity throughout XP.

9

User Stories

• Describes One Feature• Communication between Customer and

Developer• Basis for Planning• Basis for Test Cases

User Stories are very important in XP.

•User stories replace system and function specifications.•When requirements are changed, this is reflected in a small number of user stories.•US are simple enough to be understood by customers and developers.•Each US is estimated and assigned to an iteration and a responsible developer.•Test cases are derived from US.

US are organised on small cards so that they can be shuffled around during planning. Simpler than using project planning software such as Microsoft Project.

10

Iterations

• Prioritisation of User Stories• Implement a set of User Stories• Release

An iteration lasts typically 2-4 weeks. Customers and developers decide together which user stories are included in each iteration. Replanning at the beginning of every iteration.An iteration encompasses all activities of a project cycle. We can do this because we have a simple design and automated testing. We are integrating and testing continuously all the time so we know the system works. Packaging will also be automated to speed up the iteration.Integration and testing is not listed separately on this slide as they are ongoing activities.

11

Testing

• Write tests before implementation• Test execution as soon as first feature

implemented• All tests are re-run before accepting new

features• Automating tests

Test cases are written before development starts for a User Story to get as much independence of the test cases from knowledge of the design.Test cases are both at system level and at unit level.Tests are automated as much as possible as tests are executed very frequently. They are not only run at the end of each iteration before release, but also before each implemented feature is accepted as working and not breaking any other feature. Tests are used to drive development. They are the metric to say that the developer has done his job. This metric is used by management to see progress. Developers are also helped by tests. They know clearly when their job is done. No fuzz. There is no risk developers are stuck fine tuning code that fulfils no purpose as there are no test cases for such work. The developer is confident that his new feature does not break anything as this is proven by testing. The developer feels happy because he can see his achievements clearly.Customer is co-responsible for tests. Any bug reports coming in are seen as a failure to define a test case. There are no bugs (failed test cases) in XP projects, only missing test cases.

12

Testers Role

• Better test writer than developers• Better test writer than customers• Knows test tools• Test automation• Test execution

•Developers sometimes have difficulties distancing themselves from their system and seeing things from a users perspective.•Customers sometimes don’t know all the error conditions that should be considered.•Test Tools that neither developers nor customers have resources to learn.•Automation is time consuming. Using Test Tools and frameworks.•Execute Manual Tests that cannot be automated.•Explorative testing etc to find any bugs/missing test cases and misunderstood requirements.

13

Example Project

Online banking is a service many of us know. It is a kind of application that evolves over time. Perfect for dividing into iterations and release often to customers.The Metaphor here is a set of accounts that the user can work with. The paged nature of the web is also part of the metaphor.Need a “dummy customer” to act on behalf of all anonymous users.First iteration: Show this page. This page shows the features that has most value to the customer. (Login is often seen as the first feature, but it has no real value.) Get feedback on look and feel. Correct logo and colours, menu of commands logically ordered. Easy to view information on screen.Early feedback may have suggested stripes in transaction list to make it easier to follow lines.Testing against a snapshot database, because we don’t have database support yet.Note that this first iteration is not a publicly available release. We need a working database and login etc. to have a satisfactory solution.

14

Deploying XP in QA C++

QA C++, A static analysis tool for C++ source code.

• Core analyser team 3-5 people.• Had been running for 2 years when XP was

adopted. • Introduced XP during following 4 years.• 400 KLOC C++ code.

The core analyser was easy to define tests for. Most test cases consisted of source code that the tools should parse and expected warning messages.No dedicated tester. Instead a tiered automated test suite was built. The full suite was run every night (8 hours). A limited set of the test suite had to be run before code was allowed to be checked in.The test suite consisted of:•1000 selected code samples to demonstrate new features.•800 code samples from bug reports.•A compiler test suite with 14 000 test cases was bought and integrated into test suite.•A number of customer projects we managed to get our hands on.•The source code for QA C++ itself.

15

Lessons Learned from QA C++

- Too small team with very specialised roles made pair programming difficult.

- Difficult to make management co-operate and find a customer.

+ Core parser was rewritten four times.+ Never late production releases.- Slow feedback.

Building a C++ parser is a daunting task. Adding analysis to this does not only require excellent understanding of the C++ language, but also understanding how the tool is used and what needs customers have.Had done sporadic snapshot releases before. These were taking too much time as some files were missing in the release. Improved integration build scripts to be able to deliver complete release frequently.Finding a customer was impossible. Customers were seeing QA C++ as just another tool in their toolbox. No customer saw QA C++ as business critical tool. Later we had a resource in the sales support team dedicated to QA C++ who acted as a proxy customer. This was a huge improvement as this person knew very well what the customer wanted.

A good test suite was already in place, but had to be improved to make it easy to run and view the results. Thanks to the automated test suite we dared to rewrite major parts of the tool when the design had to be enhanced to cope with new features. The test suite was comprehensive enough to tell us if the new code was behaving as well as the old code did.We had an excellent track record on releasing on time, with very few bugs.Although we managed to send out a new release every month, the people on the beta list were to busy to install new versions this often. Our japanese distributor wanted 6 months to make sure that the new version was as good as the previous, that all their customisations worked properly and to translate it.

16

Adopted Practices in QA C++Onsite

Customer

Metaphor

40hWeek

PlanningGame

Refactoring

SimpleDesign

PairProgramming

Testing

ShortReleases

CodingStandards

CollectiveOwnership

ContinuousIntegration

We did not have a customer to ask for details and priorities from the start. Instead we indicated to management what the next versions were going to include. Later we had a resource in the sales support team dedicated to QA C++ who acted as a proxy customer.We knew what to do, the C++ standard (700 pages) was our ultimate requirement. Easy to create user stories and test cases from this. However, customers required support for various compiler extensions.Planning suffered from lack of understanding what features were needed in the market. We wanted to do a proper C++ parser but most customers were using Visual C++.Pair programming was difficult as the team was small and very specialised. No-one had capacity to know more than one area in the tool. We did occasional pair programming to try it. This had always positive results. The resulting code had outstanding quality. But it was exhausting to get introduced into someone elses problem domain while maintaining your own.Coding style consistency suffered due to the lack of pair programming. We used our own tool to enforce some coding guidelines. You can never cover everything in a coding standard.-----------------------------It was easy to introduce testing as a test suite was already in place. Everyone in the team thought XP was cool.

17

Agile Development

• A collection of lightweight methodologies• Patterns for design and organisation

– Agile Software DevelopmentAlistair Cockburn, ISBN 0-201-66969-9

– http://www.agilealliance.org

“Agile methods are people-oriented rather than process-oriented. They rely on people’s expertise, competency and direct collaboration rather than on rigorous, document-centric processes to produce high-quality software.”“Travel light. Just keep the models needed. The less models, the less to update.”XP is one of many agile methodologies.

18

Resources

• Books:– Extreme Programming Explained: Embrace Change

Kent Beck, ISBN 0-201-61641-6– Test-Driven Development, By Example

Kent Beck, ISBN 0-321-14653-0– Testing Extreme Programming

Lisa Crispin, ISBN 0-321-11355-1

19

Resources

• Web links:– http://www.extremeprogramming.org– http://www.xprogramming.com– http://www.stickyminds.com/sitewide.asp?sid=2301486&sqry=%2AJ%28

MIXED%29%2AR%28createdate%29%2AK%28simplesite%29%2AF%28Lisa+Crispin%29%2A&sidx=6&sopp=10&ObjectId=5045&Function=DETAILBROWSE&ObjectType=MAGAZINE