Re: [epf-dev] Mock Up of General Intentions and CollaborativePrinciples

[Per Kroll <pkroll@xxxxxxxxxx>]

Don,

what you write is a part of our vision,
and has been discussed in a number of meetings. Further on, these are not
distant maybes that could be implemented in 5 years time assuming all stars
are aligned, but things we could accomplish by e.g. 2007 assuming that
we get our ducks in a row.

We need to be crisp on what the solution
is, not only agree on a vision.

But, I had as a previous action item
(which I am behind on) to produce a draft on overall content architecture,
and I think painting a vision is a necessary piece of that. Using that
as a starting point, I suggest we use epf-dev to evolve such a vision,
and hopefully we can all sign on to the same vision. In general, I am extermely
happy about the fact that we all seems to have a shared vision, what this
in the end will come down to, is out ability to execute. Visions are easy
to create, the hard thing is to make them come true, but I think we have
been pretty successful so far...

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 08:14 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

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
] 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
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
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
  
_______________________________________________
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
  
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev