[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [epf-dev] Mock Up of General Intentions andCollaborativePrinciples
|
One way that I often describe this kind of thing is "minimally sufficient." That is, can we say that BUP is the minimally sufficient set of work products, activities, and roles to drive many types of small projects. Is it enough for every project in any organization? Certainly not, but it's a good place to start.
In previous discussions I think it has also been described that RUP is a big thing that you're supposed to subtract things from, while BUP is a small thing that you add things to. I think it has been many people's experiences that this is one of the big problems with adopting RUP -- people without experience aren't sure what pieces to subtract so they do all of it (which leads to certain doom). I think BUP is supposed to be the smallest set of stuff that we can credibly call useful (that is, if you subtract from it, the process is missing critical elements -- but this does not imply that it's complete, at least from my viewpoint).
Chris ~:|
Chris Armstrong ~:|
President
Armstrong Process Group, Inc.
651.491.5575 c
715.246.0383 f
www.aprocessgroup.com
"proven practical process"
-----Original message-----
From: "Brian Lyons" blyons@xxxxxxxxxxxxx
Date: Wed, 12 Apr 2006 08:17:14 -0500
To: "Eclipse Process Framework Project Developers List" epf-dev@xxxxxxxxxxx
Subject: RE: [epf-dev] Mock Up of General Intentions andCollaborativePrinciples
> 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-----
> From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Donald Firesmith
> Sent: Wednesday, April 12, 2006 8: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
>
>
>
