Agile Software Development and Business Analysis
By: Scott W. Ambler
In this article Scott W. Ambler, Practice Leader Agile Development in the IBM methods group, overviews agile software development and the implications for business analysts.
| Attachment | Size |
|---|---|
| Agile Software Development and Business Analysis.pdf | 39.51 KB |

Still RUP not BRU
A larger part of the article reveals:
"RUP is a large process, but it was designed to be tailorable through a technique that Rational called the development case. It can be a ponderous, suffocating beast, or it can be trim and fit. The problem is how to construct a development case that clearly identifies the essential steps to perform and the artifacts (models and documents) to develop along the way. In this area, RUP is its own worst publicist. Out-of-the-box RUP doesn't do a very good job of indicating what's essential, desirable or superfluous.
Structurally, RUP is similar to the waterfall approach: Do requirements first; then do analysis, design, implementation and testing (the RADIT cycle); finally, release the product. But, whereas the waterfall approach does each of these once in a project lifetime, in RUP we iterate within the project lifetime. This means we take a 12-month project and divide it into 13 four-week iterations, or mini-projects with their own specific goals. We do the RADIT cycle over four weeks and deliver an incremental release—a working system that performs a defined subset of the total system functionality. Using this iterative, incremental approach, RUP allows us to "eat the elephant one bite at a time." Defining the bite-size is the real challenge. The grocery system discussed here was developed using a bare minimum of RUP—hence, "Extreme RUP" (XRUP)—with very small bites." etc.,
In essence RUP can be Agile if you plan it that way. It is definately not Waterfall or 'big requirements upfront' even if some people purport to use it that way.