Content area
Full Text
E-BUSINESS DEVELOPER
Agile processes, although popular, don't address the needs of enterprise-level projects
YOU'VE PROBABLY HEARD the usual statistics about how many software projects fail or go over budget. In fact, I'm sure you've seen or participated in a good many examples yourself. And other than in big companies or government contracts, the actual software development processes used in many places are often ad hoc and not strictly enforced. However, a recent rash of new software process methodologies called agile processes have appeared that supposedly address these problems. (Extreme programming [XP] is probably the most popular example of these methodologies.) The problem is that these new kinds of software processes are more often than not just increasing the current trend of "code-and-fix" in your strategic business applications.
Over the last two years or so, agile processes have become more and more popular. They tout very attractive strategic goals such as responding to change quickly and collaborating with customers. Developers like these processes because they limit or eliminate noncode-oriented documentation and promote simple test-driven designs and collective code ownership. Although these goals are worthwhile, agile processes make two small assumptions: All your developers must be top-notch, state-of-the-art senior developers (usually the software architects or team leads on other projects), and your project must have fewer than 10 developers (agile processes aren't capable of scaling into larger or more sensitive projects).
These weaknesses derive from the lack of formalized documentation and design in agile processes. Documentation and software design, regardless of how bureaucratic or dull they may seem, are the lifeline of communication to new people on the project, existing developers, users, and other internal software projects. Without these things, effective communication becomes difficult, thus limiting how big your development team becomes, and it requires developers who are already knowledgeable and principled to make such an environment work. And management will always decree the need for formal documentation and design because they need this information to effectively plan company strategy. If your company is focused on strategic business applications that end up being deployed on an enterprise level, a lack of consistent and formalized...