[Gllug] Development Methodologies

[Aaron Trevena]

On 21/12/05, Richard <richard_c at tpg.com.au> wrote:
> >Small team, intelligent developers, capable programming language,
> >rapid iterative development directly involving the end users.  Works
> >for us anyway.

There is no reason you can't do that and make use of UML, obviously if
you were following the 1.1 specification to the word then it wouldn't
fit nicely but do you really never use dia, or anything to draw a
class schema, or write a use case on a board (XP includes simplified
use cases anyway), or a sequence diagram of what happens when?

> I wonder how far this scales, personally. I think that you're absolutely
> right that this is a great model for small-medium projects - but when
> the scope of the project creeps outside a manageable group of users (ie:
> representatives of all the different user groups can't reasonably be
> involved simultaneously), and/or the requirements simply don't allow a
> small team to complete the project in a reasonable timescale, what then?

I think it's more to do with complexity and reliability - if you
require high reliability (rather than availability which you can just
throw big iron and redundancy at) and complexity then you can't just
scribble on postcards or wave your hands around or jot notes on a
wiki.

This is especially so if you are integrating with multiple parties
and/or your software is hosted or run on client computers which makes
rolling out frequent fixes and updates unpopular and impractical.

> What of the poor CIO's ego when they can't have huge, sexy budgets for
> enormous, unwieldy projects? What of empty promises like Model Driven
> Architecture?

CIOs never look at UML or real methodologies - they look at powerpoint
presentations.

> ThoughtWorks, Martin Fowler et al. talk up an XP-like development
> methodology for enterprise systems, and I wonder what it looks like. If
> anyone can explain the guts of it, then I'm all ears.

You would have to specify what an enterprise system was - frequently
it just means that you can't get a useful price and have to speak to a
consultant and several sales people to get a vague idea of the
estimated cost ;)

> My rule of thumb has been that the upper limit on the size of a
> development team is about eight, but six is probably better - and
> anything they can't achieve is a symptom of a poorly scoped project. In
> essence, I agree with what you're saying; but I'm playing a bit of the
> devil's advocate here. I'm watching a floundering bid in the £XX,000,000
> region as I write... What odds of a successful delivery? I give it slim
> to none.

I think its about breaking work down into managable chunks - if you
have managable chunks you can use XP on that chunk and share
information with other teams using more formal notation/methodology -
so long as expected behaviour and interfaces are clearly defined the
implementation may not need the formal specification.

In the case of a 10 digit project, you have to wonder if it would be
more likely to succede if borken down into 5 smaller projects, each
split again within the bidding organisation or shared between a bunch
of small companies. Hopefully that would encourage also breaking it
into timed phases, and generally reduce the ambitousness and have
clear acheivable deliverables.

Of course that isn't very exciting and isn't something government
ministers or company executives can cheer about much.

A
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug