Hi DJ
Wow, thanks for the great feedback, at least I know I haven't stepped
completely off the deep end. I have a few comments to add to yours...see below
in red.....
Once again thank you for the feedback, I should have a first draft of
the paper (if all goes well by the end of next week or early in the first week
of September.
Best regards,
Steve
-----Original Message-----
From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On
Behalf Of DJ de Villiers
Sent: Wednesday, August 23, 2006 5:35 PM
To: epf-dev@xxxxxxxxxxx
Subject: [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).
I think the open source nature of OpenUP combined
with universal access to the EPF Composer will change the UP landscape. This
accessibility is likely to create a completely new dynamic in software process
engineering. A metaphor for these new dynamics may be the economic experience
of some of the former communist block countries moving from centrally
controlled economies to market based economies. Expressed in these terms, we
are moving UP from the central control of the process engineers, to a much
wider free market. It will be chaotic, but at least it won’t be dull J
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
;-)
This is where I have to admit my ignorance
of the meta-model, from what I have seen on the surface, it does not appear to
offer strong support for expressing coordination of understanding. But that
said, I agree with your final point that people have not articulated this
dimension of the process. I think we have just taken it for granted and simply
hope that somehow it all magically comes about. I will probably tone this one
down about in the white paper.
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"? )
Yes the use of the word inadequate probably
paints a huge target on my face for more ardent agilists (and even less ardent
ones). I think you say it quite well in “…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…”
This reminds of a quote I think attributed to Barry Boehme …”there
are only so many Kent Becks to go around”. In this light, I have
sometimes thought of OpenUP as the agile methodology for the rest of us.
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.
Agreed, it is important for the team to have
the same interpretation and understanding of events and the architecture and
requirements facilitate those. Of course just because the team is able to
coordinate their understanding and therefore have the same interpretation of
events (e.g constructed a shared common understanding or group mind) does not
necessarily mean they have a correct or even useful understanding of events. After
all, 500 years ago everyone knew the world was flat.
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.
Definitely strive is a better choice of
words.
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
**************************************
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev