ブログ：アジャイルの要件定義

アジャイルの雄Scott Ambler氏によるブログ記事の要約と、若干のコメント。

要約

アジャイルプロジェクトにおける規模に応じた要件の可視化
Requirements Envisioning on Agile Projects at Scale - Agility@Scale: Strategies for Scaling Agile Software Development Blog

一般的な認識とは異なるけれども、アジャイル開発チームもモデリングは行うし、アップフロント的な要件定義やアーキテクチャ策定は行っている。アジャイル・モデリングのベスト・プラクティスは「要件の可視化」と「アーキテクチャの可視化」。今回は「要件の可視化」を取り上げ、「アーキテクチャの可視化」についてはまた後日に。

最初に要件の可視化を行うことの目的は、プロジェクトのスコープを明らかにすること。適切なメンバーを集めて打ち合わせをすれば、数日〜1週間程度でおおよそのことは決まるはず。もし2週間ほどかけても決まらないようであれば、いろいろ詰め込みすぎかもしれない。これは「膨大なアップフロントの要件定義("BRUF")」をしろということではなく、必要な情報は手に入るはず、ということ。アジャイル・コミュニティーにとって、要件分析は日々行う必要のある重要なこと。だから最初にやらなくても詳細に関してはいずれ明らかになってくる。

業務アプリケーションにとって必要なモデルは以下の通り。

抽象度の高いユースケース（もしくはユーザストーリ）("High-level use cases")
- この段階では複雑なユースケースに関する箇条書き程度で良い。詳細は後に明らかになる。

画面遷移図 ("User interface flow diagram")
- 主要な画面と帳票が分かれば良い。

画面と帳票のスケッチ ("User interface sketches")
- 認識合わせにつかうもので、画面仕様ということではない。

ドメインモデル ("Domain model")
- 主要なエンティティとその関連。責務や属性は後でも良い。

業務プロセスの図 ("Process diagrams")
- 抽象的なプロセスの図と、主要なものについて概要をつかむためのいくつかの図

ユースケース図 ("Use-case diagram")
- プロセス図の代わりにユースケース図でも良い。お好みで。

用語集
- あまり厳密に定義しようとしないで。

チームの規模が小さければホワイトボードや紙で十分。人数が増えたり、場所が分かれたりした場合には電子化する必要があるかもしれない。

大規模チームに対して参考になるかもしれないものの紹介。

Agile Requirements: Collaborative, Contextual, and Correct Webcast （要ログイン）
IBM Engineering Requirements Management DOORS Next - Overview - United States

状況に応じて考えなければいけないことは出てくるものだ。

One of the things that people often struggle to understand about agile approaches is that you need to tailor your strategy to reflect the situation at handle. One process size does not fit all, so you will end up using different tools and creating different artifacts to different extents in different situations.
Repeatable results, not repeatable processes, is the rule of the day.
アジャイルなアプローチについて理解する際に苦労することの一つは、現実の状況を反映させた戦略を練らなければいけない、ということです。ある開発プロセスの規模がすべてにマッチするわけではないので、結局は状況に応じて異なるツールを使い、異なる成果物を異なる範囲で作ることになるのです。「反復可能なのは結果であってプロセスではない」ということですよ。

「難解なことを分かりやすく説明する力」はすばらしいですね。アジャイルということに限らず「ものを作る」上で重要なのは「そもそも何を作るの？」という水準での理解なのでしょうが、「それを業務アプリケーションに当てはめた場合にはどうなるのか」ということを、きわめて明快に切り取ってくれていると思います。色々と考える要素はあると思いますが、ここでは2点ほど。

ドメインモデル

この段階でのドメインモデルは「エンティティ」なんですね。いわゆる「モデル駆動」ということに無理につなげなくても、「論理データ構造」と置き換えることが可能かもしれません。重要な要素だとは思うのですが、ユーザ・インターフェイスに比べると、ユーザ側の認識があまり深くないため、なかなか打ち合わせが進まない部分のようにも思えます。理想はユーザ側もこういう打ち合わせを経て、これから作るシステムに関する認識を深めていくことなのでしょうけれども。