>But jokes may come from that particular sequence:
an embryo is conceived and develops into a human being fetus... than a cat is
delivered :-)
LOL Great example of a resilient architecture!
Cheers,
Chris
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ricardo Balduino
Sent: Thursday, March 30, 2006
1:27 PM
To: Eclipse Process Framework
Project Developers List
Subject: Re: [epf-dev] BUP
Fundamental Concepts and Collaborative PrinciplesProposal
I like the first sequence of pictures better.
But
jokes may come from that particular sequence: an embryo is conceived and
develops into a human being fetus... than a cat is delivered :-)
I
like the idea of keeping pictures of a cat though... the cat will not sue us
because we used its picture :-)
Cheers.
Ricardo
Balduino
Senior Software Engineer
IBM | RUP Team | EPF Committer
Phone: 1 (408) 863-5019 (TL: 560-5019)
www.ibm.com
www.eclipse.org/epf
|
Bruce
Macisaac/Cupertino/IBM@IBMUS
Sent
by: epf-dev-bounces@xxxxxxxxxxx
03/29/2006 05:33 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 Principles Proposal
|
|
The hump chart is ok, but might be fun to do something a bit different.
How about a graphic for Inception, Elaboration, Construction, and Transition
like this:
Inception
Elaboration
Construction
Transition
This sends a few key messages - elaboration is not just design - it's about
growing something.
Construction may not be delivered stuff, but it's adding onto the essentials
already built in elaboration.
Transition can contain multiple releases.
Ok - for this last I really wanted to show a person at different development
stages, from baby to adult - but couldn't find one.
This could be put into a single diagram. This isn't quite what I mean,
but it might generate some ideas.
Hope you find this at least an interesting discussion...
I think we could use an artist.
:^)
Bruce MacIsaac
|
Ricardo
Balduino/Cupertino/IBM@IBMUS
Sent by: epf-dev-bounces@xxxxxxxxxxx
03/29/2006 03:25 PM
|
Please
respond to
Eclipse Process Framework Project Developers List
|
|
|
To
|
Eclipse Process Framework Project Developers
List <epf-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
Re: [epf-dev] BUP Fundamental Concepts and
Collaborative Principles Proposal
|
|
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
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
