This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Dispersed Development
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
This is a case study presented by John daniels and Paul Dyson
What they are going to cover:
Multiple teams - each team in one office? Not the topic
Satellite Workers - most in one office, some remote workers. Not the topic exactly
Dispersed team - Every team member is remote - this is what they are covering
Why do it?
Cost (lower)
Get people who do not want to travel/relocate
Constrained by circumstances - (personal or business)
Case study, source: JD. Two FNL projects covered here. Both were part of a larger project
Specialized Workflow engine, 2 people, fixed price, 5 months, server based (EJB), no UI
Information management system with 4-6 people - T&M. Lot of interdependence between this part and others. Large EJB/J2EE project, 6 months
Case study - source: PD
Integration of web services provision for internet platform. 4-5 people, fixed price, Java web services, no UI
4-5 people, 9 months, Java, multiple interfaces, migrated from office environment. Tried to develop a product from (1)
Working Environment
Needed:
Full broadband (beware upload chokes!) - needed cable/DSL
Phones plus conf calls
Could use VOIP for one to one
Powerful machines for team.
Beware desktop sharing over net with large displays
Install complete platform at each site - so need power at each site
Wiki for sharing
Version control system that works in this fashion
NetMeeting for collaboration
VNC or equivalent
IM for chat/see who's around
Security (physical and cyber) - in practice, ignored many of the customer requirements for physical security)
Firewall
IPSec encryption (same router at each site)
Encrypted email (PGP plugin)
if appropriate, encrypt HDs
Issues
Tool support for this is currently very weak (very ad-hoc)
Supporting multiple/varied desktops is very hard. Everyone ends up being an SA.
Interacting with the customer
Initial face to face meeting (ongoing)
cannot support regular XP model of an onsite customer
More expectation mgmt needed - lack of shared experience in team
More formal review periods
Need to schedule customer time, as it is not going to happen otherwise
Need more doc - without direct interaction, necessary
Issues need to be resolved by phone/chat/wiki
Customers had no access to the environment (VPN or servers)
FNL Example
Customer had already donse some prototyping
Customer had done extensive business analysis
Jointly produced feature list
Had access to their intranet and repository
They were happy to use dispersed dev - saved desks/space
e2x
Many onsite meetings for clarification
2 - 3 week iterations, delivery after each
1-2 days onsite to assist with integration at each step
1 week onsite to really integrate
This latter project was hard
General approach
Evolutionary approach
Short iterations
Daily "stand up" meetings
features vs. tasks - used tools like the Wiki and spreadsheets to manage the difference
One thing learned - used Wiki as a "virtual wall" of cards for the project. Very difficult to enforce without discipline. Worked well, but the team needed to think about it. The actual development process was not a lot different from normal - other than the need for on site delivery and integration - in a full on site job, would have been more natural.
Designing the System
Needed to do early architecture/design work in up front face to face meetings. Worked better face to face, later on used shared desktop with virtual whiteboards. Did this in UML, used Rose (somewhat). The process was API driven (from the EJBs). Design doc was produced after the fact, not during or up front. Revisiting the design decisions were more important than in a "normal" XP process, as there is less lunch/coffee (etc) side conversations. Needed to make up for that lack. Ran up against poor tool support for dispersed diagramming.
Team Organization
mixed pairing with "buddying" - work alone, but check in with buddy on a regular basis. When pairing this way, agree on how work was to be done and split it up. Work as a pair until complexity was understood, then just go off and do it. One common split - tests vs. implementation. Most tasks were paired, there was the odd singleton task on the e2x project. In response to a question, code review and code quality takes extra work.
Programming Technology
Eclipse
( CVS
Eclipse and Tortoise clients
Server running on spare PC (Server hosting)
e2x later switched to the tool they were building (Cyclex)
Pair programming with NetMeeting
Slight delay over wire if you are not the driver (mostly ok)
re-synch to version control to switch driver
Mostly worked w/o problems!
Varying degrees of continuous integration as a result (IMHO, not a lot different from normal process issues)
Process for programming tasks
Sketch the ifc
Code the tests
Run new tests
Code the implementation
Run new tests
Iterate until pass
Run all tests until integrated
Check in
test focused rather than simply test driven
Updated user abd design doc before each software release
Project 2 FNL
Used customer repository
No Eclipse integration
Couldn't use NetMeeting while connected to their repository - made pairing very tedious
Pairing over NetMeeting via ADSL
Once VPN worked, easy
audio and desktop sharing worked well over VPN
Project e2x
Who's got the monkey?
Used an actual "monkey" toy in the office, what to do remotely?
Use IM (did not work as well)
Lack of "overheard" conversations
Interruptions are worse than when co-located (other phones, door, etc)
Latency makes swap over a problem
Poor support in CVS
Supported in Cyclex
What about Testing?
General
Focus on functional tests - are unit tests still important? They think less so
Used JUnit
Automated one click testing critical
FNL
When paiting, both developers had to get all tests to pass on their machines before it was agreed to be done - the "it works on my machine" problem
General Advice
Shared understanding of the tasks is crucial
e2x: Does work with people you don't know. Works better with people you do know
FNL: Only employed people that they knew already
Minimized start up time
Minimized cultural/personal diffs
Face to face - especially with customer - is still crucial!
Important to establish working etiquette as you go along
Allow time for setting up the infrastructure (VPNs, databases, etc)
Test focused
Maximum team size limit? They have done 5-6
Discussion session
One thing that comes up is that all interaction has to be more considered - and somewhat more formal - than in an office environment. John Daniels: This form of pairing is actually more productive (admittdely, anecdotal).
There are times and tasks where people work more efficiently alone. Remote development with buddying allows for that
Previous Topic
