[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [epf-dev] Re: Mock Up ofGeneral Intentionsand CollaborativePrinciples
|
Peter,
Apologies, I am in a day long mtg on Tue 4.18. How about Fri 4.21 10-11
am Pacific?
Thanks,
Kirti
Why don't we set-up a meeting in which you "demo" to the
current tool team how you currently use components. We can then outline in
the meeting a few scenarios how this could be done in EPF Composer, which we
then assign to people for detailing as "homework"? I propose next Tuesday after the "M3 Kickoff Meeting",
i.e. 9 a.m PST, 12 noon EST. We can use my raindance. Let me know if
you prefer a different date or time. Again, everyone interested should
join and we will record the session for partners in 'difficult'
timezones. Dial-up
information:
1.
Go to
http://cpc.on.raindance.com
2. Click on
"Join Unscheduled Meeting" on the left
3. Enter your details and the following conference ID: 2816556. Further, if
you are planning to present something during the meeting select the "Full
Version" radio button, otherwise select the "Light Version" button, click "Join
now"
4.
Raindance will check your
system and might prompt you to install a few files. It will then bring up
the conference tool.
5. Dial the
following phone number: USA 800-528-2856, International:
770-325-4737
6.
When asked, enter the
same conference ID on the phone as well: 2816556
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 16:43
|
Please respond
to
Eclipse Process Framework Project Developers List
<epf-dev@xxxxxxxxxxx> |
|
|
To
| "Eclipse Process Framework Project
Developers List" <epf-dev@xxxxxxxxxxx>
|
|
cc
| <epf-dev-bounces@xxxxxxxxxxx>
|
|
Subject
| RE: [epf-dev] Re: Mock Up of
General Intentionsand
CollaborativePrinciples |
|
Hi Peter, Sure, will be very glad to. We have the work
components that I would like to work with you to incorporate. Currently I am
working with our lawyers on Eclipse legalities and hopefully will be done soon.
Meanwhile, if you'd like me to work with you towards scenario building etc., I
will be happy to start doing that. Pl. let me know the best course going
forward. Thanks, Kirti
-----Original Message-----
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx]On Behalf Of
Peter Haumer
Sent: Thursday, April 13, 2006 5: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
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
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.
