(Also see Developer Roles)


David says: A visible statement of your team's values (not too many) is vital to keeping everyone on the same page and avoiding conflicts. Here are the values the UrbanSim team uses. I suggest you adopt a statement of values for your team. 


David says: It is important for the entire team to understand which aspects of the project's business ($) variables may change, and which may not. Here is the UrbanSim team's tradeoffs. Which of these do you want your team to fix? 

Engineering is a game of tradeoffs. There are four variables in a software engineer project: Features, Resources, Schedule, and Quality. Increasing any of these variables increases the project's monetary costs, so the choice of which to fix and which to vary is a business decision made by business people. The UrbanSim project chooses to fix three of them: Quality, Features, and Resources. Thus UrbanSim will adapt UrbanSim's Schedule.

Note that Quality is the most important for UrbanSim. Our end users will not accept UrbanSim if they cannot trust the system. They cannot trust the system if it is obtuse or it runs unpredictably, etc.

Note that Features are the next most important for UrbanSim. This is both an engineering project and a research project. It can’t be an interesting research project if we don’t experiment with different models and different implementations.

Stable versus Incremental Builds

David says: I don't expect we'll get to the point of having stable versus incremental builds, but if you all prove me wrong I'll be proud. Following is what UrbanSim says on this topic. 

Because we have real customers who really use this system to do real planning work, we have stable builds on the website for them. These are “releases” in the traditional software engineering sense: tested, stable, predictable releases.

We also have the incremental daily builds available on the web. Each and every time the light goes green, a new install is placed on the website. These installs can be, well, installed. They can also be “updated” via the update menu item. (Note: update doesn’t work as well as you might think – ask for details.)

Because the installs are always live, you need to make sure that every time you check something in, you are happy (the team is happy) to make that release live. So that means that you have good code, thorough comments, robust design, complete tests, updated documentation, etc, etc.

Daily Cycle

David says: I highly recommend you follow something like this.

Commit Checklist

Remember: you are contributing to a complete product. Your responsibility extends all the way from the green light to the end user's experience. The design you do, the user interface you create, the tests you implement, the code you write, the documentation you update - all of that is part of the customer's experience and thus all of it is your responsibility.

Defect Workflow

David says: I am working to get Bugzilla set up for your use, but don't have an estimate as to when it will be available.

Bug free software: all bugs are fixed as the most important thing each and every day. Only after all the bugs are fixed can we proceed to work on new features. Why?

  1. Our customers’ confidence in our software
  2. Unfixed bugs represent an unknown liability against the schedule and unknowns are bad.

Our workflow is:

There are a few other transitions, but they are not listed here.

Planning and Status Reports

David says: Again, the following are the UrbanSim practices. 
- "Stand-up meetings" are very effective for each team to have at the beginning of it's working session. Try this when you are working together. Don't do this with large groups. 
- I suggest you send the "Today emails" to your team member after each day you do work.

We have a number of planning activities that we do both to keep our team and ourselves on track.

Iteration (Bi-Weekly) Cycle

David says: This is a very effective lightweight planning technique for a team with fewer than 10 people or so. It can be effective when there is enough experience in the team, though it can take some time to get used to (as does any new practice). I think it's worthwhile for you to try this, and would be happy to help you through it. 

Iterations are planned using 3x5 cards on the cork board. Each task/feature is estimated in calendar days and owned by the estimator. There are typically ten calendar days in two weeks, although vacations, holidays, and other big meetings can reduce that number. Pink smiles are used to mark the cards as completed.

No card should be longer than four calendar days, and no card should be less than 1/2 a day.

No new tasks are accepted during an iteration in order to reduce context switched and thrashing. Large customer support and research tasks are carded and estimated just like the other tasks.

Release (Bi-Monthly) Cycle

David says: No time for this in 403. 

Start with a planning session, end with a retrospective.

Long Term (Multi-Year) Cycle

David says: Not for 403! 

$Id: devprocess.html,v 1.11 2002/06/20 17:47:05 duisberg Exp $