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