----- Original Message -----
Sent: Saturday, February 16, 2013 3:15
AM
Subject: [epf-dev] Minutes from EPF call
Thursday, Feb 14, 8:00AM PST
Attendees:
Bruce MacIsaac
Bob Palank
Razvan
Gliga
Minutes:
1. Discussed Plans/ideas for next
release
IBM has started working on some updates
to the Scrum library
- Updating based on latest Scrum practice
- Incorporating the Scrum library with the
EPF Practices library so that Scrum can be mixed and matched with other
practices.
Bob Palank suggested he may
contribute content on Feature Driven Development.
2. Discussed Essence submission - goes to an OMG vote in
March. Eclipse is registered to vote. How does the EPF community
want to vote?
Bruce summarized as follows:
A. There has been work on a user's guide, however, it is far
from complete.
Basically it has been
outlined.
B. There has been work
on a mapping to SPEM, but it is far from adequate.
I've included my review of the work done so far in a
postscript below.
Bob suggested
that a vote in favor of Essence would be a good show of support for this
effort.
Action on Bruce to solicit
additional EPF community feedback.
3. EPF Webinars
Bruce proposed to merge this
series with the upcoming RMC webinar series planned by IBM and make it one
co-hosted series.
Cheers,
Bruce MacIsaac
EPF Project
Lead
bmacisaa@xxxxxxxxxx
408-250-3037 (cell)
Review of ESSENCE SPEM mapping:
My general feedback on the introductory
material is that there is still too much sales literature that doesn't belong
in a standard.
If
we want to stick to the "essence" of things, here's what it boils down
to:
1. Essence
defines a standard kernel that allows you express progress and health
attributes of a team.
Standardizing on such a kernel helps teams to follow
different practices, while still expressing progress and health in common
terms.
The kernel
includes guidance on how to evaluate health and progress - and so using the
kernel is effectively a "practice".
2. Teams that don't want to use the Essence kernel
or follow this practice for evaluating health and progress (perhaps they have
alternative ways to do this)
might be able to use the Essence language, but there would
be no benefit over using SPEM.
Teams following non-Essence-based processes with roles,
work breakdown structures, templates, and checklists will find that SPEM
provides better out-of-the-box
support.
3. SPEM is more mature (having been around longer), which
provides benefits such as:
- the mapping of SPEM to tools like Microsoft Project and
Rational Team Concert is well understood.
- SPEM is supported by open source tools and
practices content
- commercial tools provide additional features and tool
integrations
-
large volume of practices, such as guidance and mappings for compliance to
various standards such as CMMi, DO178c, ISO26262, etc.
4. Teams with a significant
investment in SPEM-based processes can explore using Essence concepts, since
Essence alphas can
be expressed as work products or work product slots, and
links can be established to express desired relationships and navigation.
To go further into leveraging Essence requires either means abandoning
SPEM, extending SPEM, or a transformation from SPEM to Essence (likely with
extensions to Essence being required if no information loss is to
occur).
5. I
appreciate that a lot of work has gone into the section that deals with the
specific mappings.
This section needs a lot of work to be complete, and to
avoid confusing the reader.
The best place to start a SPEM mapping is to explain how
plug-ins, packages, configurations, and views, with a few basic elements, such
as a set of roles, could be mapped.
Here is the simplest example I can think of to
demonstrate a SPEM/Essence mapping:
Plugin A - has 2 roles, team lead and developer, and a
view (custom category) that lists these roles.
Plugin B - has an additional role,
product owner, and contributes this role to the view.
There are 2 configurations, A and AB,
which include the respective plug-ins suggested by their names.
I cannot use the proposed
mapping for even this simplest of SPEM processes, since plug-ins,
configurations, contribution, and views/custom categories aren't
covered.
6.
Ultimately the mapping should get down to the nuts and bolts of each language
element to be mapped, but again, the mapping should start with simple
things.
If I have
a simple SPEM-documented process, such as a version of Scrum, documented as
some roles, tasks, work products, and a couple of WBSs
(capability patterns) for a
"Development Sprint" and a "Release Sprint" (which includes rollout
activities), how would that be mapped?
Once we understand how these simple examples map, we can
talk about more complex aspects of SPEM.
It would be good to understand if such a migrated
process is usable, or is not usable without some minimum wiring into the
Essence kernel.
What is the minimum wiring required?
7. I find this statement
confusing:
"TaskDefinition may need to be split, or merged
with others, to serve as a suitable Activity in Essence."
Why would that be the
case?
8.
I will continue to go through the detailed mapping suggestions. I
appreciate the work that's gone into this, but it's not yet close to where it
needs to be.
_______________________________________________
epf-dev mailing
list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
|
