| AGILE DEVELOPMENT METHODOLOGY |
|
Agile software development processes are built on the foundation of iterative development. To that methodology
adherents to agile development add a lighter, more people-centric viewpoint than traditional approaches. The iterations tend to be
much shorter, typically a matter of weeks rather than months as seen in iterative development methodologies such as spiral methods.
Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software. Many projects are initiated with more features and as the project progresses a final product spec becomes apparent. There are many reasons why a feature is removed before the final product launch, in most instances time and budget play a role. In many development teams that I have managed, developers would prefer to create and add features in the order that seems best to them. Unfortunately, this is almost never the order that makes sense to the business or to clients. Agile teams learn to add features in the order that makes sense to the business which also adds to buy-in from key stakeholders. Since features always get discarded at the end of a project, a team interested in building a powerful application must build and fully incorporate the most important features first. Although there are some engineering considerations to be accounted for, a manager must be certain to build the critical business functionality first. An agile team understands the real business trade-offs that are being made as each new feature is added, and using this approach new builds of the app can occur very frequently. An additional advantage to the business is in a year long product development cycle, the business now has clear choices to make every two weeks. Options include continuing to add more features on the current plan, prioritizing the features differently, or to stop adding features altogether. The business now can decide halfway through the year if all of the key features are present. The ability to release a version of the product at each iteration also makes the developers far better software engineers. Issues such as integration and installation that previously were deferred to the end of a project must now be addressed consistently throughout the entire development lifecycle. Software built in this manner is of consistently higher quality. Agile processes seem to be more efficient than older methodologies, using less programmer time to produce more functional, higher quality software, but have the drawback from a business perspective that they do not provide long-term planning capability and therefore are more difficult for larger corporations to implement. Extreme Programming, or XP, is the best-known agile process. In XP, the phases are carried out in extremely small (or "continuous") steps compared to the older, "batch" processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model. First, one writes automated tests, to provide concrete goals for development. Next is coding (by a pair of programmers), which is complete when all the tests pass, and the programmers can't think of any more tests that are needed. Design and architecture emerge out of Refactoring, and come after coding. Design is done by the same people who do the coding. (Only the last feature - merging design and code - is common to all the other agile processes.) The incomplete but functional system is deployed or demonstrated for (some subset of) the users (at least one of which is on the development team). At this point, the practitioners start again on writing tests for the next most important part of the system. BACK TO SOFTWARE DEVELOPMENT METHODOLOGY > |