Extreme Programming and effort estimation

Extreme Programming and effort estimation

Post by Phli » Sat, 21 Jun 2003 22:50:41



[Followups set to comp.software.extreme-programming. Those with news servers
lacking that group should use http://www.veryComputer.com/ ]


> I just finished reading some chapters from Kent Beck's "Extreme
> Programming Explained". Wonderful book. Wish I had read it earlier.

> I have one doubt though. XP promotes continuous feedback mechanism,
> client interaction to see if things are in the right direction, etc.
> This will work fine where the contract with the customer is on hourly
> billing rates  basis. What about f fixed value contrats? How do I
> quote to a cusotmer if I don't know up front what *exactly* the specs
> are and they are going to change based on continuous feedback from the
> client?

This depends on >why< the customer requests a fixed cost, fixed scope
contract.

Sometimes they actually have immobile requirements, and a real deadline,
such as an airport opening.

Most of the time, though, they are only familiar with programmers who take
their money, give them long blackouts, and then deliver crap. They have
learned they must enforce a fixed price and fixed scope contract, to force
these programmers to work overtime to fix all their bugs.

The odds of being stuck with *at the end of a project are low if you
test relentlessly, don't give them long blackouts, and have your work
reviewed chronically.

Tell them this, "Let's start the project with one small contract, such as a
month's time & materials. But you give us your best domain expert, during
that time, to make absolutely certain we are doing the right thing during
that month. Then, every week, we'l give you a fully working product - even
if its very small - with your most important feature in it."

Your quality, and responsiveness to steering, will inspire them to either
change their contracting habits, or they will continue to give you little
one-month contracts with a fixed scope they know you can exceed. Which is
the same difference.

(A typical XP iteration is 2 weeks, but I suggested 1 week iterations
because when a team is in trouble - such as when they have a fretful
customer - they must become >more< extreme, not less.)

--
  Phlip
    http://www.veryComputer.com/

 
 
 

Extreme Programming and effort estimation

Post by Shayne Wissle » Sun, 22 Jun 2003 00:24:18



Quote:> (A typical XP iteration is 2 weeks, but I suggested 1 week iterations
> because when a team is in trouble - such as when they have a fretful
> customer - they must become >more< extreme, not less.)

So, 2 weeks is extreme, 3 weeks is less extreme, and 1 week is more extreme?
Hey, if being extreme is good, why not make the iterations be 2 seconds?
Would that be "way more" extreme?

 
 
 

Extreme Programming and effort estimation

Post by Ernie Varitimo » Sun, 22 Jun 2003 03:46:07



> [Followups set to comp.software.extreme-programming. Those with news servers
> lacking that group should use http://www.veryComputer.com/ ]


>> I just finished reading some chapters from Kent Beck's "Extreme
>> Programming Explained". Wonderful book. Wish I had read it earlier.

>> I have one doubt though. XP promotes continuous feedback mechanism,
>> client interaction to see if things are in the right direction, etc.
>> This will work fine where the contract with the customer is on hourly
>> billing rates  basis. What about f fixed value contrats? How do I
>> quote to a cusotmer if I don't know up front what *exactly* the specs
>> are and they are going to change based on continuous feedback from the
>> client?

> This depends on >why< the customer requests a fixed cost, fixed scope
> contract.

> Sometimes they actually have immobile requirements, and a real deadline,
> such as an airport opening.

> Most of the time, though, they are only familiar with programmers who take
> their money, give them long blackouts, and then deliver crap. They have
> learned they must enforce a fixed price and fixed scope contract, to force
> these programmers to work overtime to fix all their bugs.

> The odds of being stuck with *at the end of a project are low if you
> test relentlessly, don't give them long blackouts, and have your work
> reviewed chronically.

> Tell them this, "Let's start the project with one small contract, such as a
> month's time & materials. But you give us your best domain expert, during
> that time, to make absolutely certain we are doing the right thing during
> that month. Then, every week, we'l give you a fully working product - even
> if its very small - with your most important feature in it."

> Your quality, and responsiveness to steering, will inspire them to either
> change their contracting habits, or they will continue to give you little
> one-month contracts with a fixed scope they know you can exceed. Which is
> the same difference.

> (A typical XP iteration is 2 weeks, but I suggested 1 week iterations
> because when a team is in trouble - such as when they have a fretful
> customer - they must become >more< extreme, not less.)

> --
> Phlip
>   http://www.veryComputer.com/

This is an interesting strategy. I liken this to driving at night on a
lonely country road with a new moon trying to find the stardust motel. You
have idea where you are, intelligible directions, and no map or road signs.
You can only see 200 feet in front of you, and you're growing anxious
wondering if you'll ever get some shut-eye.

Most organizations know what they want, they just don't understand what it
will take for them to get there. More importantly, they need a map and
driving directions that clearly set their expectations from way point of way
point.

I think you can follow your strategy for the first month, but strictly to
develop metrics. Develop a bond of trust with the customer by giving them
something predictive. Once those metrics have been developed, apply a form
of function point analysis (the exact metrics formulas used are not so
important, as long as they make sense and can be interpolated).

Of course it is important that in your estimation you provide an intelligent
proper weighting factor for those components that are not completely
developed from a requirements point of view. There is no substitute for
experience here.

-ernie
http://www.veryComputer.com/

 
 
 

Extreme Programming and effort estimation

Post by Code Like He » Sun, 22 Jun 2003 04:53:22


Start Small,  in other words.  Don't handle the paper even once.

> [Followups set to comp.software.extreme-programming. Those with news servers
> lacking that group should use http://www.veryComputer.com/ ]


> > I just finished reading some chapters from Kent Beck's "Extreme
> > Programming Explained". Wonderful book. Wish I had read it earlier.

> > I have one doubt though. XP promotes continuous feedback mechanism,
> > client interaction to see if things are in the right direction, etc.
> > This will work fine where the contract with the customer is on hourly
> > billing rates  basis. What about f fixed value contrats? How do I
> > quote to a cusotmer if I don't know up front what *exactly* the specs
> > are and they are going to change based on continuous feedback from the
> > client?

> This depends on >why< the customer requests a fixed cost, fixed scope
> contract.

> Sometimes they actually have immobile requirements, and a real deadline,
> such as an airport opening.

> Most of the time, though, they are only familiar with programmers who take
> their money, give them long blackouts, and then deliver crap. They have
> learned they must enforce a fixed price and fixed scope contract, to force
> these programmers to work overtime to fix all their bugs.

> The odds of being stuck with *at the end of a project are low if you
> test relentlessly, don't give them long blackouts, and have your work
> reviewed chronically.

> Tell them this, "Let's start the project with one small contract, such as a
> month's time & materials. But you give us your best domain expert, during
> that time, to make absolutely certain we are doing the right thing during
> that month. Then, every week, we'l give you a fully working product - even
> if its very small - with your most important feature in it."

> Your quality, and responsiveness to steering, will inspire them to either
> change their contracting habits, or they will continue to give you little
> one-month contracts with a fixed scope they know you can exceed. Which is
> the same difference.

> (A typical XP iteration is 2 weeks, but I suggested 1 week iterations
> because when a team is in trouble - such as when they have a fretful
> customer - they must become >more< extreme, not less.)

 
 
 

Extreme Programming and effort estimation

Post by Phli » Sun, 22 Jun 2003 07:06:34



> Start Small,  in other words.  Don't handle the paper even once.

Not >that< small! Everyone here has experienced not starting with any
paperwork. Don't do that!

(Incidentally, your online handle's reminding me of a duck. Above the water,
it looks calm, stately, and unperturbed. Under the water and unseen,
however, its webbed feet are paddling furiously.)


> This is an interesting strategy. I liken this to driving at night on a
> lonely country road with a new moon trying to find the stardust motel. You
> have idea where you are, intelligible directions, and no map or road
signs.
> You can only see 200 feet in front of you, and you're growing anxious
> wondering if you'll ever get some shut-eye.

You might possibly be the first to like this:

    http://www.c2.com/cgi/wiki?AgilityTest

The big-contract-up-front customers want to pay for one big shot at steering
in the dark with poor light. They don't know they can turn up the light, and
pay as they go.

--
  Phlip

 
 
 

Extreme Programming and effort estimation

Post by Robert C. Mart » Wed, 25 Jun 2003 11:12:42



written this on (or about)  Fri, 20 Jun 2003 15:24:18 GMT, :



>> (A typical XP iteration is 2 weeks, but I suggested 1 week iterations
>> because when a team is in trouble - such as when they have a fretful
>> customer - they must become >more< extreme, not less.)

>So, 2 weeks is extreme, 3 weeks is less extreme, and 1 week is more extreme?
>Hey, if being extreme is good, why not make the iterations be 2 seconds?
>Would that be "way more" extreme?

Interestingly enough, the code for the computer in the Mercury space
capsule was developed using iterations of four *hours*.  And tests
were written before code.  (According to Craig Larman's wonderful
history of iterative development paper in IEEE)

I often use four hour iterations when teaching XP or TDD in courses.
Amazingly enough, it works pretty well.  Even so, I prefer one-two
week iterations.

Robert C. Martin  | "Uncle Bob"                  

PO Box 5757       | Tel: (800) 338-6716        
565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
Suite 135         |                               | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring        | www.junit.org
60061             | OO, XP, Java, C++, Python     |

 
 
 

1. Extreme Programming and effort estimation

I just finished reading some chapters from Kent Beck's "Extreme
Programming Explained". Wonderful book. Wish I had read it earlier.

I have one doubt though. XP promotes continuous feedback mechanism,
client interaction to see if things are in the right direction, etc.
This will work fine where the contract with the customer is on hourly
billing rates  basis. What about f fixed value contrats? How do I
quote to a cusotmer if I don't know up front what *exactly* the specs
are and they are going to change based on continuous feedback from the
client?
... Ash

2. MS-DOS doesn't really boot from the floppy drive ...

3. Software Project Effort Estimation Woes !!

4. Books on ORACLE

5. Extreme Programming (XP) Process is Extreme!

6. Agenda password protect

7. Aspect Oriented Programming work with Extreme Programming

8. Clean and erase Cd-Rom????

9. would Linux be useful for my game programming efforts?

10. Extreme programming without pair programming

11. Connections between Adaptive Programming and Extreme Programing

12. Aspect Oriented Programming work with Extreme Programming

13. Extreme Programming Light without pair programming?