AGILE

Ambler's "agile" analysis

Ambler's "agile" analysis

Analysis

The purpose of analysis is to understand what will be built, why it should be built, how much it will likely cost to build (estimation), and in what order it should be built (prioritization). This is similar to requirements elicitation, the purpose of which is to determine what your users want to have built. The main difference is that the focus of requirements gathering is on understanding your users and their potential usage of the system, whereas the focus of analysis shifts to understanding the system itself and exploring the details of the problem domain(Ronald, 1982). Another way to look at analysis is that it represents the middle ground between requirements and design, the process by which your mindset shifts from what needs to be built to how it will be built.

Agile Analysis

Let's begin by describing what agile analysis isn't:

* It isn't a phase in the lifecycle of your project

* It isn't a task on your project schedule

* It isn't a means unto itself

What is agile analysis? From the previous discussion of what an agile business system analyst does, your agile analysis efforts should exhibit the following traits:

1. Agile analysis should be communication rich. Agile developers prefer warm communication techniques such as face-to-face discussion and video conferencing over cold techniques such as documentation and email, as described in the Communication article. Agile developers prefer to work as closely as possible to their project stakeholders, following AM's Active Stakeholder Participation practice wherever possible.

2. Agile analysis is highly iterative. As Martin (2002) points out analysis and design activities both rely on each other: estimating is part of analysis yet that relies on some design being performed to identify how something could be implemented and your design efforts rely on sufficient analysis being performed to define what needs to be built. Hence analysis is iterative. 3. Agile analysis is incremental. Martin (2002) also correctly points out that agile analysis is incremental, that you don't need to build systems all in one go. This philosophy supports the incremental approach favored by common agile software processes where the work is broken done into small, achievable “chunks” of functionality. These chunks should be implementable within a short period of time, often as little as hours or days.

4. Agile analysis explores and illuminates the problem space. Your primary goal is to identify and understand what your project stakeholders need of your system. Furthermore, this information needs to be communicated to everyone involved with the project, including both developers and stakeholders. This promotes understanding of, and agreement with, the overall vision of your project. 5. Agile analysis includes estimation and prioritization of requirements. It is during estimation and prioritization of requirements where software development becomes “real” for project stakeholders. It is very easy to say that you want something but much hard to agree to a price for it, let alone to trade it off for something that is immediately more important to ...