1

アジャイルプロセスでは、ストーリーポイントは複雑さの尺度であり、時間の尺度ではありません。これは、それほど複雑ではないが、完了するのに時間がかかるストーリーにどのように当てはまりますか。

例を挙げましょう、

ストーリー1：ユーザーの詳細を保存します。

Story points = 2. Typically Takes about 1 day to complete.

ストーリー2：会社名がXからYに変更されました。これは、アプリケーションで更新する必要があります。約40の画面、10のレポートがあり、法的通知これらはすべて変更する必要があります。

これは単純なタスクの典型的な例ですが、実装（適切な開発基準に従った後でも、ローカライズされたアプリケーションを考慮すると）とテストには多くの時間がかかります。

従来の定義に従えば、ストーリーポイント1を与えますが、間違った速度を見ていると、良い作業を行った後でも速度が低下します。私は問題について話すこの記事を見ました。

My question is how this task can be compared to the first story and should the effort be included in story point estimation?

私はこのアイデアにほぼ確信を持っていますが、そのような場合に使用されるベストプラクティスを知りたいのですが、それについて読むことができる良い記事があれば教えてください。

4

2 に答える 2

5

「ストーリーに関連付けられているストーリーポイントの数は、ストーリーの全体的なサイズを表しています。ストーリーのサイズを定義するための決まった公式はありません。むしろ、ストーリーポイントの見積もりは、機能の開発に伴う労力の量、開発の複雑さ、それに固有のリスクなどの融合です。」 -Mi​​keCohnによるAgileEstimatingandPlanningから。

私の開発チームでは、サイズと複雑さの観点からストーリーを見積もります。私が新しいチームメンバーにそれを説明する方法は、サイズと複雑さをグラフ上の2つの直交軸と見なすことです。これにより、複雑さは異なりますが、反対方向のサイズ（労力）が等しく異なるストーリーを比較的同じと見なすことができます。

個人的な経験から、複雑さだけを考慮した場合、チームは、提供するのに多大な労力を必要とするストーリーを意図せず過小評価する可能性があることがわかりました。これにより、バックログの見積もりが回避され、三角測量などの手法を使用して見積もりを相対的に保つことがより困難になります。

于 2012-12-07T11:03:40.037 に答える
3

良い記事はわかりませんが、ストーリーポイントを使用してアクティビティを見積もる方法は次のとおりです。まず、プロダクトオーナー（PO、クライアントの意思決定者）とともに、開発チームからできるだけ多くの人を集めます。 POにタスク/ストーリー/機能を説明させてから、プランニングポーカー（POを参加者として）を使用してタスクの複雑さを評価し、ストーリーポイントの数を割り当てます。

ここで重要なのは、POの観点から、または開発者の観点から見た場合の複雑さが異なることです。「会社名の変更」の例は、POから見ると非常に簡単かもしれませんが、開発者の観点から見るとアプリケーション全体に広がるため、非常に複雑です。

プランニングポーカーは、誰もが複雑さについての彼の見解を表現できるフレームワークで私たちを助けてくれます。私たちにとって、それは優れた見積もりを提供します。

また、ストーリーポイントはストーリーの複雑さを表すのではなく、ストーリーの実現の複雑さを表すことを忘れないでください。

于 2012-12-06T14:53:03.077 に答える