[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [epf-dev] BUP Fundamental Concepts and CollaborativePrinciplesProposal
|
Everyone,
It might be nice to consider that there are other phases before and
after the traditional RUP ones. For systems, there is initial production
and full-scale production for systems development (as opposed to pure
software applications) as well as retirement. There are also
organizational phases that surround individual project phases (e.g.,
addressing product lines and programs of related projects). There are
also issues of acquisition to be addressed. The RUP phases really seem
only adequate for simple pure software development projects. Also, what
about adequately addressing system integration as opposed to green-field
application development?
Don Firesmith
Chris Armstrong wrote:
For what it's worth, I have found that most people have a really hard
time understanding what each of the RUP phases are all about (which of
course isn't terribly surprising as it relates to shifting to the
iterative paradigm). However, it's been my observation that one of the
things that makes it even more confusing are the actual phase names.
That is, many people think you "elaborate" the design during
Elaboration, and then "construct" the product during Construction.
This of course misses the whole idea of needing to build software and
test it during Elaboration. So, in many cases (where the audience
hasn't latched on to the RUP phase names to tightly), I've had success
using different names that I think help reduce (but, perhaps not
eliminate) the confusion.
Initiation vs. Inception
Stabilization vs. Elaboration
Production vs. Construction
Transition is just fine as is
The milestones associated with each phase are the same, as are the
objectives and exit evaluation criteria. In my opinion, the whole
point of the second phase is to "stabilize" the architecture and
requirements (which, of course, is not the same as finishing them).
The third phase is where you "produce" the remainder of the product.
At the end of transition, the product is put into operation, not
production (although I admit this is a tough word to re-align).
Anyway, I bring this up as an idea on how to differentiate BUP from
RUP... Thoughts?
Chris ~:|
Chris Armstrong ~:|
President
Armstrong Process Group, Inc.
651.491.5575 c
715.246.0383 f
www.aprocessgroup.com <http://www.aprocessgroup.com/>
/ "proven practical process"/
------------------------------------------------------------------------
*From:* epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] *On Behalf Of *WSA Consulting Inc
*Sent:* Wednesday, March 29, 2006 10:47 PM
*To:* 'Eclipse Process Framework Project Developers List'
*Subject:* RE: [epf-dev] BUP Fundamental Concepts and
CollaborativePrinciplesProposal
Hi Richard:
I like the hump chart because it visually captures what BUP is about.
That said, I agree with you that we should probably try to
differentiate ourselves from RUP. So perhaps we can come up with
something. Bruce has already sent a proposal around that I thought was
wonderfully outrageous J
The metaphoric phrases like “do it again, and again, and…” do need
work. I just have these in there as place holders. We will need to put
some thought into these phrases because these are likely to be the
sound bites people will hear when we do presentations. I’m sure we can
come up some good metaphors, and it will likely be easier than coming
up with a name for the methodology J
When I was just a wee co-op with IBM it was explained to me that
religious anecdotes and humour was not universal.
Chat with you all tomorrow.
Steve
------------------------------------------------------------------------
*From:* epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Ricardo Balduino
*Sent:* Wednesday, March 29, 2006 3:25 PM
*To:* Eclipse Process Framework Project Developers List
*Subject:* Re: [epf-dev] BUP Fundamental Concepts and Collaborative
PrinciplesProposal
Steve, great initiative. We certainly need text written at a level
that explains BUP principles and point to where in the process that is
captured. We can further discuss it tomorrow.
I have a few specific comments at this time:
- Should we use the hump chart? We certainly need a visual appeal for
the entry page. BUP defines disciplines slightly different than RUP
though, so we don't want to use the hump chart as it is.
- 'do it again and again' sounded more like 'rework' to me, not an
iterative approach. What about 'do it piece by piece' or 'peel the
onion layer by layer' :-), or something more serious?
- Is requirements about what 'they' want, need or what bring value to
'them' and 'their' business?
- In general, I'm not sure if we should refer to companies names, use
expressions specific to a language (may not be commonly accepted) and
make religious anecdotes (it is definitely not commonly accepted).
My 2 cents,
Ricardo Balduino
Senior Software Engineer
IBM | EPF Committer
www.ibm.com
www.eclipse.org/epf
*"steve" <steve@xxxxxxxxxxxxxxxxx>*
Sent by: epf-dev-bounces@xxxxxxxxxxx
03/29/2006 11:41 AM
Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
To
<epf-dev@xxxxxxxxxxx>
cc
Subject
[epf-dev] BUP Fundamental Concepts and Collaborative Principles Proposal
Hello everyone!
I’ve created a very, very low fidelity (vvlo fi) mockup of a possible
BUP welcome page and subsequent guidelines pages (it’s a good thing I
don’t make my living as a web page designer). The purpose of this
mockup is to propose that we specify from the welcome page BUP’s
fundamental concepts, collaboration, iteration, architecture,
requirements management. I am presenting this to you to begin a
discussion of how to capture and present to BUP users our intentions
behind BUP.
This effort began when I started thinking how we could include
collaborative principles into the BUP. For this I turned to the agile
methodologies because they are more about collaboration than specific
software development techniques. In my view the success of the agile
methodologies is how their principles capture and communicate the
intention of the methodology designers to the users. When the
methodology users understand the intention behind the methodology,
then it becomes much easier for the users to apply, adapt, and grow
the methodology to fit their specific needs.
Therefore I believe the best way to communicate our intentions to BUP
users is to capture our intentions a set of principles rather than
specific rules, tasks, and guidelines. These principles of course
shall help guide users understand BUP tasks, and guidelines and more
importantly give them the confidence to know how to apply and adapt
them. These principles are really patterns and in the examples I have
drawn a couple of example patterns from “Patterns for Effective Use
Cases” and from “Organizational Patterns for Agile Software Development”.
One thing I would also like to point out, I have been conducting an
informal survey of groups who have dumped RUP in favour of an agile
methodology. Ok, I only have three data points, but they are from some
rather large IT shops like the National Institute of Health and
Ameritrade. In a nutshell, these groups adopt agile methodologies
because they want an iterative methodology. How is that for a kick in
the place that hurts the most? The RUP is so overwhelming that it is
not seen as an iterative methodology.
Therefore I want to distill BUP into a set of guiding principles, that
are easy to remember, can be easily taught in a one (or two day
course) and immediately put into practice by a software team after the
course. The specific practices, roles, tasks, work products,
guidelines, etc. all become like a BUP reference or specific how to.
But the fundamental understanding comes from the principles which are
included as part of the methodology.
*Tour and explanation of the pages:*
*/Splash Page and Fundamental Concepts/*
As a bit of humour towards our name debates I’ve code named our
process TPFKB (The Process Formerly Known as BUP). The welcome page
gives the vision for TPFKB (an iterative process that is minimal,
complete, and extensible). Following this is the infamous hump diagram
(can we use this or are we violating copyright? Finally the meat of
this discussion, the BUP _Fundamental Concepts_, _collaboration_,
_iteration_,_ requirements management,_ and _architecture_. I have
given each of these concepts a memorable metaphoric phrase to capture
its intent, therefore collaboration is “it’s the people”, iteration is
“do it again, and again, and…”, requirements management is “know what
they really want”, and architecture is “long live architecture”. The
“long live architecture” metaphor has multiple meanings. One meaning
of course is the intention that our objective with architecture is to
create an architecture that sustains the long term evolution of the
system. The other meaning is to defiantly declare the discipline of
software architecture is still important.
These fundamental concepts are intended to be headliners to longer
narratives that describe the essence of the concept. In our language,
these headliners are pattern names and the narratives are like
patterns, captured knowledge that may be shared. I’ve been reading
through a number of papers that relate fast cycle times (the core of
agility) to heuristic narratives that help people take the initiative
within the organization in a harmonious manner. In my humble opinion,
this is what we must capture and build into the methodology.
You will also notice that I included on this page a section called
Project XYZ Guiding Principles. This opens up the opportunity for a
development organization to include project specific “guiding
principles” In this example I used principles that are specific to a
client that I am currently working with (we are using BUP on this
project). They are re-engineering a legacy system and you know how
easily legacy replacement projects can go off track, hence a set of
specific principles that we harp on again and again to keep the
developers focused on what is important.
*/It’s the People/*
If you follow the link to the “It’s the People” page you will see how
I may describe collaboration. First I start with why collaboration is
important, because success through agility is based on culture. In my
personal opinion we must emphasize this concept that success is a
rooted in culture. The agile methodologies have successfully
publicized the importance of culture and if BUP is to meet our goals
we must do likewise. The text that first appears here is derived from
USAF Colonel John Boyd’s study of strategy and fast decision making
cycles.
The collaborative principles are intended to be the half dozen or so
“guiding principles” or patterns from which emerges the collaborative
culture. I have included a few patterns from various sources to
provide an example of what these patterns might be. I have tried to
give the patterns metaphoric names. However you have to remember I
have a twisted sense of humor and I can already guess that a name like
“come to Jesus” isn’t going to go over well with most people. Just as
an aside, that name is really a place holder for a “retrospectives”
guideline or pattern. The phrase “come to Jesus” is apparently the
slang used by employees of Southwest Airlines for their weekly
retrospective meetings.
*/Share the Vision/*
If you follow the Share the Vision link you will see the pattern (or
narrative) for share the vision. This specific pattern is taken from
“Patterns for Effective Use Cases”. It describes the problem, the
forces and the solution. What is relevant to BUP is the additional
sections that show specific BUP practices (or as I joked TPFKB)
support this pattern. In this example I just quickly wrote down that
tasks like Define Vision and work products like Vision support this
principle. This connects specific BUP practices to the guiding
principles and helps BUP users understand the intention behind the
practices and the work product.
*So Where to >From Here?*
I don’t know if you agree my proposal for the welcome page, but I
would like to start the process of creating the collaboration
principles. So that is that is the task I want to propose is that we
(I guess “me”) create and write a set of collaborative principles that
are an intrinsic BUP feature. So before I start plunging head long
into this I want some feedback and a casual straw vote on whether
capturing collaborative principles in this manner as either narratives
or patterns is a good idea. I believe linking the principles to
specific BUP work products and tasks is important. I’m hoping that a
few of you are also going to jump up and say “good idea Steve, can we
participate in this?” J
Chat with you all tomorrow.
Best regards,
Steve Adolph
[attachment "bup welcome page sample.zip" deleted by Ricardo
Balduino/Cupertino/IBM] _______________________________________________
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