Re: [epf-dev] BUP Fundamental Concepts and CollaborativePrinciplesPropos

[Per Kroll <pkroll@xxxxxxxxxx>]

Don,

I would expect the processes in EPF
to support several different lifecycles, that is, several different phase
combinations. As you point out, BUP is focused on the execution of an individual
project. I would expect processes dealing with e.g. the enterprise space
to have different phases, or no phases at all.

I do however think that there is a huge
value in having a consistent set of phases to be used within all variations
of processes within the "Unified Process" <BUP and all its
future extensions> dealing with execution of an individual project.
The usage of the current 4 phases is very broadly adopted, has huge recognition,
and a lot of people I talk to articulate the value of being able to say
"I just completed Elaboration" allowing all other people to understand
where they are at in the lifecycle, and the type of issues they have dealt
with, no matter what type of project they are working on. So, I am very
much for keeping the current names for all process within the "BUP"
family of processes. Last time we had that discussion, we agreed to that
changing the names would crete a lot of confusion and extra work, and a
new set of names with introduce a new set of problems around ensuring that
people understand what the phases are about...

To exemplify how IBM Rational thinks
about the 4 phases, let's look at how we are organizing some non-RUP processes
within IBM.

• For Operations and Systems Mgmt, you typically do not think about phases. Rather, you have a number of processes, that are triggered by various business events, such as a server problem, or an SLA that is not met. The team may manage a server farm and a couple of hundred applications, and they do not think about the wolrd from an indivual application perspective. That is why we do not see a that you have a "maintenance phase" in RUP. This perspective is covered by IBM Tivoli Unified Process, see http://www-306.ibm.com/software/tivoli/features/it-serv-mgmt/itup/overview.html, and which is based on ITIL.
• For the enterprise, you have a similar perspective. Different processes address various business problems, without one synchornized project going through a series of phases. Some of things you manage go through different states, such as an application that is managed through a business process goes through a set of states from 'idea', to funded and sunsetted. We do not think it is meaningful to coordinate the 4 phases of a project with the states an application would go through in its lifecycle. That is why we do not have "preinception", since this is really managed by a business process (portfolio mgmt) in the enterprise space. The portfolio mgmt process may trigger one or several projects, each producing an application/product increment
• ...and there are naturally tons of other processes / methods within IBM that are either not using phases, or using a different set of phases for their lifecycle.

So, bottom line is that for example
the OPEN Framework could chooe to describe one or several different lifecycles,
and only if you describe extensions to BUP, you would use the 4 phases
Inception, Elaboration, Construction, and Transition. We said within the
BUP working group, that those 4 phases would be a unifying force arond
all "BUP" extensions. I would not like to add pre-inception and
maintenance and sunsetting, because those phases do not belong in a process
expressing a project perspective, as does BUP.

Finally, one of the things we discussed
in the Santa Clara meeting was that in the future, we need to be able to
support the ability to have independent process components which should
be able to be plugged in to a variety of processes. We are not quite there
yet, it will require additional meta-model and tooling work, but that would
mean that you in the future can write content, define the interfaces, and
you can plug it into a variety of processes that provides the right ports
for your component.

Cheers

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

Donald Firesmith <dgf@xxxxxxxxxxx>
Sent by: epf-dev-bounces@xxxxxxxxxxx

03/30/2006 06:45 AM

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

To	chris.armstrong@xxxxxxxxxxxxxxxxx, Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
cc
Subject	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
>  
>


_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev