I also agree with Mark and Chris.
Sheer page count is not a good measure of effectiveness in
my opinion. I don't think any user will print out all the pages and make a
decision on using OpenUP/Basic (or EPF) based on the
result. OpenUP/Basic is not a book, so page count is a fuzzy concept
to begin with, as evidenced by our difficulty in defining it. Do
users count source lines of code in deciding whether or not a business
application is a worth using?
What is important is the complexity of the process (i.e how
many pages do I have to read to complete a task? How many tasks do I have
to perform to get the job done? How many artifacts do I need to produce
and do they all bring value? Can I understand what I have to do? Is
it consistent? Can I find the information I need when I need
it?)
OpenUP/Basic should be "minimal", but it should also be
"complete" and "extensible".
Cheers,
Chris
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 ~:|
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.come
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
>
Practice
Leader Agile Development, IBM Rational
http://www-306.ibm.com/software/rational/bios/ambler.html
Refactoring
Databases (
http://www.ambysoft.com/books/refactoringDatabases.html) is
now
available.
_______________________________________________
epf-dev
mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
Whilst
this email has been checked for all known viruses, recipients should undertake
their own virus checking as Xansa will not accept any liability
whatsoever.
This email and any files transmitted with it are confidential
and protected by client privilege. It is solely for the use of the intended
recipient.
Please delete it and notify the sender if you have received it
in
error. Unauthorised use is prohibited.
Any opinions expressed in
this email are those of the individual and not
necessarily the
organisation.
Xansa, Registered Office: 420 Thames Valley Park
Drive,
Thames Valley Park, Reading, RG6 1PU, UK.
Registered in England
No.1000954.
t +44 (0)8702 416181
w www.xansa.com
