InfoQ use-case-or-user-story読んだ

http://www.infoq.com/jp/news/2008/08/use-case-or-user-story

読んだ。自分なりの考えを吐き出してみる。

ユーザストーリと比べて、ユースケースのうれしい点は、文書化を試みるという行為。複数人で時間場所を超えてまとめる行為は一時的な会話よりも記録性は高い。時間が経つにつれて、人間の記憶はあてにならない。人の入れ替わりも会話のみだときつい。（ちょっと前に、会話を重視しすぎて文書化をおろそかにしてメンバに怒られてしまったｗ。ただし、実装されないSpecが残りづづけるのは、リーン的発想では、価値を全く生まない仕掛品。不吉なにおい。バランスが肝要）。
ドメインエキスパートと開発者の複数人で編集するWikiが適していると思うが、試したことはない。ユースケース記述から受け入れてテストケースの作成は、情報の重複がみられるが、文書化されているおかげで、会話重視の比べれば、ある特定の人ではなく別の人でも作成可能で、スケジュール調整もしやすい。
文書化重視のアンチパターンの分析麻痺には気をつけたい。

ユースケースと比べて、ユーザストーリのうれしい点は、会話重視の要求をまとめるという行程だけではなく、イテレーション計画時のストーリ選択によるスコープ調整、RSpec、JDaveなどのツール連携の可能性、イテレーション終了時のユーザ視点の進捗把握などなど、幅広くかつ具体的な視点を提示したところ。
会話重視のアンチパターンの集団記憶喪失には気をつけたい。

ユーザストーリが機能する根本前提には、少ないメンバー、Spec/Impl/Design/Testの流れるような連携（開発者は、ドメインエキスパートとのユーザストーリの会話内容を、RSpecの実行可能なストーリにすぐ記録できる、キーとなるビジネス的なポリシー/ルールを実行可能かつドメインエキスパートにもわかるDSL/モデルで表現できるなどなど）、2-3週間前後のイテレーションといった圧縮された開発工程が大きいと思う

私は、ユーザストーリを使って、開発したい。太極拳の如く,開発全体の流れるような動きの極意を体得したい。