|RE: Collaboration in OpenUP/Basic (was Re: [epf-dev]Re-architectingOpenUP Telecon Tuesday August 22nd)|
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.
Jim Ruehlin, IBM Rational
RUP Content Developer
Eclipse Process Framework (EPF) Committer
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of
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?
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Steve Adolph
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 ).
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Mark.Dickson@xxxxxxxxx
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.#
-----epf-dev-bounces@xxxxxxxxxxx wrote: -----
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.
This is definitely worth discussing in the call.
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.
epf-dev mailing list