Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [epf-dev] Mock Up of General Intentions and CollaborativePrinciples


Note that what we have said about BUP being complete and minimal only applys to OpenUp/Basic, not OpenUp.

Minimal - It should only cover things required by (almost) ALL projects.

Complete - It covers an end-to-end development process for a team satisfied with a minimialistic process. This means that there should be no glaring holes in areas required by (almost) ALL projects.

So, by definition, there are tons of content required by some projects, which should not be in OpenUp/Basic, but could potentially be included in OpenUp.

Cheers

Per Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp
408-342-3815



"steve" <steve@xxxxxxxxxxxxxxxxx>
Sent by: epf-dev-bounces@xxxxxxxxxxx

04/12/2006 09:41 PM

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





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


Back to the top