[epf-dev] Minutes from EPF call Thursday, June 20, 8:00AM PST

[Bruce Macisaac <bmacisaa@xxxxxxxxxx>]

Attendees: 

Bruce MacIsaac, IBM 
Sam Courtney, APG 
Regis Coqueret, Unisys 

Minutes: 
1. Discussed Plans/ideas for next release 
       Update on Scrum practice
        IBM's changes to the
EPF Scrum practice changed from an update to a complete redo, together
with a simpler skin to improve the publishing presentation.
A first release (published only) can be found here:
https://jazz.net/agile-alm-scrum-practices

At this time IBM does not plan to include this in EPF.

2. Discussed whether or not to change the default EPF
skin to match the simpler presentation created for the IBM Scrum practice.
Bruce expressed concern that without the ability to switch
skins (a feature only in RMC) that some would like the change, but other
might prefer the collapsible sections, or their websites might not look
good.  In order to avoid disrupting existing customers, Bruce plans
to NOT change the default EPF skin. (If you have an opinion on this, send
an email to epf-dev).

3. Bob Palank suggested
he may contribute content on Feature Driven Development.

4. Upcoming EPF/RMC webinars:
        Bruce
suggested the next webinar be on Process Builder - since he has some enablement
material on this and can delivery this.
The top request at the RMC webinar  kickoff
meeting was for enablement on large libraries, so Bruce suggests that this
be the topic for the following webinar.

5. Regis Coqueret (Unisys) joined the
meeting for the first time.
He has done some interesting work on
extensions to EPF:
         -
export in various formats (html, FreeMind, MindManager, Excel 2003, etc)
        -
import custom categories and guidance from CSV file
        -
etc

He suggested that he could present on
SVN setup to use jointly EPF and RMC.
Bruce will work with Regis on timing
and content for presentations on his work to this community.

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