Re: [epf-dev] Getting started with OpenUP

[Per Kroll <pkroll@xxxxxxxxxx>]

Steve,

I think this is really good thinking.
Some of it is also the style used when describing. Scrum says that an iteration
is 4 weeks long. And when you have done Scrum, you can change the iteration
length if you need to. This sends a very simple message to the novice,
while providing the expert with necessary flexibility. 
We have  a tendency to say "well,
it depends, let me walk through all your options and the parameters that
will determine the right answer..." and there you lost anybody but
the expert...

Cheers

Per Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp
(M) 408-219-2963

"Steve Adolph" <steve@xxxxxxxxxxxxxxxxx>
Sent by: epf-dev-bounces@xxxxxxxxxxx

08/31/2007 11:05 AM

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

To	"'Eclipse Process Framework Project Developers List'" <epf-dev@xxxxxxxxxxx>
cc
Subject	[epf-dev] Getting started with OpenUP

Some of you may know that I am collecting
data on how people use methodology for my dissertation. During one set
of data collection interviews one subject mentioned “She understood in
theory how it  [a UP variant] worked and the method made sense to
her.  But when it came time to use it she was found herself overwhelmed
– she didn’t know how long an iteration should be, she didn’t know how
to create an iteration plan and found herself reverting the ‘old ways’
to get the job done”  This disconnect between understanding the theory
and knowing how to put it into practice has popped up in a number of my
data collection interviews. Compare this to Scrum and XP where iterations
are clearly defined as 30 days or in XP’s case “a couple of weeks”.
There is simply less opportunity for doubt on the part of XP and Scrum
adopters because there are APPARENTLY fewer issues to worry about. OpenUP’s
flexibility also increases its complexity (just like in software…sigh)
and makes it difficult for a team to get started.
 
I think this captures an issue that
we must overcome if OpenUP is to become widely accepted, a team will adopt
OpenUP if and only if they believe it is easy to get started. This means
we must provide supporting materials that bridge the disconnect between
people understanding and liking OpenUP in principle, but not understanding
how to put it into practices. If you look at XP and Scrum, they are pretty
much shrink wrapped simple processes, they are easy for a development team
to adopt. Another barrier to easy adoption of OpenUP is that OpenUP is
a more comprehensive method than XP and Scrum, which means it is not something
that a grass roots development effort can simply go ahead and use to create
code – or at least that is the perception potential adopters will have.

 
There are a number of solutions that
will help resolve these barriers to OpenUP’s adoption. First, Per’s suggestion
of an OpenUP poster is a good one…if we can put the process on one page,
if a developer or project manager could have a poster on their wall that
describes the process then that will go a long way to dispelling the perception
that OpenUP is a complex process. Second, we need to have relevant case
studies of OpenUP’s adoption that people can turn to, case studies. Case
studies from small product companies, small aerospace groups, small IS
groups.  
 
I am just putting these ideas on the
table for you to think about, we can discuss these more in the Enabling
and Promoting EPF call on Monday September 10th at 8:00 PDT
 
Have a great weekend everyone
Steve Adolph_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev