[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [epf-dev] Discovered Size of OpenUP/Basic
|
I agree with Brian in that the page count should mostly be used as a
baseline so we can manage the size of the process going forward. There
are some crudities in the count that, I think, make this page count high
(final pages that are nearly blank, text that may be larger than whats
found in a book, task descriptors that duplicate information, a flexible
navigation style that you cant have in a book).
However, its probably true that some people will look at the bulk and
say were too heavy. At the least, we need to have an answer even if we
dont cut down the size. Moving sections into plug-ins is technically
feasible, but in the end the published process will be the same size so
Im not sure if how well that would address those critics.
Heres something to think about: Schwabers Agile Project Management
with Scrum and Becks Extreme Programming Explained are just over 150
pages each (including appendices and excluding the index). Scrum only
addresses PM, and XP only addresses development. OpenUP/Basic addresses
much more of the process.
Take the 4 main areas of OpenUP/Basic (RM, PM, Architecture, and
Development) and assign equivalent page lengths. 150 x 4 = 600 pages.
Than add just 50 pages for CM and overarching stuff. So for OpenUP/Basic
to be equivalent in size to the popular Agile books, it would need to be
650 pages long.
So if we use two of the most popular Agile books as benchmarks, were
still 100 pages lighter than existing process descriptions, even with
the conservative method we used to estimate the pages.
- Jim
____________________
Jim Ruehlin, IBM Rational
RUP Content Developer
Eclipse Process Framework (EPF) Committer www.eclipse.org/epf
email: jruehlin@xxxxxxxxxx
phone: 760.505.3232
fax: 949.369.0720
________________________________
From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx]
On Behalf Of "Brian Lyons" <blyons@xxxxxxxxxxxxx>
Sent: Friday, December 01, 2006 5:44 AM
To: Eclipse Process Framework Project Developers List
Subject: RE: [epf-dev] Discovered Size of OpenUP/Basic
hiho,
We have been sensitive to the element-count size of the process
throughout the authoring effort and this has kept our eye on the ball
with respect to making the process understandable. In a meeting on the
Design the Solution task one person might mention what about a task for
database design? and someone else would pipe up with what about user
experience? The focus on keeping the process understandable kept us
from blowing it out into something much larger
. element-count wise.
Contrasting some recent posts, I do not discount the importance of
keeping the scale down, page-count wise. We have an experienced,
well-educated group of people as contributors here and at each step any
one of us could wax poetic about the topic at hand. Understanding the
size we have in front of us and the importance of having an
understandable process should keep our eye on the ball, keeping us from
adding fluff.
Most people have experienced process descriptions in the form of books
that are inherently quantifiable. It is reasonable to talk about the
number of pages in this process; but in using that same measurement
unit, we should make sure we are calculating it similarly. A book would
not have so much space spent on the linkages that this process does. A
book will not have each small topic start on a new page.
Jims method provides a baseline that we can compare against as we move
from 0.9 to 1.0. But I dont think it provides a comparative number to
process content that one might find in book form. Id be interested in
finding out how many pages of actual content someone would be expected
to read and intellectually digest if they want to examine the process
from end-to-end. Well have to find another means to calculate that.
----------- b
________________________________
From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Chris Armstrong
Sent: Friday, December 01, 2006 6:52 AM
To: 'Eclipse Process Framework Project Developers List'
Subject: RE: [epf-dev] Discovered Size of OpenUP/Basic
I completely agree with Mark's perspective. We shouldn't be as concerned
about size, but more about essential content. To Scott's point, it might
not be a bad idea to consider refactoring content into multiple plugins,
so for those organizations and teams that are concerned about size can
control it (but we should probably get some feedback from the user
community before we dive into it). One thing about Jim's page count to
consider is that method content is re-published in the various
descriptors used in the capability patterns and delivery process. This
might artificially inflate the "actual" size of original content...
Thanks, Chris ~:|
________________________________
From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Mark.Dickson@xxxxxxxxx
Sent: Friday, December 01, 2006 4:14 AM
To: Eclipse Process Framework Project Developers List
Subject: Re: [epf-dev] Discovered Size of OpenUP/Basic
I think we should worry less about the number of pages and more about
the value of the content on each page.
The number of pages will be artificially bloated by the page layout
delivered by Composer. For example the Architecture work product covers
two pages of printed paper but only delivers about half a page of text
in a 12pt font.
On a more general point, I am uncomfortable about the way recent
discussions have focused on the size of the process, as if somehow
smaller means more agile. I do not believe that agility is a function of
the size of the process. It is a function of how people behave, not what
the process does or does not explicitly document.
I believe that it is important that OpenUP/Basic delivers value to it's
users. I do not think that the primary audience for OpenUP/Basic is
going to be projects made up of small teams of battle-hardened agile
development veterans. Projects like that don't really need to refer to
*any* written process.
So who's our audience? Small teams of less experienced developers
adopting new technologies and techniques? People who want to use the
Unified Process but want a free alternative to RUP? I think so. If that
is the case then OpenUP/Basic had better be delivering some real content
- by which I means actual practices and guidance to help them reach a
point where they don't need it anymore.
That stuff consumes pages. And (if done right) delivers value.
When deciding what to chop out of OpenUP/Basic, we need to make sure
that we ask the question "does this content deliver value to our
audience?" If the answer is yes and we are still at 542 pages, then I am
ok with that.
Cheers
Mark
Mark Dickson
Principal Solution Architect
SAE Practice
m 0780 1917480
w www.xansa.com <https://extranet.xansa.com/,DanaInfo=www.xansa.com+>
e mark.dickson@xxxxxxxxx
-----epf-dev-bounces@xxxxxxxxxxx wrote: -----
To: "Eclipse Process Framework Project Developers List"
<epf-dev@xxxxxxxxxxx>
From: "Scott W. Ambler" <swa@xxxxxxxxxxxx>
Sent by: epf-dev-bounces@xxxxxxxxxxx
Date: 12/01/2006 03:49AM
Subject: Re: [epf-dev] Discovered Size of OpenUP/Basic
Seems to me that we need to cut it down dramatically.
What material can we move out into separate plug-ins?
- Scott
On Thu, November 30, 2006 7:56 pm, Jim Ruehlin said:
> The best estimate I have so far of the size of OpenUP/Basic is 542
pages
> (8 ½ x 11). This is based on what's in CVS as of 11/29/06. This should
> give us an initial benchmark for our OpenUP/Basic 1.0 scoping efforts.
>
>
> I determined the size by creating a PDF of the entire website, doing a
> breadth-first walk along the links starting with the Intro page. I
didn?
> t see anything missing, but I only made a cursory examination of the
PDF
> file. Glossary terms, templates, and examples are included in the page
> count. Also, many web pages are longer than 8 ½ x 11, so this estimate
> is based on a book layout, not a website layout.
>
>
> - Jim
>
>
> ____________________
>
> Jim Ruehlin, IBM Rational
> RUP Content Developer
> Eclipse Process Framework (EPF) Committer www.eclipse.org/epf
> email: jruehlin@xxxxxxxxxx
> phone: 760.505.3232
> fax: 949.369.0720
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
