(Also see Developer Roles)

Values

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. 

• High Quality - the best system we can, both for the end users and for the internal health of the code base. Keep it simple, but don't cut corners.
• Achievable Goal - always have a goal to work towards. Have short, medium, and long term goals. The goals should be a slight stretch in order to challenge oneself, but they should also be achievable.
• Realistic Plan - always have a plan as to how to reach the goals. The plans must be sufficiently detailed so that one can be sure that the bases are covered, but not overly so.
• Flexible to Change - all plans are subject to change as the world and our customers continue to change.
• Small Steps - complex systems (like UrbanSim) are easy to change in very small (almost minuscule) steps, but exponentially more difficult when steps get larger. Take very small steps and accomplish great results.
• Sustainable Pace - don't work too hard. Take time to enjoy life. Conversely, don't slack off as you will only have to work overly hard at the end to meet the goals. A day lost at the beginning of a project is just as lost as a day at the end of a project.
• Always Have a Working System - the Power of the Green Light cannot be underestimated. Always have a system that you are willing to give to a customer.
• Test Everything - Use unit tests to test both your own code (Test First Programming) as well as all the assumptions you are making about others code (verify the APIs with unit tests). Use acceptance tests to test the integration of the whole system.

 Tradeoffs

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

• Code has been reviewed
• Code has appropriate comments including Javadoc
• Code has been formatted with the default Eclipse auto-formatter
• Code has unit tests
• All unit tests in all dependent modules are green
• If acceptance tests have altered behavior, commit the new correct results
• If there are user visible changes, briefly document them in the docs/RELEASENOTES.txt file. Always insert new notes at the top of the RELEASENOTES file so that the automatic release number labeling will appear properly.
• If the user interface changes, update the user manual in the docs subdirectory.
• Also make sure that changes in the user interface are reflected in the ReadMe files. Begin by navigating from, say, UrbanSim/Readme.htm and follow all the relevant links, such as "instructions on how to run this from the command line" and make sure they still are correct.
• If the set of jars has changed (new added or old removed), check the run-junit-tests.pl, all the accept-test-*/run-test.pl, and the release-files/generate-sed-4-jex.pl scripts.
• After committing, wait for the green light.

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:

• Submitted: new defect submitted; ® Defect; ® Feature
• Defect: defect has been evaluated by a senior developer and classified as a bug; ® In Progress
• Feature: defect has been evaluated by a senior developer and classified as a new feature; ® In Progress
• In Progress: being worked on; ® To Be Verified
• To Be Verified: waiting for the submitter (or, if we cannot contact the submitter, another developer, definitely not the person who fixed it) to verify that it has been fixed; ® In Progress; ® Verified
• Verified: has been verified as fixed, waiting for a new build to go out; ® Closed
• Closed: fixed, verified, built and released

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.

• Stand-up meetings – what will I do today; is this the best thing to do today (the focus is on the future - today - not status)
• Today emails – what did I do today; what do I plan to do tomorrow. Both (Stand-up meetings and Today emails) are meant to be short, and to be both intra and inter-personal communication. The point of the stand up is to define your direction for the day and to inform the others in the group of that direction. The point of the status is to remind yourself and the others what you have accomplished.
• Iterations & iteration planning.
• Releases / Milestones and release planning.
• Planning is done collaborative with the modelers.
• All design is done together, as a team. Working solitary is not allowed.

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!