Saturday, April 14, 2007

Introduction to Agile Usability, User Experience Activities on Agile Development Projects - Part II

A continuation of an article on Agile Usability and UX ...

5. User Experience Modeling on an Agile Project
ASD practitioners are very pragmatic when it comes to modeling. The Agile Modeling (AM) methodology describes in detail how agilists approach both modeling and documentation. Figure 2 (at bottom) overviews the lifecycle of an Agile Model Driven Development (AMDD) approach to ASD, an approach which originally grew out of the XP community but which seems to capture the essence of the modeling approach on agile projects in general. Each box in the diagram represents a development activity. The initial modeling activity during Cycle 0 includes two main sub-activities, initial requirements modeling and initial architecture modeling which are done iteratively in parallel. The model storming and implementation activities potentially occur during any cycle, including Cycle 0 (yes, the rumors are true, agile practitioners will often implement working software the very first week of a project). The time indicated in each box represents the length of an average session: for example, during development you’ll often model storm for a few minutes with a stakeholder to explore a requirement and then code for several hours.

The initial modeling effort is typically performed during the first week of a project. For short projects (perhaps several weeks in length) you may do this work in the first few hours and for long projects (perhaps on the order of twelve or more months) you may decide to invest up to two weeks in this effort. There are two aspects to the initial modeling effort:

1. Requirements modeling. You need to identify the high-level requirements as well as the scope of the current release. The goal is to get a good gut feel what the project is all about, and to do that you will likely need to create an initial usage model to explore how users will work with your system (e.g. use cases or usage scenarios), an initial domain model which identifies fundamental business entity types and the relationships between then, and optionally other important artifacts exploring technical requirements.

2. Architectural modeling. The goal of the initial architecture modeling effort is to try to identify an architecture that has a good chance of working. 99% of the time agile practitioners simply gather around a whiteboard and create free-form diagrams as they discuss various architectural strategies. When the UI architecture is an important consideration, agile modelers will create a UI navigation diagram (see Figure 3 at bottom) which explores initial relationships between important screens/pages and reports (thereby giving you a birds-eye view of the UI, enabling you to ask fundamental usability questions).

In later cycles your initial models will evolve as you learn more, but during Cycle 0 the goal is to get something that is just barely good enough so that the team can get going. You don’t need to model a lot of detail, and I cannot stress this enough: the goal is to build a shared understanding, it isn’t to write detailed documentation."    (Continued via    [Usability Resources]


Post a Comment

<< Home

<< Home