BT

タスク単位ではなくストーリー単位で作業を行う

| 作者: Chris Sims フォローする 0 人のフォロワー , 翻訳者 畠山 貴 - (株)永和システムマネジメント フォローする 0 人のフォロワー 投稿日 2009年1月27日. 推定読書時間: 2 分 |

実装作業をチーム内で分散して行うために、また、適度な粒度での進捗のトラッキングを行うために開発者はユーザーストーリーをタスクへと分割する。不幸なことに、ストーリーをタスクへと分割してみると重大なタスクばかりになってしまいイテレーション内にそのストーリーを終えることができない、といったことが起こりうる。Ron Jeffriesは、ストーリーをタスクへと分割するのではなく、ストーリー自身をひとつの作業単位として扱うことを提案している(リンク)

これを実現するためにはストーリーのサイズをチームが充分に理解できて見積もり可能なくらいに小さくする必要がある。ストーリーをさらに小さなストーリーへと分割するためのアプローチのひとつに受け入れ基準を列挙する方法がある。列挙したそれをひとつづつ見ていき、それ自身がストーリーとして独立可能なものを探していく。もしその受け入れ基準がプロダクトに対して価値をもたらし、ユーザーの目に見えるものであり、他のストーリーから独立しており、テスト可能であれば、それはストーリーの良い候補となるだろう。

多くのチームではメンバーのスキルが製品システム内の特定の分野や特定の基盤技術にのみ特化しており、それがエンジニア一人ひとりが全てのストーリーを把握することを難しくしている。長期的な視点での解決策のひとつは開発者がシステムのどの部分でも作業できるように、またシステムで用いるあらゆる技術を取り扱えるように開発者を多能工化することだ。これにより柔軟性の高いチームが出来上がると同時に、システムのこの部分を保守できる人はあの人だけだ、といった組織としてのリスクを低減することができる。同じ効果を今すぐ得たい場合にはペアプログラミングを行なうとよい。あるストーリーの実装を担当した開発者は、そのストーリーを遂行するのに必要な技能を持った人間とペアを組んで実装にあたる。

Ronは「作業をタスク単位ではなくストーリー単位で行う」ことを推奨している。タスクレベルで進捗をトラッキングした場合、開発者はユーザーへの価値を何ひとつ提供しないままにいくつもの自分の担当タスクを終えることができてしまう。もしチームがストーリーの完了のみをトラックしていたら、ストーリーを完了させた時にのみ何かを成し遂げたという手応えを開発者は得ることができる。これは、より有用な概念である「完了していること(参考記事)」を促進させる。

Ronのアプローチにあなたは同意できるだろうか? コメントであなたの意見を聞かせて欲しい。

 

原文はこちらです:http://www.infoq.com/news/2009/01/Burn-Stories-Not-Tasks

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには 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