Extreme Programmingin Practice

Presented By: Bob SerrVP Engineering – Collaboration & Web Services

P2XP in Practice

Topics

» XP Overview – In Theory» Project Overview» XP Use – In Practice» Metrics

P3XP in Practice

XP Key Concepts

» Customer is key» Requirements will change» Engineering sets timeframes» Customers set priorities and picks releases (on-site

customer)» Short iterations, short releases» Refactoring is built into the process» Simplicity is key – only build what is necessary!» Design by tests» Continuous integration – build early and often» Automate everything: tests, builds, etc.» Program in Pairs

P4XP in Practice

XP Process Overview

P5XP in Practice

Stories

» Written by the Customer» Same purpose as use cases, but are different» Used to create time estimates» Replace large requirements documents» Also similar to usage scenarios, but are not

limited to user interfaces» Drive the creation of acceptance tests» Working with the Customer» How much detail?

P6XP in Practice

Story Card

Source: www.xprogramming.com

P7XP in Practice

Metrics, Points, and Project Velocity

» Stories (functionality) are estimated in terms of points» Points: arbitrary measures of time» Velocity within a release is constant (for the most part)» The key is in relative comparison, not in actual elapsed

time» Points are most useful in aggregate format: How many

points can the team accomplish in 1 week? In 1 iteration? In 1 release?

Formulas… Don’t get lost in the numbers

P8XP in Practice

Acceptance Tests

» Created from user stories» Black box system tests» At least 1 per story» Determines completeness of stories

P9XP in Practice

Pair Programming : The Basic Idea

» All production code written as a pair» Includes test cases» Does not include prototypes» Key Concept: The team owns the code

P10XP in Practice

Pair Programming : Benefits

» Two eyes are always better then one on any problem

» Reduces simple bugs» Produces more reliable, well thought-out code» Provides a built-in check for writing test cases

and following process» Increase team communication» Prevents “single points of failure” on the

development team through automatic knowledge transfer

P11XP in Practice

Pair Programming : Evidence

» 42 seniors @ University of Utah» Assignment 1: 60% more time than non-pairs» Assignment 2: 20% more time than non-pairs» Assignment 3: 10% more time than non-pairs» All Assignments: Pairs passed 15% more post-

development test cases» All Assignments: 90% of pairs enjoyed

programming more and felt more comfortable in their pairs

Source: www.extremeprogramming.org

P12XP in Practice

» Open, standard Web Services Platform» Lightweight Integration Platform» Components:

» Flexible Display Engine» divine Core Services Framework (CSF)

Pluggable Services Layer Transformation and aggregation services Web Service Enablement Registry Multiple data source consumption Other external web services, .NET Enterprise Java Beans, Java Beans, JCA, COM, etc. Server-side scripting (Javascript, Python, etc.) Decoupled transport-independent framework

Support for HTTP, SMTP, JMS, etc.

The Product

P13XP in Practice

Where the product fits

divinedisplay engine

html/jsp rss/rdf wsia/wsrp

divinecollaboration

divinecontent

management

divineenterprise

content center

divinecim - telephony

divinecim - internet

divinesearch & content

divine psocustom solutions

divineweb service engine

divine web service engine

divinecore services

security user management document services workflow other services

service api service api service api service apiservice apiservice apiservice api

in p

roce

ss

rmi/ii

op

java api

soap api

in p

roce

ss

http jms

smtp

sock

ets

java/c++ api

xml/xslsoap api

P14XP in Practice

The Timeline

P15XP in Practice

In Practice : Customer Stories

» Document technical in addition to user stories» Sometimes we needed placeholders for tech items» Stories for everything

» Gathering Requirements» The “customer” needed a lot of guidance » Wrote stories in conjunction with product mgmt

» Lessons Learned:» Make sure “customer” (product management, real

customer, whatever) has XP training» Plan to spend time writing stories w/ customers and

tearing up the first batch

P16XP in Practice

In Practice : Info Architecture and Stories

» XP does not define a clear relationship between IA and XP

» IA’s want to write customer scenarios and explicitly specify UI details

» XP works with the former, but not the latter» Lesson Learned:

» Do not define the UI as part of requirements or story writing

» Instead, pair a UI designer and/or IA with a developer to execute UI-related stories

P17XP in Practice

In Practice : Release Planning

» Customer presents stories» Team asks as many questions as necessary» Developers love to hear from customers, customers love to

have direct interaction with developers

» Teams Estimate Points» Break into teams» No more than 3 minutes per story» Spike stories that the team cannot estimate» We used 1 pt = 1 day (instead of weeks)

» Lessons Learned» Always have the customer write stories» Always have the customer at planning meetings

P18XP in Practice

In Practice : Determine The Release

» Determine Release Schedule based on:» Estimated Points» Total Available Points (using initial velocity)

Ex: 4 pts / iteration / developer * 10 developers * 3 iterations =120 pts

» Customer-Assigned Priority» Risk / Difficulty

» Lessons Learned» It’s better to time-box the release rather than extend

the release based on features» Despite continuous integration we always needed

time to cleanup, so plan accordingly

P19XP in Practice

In Practice : Iteration Planning

» 2 Week Iterations» Pick High Risk / High Priority Stories First» Customer re-reviews stories» Team asks more questions» Write stories on board» Brainstorm tasks and claim stories» Estimate tasks, map back to story-level

estimates» Lessons Learned:

» Again, always have the customer at this meeting» Force people to engage in task brainstorm» Don’t let developers leave w/o task cards.

P20XP in Practice

In Practice : Pair Programming

» Highly Effective» Chose pairs per story» Sometimes paired at daily standup mtgs» Lessons Learned:

» Personality Conflicts» Preferential Pairs» Avoidance» Dominant Partners» Passive Partners

P21XP in Practice

In Practice : Test Before You Code

» The most important element of the process» Write Tests for Each Task» Use JUnit testing framework» HTTPUnit for graphical tests» JUnitPerf for performance Tests» Lessons Learned:

» Spend extra time getting the testing framework right» Make sure everything can be automated

P22XP in Practice

In Practice : Builds

» JUnit integrated with Ant» Only check in working code» Scrap code at the end of the day if task not complete

(and tested)» Cruise Control does regular builds (once every 4 hours)» Broken builds are cause for emergency» Lessons Learned:

» Simplify the build process» Automate emails for broken builds, highlight necessary

items» Make a formal process to handle broken builds

P23XP in Practice

Integration Testing / System Testing

» Time Drastically reduced» Becomes User Acceptance Testing» Map tests back to Customer Stories» Lessons Learned:

» Involve the customer in writing acceptance tests» Involve the customer in executing acceptance tests

(verify results or manually run if necessary)» Automate these tests as well

P24XP in Practice

Refactoring

» Done early, often» Sometimes causes pains in a large system» Regardless, must not be afraid to do it» Lessons Learned:

» Don’t wait too long to refactor» Write stories for major refactors and estimate as any

other story

P25XP in Practice

Metrics

Item Count

Number of Stories 140

Lines of Code 50,000 Custom 190,000 integrated

Total Points 230

Avg Velocity 30

Total Defects 450

Unit Tests Written 270

P26XP in Practice

NOTICE: Proprietary and Confidential

This material is proprietary to divine. It contains trade secrets and confidential information which is solely the property of divine. This material is solely for the Client’s

internal use. This material shall not be used, reproduced, copied, disclosed, transmitted, in whole or in part, without the express consent of divine.

© 2002 divine © All rights reserved

robert.serr@divine.com