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