agile research

hello
This is Amitoj Singh from punjab.
i am lecturer in computer science.i have done MCA and now interested
in PhD.
i am working on agile software development techniques from last 6
months especially on extreme programing..
There are some specific areas for research which i have gone through..
like.
->Integrating software architecture centric methods in extreme
programing or in ASD eg. QAW,ADD,ATAM,ARIDS...they have heavy
documented..but finding a path to minimizing documentation and in
quality of the software
->Embedding Architecture practice in ASD especially in XP.
as ASD use JIT(Just in time) technique to develop architecture but in
some cases it should be build architecture upfront ie project in which
requirements are known in advance.
->Knowledge management strategy in ASD...ie how to gather experince
knowldge from agile process and maintain it to use further.

->to some empirical study on pair programing and acknowledgments
strategy.but its hard to find companies which use agile techniques.
Will you help me out to explore some more research area in agile
software development..or some new trends in Agile software
development(ASD)

Thank you
Amitoj Singh

ami wrote:

> ->Integrating software architecture centric methods in extreme
> programing or in ASD eg. QAW,ADD,ATAM,ARIDS...they have heavy
> documented..but finding a path to minimizing documentation and in
> quality of the software

Beware the "Big Agile Up Front"!

And note that developing the features in order of business priority, with
literate acceptance tests, is a form of analysis and architecture. If you can't
characterize a feature's specifications well enough to write their
customer-tests, then you are not ready to do the feature, and other features
must come first. They will support the subsequent features.

And if your client has some feature on their mind, and they are dying to see it
in code, then they probably have a good idea about its specifications. So the
highest business-value feature is typically the one the client can best
characterize.

This is called "just in time requirements".

> ->Embedding Architecture practice in ASD especially in XP.
> as ASD use JIT(Just in time) technique to develop architecture but in
> some cases it should be build architecture upfront ie project in which
> requirements are known in advance.

Never. Even if you know the requirements, you don't know a good path to
implement them.

If you indulge in "Big Requirements Up Front", then you will break one of the
cardinal rules of "Lean Software Development". The longer a requirement stays on
the shelf - like inventory behind an assembly line - the more stale and
high-risk it gets. A requirement is a decision, and live code is feedback on
that decision. When you delay feedback, you add risk and mistakes to the process.

Whenever you hear of some failed project that wastes $400 million, like this...

http://www.adtmag.com/article.aspx?id=10182

....you can bet its "lead architects" spent a lot of money and time, during the
first year of the project, "diligently" working only its requirements, without
any live code.

Implementing features in order of business priority is a design technique. If
Ford and Oracle had spend the first month ensuring one tiny piece of their
mega-project was online and working, they could have then followed a strategy of
repeating their successes.

> ->Knowledge management strategy in ASD...ie how to gather experince
> knowldge from agile process and maintain it to use further.

That's what Pair Programming is for.

Really. XP is a set of weak practices that together form a strength. You can't
over-analyze one of those practices in isolation from the others. Asking
questions like "how can we add extra paperwork to achieve CMM Level 4, with each
team comparing notes with the others" is the admission of failure before you
start. If you instead ensure teams work together, such as by frequently swapping
their developers, then knowledge will transfer as if "by itself".

> ->to some empirical study on pair programing and acknowledgments
> strategy.but its hard to find companies which use agile techniques.

That's the rub! Plenty of companies call themselves "Agile" these days, but does
the boss give up micromanagement of the developers? Does she or he trust them to
give up "big architecture" in favor of thousands of small test cases? Does the
team continuously integrate and deploy daily?

--
Phlip