Xtreme Programming

I found a list of small details on Extreme programming the current methodology used by the company Im working on.

I took some list since I want to check it out through my blog instead of a link. heres the link

Extreme Programming

Extreme Programming (XP) is a lightweight process
Ground rules:

• small team (2 to 12)
• continuous access to customers
• OO design and code (Smalltalk, Java)
• change management system (code and tests)
• the system is always “working” (growing functionality over time)
• overall development cycle – between 4 and 12 months
• new release to customer every 2-3 months
• internal iterations every two weeks
• not for life-critical systems (heart monitor, nuclear power plant, avionics systems, etc.)

Some Rules of Extreme Programming

Planning rules

• do project planning via “user stories”
• plan a series of very small internal releases
• start each day with a “stand-up meeting”

Design rules

• keep the design simple (use the simplest thing that could work)
• refactor as needed

Coding rules

• talk with the customer throughout the coding process
• always code in pairs
• code unit tests first
• follow coding standards

Testing rules

• unit tests for all code
• acceptance tests for each user story

Information on XP

Books:

• Extreme Programming Explained (Kent Beck)
• Planning Extreme Programming (Beck and Fowler)
• Questioning Extreme Programming (McBreen)

Web sites:

• www.extremeprogramming.org
• http://c2.com/cgi/wiki?ExtremeProgramming

A day in the life of an XP developer

First thing in the morning: developer attends a stand-up meeting with the rest of the team (10-15 min)

• developer chooses a task (part of a user story); chooses a development partner for the day

Developer and partner sit together and do the development work for the task

• write new unit tests, check them into the change management system
• write new code, check it in
• fix things that need to be changed in existing code; rerun the unit tests
• run the new unit tests; run the acceptance tests for the user story

Developer goes home at 5:00 (no overtime)

Planning an XP project

User Stories

• Capture requirements “in the users’ words”
• Small, discrete, testable
• Include scenarios
• May include business interactions outside system

“Planning Game”

• Users own stories
• Developers set and own estimates
• Users set priorities – “business value”
• Joint goal: group stories into iterations
• Business value
• “Worst first”

Planning an XP project

• Interview the customer; write user stories on index cards
• Developers give development estimates for each story
• estimates in “ideal person-days”
• estimates based on experience with similar problems
• If a story is too big, split it into smaller stories
• Create a release plan – list the stories in each release
• highest priority or “risky” items early
• Track execution of the plan
• Post the user stories on a bulletin board (in time order)
• Check off each user story after the code is complete and the acceptance tests have passed

Examples of User Stories

see http://www.c2.com/cgi/wiki?UserStoryExamples

Pair Programming

One important practice in XP: all code is reviewed as it is written

• how does pair programming work?
• two developers, one workstation
• one person is the driver, the other is the navigator
• the navigator suggests design alternatives, checks for conformance to coding standards, prevents driver from writing unreadable code
• pair assignments usually change every day
• reduces the need for elaborate design documentation
• pair programming actually improves productivity

Agile characteristics

Most of the agile processes are “controlled chaos”:

• short development iterations, with product “shipped” to either a customer or a pseudo-customer at regular intervals
• continuous testing – such as daily regression tests
• collecting customer requirements using scenarios or use cases
• small team sizes
• informal modeling techniques – CRC cards, simple drawings on whiteboards
• adaptive planning techniques – plans are updated based on intermediate results and reprioritization by the customers

Agile versus XP

Most agile process are less radical than XP:

• don’t require pair programming
• multiple roles, not just “general-purpose developer”
• various methods of iteration planning
• existing heavyweight processes can be adapted to be more “agile”

Which agile process?

Scrum

• Scrum is a very general iteration management process, which can be used in conjunction with any methodology
• development activities are in 30-day “sprints”

Adapt existing processes

• OOPSLA experience report on “agile” version of Rational Unified Process
• oopsla.acm.org/extra/pracreports/MakingRUPAgile-Report.pdf

Crystal Clear

• much lighter than XP, but the team must define their own “required project documentation”
• see Agile Modeling by Scott Ambler for ideas
• good for a team of 4 to 6 people

Books on Agile Processes

• Crystal Clear: Writing Effective Use Cases (Cockburn)
• Scrum: Agile Software Development With Scrum (Schwaber and Beedle)
• Adaptive Software Development: Adaptive Software Development (Highsmith)
• DSDM: DSDM, Dynamic Systems Development Method: The Method in Practice (Stapleton)
• Lean Development: Lean Development: A Toolkit for Software Development Managers (Poppendieck)
• full text at http://www.poppendieck.com/ld.htm

by David Laurance / Dennis Mancl