I forgot to add...
These suggestion descriptions are very desktop centric. We would of
course have the appropriate stuff on the Cosmo side as well in
addition to sub-deliverables for integration etc.
Sheila
On Feb 28, 2007, at 4:53 PM, Sheila Mooney wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
