In many software projects the business goals are poorly understood, in flux and hard to communicate. That’s where the agile/iterative approach comes in. Because you can quickly adapt to moving targets it’s much easier to deal with unstable requirements. Now consider a company that wants to put into place a new software system. If they were to start from scratch, they’d probably start playing around with a prototype, throw this at pilot-users and iteratively adapt according to feedback and a more mature requirements. What however, if they decide to build on top of a commercial platform and customise in-house? Then they need to decide for a commercial vendor that *fulfils their requirements* and that’s where the crux lies. How can they evaluate and decide for one or the other vendor when the requirements are everything but clear and stable? Furthermore, a decision is irreversible (more or less, after the licensing fee has been shelled out).
Effectively, you are forced to switch back to the good old “requirements-design-build-test-deploy-manage” approach for this step of the process. All agility is lost! As far as I can see, the only solution to somehow mitigate the problem lies in playing around with open source software before making the vendor-decision. This way you can establish some need-to-have requirements on the basis of which to pick the commercial vendor.
What do you think about this problem? Am I overlooking something, stretching the agile methodology too far? Can you see a solution consistent with the premises of agile development?
Also see Item 6. on the "Overly Long Guide to Being A Software Architect"
No comments:
Post a Comment