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

[Peter Haumer <phaumer@xxxxxxxxxx>]

> 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.

Hello Don.

We covered that with Need 4 which in particular traces
down to Features 3.9, 3.17.  Please let me know what we concretely
need to change to cover what you request and I am more then happy to add
and refine it.  These features are currently only scoped as P2 because
we do not have anyone who volunteered working on them or at least providing
a refined vision or detailed requirements of how they shall be realized.

We need committers interested in these
tool features to work with us.  We see a lot of email traffic and
work being done on the content side, but the tool meetings are not visited
much.  Also the recordings of the tool meeting do not get downloaded
(e.g. only one committer looked at the recording from the 28th (5 downloads
in total) and no committer looked at this week's recording (1 download
in total) in which we discuss the tool vision's requirements).  If
you want to shape the vision of the tool we need you to participate.

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
______________________________________________________________

epf-dev-bounces@xxxxxxxxxxx wrote on 04/13/2006 08:14:32:

> 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