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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, August 24, 2006 8:50 AM To: [email protected] Subject: epf-dev Digest, Vol 8, Issue 57 Send epf-dev mailing list submissions to [email protected] 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 [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] 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... ([EMAIL PROTECTED]) ---------------------------------------------------------------------- Message: 1 Date: Wed, 23 Aug 2006 14:59:34 -0700 From: "Steve Adolph" <[EMAIL PROTECTED]> Subject: [epf-dev] A few potentially controversial assertions... To: "'Eclipse Process Framework Project Developers List'" <[email protected]> Message-ID: <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] Subject: Re: [epf-dev] A few potentially controversial assertions... To: "Epf" <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Skipped content of type multipart/alternative-------------- next part -------------- _______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev ------------------------------ _______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev End of epf-dev Digest, Vol 8, Issue 57 ************************************** _______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
