BT

繰り返しタスクはアジャイルの臭い?

| 作者: Mark Levison フォローする 0 人のフォロワー , 翻訳者 南 伸二 フォローする 0 人のフォロワー 投稿日 2010年4月29日. 推定読書時間: 2 分 |

原文(投稿日:2010/04/03)へのリンク

Mouse開発においてストーリーを垂直方向に切り出すすることはストーリーがアプリケーションのアーキテクチャに縛られないようにするためのよく知られたアプローチである。チームのメンバはたいていそのトレーナーやコーチからストーリーを水平に切り出すと、アーキテクチャを前提にしてしまう、私たち開発者が必要だと思った機能を書いてしまう過剰生産(あるいは金メッキ)をしてしまう、そして最も重要な、進捗が見えなかったり顧客にとってのビジネスバリューを生み出さなくなってしまう、といった、数多くの問題を生むと警告される。より詳しくは、Mike Cohn氏のUser Stories Appliedを見て欲しい。

Antony Marcano氏はタスクは一般にストーリーを繰り返し水平に切り出したものであるという一つの興味深いねじれを持ち出している。例えば、"モデルにxを追加する"、"Viewを変更する"といったように。伝統的なスクラム/アジャイルアプローチでは、チームはスプリントのタスク時間数を見積もり、それをスプリント/イテレーションバーンダウンチャートに記録する。Anthony氏はこれはソフトウェアを開発する上での進捗の真の評価軸ではないと指摘する。

この問題に回答して、次のような指摘した人もいた。タスクではなくストーリーを減らせ 、タスクの時間経過ではなく速度を計測せよ

Antony氏は書くストーリーの実装が成功したかどうかの合格基準を記録せよ、と提案している。これを行うために、合格基準をぼんやりとした記述から検証可能なものに変更する必要がある。例えば、“プロファイルを保存するためのリンクがなければならない” –> “新しいプロファイルを作成する”のように。いったん合格基準がテスト可能になれば、合格基準のためのテストがあるかどうか、およびそれらがパスしたかどうかを記録することができる。

Jason Gorman氏はタスクトラッキングは完了の意味を間違えることにつながると気づき、前述のものと同じ問題に言及した。

“タスクは"やり方"であり、タスクという視点からはユーザストーリーの90%完了しているが、ユーザにはまったく価値を提供できていない、ということが実際に可能である。そのため、タスクを使って計画し、イテレーションを記録することで、悪名高き誤解である"90%完了" 症候群に陥る可能性がある”

Jason氏のアプローチはAntony氏が述べた問題の1つの解である。Jason氏はチームに1つのストーリーに対するそれぞれのテストの複雑さを見積もらせるだろう。チームは合格テストのうち提供できたものを得点化して記録する。

どういう切り口から考えても、タスク時間を記録するということは時代遅れであり、その代わりに顧客に提供した価値を測定する方法を見つけるべきである、というのが共通認識であるということは確かである。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT