>> If anything, I think they [waterfalls] were too disciplined.
> I am not sure what "disciplined" means in this case.
>
> Clearly they were too sequential... teams need the feedback that
> comes from synchronizing needs, designs, tests, and products. Esp.
> in a new area like SOA staying in synch with real feedback is
>
critical.
> Clearly however the agile approaches are more disciplined in the
> sense that they recommend test-first, automate everything possible,
> and engineer your requirements into an ongoing stream of
> similar-sized work packets.
I worked on a project in the early 90s that could have met almost all of your criteria (we didn't Unit Test first, but we did write test scripts first). We had the project broken down into broad service areas, and then these bit broken down into similar sized work packages designed to be delivered by no more than two people, and most normally one person, within the next iteration.
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.
> detail. All these lend themselves to an agile enterprise, and it is
> difficult to imagine how to become agile without them.
> -Patrick
In terms of the tasks yes, but whether it needs an "agile" methodology or a decent software engineering process should be open to debate. 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. There is no ulitmate process that works for everything, hell you could get some fantastic developers but have a moronic business strategy (say developing a platform agnostioc software solution then deciding to build the hardware as well) and nothing is going to help.
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.
__._,_.___
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
