Agile Software Development - The Manifesto for Agile Software Development

[M Greenaway]

Wow - I am amazed at the amount of models there are out there, both ISO and non-ISO, for software design and development processes.

I am particularly intrigued by what is termed 'agile' software development.

To me this appears to be an attempt to justify and methodise (if that is a word) the normal ad-hoc approach to software development.

Also techniques such as XP appear to attempt to 'inspect quality in' to the software product.

The boffins appear to claim that software design cannot follow traditional design processes that have been employed in mechanical and construction design, in particular things like design planning cannot be done.

This sounds very lame to be, what do others think ?

[Craig H.]

Martin, it's been ages since I have written any code. FORTRAN ring a bell?

Still, I'd have to agree: lame, lame lame.

But, with software, instead of finding the time to do it again, all too often they find the time to fix it in the next version. Shame, shame, shame.

[blainehilton]

Agile software development is one of those buzzwords that can work if you play it right. The traditional method of software design known as the waterfall method doesn't work in the "real word". With the traditional method you would make a plan and then execute the plan and when completed there would be a finished software product. To compare this to a building project imagine hiring a firm to build your new facility and saying you will come by next year to move in. You will not be able to see the project at all during construction. If this is fine with you then yes “lame” is the proper response.

This doesn't work though because requirements change, and they change fast. By the time the software is finished and delivered it may very well be irrelevant and the feature set completely wrong. If on the other hand releases happen more often the software can be changed as the underlying requirements change.

The problem I have found in my software development work is clients pressure me for software. The software they want they needed last month. As such clients want code that works, and just works. They do not specifically care for mundane things such as security, documentation, software testing and benchmarking. Most of the time this doesn't matter, but when it does matter it really matters. When this happens it is always my fault. It doesn't matter if I warned the client and said that this is possible or if you want it by tomorrow we can't do full testing.

Agile methods are the solution for these problems, the hardest part though is training everyone on the methods. The client needs to understand it along with the development staff. One of the major changes I have made lately is working with unit testing. Once a client understands that the unit testing can save time and money over time they are usually fine with it.

[Marc]

Originally Posted by Craig H.

...it's been ages since I have written any code. FORTRAN ring a bell?

It does for me - About 1975 for me... Not to mention cobol...

I cruised a bit and found Roadmap to Agile Methods and Tools

What Is Agile Software Development?

In the late 1990's several methodologies began to get increasing public attention. Each had a different combination of old ideas, new ideas, and transmuted old ideas. But they all emphasized close collaboration between the programmer team and business experts; face-to-face communication (as more efficient than written documentation); frequent delivery of new deployable business value; tight, self-organizing teams; and ways to craft the code and the team such that the inevitable requirements churn was not a crisis.

Early 2001 saw a workshop in Snowbird, Utah, USA, where various originators and practitioners of these methodologies met to figure out just what it was they had in common. They picked the word "agile" for an umbrella term and crafted the Manifesto for Agile Software Development, whose most important part was a statement of shared development values:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions - over - processes and tools
Working software - over - comprehensive documentation
Customer collaboration - over - contract negotiation
Responding to change - over - following a plan

That is, while there is value in the items on the right, we value the items on the left more.

[Steve Prevette]

Hmmmm maybe I have been doing agile programming and not realizing it. I just have been thankful I know how to do my own programming (currently in Visual Basic) to get the data I need for my charting. If I had to deal with our CIO office and software "provider" I'd have been either committed as insane or fired years ago.

[Marc]

I found this link today: Agile software development

[Dave Dunn]

I definitely agree that a lot of software development these days is rushed and needs extensive rework post-production. It can be seen often in the computer entertainment industry. Some companies, especially if not under constant pressure from the publisher, put out extremely good product, while others produce kludges that need patching right out of the box.

The software industry has some serious challenges though that make creating bug and vulnerability-free products extremely difficult.

The biggest challenge is designing software that will work as intended on practically unlimited variations of hardware configurations. It's not the same as, for example, producing a component for vehicles.

The variety of vehicles, even taking into account make, model, and accessories, is much smaller than all the varied internal components of a computer. Particular components for vehicles are also specifically designed for particular models of vehicle, limiting the overall variety that the component is required for.

With computers, software developers have to deal with a range of motherboards, memory, video cards, sound cards, etc., from multiple OEM's and resellers, and also with a huge variety of operating systems and other installed software, any combination of which could conflict with new products being added.

The other significant problem for software developers is designing the product around the human element, i.e. hackers, virus writers, and end users that are not as adept with computers. As smart-phones and other similar devices become more prevalent and programmable, consumers are finding that even these things are not safe from outside attack. In comparison, most other consumer products are not attackable in the ways that computers are..at least not at this point in time.

Maybe in the future when we get those Win XP toasters.

[WALLACE]

I would like to look at any available AGILE examples?
I have recently though about adopting a more process oriented format for further development of a software program I'm heavily involved with.
My issue:
I'm one of the developers but, my main team are located overseas (Europe) and, we have a language issue regarding translating with clarity; English to Norwegian and Vise versa. Adopting a more AGILE process is my main focus though.
Wallace.