Re: agile/xp question (formal analysis)

From: AndyW (foo__at_bar_no_email.com)
Date: 12/02/04 

Date: Fri, 03 Dec 2004 10:33:10 +1200

On Thu, 02 Dec 2004 07:14:37 -0500, Ron Jeffries <ronjeffries@acm.org>
wrote:

>I'm re-ordering things a bit here.
>
>On Thu, 02 Dec 2004 10:02:09 +1200, AndyW <foo_@bar_no_email.com>
>wrote:
>
>>On Wed, 01 Dec 2004 07:02:33 -0500, Ron Jeffries <ronjeffries@acm.org>
>>wrote:
>
>>>In a phaseless approach such as an Agile method, the dates on the
>>>calendar are associated /only/ with a list of things to be
>>>accomplished, typically almost completely vague things.
>>>
>>>Between those dates, any of analysis, design, test, and code can occur
>>>on any given day. The focus is on the feature, not on the ADCT phase
>>>the feature is in.
>>>
>>Yes, but it would be suicidal to try that approach with a large piece
>>of funding. You wouldnt get it. :)
>
>This is a perfectly pragmatic reason to organize software development
>the way you have described. It is no evidence whatsoever that it's a
>good way to do it, much less ideal. It sounds like your projects are
>successful: if so, good for you, and the way is working for you.
>
>We know that many large projects are not delivered on time, on budget,
>and fit for purpose. This suggests to me that the approaches that get
>funded are not inherently good approaches.
>
>----
>
>On the subject of phases:
>>
>
>>>In a phased approach, Analysis, Design, Code, Test are associated with
>>>plan dates on a calendar. We know /when/ Design of some thing is
>>>supposed to be "done", and so on. We try to measure things like
>>>"Analysis of XYZ complete".
>>
>>No,
>>
>>Milestones (in project management) are associated with various parts
>>of the calendar, the phases are not.
>>
>>I might have 4 analysis phases each containing 10 different milestones
>>for when the AOM is complete for different subject areas, depending on
>>those milestones will be when I need designers to come and pick up the
>>result or work with the analysist in performing their tasks.
>>
>>Developers will need to know approximately when to perform their tasks
>>and how to schedule their workload (I may be moving them between
>>feature teams) and the Test team will be working on their own
>>calendar, but will need to plan approx when the appropriate work
>>products are coming their way.
>>
>>Like wise there is a whole host of budgeting, resourcing and
>>scheduling issues that hang off those milestones.
>>
>>Certianly in mini-waterfall you would never have a start and end date
>>for analyssis or any other phase because you wouldnt know how many
>>iterations and what overlaps to do.
>>
>>You would in waterfall, but thats a different method.
>
>Yabbut ... miniwaterfall is just a bunch of mini waterfalls. They
>still separate Analysis from Design and so on. So they still have the
>same problem that I'm concerned about: The calendar says analysis will
>be complete. Therefore there's a good chance that it will be declared
>complete. Problems in the analysis can be discovered only sometime
>much later in design, and often even much later, in coding, and
>sometimes only in testing, when someone finds a conflict of
>understanding.

Unless someone is a control merchant, I havent seen that done in
years. Each mini-waterfall (at that level) would be for the
development of a feature.

For a PM, you'd probably only have the start and end of the feature on
your project plan. The implementation manager would have the actual
Work Break Down structure in their plan (on a small team it would
likely be the same plan which is what I think you are visualising).

>
>To the extent that Analysis is separate in time from Design, from
>Code, from Test, the feedback loop on the quality of each phase is
>slowed.
>
>One way of looking at Agile methods in this context might be to
>describe them as "micro-waterfall". The objective is to get ADCT as
>close together as possible. One very good result of this is that you
>can actually measure the project differently:
>
Thats what all methods achieve, nothing to do with the method itself,
thats the domain of good planning by the PM. The phases of the method
are only there to indicate that certain types of work need to be done,
not When they should be done as thats a planning issue.

> Feature Running and Tests Passed is a very different kind of
>milestone from Analyis Complete.
>
>Another good result is:
>
> With a Features Complete orientation, we might ship with only
>partial function, but we're guaranteed to be able to meet our date. If
>we do features in priority order, we're guaranteed to meet our date
>and budget with the best possible subset.
>
>There are of course potential problems with working this way. At the
>scale that I work, I prefer those problems to get the certainty. At
>some other scale they might multiply in some way as to make
>"mini-waterfall" be the right scale.
>
>I don't know that. I don't know how to measure it, nor how anyone else
>does. To me it just looks like people's underwear ouside their pants.
>
>So ... how /do/ top teams like yours measure whether the size of the
>mini-waterfalls should be smaller, larger, or stay the same?
>
>Very interesting, all of this. I'm not sure we're going anywhere, but
>I'm at least gaining more understanding. That's good for me, at least.
>:)

I'm a methologist when people dont ask me to write code. Someone has
to be able to manage the managers :)

Thats the fun stuff.

Relevant Pages

  • Re: agile/xp question (formal analysis)
    ... >means that the analysis, design, code, test, and fix for the average ... >feature will be 20 person days. ... >developers, not 20, and it delivered a fully integrated and tested ... dev process for each of the feature teams, a resource plan, high level ...
    (comp.object)
  • Re: (Lengthy) entire outline of abandoned futuristic RL attempt
    ... you plan out every feature you'd like in the game first, ... your design will be wrong. ...
    (rec.games.roguelike.development)
  • Re: this is getting crazy
    ... But the projected sales volume is tens of thousands per annum, so thats millions of photodiodes. ... Aside from the fact I get paid, its heart-warming to design something thats truly helpful. ... Its the brainchild of a guy who worked as a sparky at a facility for disabled people, and was disgusted at the primitive human-computer interfaces available. ...
    (sci.electronics.design)
  • Re: MaxInt on Vista-64bit?
    ... I found out, thats by design, ... compile python 2.6 with maxint of 64bit integers? ... no. Use a real 64-bit operating system ...
    (comp.lang.python)
  • Re: break removal
    ... >thats because its not supposed to, its part of the switch statement to ... >allow you to overlap cases, its a feature. ...
    (comp.lang.java.programmer)
Loading