"Shannon -jj Behrens" <[EMAIL PROTECTED]> wrote >> Also, can anyone comment on the limits or caveats of agile >> development?
I posted a longish response on this but it seems not to have made to gmane! Here it is again: =================================== "Stephen McInerney" <[EMAIL PROTECTED]> wrote > Can anyone recommend me the best single must-read book for Agile > Programming? One of the most widely cited is Robert Martin's Agile Software Development. Personally I didn't like it much for agile but it is quite good on OOD. The original XP book by Kent Beck is good too, along with its sequel. > Also Agile Testing. Sorry I can't comment on any specific testing books. > (If they compare Agile in general to the other methodologies, > that would be great) The best comparison book I can recommend is Balancing Agility & Discipline by Barry Boehm. > Also, can anyone comment on the limits or caveats of agile > development? I'm sure lots of people can but Agile is such a nebulous concept that its difficult to get anything objective or useful. My own personal experieces follow for what they are wrth: Agile works well if: 1) You have very close contact with end users/requirement owners 2) Small, co-located teams - small = 20 or less people 3) The requirements are not clearly understood (even by the users). 4) You have an experienced, talented team You need *all* of those to make it work significantly better than traditional methods. If even one if missing you will be no better off. You might not be any worse off, but you will be no better. If you have only one of those items then traditional methods (NOT waterfall!) will be better. Dangers of agile: 1) Not good for building scaleable, resilient, long term flexible structures 2) Very expensive due to the large proportion of time spent in rework (aka refactoring) 3) Tendency to drift over budget as new featiures get thought up and added to the original scope. 4) Not good for long term maintenance, the documentation often being inadeqate for anyone outside of the original project team Note, All of these things can be addressed but it takes specific, directed action to do so. Some general comments: 1) Its easy for management to "embrace agile" by adopting some bits that they like. Requirements become User Stories, Progress meetings become Stand-Ups, Phased releases become iterations. in fact its just a renaming exercise not real Agile. Re-naming doesn't work, agile does (with the caveats above) 2) Agile is very open to hype. Exaggerated claims and comparisons with the waterfall method are common, even though the waterfall method has not been widely used for years and methods like RUP are more appropriate comparisons. If you compare a motorcycle to a penny farthing cycle you will get an exaggerated idea of "progress" 3) Agile badly done is just as bad as traditional badly done. 4) finally, do you need to hire an architect to build a garden shed? Agile is in some ways addressing an artificial problem. Software engineeering was invented in the late 70's to deal with very large projects. Most methodologies still tackle that problem. Many software houses now work on much smaller problems that only need small teams and can be completed in a few weeks. If you apply traditional methodologies to those problems they will be overkill. So Agile comes along. But on these very small projects, usually all that's needed is some common sense and experience - like building a garden shed! My personal career jhas been based on large projects. On most large projects there is a tools team who churn out little programs used by the main development/test teams. The tools team does not typically apply the main project methodology for each tool written, they "just get on with it". The tools team will typically be 4-10 people. A tool will typically take 1-20 days to write. In other words the small end of Agile, but they don't use Agile, they don't use anything but common sense and their experiece... That's way more than I intended writing! I'm sure others will have different views. HTH, -- Alan Gauld Author of the Learn to Program web site http://www.freenetpages.co.uk/hp/alan.gauld _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
