Bruce,
Try http://epf.eclipse.org/wikis/openup/index.htm does it work for you ?
Bob
----- Original Message -----
From: Bruce Macisaac
To: Eclipse Process Framework Project Developers List
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
[email protected]
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/epf-dev
