|
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
"proven practical
process"
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
|
