RE: Managing Extreme Programming

"Alleman, Glen B." <[email protected]>
Newsgroups gmane.comp.programming.extreme-programming.adoption
Message-ID <[email protected]>
George,

> -----Original Message-----
> From: Dinwiddie, George 
[>] snip
> 
> So Earned Value is the sum of the values of all user stories for which
the
> acceptance tests pass?

[>] The cumulative cost incurred to produce the delivered product as
well as the incremental costs for each deliverable milestone (inch
pebbles for the XP style project), is held in the BCWP.

A key pillar of EV is that the PM knows at all times what percentage of
the physical work has been accomplished, the percent complete, as
related to the total job.

The emphasis is on "physical" percentage complete, not the percent of
hours, or percent of stories -- unless each storey and each hour
produces the same "value."

It is this "variable" production rate that BCWP makes visible.

> > The business and PM folks I support have no clue about the
> > terms used in XP. They live and breathe EV. For adoption to
> > take place we have to (and
> > have) moved to their vocabulary NOT had them understand the
> > vocabulary of XP. At least that's how we've made progress.
> 
> That's reasonable, but we need a dictionary to translate between the
two
> languages--in both directions.

[>] For EV it is EIA 748B and Quentin Fleming's book Earned Value
Project Management, Second Edition.

> > > > (2) How to "digitize" the overall schedule (say 3 years
> > and $100M of
> > > > radar systems development of hardware, software a flight
> > platforms)
> > > > down to daily builds, and bi-weekly iterations and
> > monthly releases
> > > > of software for the project.
> > >
> > > What does it mean to "'digitize' the overall schedule?"  Again, I
> > don't
> > > know
> > > what this means.
> >
> > [>] reduce the "progress to plan" measurements to a daily or
> > 3 day level. A typical "big" project might run for 3 years
> > and be 10's of millions in software alone. In the past this
> > was managed using EV on large grained boundaries (say 3 to 5
> > month milestones). We're reducing these to 3 day milestones
> > with "testable requirements," as the exit criteria for the
> > milestone, that when it passes accrues the "earned value" -
> > BCWP booked as value.
> 
> I still don't understand your meaning of "digitize."  Do you mean
"convert
> to numbers?"  Do you mean "convert to a set of booleans?"

[>] It's a metaphor. (ah s@#t I sound like Ron). The metaphor is to take
what is considered in traditional PM methods an analog process -- time
passes so progress must be taking place. Change this metaphor to one of
"inch pebbles," "fine grained" deliverables, say on daily or 3 day
boundaries, and "sample" the continuous S-curve. Either the sample
produces a 100% booked value for the increment or a 0% earned value.
100% if it passes the requirements test, 0% if it does not. The S-Curve
(see the EV on one page) then looks like a large number of fine grained
step functions == digitized.

> Is it assumed that the cost of development is equal to the value of
that
> which is developed?

[>] Ah, now you're on to something - maybe not. In that is the case the
task is Level of Effort == cost equals value. In other cases the value
may not equal the cost - cost variance or schedule variance. The code
component is say worth $100 (1/10 of a $1,000 function point). But it
took $110 to get it, so we have a Cost Variance (CV) of ($10), but it
came in on time so the SV is 0.

> > [snip]
> 
> I'm starting to get into too many questions for one email.  I think I
need
> to take this list a little slower as I learn Earned Value.
> 
> > [>] In the majority of our work (to date) the customer is in
> > the form of a three ring binder, called the Functional
Specification.
> 
> Sure.  And someone needs to really understand that document and make
sure
> that the development team is building the right thing.  And where
there is
> ambiguity in that document, someone needs to clear up that ambiguity
and
> make a decision.  That someone (or several someones) is the Customer.

[>] Yep that's our daily routine.

> > > > (6.1) How to dollarize the velocity units in terms the project
> > > > accounting folks will accept.
> > >
> > > Lets see...  If x developers average y units per iteration, and
the
> > > fully-loaded cost of those x developers is $z per
> > iteration, then the
> > cost
> > > per velocity unit is $z/y.  Not so difficult.
> >
> > [>] Except this calculation I a level of effort and does not
> > describe the "value" in dollars of the delivered code. It
> > described the dollars spent but not the dollarized value
> > delivered. Again see some of the intro materials in the link above.
> 
> Can you express the dollar value of a completed User Story?  Or the
dollar
> value of a requirement in the Functional Specifications document?

[>] We've dollarized the individual story at the beginning of the
iteration. The same can be made for a specific requirement or FP. Take a
look at
http://www.testablerequirements.com/testablerequirements/index.htm for
some background.

> 	- George

Glen 


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Turn flat surfaces into speakers with the Soundbug.
http://us.click.yahoo.com/QWAVSC/onCFAA/xGHJAA/nhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.