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
