| RE: [epf-dev] Mock Up of General Intentions and CollaborativePrinciples |
|
hiho, The BUP vision remarks that the process is intended to be complete.
That notion is bolstered with the statement "The process is complete in
that it can be manifested as an entire process to build a system". In each EPF meeting we have talked about specifying the context within
which BUP is applicable, but we have never nailed it. We wanted to change
one perspective that Ricardo Balduino started with in his early BUP white paper
(http://www.eclipse.org/proposals/beacon/Basic%20Unified%20Process.pdf)
wherein he states that the process is only for small projects. The team
felt that the projects should not be too complex (where size is but one factor
that drives complexity) and that the projects must exist within a context of
existing process. An example of the latter point is that BUP does not
have an Environment discipline because BUP is meant to help development projects
that exist within an existing environment. To stick with a pattern of presenting evidence
initiated by Mark Dickson in this forum, I'll include the definition of
Complete from dictionary.com: "Having all necessary or normal parts, components,
or steps; entire: a complete meal". It has been the perspective of the team that, in the appropriate
context, BUP is a complete process providing all necessary process
elements.
---------- b -----Original Message----- 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 |