Great point and well stated Don.
I also believe the true value in EPF is
the extensible framework and tool.
The exemplary processes should be
positioned as just that, exemplary. These exemplary processes should
provide a good starting point for tailoring and an example of the constructs
used to create project specific processes….a populated training database.
I don’t think we should attempt to
create a process that is everything to everyone (and I don’t think we
are).
Minimal is a key feature I believe (to
simplify understanding).
Complete should be positioned as complete
in the sense that it provides a complete example (that may be useful to many projects
as-is) but not complete in the sense that we can proclaim victory that we have
created THE process.
I think the library of re-useable
components will emerge, and Don you have a lot to offer in this area.
Cheers,
Chris
From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Donald Firesmith
Sent: Thursday, April 13, 2006
8:17 AM
To: Eclipse
Process Framework Project Developers List
Subject: Re: [epf-dev] Mock Up of
General Intentionsand 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
