I worry about making collaboration an
add-on or plug-in. Collaboration should be an essential quality of OpenUP
rather than just a feature.

The new Collaboration layer (sub-process)
of OpenUP should contain content that makes OpenUP the OpenUP process. In other
words, you can replace the Management layer (for instance) and still have
OpenUP. But if you replace the Collaboration layer it’s no longer OpenUP.
The definition, guidance, and spirit of collaboration should live in the
Collaboration layer, and by doing so constrain the rest of OpenUP to be highly
collaborative (this is still a goal we need to attain with OpenUP). I think
that the more collaboration we can describe and distribute throughout the
process, the better for OpenUP.

How about a plug-in called
"Team" that includes all the roles as suggested by Todd and
collaborative principles/practices? This way there will be dependencies
from other packages to this, but it will minimize the N**2 coupling that would
occur between plug-ins?

I think you make a good point when you
suggest a plugin for collaboration in OpenUP. I think plain vanilla
OpenUP/Basic needs to state at its core we recognize the importance of
collaboration. But simply suggesting collaboration is important is like saying
it’s important to be nice to people on your project. How do you
operationalize this? At the moment, the purpose of the white paper I am trying
to write is to convey a couple of ideas how the core principles may be
operationalized. The white paper is really a poor substitute for guidelines.
Collaboration guidelines could then be written up and distributed as part of
plugin. This way we could have different implementation of the core principles
(e.g. practices for co-located teams versus practices for less than co-located
teams ).

Sorry I wasn't able to make the Re-architecting
call - I am in the in the midst of a house move this week, so I'm a bit
overloaded.

Deliving into Steve's point below I agree with the point
about collaborating roles. I have some thoughts I'd like to contribute to the
discussion. I'm not suggesting that we should change anything for the
Spetember release by the way.

When I first got involved I saw the "Additional
Performer" tag as a potentially powerful way of demonstrating the
collaborative nature of the process.

I guess this is influenced by a the way that DSDM
approaches things. DSDM looks at the roles responsible
for production, contribution to, review of and acceptance of
artifacts (products). Although this might look a little prescriptive from a
superficial perspective, it drives home the point that software development is
a social activity rather than a solo one.

In the UP context, Tasks (IMHO) should show how people
come together to do work (represented by the delivery of Work Products). I
see the Primary Performer as the lead role on a Task - held responsible for the
quality and delivery of products to the team. The Additional Performer provides
a guide to who the Primary Performer (and PM) needs to involve in the Task.

In this way, we embed collaboration throughout the
process. Like Scott's Agile Data plugin, it's an approach that I am following
in the DSDM Plugin for Business Stakeholders.

I see that it does present a problem though, when looking
at OpenUP/Basic as the kernel for OpenUP in the large, in that it creates
potentially tight coupling between process packages.

Maybe it's something that can be added to OpenUP/Basic
through a plugin? I guess it could create an opportunity for a literal
interpretation that collaboration is an optional extra in OpenUP. Maybe
such a plugin could be presented as providing more explict guidelines on how to
effect collaboration in OpenUP? The argument being that vanilla OpenUP/Basic
advocates and implies the same but is not explicit or prescriptive on the
subject - thereby leaving it to the commonsense judgement of experienced
practitioners?

It's something to think about for the post-September
version(s) of OpenUP anyway.#

One of the things that I've been trying to do in the agile
DB techniques plug in is to have every task performed by a pair (e.g. primary
and secondary roles). In the text I describe how they work
together. It's likely not a perfect solution, but it's a start.

I wonder if the desire to incorporate collaboration into the
capability patterns works against our desire to have our capability patterns
relatively decoupled and therefore replaceable. If collaboration cross cuts
through all capability patterns this can make replacement of a capability
pattern problematic.

At the moment, the only hint of collaboration we have is expressed
in the content of the core concepts which are a bit of a ?pretty bag? on the
side of OpenUP. At first I thought this was a poor way to express collaboration
because I wanted collaboration to permeate all through the OpenUP
capability patterns. However I am beginning to question both the practicality
of this and the desirability. The view that I am thinking may be more
appropriate and practical within the time frame we have is the domain based
capability patterns express actions and how those actions are coordinated . Our core principles express coordination of understanding ? how a team
interprets the capability patterns. In other words, OpenUP is a software development
process that is expressed from two dimensions, as a set of capability patterns
(coordination of action), and as a set of concepts (coordination of
understanding). I also have a concern that incorporating collaboration
into the capability patterns may be too prescriptive.

I'll try to see if I can participate. However, I'll be in the Upper
Peninsula of Michigan camping, so I can't speak to the cell phone reception and
general mayhem at-large. If I can't make it, I guess the biggest point I have
(irrespective of the graphic) is that we should represent collaboration pretty
clearly. I think it would be ironic if we claim that OpenUP is collaborative,
but with little evidence of such collaboration in the actual process model. So,
I propose that our capability patterns not be discipline-focused (which doesn't
represent collaboration with other roles very well), but instead be
collaboration-focused. That is, they should include at least one role (and
appriopriate tasks) from at least two of the domains (management, user,
development). In the four-circle graphic (with the product at the center),
these proposed capability patterns are represented on the arrows between the
domains. Then I suggest that we represent complete team-focused collaboration
(which is also product-focused) as configurations of these capability patterns
in each of the four phases (represented by their intent vs. their actual names
in the product circle).

I believe in the current OpenUP method content, each domain is
reasonably decoupled from another (as it relates to interdependencies between
tasks and work products), with the exception of key work products such as work
item list and others. In the collaboration approach I described, there would be
pretty high coupling in the inter-domain capability patterns. So, the
consequences of this would be if some one wanted to replace a domain, we would
place pretty few constraints on what they replaced it with (based on the shared
work products). However, they would need to redefine the capability patterns
that represented collaboration with the other two domains. This does not
trouble me, however. Basically the capability patterns are method content
configured into process, so if someone replaces a big chunk of OpenUP method
content (like an entire domain), it seems only natural that they would need to
redefine the collaboration that the replaced domain has with the other two
pre-existing domains (i.e. redefine part of the existing process, but not
redefine the existing method content).

Hi,
I can attend.
Brian, which slides are you referring to? I see a Word document from 7/24 with
one graphic showing a Venn diagram. Is there more than that graphic?
Also, was there a discussion in DC about a potential 4th pie, suggested by
Scott, dealing with Deployment? My gut feeling is that it is a good idea, but
we do not have much on deployment today. It could serve as better to wait a
little before adding it, so we do not have a pie advertising our big hole.. :)
Also, before taking a clear stand on whether that pie makes sense, I would like
to see the underlying process model to ensure that it is reasonably well
decouplde from the other "pies"..

hiho,
I?ll be there.
Can we also ensure that Chris Armstrong is on the call? During the
face-to-face I was enamored with all the thought that went into the graphics he
created, but I want to make sure we have a unified perspective and that the
Venn/evil-eye ideas synch with the pie ideas.
------------ b

This call is scheduled for Tuesday August 22 nd at 8:00am PDT.
Please refer to the calendar for call details.
This call may have to be re-scheduled if Per Kroll is not available.
Best regards,
Steve _______________________________________________ epf-dev mailing list epf-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/epf-dev _______________________________________________
epf-dev mailing list epf-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/epf-dev

Whilst this email has been checked for all known viruses, recipients should
undertake their own virus checking as Xansa will not accept any liability
whatsoever.

This email and any files transmitted with it are confidential and protected by
client privilege. It is solely for the use of the intended recipient.
Please delete it and notify the sender if you have received it in
error. Unauthorised use is prohibited.

The information contained in this e-mail,
including any attachment or enclosure, is intended only for the person or
entity to which it is addressed and may contain confidential material. Any
unauthorized use, review, retransmissions, dissemination, copying or other use
of this information by persons or entities other than the intended recipient is
prohibited.