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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] 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 [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ----- To: "Eclipse Process Framework Project Developers List" <[email protected]> From: "Scott W. Ambler" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] > > phone: 760.505.3232 > > fax: 949.369.0720 > > > _______________________________________________ > epf-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/epf-dev <https://extranet.xansa.com/mailman/listinfo/epf-dev,DanaInfo=dev.eclipse.or g,SSL+> > Practice Leader Agile Development, IBM Rational http://www-306.ibm.com/software/rational/bios/ambler.html <https://extranet.xansa.com/software/rational/bios/ambler.html,DanaInfo=www- 306.ibm.com+> Refactoring Databases ( http://www.ambysoft.com/books/refactoringDatabases.html <https://extranet.xansa.com/books/refactoringDatabases.html,DanaInfo=www.amb ysoft.com+> ) is now available. _______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev <https://extranet.xansa.com/mailman/listinfo/epf-dev,DanaInfo=dev.eclipse.or g,SSL+> 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
_______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
