[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[epf-dev] Re: A few potentially controversial assertions...
|
Steve
You have done a good job of highlighting some of the key ideas. Reading
these as objectively as possible in order to anticipate objections or
questions, I have the following remarks.
1. OpenUP is not re-packaged RUP
[DJ] I don't feel the features you list satisfactorily distinguish OpenUP
from RUP, except maybe the open source idea. Features 1 and 3 have been part
of the RUP vision and plans for several years now. OpenUP does not bring
anything new to the table in this regard. A key change from RUP to OpenUP is
the idea of starting with a small minimal process and adding to it when
necessary. However, I still feel the primary audience of OpenUP is the
process engineer rather than the practitioner (as is the case with RUP).
3. the OpenUP delivery process describes only one dimension of
coordination, the coordination of action
4. difficulty with describing coordination of understanding in OpenUP
results from the meta model because the meta model seems based on a strict
Input-Process-Output model
[DJ] I agree that the process itself describes the cordination action and
the metamodel is fine-tuned for this type of description. Many of us know
from experience that UP (and by extension OpenUP) contains elements that
help us coordinate understanding, but that coorindation is not explicitly
described in the process itself. So its maybe not so much a shortcoming of
the metamodel, as it is we (the UP community) just haven't articulated that
dimension of the process. Maybe we have always taken it for granted and
forgotten that if we don't write it down, people may forget to do it ;-)
5. the agile methodologies may be inadequate for coordinating action.
[DJ] Not sure I would use the word "inadequate". Its more a case of them not
having explicitly described it (as is the case in the UP community). One of
the difficulties the agile community faces is that we are going to have to
start explicitly articulating these "tacits" in order to expand the reach of
agile methodologies into the broader market (read = teams who are not
already naturally agile). ( Remember the discussions in Atlanta and
Cupertino about "what constitues agility"? )
6. in OpenUP architecture and requirements are collaborative tools that
enable to the team to collectively build a common understanding of the
project
[DJ] These may be the "elements" I was referring to that enable the
coordination of understanding, but we all know there are good architectures
and bad architectures, good requirements and bad requirements. Without
having explicitly qualified what constitutes good architecture and good
requirements, by the shared understanding they evoke, OpenUP will continue
to suffer the same limitations as the agile methodologies do in terms of
providing concrete guidance for coordinating understanding.
7. The OpenUP core principles attempt to operationalize coordination of
understanding and therefore improve the OpenUP delivery process.
[DJ] We could say "strive" rather than "attempt" until we feel we can point
at something in the process that explicitly describes the intangibles we
feel helps teams coordinate understanding.
Thanks for your suggestions!!
DJ
-----Original Message-----
From: epf-dev-request@xxxxxxxxxxx [mailto:epf-dev-request@xxxxxxxxxxx]
Sent: Thursday, August 24, 2006 8:50 AM
To: epf-dev@xxxxxxxxxxx
Subject: epf-dev Digest, Vol 8, Issue 57
Send epf-dev mailing list submissions to
epf-dev@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/epf-dev
or, via email, send a message with subject or body 'help' to
epf-dev-request@xxxxxxxxxxx
You can reach the person managing the list at
epf-dev-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific than
"Re: Contents of epf-dev digest..."
Today's Topics:
1. A few potentially controversial assertions... (Steve Adolph)
2. Re: A few potentially controversial assertions...
(Mark.Dickson@xxxxxxxxx)
----------------------------------------------------------------------
Message: 1
Date: Wed, 23 Aug 2006 14:59:34 -0700
From: "Steve Adolph" <steve@xxxxxxxxxxxxxxxxx>
Subject: [epf-dev] A few potentially controversial assertions...
To: "'Eclipse Process Framework Project Developers List'"
<epf-dev@xxxxxxxxxxx>
Message-ID: <007e01c6c6ff$6db3ae10$6601a8c0@WINDELL>
Content-Type: text/plain; charset="us-ascii"
Hello Everyone
As I am writing up a white paper for understanding the OpenUP core
principles I realize I am making several potentially controversial (or even
incorrect) assertions that could start a flame war (or just reveal my
ignorance :-), but that's good too, it's the only way to learn ) The purpose
of the white paper is to:
* explain why we included the core principles into OpenUP,
* how they align with the agile manifesto and agile principles, and
* how to operationalize them.
However, before I go through all that I wanted to get your feedback on these
assertions and ideas before I surprise you with them in a white paper.
OpenUP Not your parent's UP
One of my first assertions and probably least controversial is OpenUP is not
re-packaged RUP, or the next contender in a long line of "yet another UP
process". Three features distinguish OpenUP:
1. A set of core principles that express the intentions of OpenUP's
authors. These core principles are used to guide understanding and
interpretation of the OpenUP delivery process.
2. OpenUP is open source.
3. OpenUP's plug-in architecture.
Software Development Processes are Coordinating Processes
The next assertion I want to make is software development processes exist to
coordinate people. I want to make a statement to the effect of "for most
software of significant value people must work together to create it.
Software development processes are about coordinating how people work
together"
I am putting forward the assertion there are two dimensions to coordination,
coordination of action and coordination of understanding. Actually according
to Holly Arrow from whom I taking much of this theory from, there is also a
third dimension, coordination of goals.
OpenUP only describes coordination of action
I want to argue the OpenUP delivery process describes only one dimension of
coordination, the coordination of action which is the spatial and temporal
synchronization of two or more people so that those actions fit together
into a spatial and temporal pattern. Our capability patterns and delivery
process nicely fit into this example and the OpenUP delivery process is a
classic Input-Process-Output model describing who does what, and when.
However, the Input-Process-Output model is falling out of favour with many
industrial psychologists and is being replaced by what is called an
Input-Mediator-Output-Input model. The dual "Input" imply feedback, and
Mediator is more descriptive of how work is accomplished.
What is missing from this delivery process is attention to a second
dimension of coordination known as coordination of understanding, which is
achieving either explicit or tacit meaning among members of the group
regarding the meaning of information and events. In other words, does
everyone perceive and interpret information the same way?
Agile Processes attempt to foster coordination of understanding
Most of the XP and Scrum practices (e.g. planning game, co-location, on-site
customer, daily stand-ups) are intended to get a team communicating with one
another and building a common shared understanding of the project. In on
coordination of action the agilists have drawn our attention back to the
importance of coordinating understanding. In my opinion, the agile
methodologies have addressed this second dimension of coordination sometimes
at the expense of the first.
OpenUP Meta model does not readily accommodate mechanisms for coordination
of understanding
Another assertion that I would make is the difficulty with describing
coordination of understanding in OpenUP results from the meta model because
the meta model seems based on a strict Input-Process-Output model. I'm not a
UMA expert so I can only speculate. When you look at a capability pattern,
and follow the task network, each task seems to imply that it is performed
by an individual who takes some inputs, does some thinking, and creates a
work product that is then handed off to another individual. There is no
mechanism for describing the ongoing conversation that may take place
between individuals. For example, when the developer is designing the
solution, there is nothing to indicate an ongoing conversation with a
tester, a stake holder, the project manager, or even a "buddy developer".
The architect is listed as an "additional performer" Oh by the way, one of
the first steps "understand the requirements" suggests the developer should
talk to the analyst, shouldn't the analyst be listed as an additional
performer? The way the process is documented it could be seen as encouraging
a caste system and document based isolationism.
Agile Methodologies may be inadequate for coordinating action
The next controversial assertion that I want to make is the agile
methodologies may be inadequate for coordinating action. This may be one of
the factors that inhibit scalability. Taken to the extreme (pun intended) a
strict reliance on tacit knowledge, refactoring, and emergence leads to
local optimizations at the expense of the overall system.
Architecture and Requirements are collaborative tools to foster coordination
of understanding
In my humble opinion, architecture and requirements are still important, and
this leads to my final controversial assertion, that in OpenUP architecture
and requirements are powerful collaborative tools that enable to the team to
collectively build a common understanding of the project.
Based on this last assertion I am planning to write things like
Like all UP processes, OpenUP has architectural focus. In OpenUP however,
the intention behind the architecture is to serve as a collaborative tool
that helps project participants build a shared common understanding of the
system. The purpose is not to create pretty UML models, rather it is to
ensure that not only does each project participant see the big picture, but
they see the same big picture.
Of course there are other consumers of the requirements and architecture,
but I see the primary role of the architectural artifacts for the
development team as a focal point for coordinating the mental models they
have of the system and providing a vocabulary for reasoning about the
system.
Summary
Here are the assertions that I think are controversial (or at least may
raise a few eyebrows):
1. OpenUP is not re-packaged RUP
2. software development processes exist to coordinate people
3. the OpenUP delivery process describes only one dimension of
coordination, the coordination of action
4. difficulty with describing coordination of understanding in OpenUP
results from the meta model because the meta model seems based on a strict
Input-Process-Output model
5. the agile methodologies may be inadequate for coordinating action.
6. in OpenUP architecture and requirements are collaborative tools that
enable to the team to collectively build a common understanding of the
project
7. The OpenUP core principles attempt to operationalize coordination of
understanding and therefore improve the OpenUP delivery process.
I think from the above you see the outline of the white paper. So before I
get too deep into this, I want get your feedback. After all while these may
be my assertions, this is a collaborative effort :-)
Best regards,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://eclipse.org/pipermail/epf-dev/attachments/20060823/a9ed4024/attachmen
t.html
------------------------------
Message: 2
Date: Wed, 23 Aug 2006 23:49:30 +0100
From: Mark.Dickson@xxxxxxxxx
Subject: Re: [epf-dev] A few potentially controversial assertions...
To: "Epf" <epf-dev@xxxxxxxxxxx>
Message-ID: <OFECB71E94.81D79FBA-ON802571D3.007D6200@xxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
Skipped content of type multipart/alternative-------------- next part
-------------- _______________________________________________
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
End of epf-dev Digest, Vol 8, Issue 57
**************************************
