How are we doing in getting useable software out sooner?
First, some good news: We’re reliably hitting a majority of our bi-weekly milestone goals, perhaps even two-thirds. A good start, room for improvement.
Developers feel like they know what they need to do and aren’t blocked from doing it. Distractions (anything getting in the way of writing code) seem at an acceptable level.
In thinking about incremental improvements to our process, we’ve reached a few decisions.
We will start creating something like functional specs for current feature implementation. Info on the wiki is too diffuse and in reality we rely on coordination through meetings. It’s working, but it could work better, and isn’t going to scale. We want a lightweight approach, i.e., no waterfall methodology here. We’ll start with some simple experiments and evolve it. We’ll write down enough with enough clarity so there is a written record of both the details of the design intent and development approach, analogous to architect’s drawings and construction documents. Sheila Mooney, who’s just joined as in product management will be playing a key role here.
We’re going to make the tracking of progress in two week milestones a little more crisp. No magic bullet, but the bi-weekly milestone review meeting Tuesdays at 4:00 takes on added importance.
We already know a major focus of the 0.5 release will be performance improvement in the repository.
We’re pruning target features from the initial release plan. I’ve urged Chao Lam, Chandler’s Product Manager, to consider focusing on defining a “kibble” release, at 0.7 or 0.8. It’s short of a 1.0 but still has the preponderance of features one needs for regular day-to-day work. It leaves us room to add more features to 1.0 if time permits, but does not compel us to. There will be a number of important features (for example, an integral IM client, a full-featured contact manager) but not crucial which likely are going to slip beyond both “Kibble” and 1.0. Again, watch the design and dev lists in the next few weeks for more details.
We’re getting real about having a “dog food for developers” plan which parallels the end user plan. That is, we’ll have specific goals (and non-goals) for what developers should be able to do with Chandler on a release by release basis. We’ll allocate resources to meet these goals, e.g. documentation work, and we’ll measure progress on a milestone by milestone basis. This is work in progress. Details to be published to the dev list and wiki as you would expect soon.
We’ve identified a few areas where we know we need to have a real plan in place but don’t yet have resources assigned or available to work on it.
-- level of “Kibble” support for PDA’s and smartphones
-- Interoperability with calendars etc.
-- i18n plan
-- user doc
Top two points will be part of the job of new product marketing manager, once hired.
Posted by mitch@osafoundation.org at August 18, 2004 01:17 PM