| RE: [epf-dev] Re: A few potentially controversial assertions... |
|
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----- Steve You have done a good job of highlighting some of the key ideas. 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 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" < Subject: [epf-dev] A few potentially controversial assertions... To: "' <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 |