| RE: [epf-dev] Work Item List |
|
Hi Bjorn, sorry I’ve taken so long to
respond – I’ve bee on vacation. Could you elaborate on what you believe
should be in the Iteration Plan that would not be in a view of the WIL for a
specific iteration? Our thinking was that the Iteration Plan
is essentially a fine-grained plan for the iteration, and the WIL already has
those fine-grained tasks. In a small project, tasks, requirements, and change
requests can often be lumped together easily so separate management of each type
of item isn’t a problem (if it is then it may be time to separate requirements
and CRs from the WIL). Thanks, Jim ____________________ Jim Ruehlin, IBM Rational RUP Content Developer Eclipse Process Framework (EPF) Committer email: jruehlin@xxxxxxxxxx phone: 760.505.3232 fax:
949.369.0720 From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of "Bjorn Gustafsson"
<bjorn@xxxxxxxxxxxxxxx> Hi all, I’m a new contributor to EPF but I’d like
to throw in my view of the proposed Work Item List. For those of you who don’t know me, I was
involved with the development of the previous RUP technology – RPW, Organizer,
RUP Builder. (and I totally love the new Composer stuff!) I now lead the
development of our ProjectKoach product – a process-empowered project
management solution. Hence I view EPF from a process enactment point of view. I like the simplification WIL makes and I
can see its alignment with the Product Backlog of Scrum and the Release Plan of
XP. My concerns are that the presented WIL
draft definition is “too much implementation” - it effectively presents a
development case with a particular tool and format in mind – and that it makes
it too simple by throwing out the
Iteration Plan. This can make it difficult to map this process to other
implementations in projects using other means than the envisioned Excel spreadsheet
format to support it. Software projects have many types of
drivers of their work – which go by many names: requirements, issues, defects,
change requests, etc. These represent stakeholder requests, i.e.
“what the system is requested to
do”. We devise plans to schedule their implementation, and these plans
represent the planning aspect of these drivers, or “who shall implement their support, and when”. (Scrum: Product Backlog and Sprint
Backlog, XP: Story Card and Release Plan) So, at level M0 there are two separate
concerns and my argument is that we shall preserve this separation also at
level M1. Even in the simplest process. I suggest that the Iteration Plan be kept
as a separate artifact alongside with WIL, and that WIL description be adjusted
accordingly. I would be happy to elaborate more on
these thoughts, but I wanted to throw in my 2 cents worth by providing this
feedback before the end of the week. Thanks, Bjorn Bjorn Gustafsson GOOD Software Inc tel: +1-604-948-2006 cell: +1-604-644-9051 fax: +1-604-677-5948 From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Jim Ruehlin Hello, There have been no comments on Bugzilla entry: https://bugs.eclipse.org/bugs/show_bug.cgi?id=137120,
which describes the work item list. There has been generally positive response
in the discipline meetings to the proposed definition of the WIL described in
the entry. I just proposed in the entry that we give it until the end of this
week to see if there are significant comments/objections, and if not we go
ahead and implement it in OpenUP/Basic as described. I wanted to give everyone a
heads-up as the WIL is a primary artifact that a lot of tasks depend on. If the
work you do will be affected by the WIL I encourage you to take a look at the
description in the Bugzilla entry. Thanks, Jim ____________________ Jim Ruehlin, IBM Rational RUP Content Developer Eclipse Process Framework (EPF) Committer email: jruehlin@xxxxxxxxxx phone: 760.505.3232 fax: 949.369.0720 _______________________________________________ |