実装作業をチーム内で分散して行うために、また、適度な粒度での進捗のトラッキングを行うために開発者はユーザーストーリーをタスクへと分割する。不幸なことに、ストーリーをタスクへと分割してみると重大なタスクばかりになってしまいイテレーション内にそのストーリーを終えることができない、といったことが起こりうる。Ron Jeffriesは、ストーリーをタスクへと分割するのではなく、ストーリー自身をひとつの作業単位として扱うことを提案している(リンク)。
これを実現するためにはストーリーのサイズをチームが充分に理解できて見積もり可能なくらいに小さくする必要がある。ストーリーをさらに小さなストーリーへと分割するためのアプローチのひとつに受け入れ基準を列挙する方法がある。列挙したそれをひとつづつ見ていき、それ自身がストーリーとして独立可能なものを探していく。もしその受け入れ基準がプロダクトに対して価値をもたらし、ユーザーの目に見えるものであり、他のストーリーから独立しており、テスト可能であれば、それはストーリーの良い候補となるだろう。
多くのチームではメンバーのスキルが製品システム内の特定の分野や特定の基盤技術にのみ特化しており、それがエンジニア一人ひとりが全てのストーリーを把握することを難しくしている。長期的な視点での解決策のひとつは開発者がシステムのどの部分でも作業できるように、またシステムで用いるあらゆる技術を取り扱えるように開発者を多能工化することだ。これにより柔軟性の高いチームが出来上がると同時に、システムのこの部分を保守できる人はあの人だけだ、といった組織としてのリスクを低減することができる。同じ効果を今すぐ得たい場合にはペアプログラミングを行なうとよい。あるストーリーの実装を担当した開発者は、そのストーリーを遂行するのに必要な技能を持った人間とペアを組んで実装にあたる。
Ronは「作業をタスク単位ではなくストーリー単位で行う」ことを推奨している。タスクレベルで進捗をトラッキングした場合、開発者はユーザーへの価値を何ひとつ提供しないままにいくつもの自分の担当タスクを終えることができてしまう。もしチームがストーリーの完了のみをトラックしていたら、ストーリーを完了させた時にのみ何かを成し遂げたという手応えを開発者は得ることができる。これは、より有用な概念である「完了していること(参考記事)」を促進させる。
Ronのアプローチにあなたは同意できるだろうか？ コメントであなたの意見を聞かせて欲しい。
原文はこちらです：http://www.infoq.com/news/2009/01/Burn-Stories-Not-Tasks