extreme programming, it's worth a look

3
48 IT Pro May June 2002 1520-9202/02/$17.00 © 2002 IEEE Extreme Programming: It’s Worth a Look Arthur English E -business has opened a new dimension of appli- cation development, and most enterprises are keenly interested in investigat- ing and evaluating new manage- ment strategies and pro- cesses. Extreme Pro- gramming (XP) is one of the more popular processes—causing as much stir as Java and Web services did in their infancy. XP’s creator, Kent Beck, introduced the process in 1996 while leading C3 (Chrysler Comprehensive Compensation), a long-term project to rewrite Daimler-Chrysler’s payroll sys- tem. Since completing that pro- ject, Beck has written Extreme Programming Explained: Em- brace Change (Addison-Wesley, 1999) and won the coveted Software Development Jolt Pro- duct Excellence award. Tom DeMarco, noted author of software project management books, characterized the XP movement as “...a way to make IT projects light and quick. The principles of XP are not just another methodology, another process. They are the antithesis of process. They are the means to make process irrelevant” (from the foreword to Planning Extreme Programming, Addi- son-Wesley,2001). Indeed, XP is deliberately lightweight, dispensing with lengthy use-case specifications, requirements definitions, and extensive documentation. As such, it is not, nor was it designed to be, a full life cycle methodology. But neither is it hacking, as some of its critics maintain. Rather, it is a collec- tion of highly disciplined prac- tices that companies can either formally introduce into their existing process or use to sup- plement individual processes for project management, change management, requirements planning, and testing. XP proponents find that it improves software quality, in- creases productivity,and reduces costs. The rapid release cycles and continuous communication between developer and cus- tomer may seem chaotic to those comfortable with traditional IT. But in light of the pressure to deliver applications in less time with reduced costs, a little chaos seems a reasonable tradeoff. As its core practices show, XP is more a product of evolution than revolution; many of its XP has been making waves among application developers for good reason. Its 12 core processes emphasize the small and simple, which translates to fast, efficient code generation. practices have been around for decades. XP works best with small to medium projects (de- velopment teams of no more than 10 programmers each) and on projects where everyone expects requirements to change many times before the project is over. REQUIREMENTS AND PLANNING XP encourages stories, brief descriptions of a system task, instead of the more traditional Unified Modeling Language (UML) diagrams and models. The planning game encourages customers (users or stakehold- ers) to define application fea- tures with user stories, which are similar to use cases and sce- narios. Developers then priori- tize the stories and schedule the most important ones for the next iteration. Only program- mers working on a story can estimate how much time it will take to complete the story. Customers and managers set goals, but the developers ulti- mately decide what to imple- ment as part of an iteration release. XP’s metaphor guides all de- velopment with a simple shared story of how the whole system works, and this metaphor ex- presses the evolving project vision that defines the system’s scope and purpose. XP projects should derive their system metaphors directly from the enterprise architecture’s vision, principles, and standards. For critical e-business projects, the metaphor should not replace a full-fledged architecture effort.

Upload: a

Post on 26-Feb-2017

222 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Extreme programming, it's worth a look

48 IT Pro May ❘ June 2002 1520-9202/02/$17.00 © 2002 IEEE

Extreme Programming:It’s Worth a LookArthur English

E-business has opened anew dimension of appli-cation development,andmost enterprises are

keenly interested in investigat-ing and evaluating new manage-

ment strategies and pro-cesses. Extreme Pro-gramming (XP) is oneof the more popularprocesses—causing asmuch stir as Java andWeb services did intheir infancy. XP’screator, Kent Beck,

introduced the process in 1996while leading C3 (ChryslerComprehensive Compensation),a long-term project to rewriteDaimler-Chrysler’s payroll sys-tem. Since completing that pro-ject, Beck has written ExtremeProgramming Explained: Em-brace Change (Addison-Wesley,1999) and won the coveted

Software Development Jolt Pro-duct Excellence award.

Tom DeMarco, noted authorof software project managementbooks, characterized the XPmovement as “...a way to makeIT projects light and quick.Theprinciples of XP are not justanother methodology, anotherprocess. They are the antithesisof process. They are the meansto make process irrelevant”(from the foreword to PlanningExtreme Programming, Addi-son-Wesley, 2001).

Indeed, XP is deliberatelylightweight, dispensing withlengthy use-case specifications,requirements definitions, andextensive documentation. Assuch, it is not, nor was itdesigned to be, a full life cyclemethodology. But neither is ithacking, as some of its criticsmaintain. Rather, it is a collec-tion of highly disciplined prac-tices that companies can eitherformally introduce into theirexisting process or use to sup-plement individual processes forproject management, changemanagement, requirementsplanning, and testing.

XP proponents find that itimproves software quality, in-creases productivity,and reducescosts. The rapid release cyclesand continuous communicationbetween developer and cus-tomer may seem chaotic to thosecomfortable with traditional IT.But in light of the pressure todeliver applications in less timewith reduced costs, a little chaosseems a reasonable tradeoff.

As its core practices show, XPis more a product of evolutionthan revolution; many of its

XP hasbeenmakingwavesamong

applicationdevelopers for goodreason. Its 12 coreprocesses emphasizethe small and simple,which translates tofast, efficient codegeneration.

practices have been around fordecades. XP works best withsmall to medium projects (de-velopment teams of no morethan 10 programmers each) andon projects where everyoneexpects requirements to changemany times before the projectis over.

REQUIREMENTS AND PLANNING

XP encourages stories, briefdescriptions of a system task,instead of the more traditionalUnified Modeling Language(UML) diagrams and models.The planning game encouragescustomers (users or stakehold-ers) to define application fea-tures with user stories, whichare similar to use cases and sce-narios. Developers then priori-tize the stories and schedule themost important ones for thenext iteration. Only program-mers working on a story canestimate how much time it willtake to complete the story.Customers and managers setgoals, but the developers ulti-mately decide what to imple-ment as part of an iterationrelease.

XP’s metaphor guides all de-velopment with a simple sharedstory of how the whole systemworks, and this metaphor ex-presses the evolving projectvision that defines the system’sscope and purpose. XP projectsshould derive their systemmetaphors directly from theenterprise architecture’s vision,principles, and standards. Forcritical e-business projects, themetaphor should not replace afull-fledged architecture effort.

Page 2: Extreme programming, it's worth a look

CONSTRUCTIONSmall releases ensure that develop-

ers use only the most valuable busi-ness requirements to build the system.Releases occur every two to threeweeks, and customers should be ableto review and use the working systemduring the project to make sure thatdevelopers are addressing all therequirements.

Simple design discourages com-plexity by helping the team deliver asystem that meets the customer’simmediate needs—no more, no less.Duplicated logic is not allowed.Instead,XP encourages developers towrite components with the fewestpossible classes and methods, imple-menting only the functional features acustomer has described in a story.

Testing is continuous. Programmerscontinually write unit tests to validatecorrect operation of modules beforethey write functional code for themodule under development. Theseunit tests must run flawlessly for devel-

opment to continue. Customers thenwrite system tests to demonstrate thatthe code satisfies requirements.

QUALITY ASSURANCERefactoring is the process of restruc-

turing the system to remove duplica-tion, simplify code, and add flexibility

without changing how the code oper-ates. Even if a company doesn’t buyinto XP as a whole, it should seriouslyconsider adopting refactoring. InRefactoring: Improving the Design ofExisting Code (Addison-Wesley,1999),Martin Fowler defines refactoring as aset of techniques for identifying and

A good first choice for XP information is http://www.XProgramming.com. The site features articles, book reviews, and links to other XP sites.The URL http://www.extremeprogramming.org contains a useful XP tuto-rial for developers who are just getting started. For those who prefer hard-

copy sources, Addison-Wesley publishes an entireseries on XP. Extreme Programming Explained:

Embrace Change (Kent Beck, Addison-Wesley,1999) is the best book to get your feet wet.After you’vedecided to try XP in your organization, I recommendreading Planning Extreme Programming (Kent

Beck and Martin Fowler, Addison-Wesley, 2001),which details how to implement the XP process.

More on XP

Choose from 100 courses at the IEEE Computer Society’s Distance Learning Campus. Subjects covered include…

* Java * Project management * HTML* PowerPoint * Visual C++ * Visual C++* Cisco * TCP/IP protocols * CompTIA* Windows Network Security * Unix

With this benefit, offered exclusively to members, you get…* Access from anywhere at any time * Vendor-certified courseware* A multimedia environment for optimal learning * A personalized “campus”* Courses powered by KnowledgeNet®—a leader

in online training

Sign up and start learning now!

http://computer.org/DistanceLearning

Get thousands of dollars worth of online training—FREE for members

New 2002MembershipBenefit

May ❘ June 2002 IT Pro 49

Page 3: Extreme programming, it's worth a look

P E R S P E C T I V E S

project code. Thus, any programmercan change any code in the system atany time.Collective ownership in manyways works like open source program-ming. The idea that a group of pro-grammers can own and make changesto the same code base is markedly dif-ferent from traditional approaches, inwhich a single developer owns a par-ticular set of code. Proponents of XPand open source argue that the moreprogrammers on the code, the fewerthe bugs. Collective code ownershipcan be key to meeting user demandsfor system changes. Last-minutechanges become a team effort, not anindividual workload crisis.

PROJECT MANAGEMENTFour XP practices center on project

management.The idea behind contin-uous integration is to make integrationa day-to-day activity.Developers inte-grate and test code after a few hoursor a day at the most and integrate oneset of changes at a time.This simplifies

improving bad code, weeding outunnecessary code, and keeping theproject as simple as possible.

In pair programming, two develop-ers work side by side on a single com-puter, continually developing anddiscussing each other’s code with theaim of improving quality.This practice,the most controversial aspect of XP, isnot for everyone. In fact, it gives manyprogrammers the creeps.It works quitewell in some environments, however,as the anecdotes on the XP mailing list([email protected]) attest. Before trying to imple-ment pair programming on any pro-ject, the development team shouldattend an XP programming boot campto learn how to work together XPstyle. Companies should never man-date pair programming when pro-grammers vociferously oppose it.

The goal of pair programming is topromote another XP practice—collec-tive ownership, in which every teammember becomes familiar with all the

the integration process and makes itobvious who is responsible for fixingthe code when integration tests fail.

A 40-hour week is highly encouragedon XP projects.As Beck states,“It’s OKto work overtime when it’s required,but don’t do it two weeks in a row.”XPprojects also have an on-site customer,a real customer who works with theteam and is available to answer ques-tions, resolve issues, and set priorities.The customer remains with the devel-opment team throughout the project.

Finally,XP mandates the use of cod-ing standards—not just guidelines.Programmers must follow a commoncoding standard so that all the codeappears to have been written by oneperson. This is common sense: If anyteam member can work on any partof the system at any time, movingfrom one pair-programming partnerto another, and doing constant refac-toring, the team can’t afford to havedifferent coding practices.

R egardless of what you thinkabout XP as a complete pro-cess, it’s hard to debate the use-

fulness of some XP practices likecoding standards, refactoring, andsimple design. XP success storiesabound. Ted Waltman, president ofIFC, a consulting firm that specializesin development with XP, states, “XPhas enabled our firm to deliver on-time, on-budget projects in 40-hourwork weeks for clients in a variety ofsoftware environments, includingC++, Java, and even Visual Basic.”

If you decide that XP makes sensefor your organization, don’t expect toroll it out in one shot, and plan tobring in XP gurus to help with train-ing and the initial rollout. Rememberthat XP is not an all-or-nothingproposition. You can easily adaptparts of it to match your company’sculture and style and still improve thebottom line. �

Arthur English is a research directorat Unisys Corporation Global Indus-tries. Contact him at [email protected].

50 IT Pro May ❘ June 2002

computer.org/e-News

Available for FREE to members.

Good news for your in-box.

Be alerted to

• articles and special issues

• conference news

• submission and registrationdeadlines

• interactive forums

Sign Up Today for the IEEE

Computer Society’s

e-News

Sign Up Today for the IEEE

Computer Society’s

e-News