Popularity ContestAgile processes, although popular, don't address the needs of enterprise-level projectsby Michael J. Hudson 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 documentation and design procedures is definitely going to hurt, especially when maintenance cycles begin. Pros and ConsIn support of agile processes, documentation and design still happen in these projects (it's called agile modeling), but the process doesn't explicitly force developers to use any formal standards. Although more formal, traditional processes describe in detail tons of design and documentation that must be done in each minute step of the process, agile processes work because they don't specify any quantity or kind of documentation or design during any of the software project phases. Agile processes' main goal is to reduce up-front analysis and make design an every day occurrence. But for any project to be successful under these assumptions you need a set of developers with a lot of experience, discipline, and uniformity. And although I'm sure companies wish that every developer they hire met those standards, finding them would take a lot of time and money. And if any group of developers were really that good all the time, why would you need any kind of process? Nonagile processes such as rational unified process (RUP) can work with developers at all skill levels. RUP processes formalize and standardize the actions, workflows, documentation, and design that are necessary to successfully accomplish any software project. You still need good developers, but your standard doesn't have to be as high as in an agile-styled project. Nonagile processes, themselves, enforce conformity of coding standards, design documents, and requirements and provide mechanisms for tracking project features and bugs. They walk the developers through every software life-cycle phase.
|
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
|