davehane | 1 Apr 2003 01:01
Picon

Re: Hard Data on XP vs. Traditional Methodologies

--- In extremeprogramming <at> yahoogroups.com, "Phlip" <plumlee <at> s...> 
wrote:
> > I am current engaged in non-XP work for a client that doesn't know
> > that they are in the software development business.  Delusional
> > issues aside...
> > What I am looking for is hard data...
> 
> Uh, if they are delusional, the kind of hard data that would help 
cure them
> escapes me. And me.
> 
> If they are delusional, fit what you are doing into their delusion, 
and call
> it whatever they want to call it.
> 
> Oh, but is this feature done yet? Or should I add all these [gold 
plating]
> line-items to the feature?
> 
> No? Wise choice. How about I compile a demo version and let you 
play with it
> while I go on to the next feature.

Ok, delusional was poor word to use.  More like, they don't see 
themselves as being in the software development business or they 
don't see software development as a core capability ... 

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com
(Continue reading)

Phlip | 1 Apr 2003 01:07
Favicon

Re: Hard Data on XP vs. Traditional Methodologies

> Ok, delusional was poor word to use.  More like, they don't see
> themselves as being in the software development business or they
> don't see software development as a core capability ...

I meant you could exploit where they are, not snow them with "hard data"
showing where you want them to say they should be. Go with the flow.

--
  Phlip

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 

yahoogroups | 1 Apr 2003 03:18

Re: What are the other heavyweight methodologies?


----- Original Message -----
From: "Olson, Curtis B" <olsoncb.at.state.gov <at> yahoogroups.at.jhrothjr.com>
To: "'extremeprogramming <at> yahoogroups.com'"
<extremeprogramming.at.yahoogroups.com <at> yahoogroups.at.jhrothjr.com>
Sent: Monday, March 31, 2003 5:35 PM
Subject: RE: [XP] What are the other heavyweight methodologies?

> > -----Original Message-----
> > From: Tom Cagley [mailto:tcagley <at> kellnet.com]
> > Sent: Monday, March 31, 2003 5:11 PM
> > To: extremeprogramming <at> yahoogroups.com
> > Subject: RE: [XP] What are the other heavyweight methodologies?
> >
> >
> > I mis-spoke, RUP is sold as a one size fits all methodology.  They now
> > even have path through the method that is marketed as agile.  One size
> > fits all (anything) is dangerous.
>
> Respectfully, I disagree.  It is sold as a configurable product that must
be
> sized appropriately to the project being undertaken. The project's process
> engineer chooses what size to use, not Rational.  If, as Ron seems to be
> saying, a project that tries RUP will tend to drift more towards the
> heavyweight side, then that is the consequence of the process engineer's
> choices and not the fault of the product.

That's what is *supposed* to happen. I've heard enough comments about
clueless management that thinks that it can simply be implemented "as is,"
without configuration, to know that there are a lot of shops that do it that
(Continue reading)

Keith Nicholas | 1 Apr 2003 03:22

RE: What are the other heavyweight methodologies?

There is the shlaer mellor methodology....

http://www.projtech.com/pubs/xtuml/summary.html

Interesting stuff...lots of good ideas.

Regards,

Keith

> -----Original Message-----
> From: K.Vivekanandan [mailto:kvivek27 <at> vsnl.net] 
> Sent: Tuesday, 1 April 2003 4:33 a.m.
> To: extremeprogramming <at> yahoogroups.com
> Subject: [XP] What are the other heavyweight methodologies?
> 
> 
> The  XP and the other lightweight methodogies are the alternative 
> methodologies to  encounter the difficulty/limitations introduced by 
> heavyweight methodologies. In XP resoruces only the following heavy 
> weight methodlogies are mentioned
> 
> 1. CMM (But it is also argued that  CMM  only recommneds but 
> acutually it is made as heavy weight by the companies)
> 2. RUP ( Again they mentioned that RUP can also be configured as 
> light weight process)
> 
> 
> Are  there any other well know heavy methodologies? Most of the XP 
> books decribes only the chracteristics of heavyweight methodologies 
(Continue reading)

Ron Jeffries | 1 Apr 2003 03:35
Picon
Favicon
Gravatar

Re: What are the other heavyweight methodologies?

On Monday, March 31, 2003, at 5:35:42 PM, Olson, Curtis B wrote:

> Respectfully, I disagree.  It is sold as a configurable product that must be
> sized appropriately to the project being undertaken. The project's process
> engineer chooses what size to use, not Rational.  If, as Ron seems to be
> saying, a project that tries RUP will tend to drift more towards the
> heavyweight side, then that is the consequence of the process engineer's
> choices and not the fault of the product.

If the implementations were uniformly distributed between too heavy and too
light, I would agree. To the extent that they are biased in one direction
or another, it would seem that the product must be at least partly to
blame.

Ron Jeffries
www.XProgramming.com
In programming, do, or undo. There is always try.  --Yoda

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 

Steve Ropa | 1 Apr 2003 04:11
Picon

RE: What are the other heavyweight methodologies?

I wonder if this is true for folks just coming in to the profession.  I know
that when RUP was first on the market it was being sold by Rational as a
"everything including the kitchen sink" methodology, but we have seen this
change of late.  Is there anyone who has only recently been introduced to
RUP?  Does it still seem to drive you to the "over-heavy" side?

Steve

-----Original Message-----
From: Ron Jeffries [mailto:ronjeffries <at> acm.org]
Sent: Monday, March 31, 2003 6:35 PM
To: extremeprogramming <at> yahoogroups.com
Subject: Re: [XP] What are the other heavyweight methodologies?

On Monday, March 31, 2003, at 5:35:42 PM, Olson, Curtis B wrote:

> Respectfully, I disagree.  It is sold as a configurable product that must
be
> sized appropriately to the project being undertaken. The project's process
> engineer chooses what size to use, not Rational.  If, as Ron seems to be
> saying, a project that tries RUP will tend to drift more towards the
> heavyweight side, then that is the consequence of the process engineer's
> choices and not the fault of the product.

If the implementations were uniformly distributed between too heavy and too
light, I would agree. To the extent that they are biased in one direction
or another, it would seem that the product must be at least partly to
blame.

Ron Jeffries
(Continue reading)

Turpin, Jay | 1 Apr 2003 06:43
Picon
Favicon

RE: Best XP Resources

Here's my list of good articles/sites:

Websites 

Ron Jeffries eXtreme Programming site: http://www.xprogramming.com 
Ward's Wiki: Lots of XP-related material and
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap. 
http://www.extremeprogramming.org - The "gentle introduction" to XP by
Don Wells
http://www.objectmentor.com - Object Mentor is a long time proponent of
XP and has an excellent XP Immersion course
http://www.pairprogramming.com/ - Everything you wanted to know about
the controversial, but very effective, practice of pair programming. 
http://www.xp123.com/xplor/ or http://users.vnet.net/wwake/ - Bill
Wake's collection of XP articles. 
http://www.martinfowler.com/ - Martin Fowler's site covering lots of
things, including XP, refactoring, and patterns. 
http://industriallogic.com/ - Industrial Logic - These folks have some
interesting XP games, training and offer XP consulting. 
http://www.jera.com/techinfo/xpfaq.html - John Brewer's eXtreme
Programming Frequently Asked Questions 
http://www.agilemodeling.com/ - Scott Ambler "Agile Modeling" site 
http://testing.com/agile/index.html - Brian Marick's Testing website
http://www.fawcette.com/resources/managingdev/ - Fawcette Publications
website devoted to all sorts of agile development articles 

Articles 

One Team by Kent Beck - A good description of what a "customer" on an XP
project:
(Continue reading)

Aston, Nigel | 1 Apr 2003 07:20

Software Engineering: Recording code reviews when pair programmi ng - how?

We are moving across from non-agile to partially agile.  Previously we had
formal code review sessions and recorded the results on hard copy print outs
and review forms.  With pair programming we would still like to maintain a
record that certain areas of code have been reviewed by the nature of pair
programming.  The purpose would be to know where we are falling down on code
quality as well as a record for some customers who require to know that the
code has been developed and reviewed accordingly. 

*	How would you propose keeping a record of such information?  The
same question could be asked about recording reviews of the auto tests.

Thanks

Nigel Aston, Taylor Hobson Ltd., Leicester, UK

DISCLAIMER: This message may contain privileged and confidential
information. If you think for any reason this message has been addressed in
error you must not copy or disseminate it and we would ask you to notify us
immediately by return email to postmaster <at> taylor-hobson.com. Internet emails
are not necessarily secure. Taylor Hobson Holdings plc is the holding
company for the Taylor Hobson group of companies and is registered in
England No. 3230332, with its address at 2 New Star Road, Leicester, LE4
9JQ, England. 

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 

(Continue reading)

nwaston2003 | 1 Apr 2003 07:24

Software Engineering: Recording code reviews when pair programming - how?

We are moving across from non-agile to partially agile.  Previously 
we had formal code review sessions and recorded the results on hard 
copy print outs and review forms.  With pair programming we would 
still like to maintain a record that certain areas of code have been 
reviewed by the nature of pair programming.  The purpose would be to 
know where we are falling down on code quality as well as a record 
for some customers who require to know that the code has been 
developed and reviewed accordingly. 

How would you propose keeping a record of such information?  The 
same question could be asked about recording reviews of the auto 
tests.

Thanks

Nigel Aston, Taylor Hobson Ltd., Leicester, UK

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 

Jim Little | 1 Apr 2003 07:10

RE: Continual design vs. Up-front design (Was: Pragmatic Programmers on XP)

From: Martin Fowler [mailto:mfowlerlists <at> thoughtworks.net]
> One thing I would add is some technical details on the design changes.
> What did you actually have to do to add internationalization? How did
> the existing design help you do that?

It's been a while since I worked on that system, so this is from memory.  As
I said, I've retrofitted web applications with internationalization twice.
Each case was significantly different.

In the first case, we were working with a mature XP project.  It wasn't
perfect, but it had very good code.  The presentation layer used WebMacro, a
minimalistic HTML templating tool.  WebMacro interpolated variables and had
a few conditional and looping commands.  It used reflection to hook up to
Java code that populated the variables.  It was a good, minimal product and
I liked it.  (http://www.webmacro.org)

One of the things we did early on was migrate from a framework-style
approach with WebMacro to a library-style approach.  In the beginning, we
used the WebMacro servlet to call our code--a framework-style approach.  As
time went on, though, that became restrictive.  We refactored the code so
that we had our own servlet that called WebMacro like a library.

Setting up WebMacro that way was a bit more work than the framework
approach, and it required a bit more understanding about advanced WebMacro
usage.  That's why we didn't do it that way at first.  But we started
needing more control, so we refactored.  I think we did it to make our
presentation flow logic cleaner.

When we did this, we had to set up some logic to tell WebMacro where to load
its templates from.  It handled that automatically before, but now we were
(Continue reading)


Gmane