[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[epf-dev] RE: Re: PM stuff
- From: "Chris Armstrong" <chris.armstrong@xxxxxxxxxxxxxxxxx>
- Date: Fri, 14 Jul 2006 07:53:15 -0500
- Delivered-to: email@example.com
- Organization: Armstrong Process Group, Inc.
- Thread-index: AcamMcvVX+AgbINISgaSrRjj47KTywBDj9kg
Per, I checked them out and they pretty good -- nice job!
As far as the templates, a couple of things...
1) Related to usability and look-and-feel, I think we
should consider a slightly different layout - different headers/footers and
styles. While these templates are definitely less formal that what's in RUP,
they still look like RUP to me (but that could be because I'm too familiar with
2) Project plan: I think the sections you have and how
they've been completed are appropriate. I think we should add the development
process section (as it is mentioned as a step in "Plan the Project"). For PM at
least, I'd like to ensure that the steps of the process match the work products
(and their supporting templates). I.e. if we say "Define the process for the
project" in "Plan the Project" and the "Project plan" is an output of that task,
then there should be something in that work product/template to handle that step
(i.e. a place to describe the project's process). Of course, in this instance,
the other option is to remove the "Define the process for the project" step and
then they'd match! :-)
3) Iteration plan: Similarily the sections look
appropriate. The "Iteration Objectives" section is simpler (and less confusing)
than the table that is in the original template. I presume "Measure Results" are
the iteration evaluation criteria (which corresponds with the "Identify system
elements to test" step in the "Plan Iteration" task)?
What about risks? Should we describe them here (as the
subset of risks relevant to the current iteration) or separately (as the
complete list of all risks)?
What pieces of data do we expect leads to provide for work
items (getting back to the issue at hand)? For EPF, do we capture points for
work items in the burndown chart or in the iteration plan? Is this where a lead
would expand the work items into smaller assignable things (either sub-work
items or tasks) and provide effort estimates and effort allocation by week?
Based on the current burndown chart, there doesn't seem to
be a place to put points (where it seems like it should be since Bugzilla can't
capture this). I think we should be measuring development burndown by iteration
(not by week as the current chart does). It does not appear as if we can really
capture and measure iteration burndown since the current chart cannot
accommodate effort allocation by week (and we'd also need another actual chart
for each iteration's burndown).
One thing I'm not quite sure about with the option of
having one list, is how does one distinguish between an item that is to used to
measure requirement coverage (i.e. development burndown) and an item that is to
be used to measure expenditure of effort (i.e. iteration burndown)? Should that
option prevail, we'd have to clearly describe how to calculate these
two metrics from one list (and have it clearly represented in the
supporting templates and EPF examples).
Thanks, Chris ~:|
I felt that these templates / examples were a little bit
more advanced than I would like to include in OpenUP / use for EPF. Whenever in
doubt, I suggest we go for less....
think that there are a few good things I should include in the EPF proj plan,
such as measurement and project organization. I think that it would be
interesting for people to know who is actually working on the project (Committer
as well as contributors). So I suggest I add that.
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process
Rational Software, IBM Corp
07/11/2006 08:56 AM
Chris Armstrong ~:|
Armstrong Process Group, Inc.
Come see APG at:
Agile 2006 International Conference
Minneapolis, MN, July 23-28, 2006 - www.agile2006.com
14th IEEE International Requirements Engineering
Minneapolis, MN, September 11-15, 2006 - www.re06.org