| Carl K. Chang, Ph.D.
President IEEE Computer Society, 2004
Professor and Chair, Computer Science Department, Iowa State University
To succeed in today's IT environment we can no longer ignore the gap that exists between the vocabulary and value systems of business stakeholders and those of software developers. Successful software projects must not only be delivered on-time and within budget, but must fulfill organizational objectives and bring meaningful financial rewards. This can only be accomplished by managing business strategies as an integral part of the software development process. This book addresses the need head-on with analytical techniques, concepts, and tools to ensure that your corporation's software investment does not fall into the gap of cost overruns, finger pointing, late delivery and feature irrelevancy!
|
| Agile
Back to top Alistair Cockburn
It is not often these days that a software book contains new enough
information, captured in a different enough way, that I feel compelled
to read it carefully and extract, to the extent I can, the knowledge of
the authors. This is one of those rare books.
Two things struck me immediately, and a third almost half-way through my
reading (well, page 50).
First, they *presuppose* that the project will be developed and
delivered incrementally, and move forward from there. That is already
interesting, since most authors spend their energies attempting to
convince the reader to attempt incremental development at all. These
authors provide information to convince those who don't know incremental
development but want to stare at the arguments closely, and add relevant
new information to those who already do know it well.
Second, they put numbers behind the agile approach of delivering usable
functionality early. That is again only their starting point, and they
move forward to show how some reasonably simple spreadsheet math points
to a difference in *which* pieces get delivered first. (I focus on the
presence of the agile style, since that is what I do).
Third (the one I discovered only half-way through my reading), they take
into account financial consequences of incremental development of the
*architecture* elements also, which I have never seen done before. (I
and others recommend and do incremental architecture, but I've never
seen a financial argument supporting the strategies). And again, that is
where they start, and they move forward to derive which might best be
developed first, etc.
Mind you, I'm generally allergic to looking at tables of financial
numbers (and I'll guess most of you are, too), so it took some deep
breathing exercises before I sat down with my cup of tea and worked my
way through the first example on page 20. That activity was worthwhile,
however, and I could see where they were headed (OK, overstatement
again, they surprised me a few more times in the next 50 pages).
The book' material seems to have been derived from projects that were
financially researched to a greater extent than the projects I've been
involved in (read the preface for examples), so I don't know that I'll
actually create a spreadsheet for my projects. However, the math and
logic are compelling, and the spreadsheets are there for any financial
officer or competitive bidder to use to examine the strategies for
themselves. Maybe on my of my next projects, I'll draft someone to help
me work through the math to see if our intuition matches the tables.
I can hope that as future work, these authors might take on two
additional challenges: Include the "value of information" derived from a
prototype or early increment, and show us how to fold those into the
tables. Show how to work with coarse-grained valuations such as Tiny,
Medium, Large, Humungous, and derive meaningful strategies from
dependency networks of those.
Two last notes (I'd include some nifty quotes from the book, but this
review is already long enough, so someone else can do that). First,
perhaps a small point for some --- I rarely make it half-way through a
book before getting too tired to take in more information, so I'm really
glad they got the heart of their story in the first 77 pages (the grand
denouement, incorporating XP, cost of money, and architectural
dependencies all at once, is on pages 73-75 (not that you'll understand
it if you don't read the previous pages)). They used the second half of
the book for recap, extensions and examples. One of these days I'll have
the energy to work carefully through their example on concurrent
development. Second, their model suits both fixed bid and XP
environments (and their discussion shows they understand modern agile
development).
Tom Poppendieck
I picked up Software by Numbers at OOPSLA where a colleague
described it as making the economic case for XP. Incremental funding of
projects via minimum marketable features enables meaningful
customer/management tradeoffs just a use cases enable user interface and
workflow analysis and user stories enable reliable, predictable code
development. This is well worth adding to your customer toolkit
for iterative incremental projects. It is systematically and broadly
applies ideas similar to tool 12 in Lean Software Development, which
describes using a project P&L to guide project decisions. Highly
recommended.
Mary Poppendieck
Review at
http://www.poppendieck.com/funding.htm
Jim Shore
Software by Numbers describes a
ReturnOnInvestment-based
approach to selecting and prioritizing software features. The book
includes an extensive discussion of its method, IFM (Incremental Funding
Methodology), and guidelines on implementing it alongside
RationalUnifiedProcess or XP.
IFM is a perfect fit for
ExtremeProgramming:
where XP addresses levels 1-3 on the
LevelsOfSoftwareSuccess scale, Software by Numbers addresses levels
4-6. XP's simple approach to architectural dependencies (EvolutionaryArchitecture)
looks like it'll make IFM even easier to implement.
Although some people may be turned off by the numbers-centric
view, I loved the focus on
DeliverValue and putting costs into context. I think this book
offers guidance for
OnSiteCustomers that XP lacks. Highly recommended. --
|
