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" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 08/31/2007 11:05 AM Please respond to Eclipse Process Framework Project Developers List <[email protected]> To "'Eclipse Process Framework Project Developers List'" <[email protected]> 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 [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
