Philippe, I agree 100% that tracking the milestones is an excellent
way to measure our progress, so +1. More information is better to
help mitigate the risks and I was going to suggest we enhance the
proposal with some of the following information as well.
My impression from the discussions was that the end goal was a bit
fuzzy. I was going to suggest we be a bit more concrete about what
the actual finish line is so when people see where we are currently,
it's clear where we are going and why we can or cannot make the
decision to defer or cut certain features/bugs. For example, the exit
criteria such as "accommodating design changes or feature rework" is
a bit vague and it doesn't really give people the comfort that we
won't spiral with changes uncontrollably or have a huge bug queue for
weeks and weeks - resulting in a release date getting pushed out.
-> We could also track some sub-milestone criteria such as the
following....
+ What features have we done?
+ What features are left to do?
+ What workflows are complete?
+ What workflows are incomplete?
+ What's been tested?
+ What hasn't been tested?
+ What non-code deliverables are complete?
+ What non-code deliverables are incomplete?
Tracking workflows helps me as well since this makes it easier to
punt stuff. We could decide to defer a complete workflow which
entails punting a group of bugs across multiple features.
-> The other thing I heard is that we could also agree on our
ultimate end-user goals and set those expectations properly. Do we
want real users or just people trying out the app to give us
feedback? A proposal...
Dogfood Goals:
Get people outside of OSAF to dogfood Chandler the way Mitch, Sheila,
Priss and Mimi have been dogfooding:
+ Using Sharing
+ Using the Dashboard
+ Using the Calendar
+ Using Edit/Update
-> Also, giving people some visibility into how we are going to
prioritize/punt bugs is also worthwhile so that they know what
categories the P1s and P2s fit into and they understand we aren't
gold-plating but fixing very core problems. Then we can make
decisions like "punt all bugs in the convenience category" or say
that anything which doesn't make it into those buckets gets deferred
automatically. (We may need an additional bucket for developer/build/
qa related stuff - this is just an example).
Buckets for prioritizing features and bugs:
+ Playing around with the app, trying out the features
+ Stuff that blocks day to day usage
+ Stuff that confuses people
+ Stuff that makes it more likely for people to stick with Chandler
(conveniences)
Sheila
On Feb 28, 2007, at 2:26 PM, Philippe Bossut wrote:
Hi,
About...
Sheila Mooney wrote:
+ There is some anxiety around the uncertain release date. Some
are not comfortable with a release date that is constantly
slipping or not being able to rally and plan/pace around a fixed
solid date. They would like to pick a fixed date and cut in order
to make it.
...the only way I know of handling risks is to mitigate them with
some level of process, i.e. predetermine check lists used to assess
the health and progress of the project. In that particular instance
(schedule uncertainty) there's no substitute to pacing ourselves
through a set of identified milestones and check if we pass them or
not.
I wrote such a list of fine granularity milestones and associated
criteria some weeks ago:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-
February/007658.html
I didn't receive any comment on it meaning that either everyone
agreed or, more than likely, the objective of such process was
unclear.
So, here we go: the objective of this process is to mitigate the
risk of an uncontrollably slipping schedule: identify were we are
in the schedule, how we are doing and how far we are from the final
objective.
Of course, this is of little use if there's no buy in from the
interested parties, so I think I'm asking the question again:
comments on the proposed process?
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
