(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.
- 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.
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?
- Our
customers’ confidence in our software
- 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!
$Id: devprocess.html,v 1.11 2002/06/20 17:47:05 duisberg Exp $ |