バグ修正タスクのストーリーポイント：スクラムに適していますか？
バグ修正タスクにストーリーポイントを割り当てる必要があるかどうか疑問に思っています。問題追跡ソフトウェアであるJIRAにはBugタイプの問題のストーリーポイントフィールドがありません（Story sおよびEpic sの場合のみ）。
Bug課題タイプをStory Pointsフィールドの該当する課題タイプに追加する必要がありますか？長所と短所は何ですか？それはスクラムに適していますか？
理想的には、ソフトウェアは各反復後にバグがなく、バグの修正は各スプリントの一部である必要があります。そのため、ストーリーポイントを割り当てるときは、バグの修正に必要な作業を検討する必要があります（つまり、バグを生成する可能性が高いタスクは、より多くのストーリーポイントが割り当てられています）。
ただし実際には、テストがどれほど厳格であるかに関係なく、展開後のバグは常に表面化しています。それが発生した場合、バグを削除することは別の変更であり、可能であれば機能です。このコンテキストでは、バグレポートと機能リクエストの間に基本的な違いはありません。どちらの場合でも、アプリケーションは特定の動作を示し、ユーザー（または他の関係者）はそれを変更したいと考えています。
ビジネスの観点からは、バグ修正と機能も同じですが、実際には同じです（シナリオB）またはしない（シナリオA）。どちらのシナリオにもコストとメリットがあり、きちんとしたビジネスパーソンはそれらを比較検討して、より多くの利益を生むものなら何でも実行します（ビジネス戦略に応じて長期または短期）。
したがって、はい、必ず、バグにストーリーポイントを割り当てます。他にどのようにバグ対機能、およびバグに対するバグを優先しますか？両方に対してある程度の開発努力が必要であり、比較可能である方がよいでしょう。
これに関する最大の問題は、バグ修正の見積もりが難しいことが多いことです。実際の作業の90％以上が原因の特定にあります。いったん見つけたら、正確な見積もりを出すことができますが、検索にかかる時間を判断することはほとんど不可能です。ほとんどの時間が再現バグの試行のみに費やされた、かなりの数のバグを見たことさえあります。一方、バグの性質によっては、見積もりを行う前に、最小限の調査で検索を絞り込むことができます。
あなたすべきではないバグ解決にポイントを与える。バグが、開発者がストーリーを完了するためにすでにポイントを獲得しているのストーリーから発生しているという事実を考慮してください。ポイントを受け取るべきではありませんagain実際には実際にはポイントを獲得していないはずです。
バグ修正はベロシティにマイナスの影響をもたらすはずです。それ以外の場合、品質の低下は、影響を受けない、または速度の増加で報われることになります！
おそらく便利なリンク：
ポイントを使用したバグの推定は、他の回答ですでに指摘されているように本質的に困難であり、はい、理想的な解決策は次のとおりですスプリントが受け入れられた後に機能で見つかったバグは、新しい機能と見なす必要があります。
しかし、バグのポイント推定のこの困難さは、アジャイルPMソフトウェアパッケージがタスクとバグを数時間で推定できるようにする多くの理由の1つです。ポイント推定に熟練するには熟練と経験が必要だからです。多くのプロジェクトは速度を適切に決定することで重大な問題に遭遇するため、多くのアジャイルプロジェクトはポイントを使用してスプリントに組み込むストーリーを決定しますが、バーンダウンチャートの計算には時間を使用します。
スプリントのコミットメントを決定する際の要素として時間の見積もりが使用されない限り、直観に反するように見えますが、管理可能です。オーバーコミットメントは当然、機能の欠落や不完全さ、または残業につながります。そのため、時間の経過とともに、関係するすべての人がポイント推定で改善することを余儀なくされ、その時点で、タスクおよびバグの時間の推定はゆっくりと無意味な指標になります。
バグをユーザーストーリーとして扱い、いくつかのポイントを割り当てることをお勧めします。ユーザーストーリーのように、必ずしも「Xとして、YにしてZにしたい」という形式で書く必要はありません。「IY、Zが発生したときは、Xとして」と書きますが、 Z 'は予想される動作です。」.
これの利点は、新機能の要求と並行してバグ修正に優先順位を付けることができることです。真実は、バグを修正するよりも新しい機能の方が重要な場合があります。ただし、必要な作業のサイズを適切に設定できるので、必要に応じてスプリントに合わせることができます。
バグを修正するために必要な労力を見積もるのは難しい場合があることを覚えておいてください。これには、相互に作用する複数のコンポーネントが関係する可能性があり、システムの大きな部分の相互作用に精通している誰か、または修正に取り組む複数の人々が必要になります。
ストーリーの見積もりは、時間の経過とともに、チームはそれらを解決する経験を積むという概念に基づいています。これにより、精度が向上し、チームの速度を測定する速度を確立できます。将来のスプリントのための信頼できる予後を確立するための完璧な方法論。
バグはソフトウェア開発会社にとっては当たり前のことです。ストーリーの作成中にバグをすべてキャッチする必要があることには同意しますが、これは常に達成できるとは限らないことを受け入れることは、すべてのチームが計画する必要があるものでなければなりません。プロセスがチームを統治するべきであると頑固に考える代わりに、それは逆の方法でなければなりません。
もちろん、バグやストーリー、ビジネス側からは、チームが何を扱っているかは問題ではありません。どちらも製品所有者に同等の価値をもたらします。
私たちのチームでは、バグを推定するためのいくつかの手法を試しました。
- 完全に未知のバグの推定
- すでに分析されたバグのみを推定
- バグを修正するための時間を割り当て、バグを推定せず、ビジネス価値のみに基づいてランク付けする
1.では、ひどく失敗しました。ほとんどのバグでは、90％の時間がバグ分析に費やされています。その後、バグ修正はストーリーと同じ方法で推定できます。バグをスプリントに計画することで、未知のスコープがストーリーの解決に影響を与えるというミスを犯しました。これは、この方法で行ったほぼすべてのスプリントが失敗するところまでです。
90/10の比率（分析とバグ修正）の推定手法オプション2に基づくと、スプリント計画の対象ではない分析を計画する必要があったことを意味しました（オプション1から学んだが、実際の解決策はなかった分析されたバグの続行方法）。その結果、スプリントは計画された項目に焦点を合わせたため、バグ分析は行われませんでした。チームには、バックログのバグに集中する時間がありませんでした。したがって、最終的には彼らも完了しませんでした。
不確実性を受け入れることで、オプション3で解決しました。製品のバックログを、チームがストーリーポイントとバグバックログを使用して推定できる通常のストーリー/タスク部分に分割しました。バグバックログでは、製品の所有者がビジネス価値と非常に大まかなチーム判断に基づいてバグをランク付けします。チームは、スプリント中にバグに集中するために費やすことができる時間のチャンクを割り当てることができます。以前はそれを計画できなかったため、製品の所有者は正確な結果を知りません。バグバックログと通常のバックログの比率は、各バックログの現在のステータスとコンテンツの重要性とビジネス価値に応じて、スプリントごとに調整できます。
不確実性を取り除くことで、チームを再び解放しました。スプリントは未知のバグによって危険にさらされませんでした。バグを別のバックログに分離することにより、チームの定期的なスプリントの焦点が増加し、重要なビジネス価値を含むバグを仕上げることができました。
したがって、ストーリーポイントがあなたに適しているかどうかによって異なります。最初にストーリーポイントを使用してバグを推定しようとします。それが失敗した場合は、私のオプション3を試してください。これにより、（30を超える古いスプリント）チームは、大きなビジネス価値を含む古いバグに再び集中できるようになりました。また、チームが簡単に見積もることができないものを提供しようとすることから解放されました。私たちを現実に近づけ、またスプリントを再び成功に導いた未知の要素を採用していましたwhileバグ修正を通じてビジネスバリューの大きなチャンク（バグとストーリーの比率に基づく）を提供しました。最近使用した比率は50/50でした。
バグにストーリーポイントを割り当てるというトップアンサーに同意する必要があります。ストーリーポイントは、新しい価値を提供するためのものです。製品の価値のあるアイテムと価値のないアイテムにポイントを割り当てる場合は、時間を見積もり、追跡することもできます。
バグは昨日あなたがしたことのオーバーヘッドであり、製品の完成の速さを示すものではなく、新しい製品の価値も生み出しません（考えてみてください）。バグは一種の割り込みのようなものであり、毎週対処する必要がある他のすべてのカウパイです。ストーリーポイントの全体的な考え方は、製品（または機能セット）をいつ配信するかを追跡/推定することです。ストーリーポイントは任意であり、それがすべての非値オーバーヘッドを推定から取り除く方法です。一般に、価値のない作業は週ごとに一定であるため、チーム速度に組み込まれます。この価値のない作業を削除または削減すると、チームは加速します。
別の言い方をすれば、なぜバグのポイントを追跡するのですか？つまり、1日の終わりに、各メンバーがどれだけの「仕事」をしたかを知っているのでしょうか。それを停止する！悪いマネージャー！ :)プレーヤーではなく、チームを測定します。 1人が体重を減らしていない場合は、自分で管理することをチームに奨励します。はるかに効果的です。ストーリーポイントアイテムを実行しても、個人の気分が良くなるはずはありませんが、スプリントの最後にコミットメントを行うと、チーム全体として気分が良くなるはずです。スポーツにおいて、ゴールはチームにとっても個人にとっても良いのでしょうか？個人が自分でプレーする場合、チームは長期的には負けます。
最終的に、ポイントをまったく使用しないようにする必要があります。見積もりは、実際の作業から離れた時間です。チームが最大カイに到達したとき、彼らはポイントをまったく使用していませんが、スプリントにプルできるアイテムの数を正確に把握しています。彼らは、推定がプロセスの無駄であるという作業単位を分割する技術を習得しました。
見積もり可能なタスクもあれば、見積もりできないタスクもあります。 見積もりできないものについては、予算を使用してください。
欠陥の修正は、未知のコンポーネントがいくつかあるため、簡単に見積もることはできません。欠陥の原因は何ですか？原因を理解したら、どうすれば修正できますか？この変更はシステムの他の部分にどのような影響を与えますか？この欠陥を修正するために、いくつの新しい欠陥を注入しましたか？
欠陥の原因は、ソフトウェアライフサイクルの任意の時点から発生する可能性があることに注意してください-誤解または誤解された要件、設計の誤りまたは誤った仮定、コーディングの誤り、テストの誤り、現在のリリースから得られた情報に基づく問題に関する新しい知識...
予算の作成は、バグ修正タスクのいくつかの異なる方法で行うことができます。これが私が効果的に使用したいくつかのアイデアです：
- 過去のデータ（たとえば、前の反復からのもの）を使用して、バグ修正のために取っておかれる時間を理解するのに役立てます。
- バックログにバグ修正の "ブロック"（たとえば、5ポイントまたは20時間）を入れ、顧客がストーリーの代わりにこれを選択できるようにします。
- チームの各メンバーが指定された時間を費やして、各反復で欠陥を修正することを要求します。
あなたの目標は、割り当てられた予算内で可能な限り多くの欠陥を修正することです。報告された欠陥に優先順位を付けるためのお客様の戦略について話し合います。たとえば、重大度の次に優先度で欠陥を分類しますか？厳密な優先順位？最初に「ぶら下がっている果物」を攻撃するべきですか？最初にUIバグ？
また、バグを修正しても価値はありません。欠陥の修正は、一種の無駄です。あなたはすでに機能の価値を獲得しているので、バグを修正するための「ボーナスポイント」を取得すべきではありません。
予算があると計画に役立ちますが、それでも速度の正確な画像が得られます。バグ修正のために特定のポイントに予算を割り当て、履歴データに基づいて予算におよその時間を割り当て、予算内でできる限り多くのバグをつぶします！
ストーリー、バグ、雑用、それぞれのポイントに重点を置くのではなく、顧客に機能を提供することに重点を置くほうがよいと思います。
お客様は、ソフトウェアが機能することを期待し、開発、拡張、および新機能がビジネスを推進するため、それらに真の価値を与えるだけです。
バグの修正は、それらが重要である可能性があるとしても、ビジネスを新しい領域や新しい顧客に押しやることはありません（接線方向にそして最終的には可能ですが、すぐにはではなく、経営陣が測定しているものです）。
したがって、ポイントは、速度のより高い視点から、および同様にスコア付けされたストーリーで歴史的に行われた週あたりのポイント数から最もよく見られます。
これは、今週のストーリーを完成させ、頻繁にそうでないことを発見する緊急の必要性を押し進めるのではなく、実績履歴による管理につながる可能性があります。ただし、事前のコントロールが失われ、これが必要とする信頼が高まると、一部のマネージャーがドアを恐怖に陥れることになります。
私はPivotal Tracker（JIRA、Trak、Trelloなども使用しています）を使用しており、Pivotal Trackerは雑用やバグのポイントも行いません。これは、JIRAでも同様の理由で行われます。