RDRA+Iconix+DDDでScrumを組んで!(机上での話し)


AgileJapan2010に参加してから、私の興味はもっぱらAgileに向いています。
特にScrumの手法をなんとか取り入れる事はできないかと考えています。

私は自社で兼ねてからRDRAで要件定義をしてIconixDDDで設計を推進してきました。
これらをScrumでできないかと考えました。

しかし、Scrumについて1つなんとも抽象的でわからない事がありました。
それは『ユーザーストーリー』です。
ユーザーストーリーとは何かと言うことよりも、『ユースケース』とは違うのか?とか『ユーザーストーリー』とともに語られる『エピック』とか『テーマ』とは?
などがわからなかったのです。

さらに自分を混乱させたのがInfoQのこの記事です。『見積もりするのに使用するのはユーザーストーリーでもユースケースでもよい』みたいに読めてしまいます。

この疑問を完全に解決してくれたのはやはりInfnQの記事で『リーン/アジャイルな要求獲得のためにユースケースは価値がある(オプションだけど)』

そしてユーザーストーリーの書き方をテーマにした勉強会『スクスクすくらむ』(開催の事すら知らなかったのですがこれは参加したかった!)

これらから以下のように整理をしました。

  • ユーザーストーリーとユースケースは全く違う。
  • ユーザーストーリーはユーザーの機能要件に近い。
  • ユースケースはもちろん機能そのもの
  • ユーザーストーリーはRDRAの機能要件で表現できる。
  • テーマはユーザーストーリーの大きい単位。これもRDRAの機能要件で表現できる。(効果的な製品バックログの作成より)
  • エピックはテーマとユーザーストーリーの大きい単位。これもRDRAで表現可能。(効果的な製品バックログの作成より)
  • 見積もりはユーザーストーリー単位でもユースケース単位でもいいと思う(InfoQの記事より)
  • Scrumにおいてユーザーストーリーは必須。ユーザーの要件だから。
  • でもユースケースはオプション(InfoQの記事より)
  • Iconixではユーザーストーリーが必須。(でないと先に進めない)
  • よってIconixをScrumで実施するにはユーザーストーリーとユースケースは両方必要。
  • RDRAと連携するなら機能要件をユーザーストーリーとできそう。
  • ユーザーストーリーのユーザーの部分は機能要件のユーザーの図にできる
  • RDRAでは機能要件とユースケースの連携を利用シーンとユースケースの連携で確認するから漏れも防げそう
  • 機能要件とユースケースは連携してるからやはり見積もりはどちらを基準にしてもよいと思う
  • 個人的にはユースケースはなんとなく『理想日』で考えてしまいそうな気がする。『相対的なストーリーポイント』で考えるならユーザーストーリーの方がいいかもとか感覚的に思う。
  • さらにユーザーストーリーはユーザー目線でユースケースは機能目線なのでユーザーに見せる見積もりはユーザーストーリーの方が理解が得やすいかも
  • さらにさらにスクスクすくらむで非機能的要件もユーザーストーリーに変換すべきとあり、それを考えるとやはりユーザーストーリーを見積もりの基準とした方がいいのかも…

なんて感じで列挙してみました。机上で考えたものなので実際一度試してみたいです。

しかしRDRAのプラクティスはすごいです。
今回の件だけでなく利用シーンはアジャイルUXのインタビューとして、DDDのコンテキスト図もRDRAはカバーしています。
なんかRDRAはアジャイルにぴったり合うツールのような気がします。
そしてScrumやDDDなど他の事を学ぶ事で充実した要件定義ができる事に驚いています。


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です