Once more into the breach dear friends….
What makes OpenUp – the process
previously known as BUP – interesting is that while a committee of stodgy
infighting methodologists will give it life, it will not be ours to control.
Once we release it, it will take on a life of its own because anyone with a net
connection and an idea will be able to create their own variant and intermix it with other variants. What I
expect to happen is a wonderful and exciting free market of UP and other
methodologies to flourish – something that really was not possible
before. Of course we will create OpenUp 1.1 and 1.2, and we may even be
able to create a methodological framework that allows components to be traded
between different methodologies. OpenUp will be a reference standard, think of
it as a gold standard. I don’t expect a lot of small 5 to 10 person teams
will use OpenUP. I don’t expect a standard committee designed framework
to go far (anyone remember OSI????) But I expect we will be offer the community
a vocabulary and a mechanism for exchanging ideas and I expect one or two
charismatic developers (think Beck or Cockburn) will create a UP variant using
our ideas as a base and start a following. Then lots of people will start
thinking about methodology and exchanging ideas. In my mind this is what is
truly exciting about what we’re doing.
Best regards,
Steve
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Peter Haumer
Sent: Thursday, April 13, 2006
3:53 PM
To: Eclipse Process Framework
Project Developers List
Cc: Eclipse Process Framework
Project Developers List; epf-dev-bounces@xxxxxxxxxxx
Subject: RE: [epf-dev] Re: Mock Up
of General Intentionsand CollaborativePrinciples
Hello Kirti.
As
we discussed in Atlanta
we would be very much interested in incorporating these components. Can
you work with us specifying usage scenarios and concrete requirements to make
this happen?
Thanks and best regards,
Peter Haumer.
______________________________________________________________
Rational Software | IBM Software Group
PETER HAUMER, Dr. rer. nat.
RUP Development, Cupertino,
CA
Tel/Fax: +1 408 863-8716
______________________________________________________________
"VAIDYA Kirti"
<KVAIDYA@xxxxxxxxxxxx>
Sent
by: epf-dev-bounces@xxxxxxxxxxx
04/13/2006 15:14
Please
respond to
Eclipse Process Framework Project Developers List
<epf-dev@xxxxxxxxxxx>
|
|
To
|
"Eclipse Process Framework Project
Developers List" <epf-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [epf-dev] Re: Mock Up of General
Intentions and CollaborativePrinciples
|
|
DJ,
The SIG is a good idea.
A thought - When an executive stakeholder checks
on a project with the PM, s/he generally looks for the status of the
"process-agnostic" method content, chunks that deliver on age-old
must-do's like Scope Definition, Requirements Finalization ("has business
signed up on the requirements yet?"), may be a Prototype, Implementation,
Testing etc. I believe these indicate a really small set of business use cases
("Define Scope", "Baseline Architecture", etc.) for a
typical software development project. The Covansys "Work Component"s
realize these use cases. They get assigned to one owner (work component
"Define Scope" to Analyst) and generate one result
("scope"). In a typical RUP project we place Define Scope in
Inception and Baseline Architecture in Elaboration, etc., make simple posters
of the project's lifecycle and splash them around! Clients love to see their
familiar work chunks. We love the risk mitigation offered by the chunks ordered
in our familiar RUP!
Kirti
-----Original Message-----
From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx]On
Behalf Of DJ de Villiers
Sent: Thursday, April 13, 2006 4:08 PM
To: epf-dev@xxxxxxxxxxx
Subject: [epf-dev] Re: Mock Up of General
Intentions and
CollaborativePrinciples
Don
You said: "My primary worry is whether what I
propose is part of the
ultimate vision for epf or is this effort just
going to be producing two
more defacto industry standards."
I voiced this exact concern in Cupertino, pointing out that it looked to me
like we're creating two (or more) fundamentalist
processes. Organizations
will be forced to choose one of them and very
likely the content, extensions
and plug-ins written for one will be incompatible
with the other. Ideally
what we want is for method content (aka practices)
to be process-agnostic.
We want the industry to be able to use any
practices on top of any process.
Industry experts who would like to author some
content don't want to be
forced to choose a process to extend - they want
anybody to be able to use
it.
There was a lot of debate on this topic in Cupertino, which
indicates we
HAVE NOT been doing a good enough job of
communicating this - internally or
externally. In Cupertino everyone finally agreed: yes, this
is ideally what
we would like to do, but given the current tool
limitations it will be
difficult. I am glad to see Convansys has
suggested a solution. IJI has also
suggested a solution. The EssUP core concepts
(such as alpha and competency)
are an integral part of achieving separation and
composition of practices.
Ivar's Ottawa
postcard outlines some of these ideas.
We said in Cupertino
it may make sense to launch a SIG within EPF to look at
different ways of achieving this vision. I am sure
there are many people
with great ideas to contribute.
DJ
-------------------------------------
Date: Thu, 13 Apr 2006 11:14:32 -0400
From: Donald Firesmith <dgf@xxxxxxxxxxx>
Subject: Re: [epf-dev] Mock Up of
General
Intentions
and
CollaborativePrinciples
To: Eclipse Process Framework Project Developers List
<epf-dev@xxxxxxxxxxx>
Message-ID: <443E6AD8.1090603@xxxxxxxxxxx>
Content-Type: text/plain;
charset="iso-8859-1"
Per,
Makes lots of sense as an /intermediate/ solution.
For method
engineering to work, there needs to be excellent
tool support to make it
easy to select the right components, tailor them
as appropriate, maybe
even add a few components, and then integrate them
together to make a
good project, program, or organization-specific
method. Also, once an
organization has such its own epf-compliant
method, it can become the
basis of tailoring for future projects. I
understand that the epf
toolset is currently not where I would like it to
be yet in terms of its
support for method engineering. For example,
we need an automated
process engineer tool to ask the right questions
and help a project
process engineer (usually not qualified to do the
job) do the selecting
and tailoring for method engineering to be
acceptable in terms of ease
of use and quality of resulting method.
Until an organization has one
or more organizational methods to use as a
foundation, creating an
OpenUP and OpenAgile can make reasonably good
sense, especially if it is
alos used to ensure that the interim toolset is
well architected, etc.
My primary worry is whether what I propose is part
of the ultimate
vision for epf or is this effort just going to be
producing two more
defacto industry standards. I feel that we
need to architect into the
toolset the kind of extensibility and scalability
to support method
engineering now, or it will be too difficult to
add on later and then
the eclipse epf will just supply another RUP and
Agile method.
My problem is that I do not see support for method
engineering in the
current vision documentation. If it isn't
part of the current plan,
then it is likely that it will never be.
Don
Per Kroll wrote:
>
> Don,
>
> I think there is general agreement on that we
cannot provide a process
> that everybody should use, but rather a
framework allowing projects to
> rapidly assemble a variety of different
processes that fits their needs.
> So, you have a series of different baselines
you may choose to use as
> a starting point, and you can plug-in various
components on top of
> them, or write your own components.
> You can have many different baselines, or you
can build your own.
>
> Today, we have a technical limitation so you
need to describe what
> base a process component extends, but in the
future, we hope to
> resolve this by defining API. This has been
propsed by Covansys and
> become a part of SPEM, and Ivar Jacobson
International has also
> proposed. And the idea has been well
accepted.
>
> So, do you even need a few standard base
processes? Eventhough it is
> hypocritical to think we can define a process
that is the "right'
> process for a certain project, I think it is
not much better to say
> "here are 10,000 building blocks, go at
it! So, if you believe in a
> certain set of key development principles,
such as for OpenUp, you
> believe in the importance of architecture, in
iterative development,
> and so on, we have created a starting point
(OpenUp/Basic) that
> probably is close to what you may want to
use. If you do not like it,
> customize it. Or create something from
scratch.
>
> You can then add a number of process
components to that starting
> point. In case it is hard for you to choose
which to add, maybe it is
> easier if you use a configuration as a
starting point targeting your
> type of environment, such as OpenUp/MDA.
Using that as a starting
> point, you cann add or remove components, and
as always, write your
> own, or modify any of the existing
components.
>
> Does the above make sense?
>
> I am a bit worried about people like you
believing that we are about
> "producing a standard process for
everybody to use", since this is
> very far from what we are working on.... So,
my take is that we are
> doing exactly what you think should be done
(well, at least reasonably
> close, working with current technical
constraints), but even after you
> have spent considerably amount of time on
this forum, your perception
> is that we are doing something completely
diffferent... So, what are
> we doing wrong in our communication?
>
> Cheers
>
> Per Kroll
> STSM, Manager Methods: RUP / RMC
> Project Lead: Eclipse Process Framework
> Rational Software, IBM Corp
> 408-342-3815
>
>
> *Donald Firesmith <dgf@xxxxxxxxxxx>*
> Sent by: epf-dev-bounces@xxxxxxxxxxx
>
> 04/13/2006 05:17 AM
> Please respond to
> Eclipse Process Framework Project Developers
List <epf-dev@xxxxxxxxxxx>
>
>
>
> To
>
Eclipse Process Framework Project Developers List
<epf-dev@xxxxxxxxxxx>
> cc
>
> Subject
>
Re: [epf-dev] Mock Up of General Intentions
and
> CollaborativePrinciples
>
>
>
>
>
>
>
>
>
> Steve, I'm getting on my soapbox so read this
accordingly:
> IMHO,part of the eclipse epf program's
problem is the goal of creating
> yet two more methods (processes) [greatest
things since sliced bread]
> as opposed to a method component
repository and associated tool set
> from which anyone could build a
project-specific method so that they
> can perform the right process. I have
long ago stopped believing in
> the appropriateness of a bunch of
methodologists sitting around a
> preverbial virtual table and coming up with a
standard "tailorable"
> method for everyone to use, when they haven't
even talked to anyone on
> the project, don't know its needs, and don't
know its characteristics.
> What hubris I had when I wrote my
methodolgy book recommending my
> favorite method. And I don't think getting
a bunch of methodologists
> and process engineers together to do the job
as a committee yields any
> better result (the camel being a horse
designed by committee after all
> does have some truth to it). Thus, I
have little or no faith in
> OpenUP and OpenAgile (or what ever we decide
to call it). What I do
> have faith in is the epf and associated tool
set, that if properly
> developed would allow anyone to EASILY and
QUICKLY produce and
> maintain a project-specific method that the
project users will support
> because it meets their actual needs, not some
generic set of needs
> made up by someone who has never even talked
to them about their
> project. Thus, until eclipse epf
addresses this challenge, then I
> fear that the work on OpenUP and OpenAgile
will be of little true
> value, merely adding one more pair of methods
to the pile. We don't
> need more project independent methods, but
more project-specific
> methods. In other words, I want
patient-based gene therapy and I
> think the eclipse epf and tools could be a
way to achieve that goal in
> a method-independent manner. At best,
OpenUP and OpenAgile are useful
> to help develop and test the eclipse toolset.
At worst, they will
> merely add a few more /standard /methodologies
when we already have
> too many of them. What we need is
standard class libraries. In other
> words, we don't need more generic Java
programs, but rather a great
> Java class library and a great development
environment that makes it
> easier for everyone to develop the Java
programs they really need, not
> the standard ones we think they need.
> Stepping down now. ;-)
> Don
>
> steve wrote:
> Hi Don:
>
> I absolutely agree we really need to define
what "complete" means (and
> minimal for that matter) because I could make
the argument BUP (now
> OpenUP)
> is becoming "bloated", not
that I would of course ;-)
>
> We are in the rather uncomfortable position
of being squeezed from both
> ends. The agilists at the low end who may
argue that we are creating yet
> another coercive heavy weight process (I
disagree, but that argument
> can be
> made) and the heavy weight process dudes on
the high end (e.g. the
> true RUP
> aficionados). This means we to need to
be careful in the crafting of our
> out reach message and our explanation of
minimal and complete.
>
> Best regards,
> Steve
>
> -----Original Message-----
> From: epf-dev-bounces@xxxxxxxxxxx
<mailto:epf-dev-bounces@xxxxxxxxxxx>
> [ mailto:epf-dev-bounces@xxxxxxxxxxx
> <mailto:epf-dev-bounces@xxxxxxxxxxx> ]
On
> Behalf Of Donald Firesmith
> Sent: Wednesday, April 12, 2006 5:16 AM
> To: Eclipse Process Framework Project
Developers List
> Subject: Re: [epf-dev] Mock Up of General
Intentions and
> CollaborativePrinciples
>
> Steve,
> I read you document and one thing clearly
jumped out at me. BUP is
> anything BUT complete. It seems to be the
least one can get away with.
> There are a huge number of useful method
components that one could add,
> but which were chosen not to add. Because
"complete" is being used (if
> correctly at all) in a very non-standard way,
it is critical to clearly
> define what is meant by the word. Better yet,
you should avoid the word
> complete completely. ;-)
> Don Firesmith
> P.S. For an example of complete and much that
is missing in BUP, see the
> www.opfro.org <http://www.opfro.org/>
repository.
>
> steve wrote:
>
>
> Hello Everyone:
>
> I'm having a bit of a tough time working my
way up the CVS/Eclipse
> learning curve (at this moment the designer
of the Eclipse/CVS feature
> may be feeling the itch of my projected
frustration..:-( ) and my lap
> top is getting ready for the big desk in the
sky...So with our Tuesday
> deadline looming I did not want to miss
getting a few of my ideas into
> discussion for Thursday.
>
> I have attached a word document that can
serve as a mock-up of a
> proposed set of general concepts for BUP,
collaboration, iteration,
> requirements management, and architecture.
These concepts are broken
> down into philosophical principles (why is
this concept important and
> what it's objectives are) and specific
actionable practices (how do
> you implement these castle in the sky
philosophies). The practices
> should eventually be linked to specific BUP
tasks, roles and
> artifacts. Much of what these general
principles are about is
> providing the context and intention behind
specific tasks, roles, and
> artifacts. For collaboration I have drawn for
John Boyd's principles
> for organizational success (trust, vision,
intent, and skill). I have
> then tried to propose seven specific
collaborative practices that
> implement and give rise to these principles.
>
> My intention is these general principles can
be added to BUP as a
> separate plug-in (General Principles plug-in)
perhaps.
>
> That all said, these principles, and
especially the collaborative
> principles, will be seen as a "bag on
the side" of BUP if they are not
> integrated into specific BUP tasks, roles,
and work products. This
> will definitely give rise to some
controversy. For example, in the
> collaborative practices, there is a practice
named "*Manage By
> Intent*" whose ultimate actionable
manifestation is coarse grain task
> assignment (e.g. 2 to 3 days in scope). This
will have a significant
> affect on Kirti and the project management
discipline. But more than
> that: is coarse grain task assignment
something we all agree with?
> Personally, I think fine grain task
assignment is at best silly, but
> then many people may think my ideas are
silly. Another practice is
> "*Buddy Up*" more than one person
shall have responsibility for a
> task. One person may of course have
"primary responsibility" that is
> they are the task owner, but others are also
made responsible for the
> performance of the task (e.g. review). This
practice can manifest
> itself as pair programming, adjacent
programming, or
> programmer/reviewer pairs (or even triples)
but it changes the way
> work is assigned ( or signed up to ) by team
members.
>
> In short there is a lot of new territory to
cover here on the
> collaborative side and I am going to need all
the assistance and
> willing volunteers that are willing to
collaborate on this.
> Personally, I think this is going to be the
most exciting part of BUP
> - but then I may be biased J
>
> I will open several Bugzilla issues for this.
>
> Chat with you all later after I figure this
*&#%%@*I!U@++#@(@&&!)))
> piece of fine software.
>
> Steve
>
>
------------------------------------------------------------------------
>
>
_______________________________________________
> epf-dev mailing list
> epf-dev@xxxxxxxxxxx
<mailto:epf-dev@xxxxxxxxxxx>
>
https://dev.eclipse.org/mailman/listinfo/epf-dev
>
<https://dev.eclipse.org/mailman/listinfo/epf-dev>
>
>
>
>
>
>
_______________________________________________
> epf-dev mailing list
> epf-dev@xxxxxxxxxxx
<mailto:epf-dev@xxxxxxxxxxx>
>
https://dev.eclipse.org/mailman/listinfo/epf-dev
>
<https://dev.eclipse.org/mailman/listinfo/epf-dev>
>
>
>
> _______________________________________________
> epf-dev mailing list
> epf-dev@xxxxxxxxxxx
<mailto:epf-dev@xxxxxxxxxxx>
>
https://dev.eclipse.org/mailman/listinfo/epf-dev
>
<https://dev.eclipse.org/mailman/listinfo/epf-dev>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://eclipse.org/pipermail/epf-dev/attachments/20060413/aacd9ba2/attachmen
t.html
------------------------------
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
End of epf-dev Digest, Vol 4, Issue 43
**************************************
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
Confidentiality Statement:
This message is intended only for the individual
or entity to which it is addressed. It may contain privileged, confidential
information which is exempt from disclosure under applicable laws. If you are
not the intended recipient, please note that you are strictly prohibited from
disseminating or distributing this information (other than to the intended
recipient) or copying this information. If you have received this communication
in error, please notify us immediately by return email.
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev