RE: [epf-dev] BUP Fundamental Concepts and Collaborative PrinciplesPropo

[Per Kroll <pkroll@xxxxxxxxxx>]

Hi,

I would keep the hump chart (naturally
updated to reflect our disciplines, etc), since it is very widely adopted
among a variety of unified process variants, I would however not have it
as the fist thing that comes up, and rather have the front page to show
key principles, etc per your suggestion below.

Note that the disciplines may vary within
various process vairants within the unified process family. so, we may
need different variants of the hump chart. As an example, the MDA work
will likely introduce at least business modeling as an additional discipline.

Cheers

Per Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp
408-342-3815

"WSA Consulting Inc" <steve@xxxxxxxxxxxxxxxxx>
Sent by: epf-dev-bounces@xxxxxxxxxxx

03/29/2006 08:47 PM

Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>

To	"'Eclipse Process Framework Project Developers List'" <epf-dev@xxxxxxxxxxx>
cc
Subject	RE: [epf-dev] BUP Fundamental Concepts and Collaborative        PrinciplesProposal

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