Very good points, Buck. Waterfall estimates are very iffy at any significant scale. And even with waterfall, specs change per the users, surprises hidden in the application code you're modifying tend to pop up like a jack-in-the-box, and so on, especially if it's been around awhile.
Agile also recognizes that you cannot budget the biggest changes (convert to new back-office enterprise system) very well for all the above reasons. But CFO's really really want to budget everything and CEO's really really want to plan ahead. But Information Technology is not the only vector for pop-up unpredictability, nor is it the worst. "Compliance" requirements are WAY worse for that.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck Calabro
Sent: Thursday, October 24, 2013 4:48 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Looking for Agile Experience
On 10/24/2013 3:49 PM, Matt Olson wrote:
With a lack of requirements how does one estimate the time and cost involved in such project?
Story points.
It turns out that story points are a very close analogue to function points, even though 'point' means something different. Mostly, so-called 'estimates' under the waterfall philosophy are useless. Any chunk of work longer than a couple of hours is basically impossible to estimate (in my estimation). So seeing 'Order Entry display - 4 days'
is a joke, and looking at how many waterfall projects go over estimate, I'd say that objective evidence supports my opinion.
If, instead, the estimate were broken into smaller functions (validate customer ID, check customer credit worthiness, pop up tickler window for
specials) the sum of the estimates plus an integration estimate brings us much closer to a useful (ie can plan employee hours) figure. Note that the functions look an awful lot like user stories.
--buck
-----Original Message-----
From: John Yeung
Sent: Thursday, October 24, 2013 8:45 AM
To: Midrange Systems Technical Discussion
Subject: Re: Looking for Agile Experience
On Wed, Oct 23, 2013 at 10:11 AM, Richard Schoen <richard@xxxxxxxxxxxxxxx> wrote:
There appear to be shades of Agile, so we've picked up the bits that
seemed to make sense such as requirements before coding
Well, "requirements before coding" is actually more strongly associated with the waterfall development style than the agile style.
You could definitely argue that it is part of agile, but the emphasis of agile is on adaptability and responsiveness; and as such the requirements are much more likely under agile to change quickly or be revisited.
Whenever I hear people in IT (particularly in companies whose core business is NOT their IT) talk about requirements before coding, it's in the context of having as close to iron-clad specs as possible for a whole project prior to doing any coding at all for that project. The specs are typically only revisited if it is discovered that they are unworkable (and the IT people working under this model typically blame the users for giving them bad specs or for asking to change the specs after the work starts). This model sounds much, much more like waterfall, and practically not at all like agile.
If by "requirements before coding" what you really mean is "let's understand something (which is preferably some small piece) well enough to be able to write tests for it first (and let's then go ahead and write those tests first) before we do coding (for the functionality being requested)" then, yes, absolutely, you are talking more agile-style than waterfall-style. But that's a lot of extra verbiage that you're implying/assuming. In my opinion, far too much to distill to a three-word buzzphrase.
John
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
--------------------------------------------------------------------------------
Confidentiality Notice: This email may contain confidential information or information covered under the Privacy Act, 5 USC 552(a), and/or the Health Insurance Portability and Accountability Act (PL 104-191) and its various implementing regulations and must be protected in accordance with those provisions. It contains information that is legally privileged, confidential or otherwise protected from use or disclosure. This e-mail message, including any attachments, is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you.
--------------------------------------------------------------------------------
midrange.com
