> And being clear we were not using anything that would in anyway be > described as an agile process. It was iterative and it had software > engineering good practice, but XP, DSDM, SCRUM it was not.
It could be described as "agile" in the general sense it if provided the team agility. But let's not argue about that. I agree there've been and there will be approaches to development that are good that are not named XP, Scrum, etc. When I wrote "agile" I was attempting to use the more general notion. >> None of the other approaches I am familiar with go into as much >> detail. All these lend themselves to an agile enterprise, and it is >> difficult to imagine how to become agile without them. > > In terms of the tasks yes, but whether it needs an "agile" > methodology or a decent software engineering process should be open > to debate. That's fine. See above. > My experience has been that at the enterprise level these agile > processes fail to work, and for certain types of task they don't > work either. A key to agility needs to be the ability to not get > sucked into the "one process fits all" mentality and be able to tune > your delivery process as appropriate for your current service > delivery. No argument... a key to agility is to be able to improve development processes as well as the developed product incrementally. I don't believe in one-size-fits-all either. And so success has more to do with the team collaborating effectively than it does what particular label they apply to their starting point. > This is (IMO) where service really help, as you can change the > delivery process as appropriate for the service, and if it really is > an area where you know all the requirements and know they won't > change (maybe a stock control system) then waterfall might actually > be the best approach. Maybe. Size matters as much as anything, so if it is a smaller size and you know everything up front then by all means. However, feedback matters as well to there is a risk of lack of feedback the greater the effort and the less you realy end up knowing. By the way, if you go back to the source, Winston Royce, in the late 1960's, for "waterfall", you will find that even he built one iteration into his process. That iteration over the most essential aspects of the system is used to feedback to all the phases of the waterfall... he literally defined a constrained approach to "plan to throw one away". >From Winston himself... "If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations areas are concerned." >From the pdf... http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf -Patrick ------------------------ Yahoo! Groups Sponsor --------------------~--> Great things are happening at Yahoo! Groups. See the new email design. http://us.click.yahoo.com/TISQkA/hOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
