Re: agile/xp question (formal analysis)

From: AndyW (foo__at_bar_no_email.com)
Date: 11/29/04 

Date: Mon, 29 Nov 2004 22:55:03 +1200

On Mon, 29 Nov 2004 09:25:02 +0100, "Ilja Preuß" <it@iljapreuss.de>
wrote:

>Ron Jeffries wrote:
>
>> What seems equally true to me is that we might have taken a handful of
>> people, looked at an existing flight booking system, talked with, as
>> Laurent suggests, people from one airline, and begun to produce a
>> system.
>
>My biggest fear with that approach would be that, with the high competition
>between airlines, it might not be in the one airline's interest to build a
>booking system that you can sell to their competitors, too. As I've never
>been in such a situation, I don't know wether I should expect that fear to
>materialize or how I would deal with it, though...
>
>> Again, I agree that you
>> are describing a valid way of doing these large projects, but it's not
>> clear to me that it is the only way or even the best way -- though
>> surely it's the best way we know so far.
>
>Did you take a look at the works of Jutta Eckstein yet?
>http://www.jeckstein.de/agilebook/index.html
>
>A week ago she gave a keynote at the XP-days Germany. One thing that stuck
>was her notion that *especially* with large teams she would want to be
>Agile, and specifically have frequent milestones with running tested
>software. The reason being that big teams produce more in a shorter time
>frame (that's why we use them, isn't it?), and therefore more can go wrong
>in a shorter time frame (and more money will be lost if something goes
>wrong). Sounded reasonable to me...
>
>Regards, Ilja
>

Yes, she is talking about an issue I raised in earlier posts about
cost metrics and also using software baselines.

The latter is only usefull if you have managed to keep all your
development teams in synch - the alternative is to schedule drill
downs (end to end scenario testing).

On another note - the biggest thing I have picked up from the last few
points is the lack of understanding for what a customer on a large
project actually is. Likewise its hard to explain a large project to
someone that has never seen one.

Even the concept of meeting a new person at the coffee machine every
day for a year can sound odd :)

Customer for a large project in many cases can often be a country (or
several for one I worked on) and/or a set of mega corps. You cant
just treat them like the small business down the road.

Relevant Pages

  • Re: agile/xp question (formal analysis)
    ... > Laurent suggests, people from one airline, and begun to produce a ... booking system that you can sell to their competitors, ... The reason being that big teams produce more in a shorter time ... in a shorter time frame (and more money will be lost if something goes ...
    (comp.object)
  • Re: concurrency for asp.net
    ... irritating for other customer if he has to wait for someone else to make ... > disallow any other customer from trying to check the same booking until the ... my application is going to implement a online restaurant ... >> table booking system ...
    (microsoft.public.dotnet.framework.aspnet)
  • customise primary Key
    ... creating booking system for repair. ... for both tables i need to create a customize key for customer ... year and finally a unique intger for example ...
    (comp.databases.ms-sqlserver)