2016年1月26日デジタルとアナログ。2016年1月12日2016年あけましておめでとうございます。ギルドワークスで開発を行うときは、ユーザーストーリーを使ってタスクを管理することが多いです。その際に気をつけていることをまとめてみたいと思います。ユーザーストーリーの”INVEST”ユーザーストーリーをつくるときに意識するのは、おなじみ”INVEST”と呼ばれる、優れたユーザーストーリーが満たすべき特性です。復習してみましょうか。先行するストーリーが完了してないと始められない、など他の影響を受けない。ストーリーが具体的なタスクに落ちすぎておらず、プロダクトオーナーと実現方法について交渉することができる。ストーリー単独で顧客にとっての価値があること。ストーリーを実現するのにかかる時間が(他ストーリーとの相対時間として)見積もれるだけ、十分な情報があること。適切な大きさである(小さい)。チームが開発を回していくにあたって、ストーリーを実現するのに要する時間が長すぎない程度に、適切なサイズに分割されていること。そのストーリーが完了したかどうかをテストできること。受け入れ条件が明確になっていること。このINVESTをしっかり意識したストーリーを作れば、うまくユーザーストーリーで開発を回すことができます!・・・って果たしてそうなんでしょうか?実は、”INVEST”全てを同時に満たすことは、かなり難しい、もっというとすべてを同時に満たすことにあまり意味が無いものなのです。“INV”と”ES”の違い例えば、「交渉可能」にしたストーリーって、やり方についてまだまだ交渉の余地を残しているということです。固まっていない、とも言えます。ストーリー単独で「価値を出し」たり、他のストーリーに依存しない「独立した」ストーリーをつくろうと思うと、どうしても「適切な大きさ」から離れていってしまう、なんてことも有ります。前半3つの”INV”と続く”ES”は、実はコンフリクトするのです。“INV”と”ES”は異なる要請から導かれているものだからです。“INV”は、乱暴に言ってしまえば上流工程寄りのストーリーの捉え方です。システムに必要な機能を洗い出す際に抜け漏れをなくすため、実装時に柔軟な対応を確保しておくため、など要件定義やプロジェクトマネジメント的な観点からストーリーに求める要件なのです。”ES”は下流工程、つまりいざ手を動かして実装していく時に重要になってくる事柄です。開発チーム内で不幸なコミュニケーション事故がおこらないためにも、「見積もり可能」で「適切な大きさ」になっていなければいけません。スクラム的なイテレーティブなプロセスを取るならば、まずは”INV”を重視したストーリーを作っておき、いざ実装が近づいてきたストーリーについて、”ES”の観点から見直し、必要に応じて書き換えたりバラしていく、という流れが必要になります。圧倒的に大切な”T”しかし、この中で”T”だけは別格です。”Testable”すなわち“受け入れ条件”だけは、ストーリーが生まれた時から死ぬまで明確にしておかないといけません。”受け入れい条件”がブレないからこそ、”INV”から”ES”に振ったとしても、そのストーリーが実現する物事についてブレなく矛盾なく保つことができます。ストーリーが分割されて小さくされたり、実現方法が決まって見積もり可能になったとしても、そのストーリーが達成された結果として実現されることは変わりません。ユーザーストーリーのライフサイクルこのように、”T”をストーリーのかすがいにしつつ、上流寄りの”INV”なストーリーから下流寄りの”ES”なストーリーに変えていく、そんなライフサイクルを意識すれば、よりスムーズにユーザーストーリーを使って開発を行うことができるでしょう。この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください。コメントをキャンセルコメントを入力してください。以下に詳細を記入するか、アイコンをクリックしてログインしてください。アカウントを使ってコメントしています。アカウントを使ってコメントしています。アカウントを使ってコメントしています。アカウントを使ってコメントしています。新しいコメントがついたらメールで通知。