スクラムでは、バックログを機能的なバックログと技術的なバックログに分割する必要がありますか？
スクラムチームでは、バックログを使用します。バックログには、主に機能的なトピックが含まれますが、技術的なトピックが含まれることもあります。バックログが1つあることの利点は、次のスプリントのトピックを選択しやすくなることですが、いくつか質問があります。
- まず、私にとっては、開発者自身が純粋な技術項目を追加できる個別の技術バックログを持つ方がより論理的であるように思われます。たとえば、このメソッドでパフォーマンスを向上させることができ、このクラスには技術ドキュメントが不足しています...開発者は常にトピックをバックログに追加するために製品所有者を経由する必要がありますが、これは製品所有者にとって追加の不要な作業のようです。
- 第二に、純粋な機能のアイテムのみに焦点を当てている製品所有者がいる場合、純粋な技術的なアイテム（欠落している技術ドキュメント、侵食されてリファクタリングされるコード、デバッグがないときに常に問題が発生するクラスなど）安定した基盤であり、リファクタリングする必要があります。..）「顧客に直接サービスを提供しない」ため、常にリストの最後になります。個別の技術バックログを用意し、これらの純粋な技術項目のすべてのスプリントに時間を確保することで、アプリケーションを機能的に改善するだけでなく、内部を正常に保つことができます。
最善のアプローチは何ですか？ 1つまたは2つのバックログ？
私はエキスパートではありませんが、チームごとに1つのバックログしか持てないと思います。チームは、どの問題が緊急で、どの問題を延期できるかを決定する必要があります。問題を別々のタイプのスタックに分離すると、スクラムの中心にあるコアアイデアに反します。つまり、問題のプールがあり、各スプリントはチームが最も緊急に取り組んでいます。チームを（サブ）分割すると、それらに関連するタスクのタイプを分割できる可能性がありますが、基本的には並行して作業するチームを設定することになります。緊急性/必要性は、次のスプリントを計画する際の第一の決定者です。タスクを分類することはできますが、これが決定プロセスの邪魔になってはいけません。
製品ごとに1つのバックログを推奨する人に私の声を追加したいと思います。別のバックログを作成することは合理的な対応ですが、本当に中心的な問題を回避しているだけです。なぜ、プロダクトオーナーが機能アイテムよりも技術アイテムを優先しないのですか？あなたはそれを回避するのではなく、これを解決することに集中すべきです。たとえば、 5 Whys テクニックを使用して、物事の根底に到達しようとすることができます。
POが技術的な問題を優先しない理由はたくさんあります。たとえば、技術チームが技術的な負債に対処しないことによる長期的なコスト（$$$）を説明していない可能性があります。多分それは完全に別のものです。コミュニケーションの問題が原因である可能性が高く、長期的な解決策は、その問題に取り組み、解決することです。障害を取り除いてください。
さらに、もう1つ質問があります。そもそもなぜ技術的負債が発生したのですか。理想的には、リファクタリングなどの作業は、機能的なストーリー内で行われ、スプリント内で完了する必要があります。それらはそれ自体で追加のストーリーであってはなりません。そうでなければ、潜在的に出荷可能なコードがありません。
あなたが言及しているものは、一般に「技術的負債」と呼ばれています。欠陥がそうであるのと同じように、技術的な負債の仕事がスクラムプロセスにどのように適合するかを見るのは時々難しいかもしれません。
あなたが提案しているのは、別個の「欠陥バックログ」もあると提案するのと同様であり、バックログを3に分割します。
個人的には、私はnot製品のバックログを分割することを推奨します。製品バックログのアイデアは、未解決の作業項目を表すことです。その観点から、機能と技術的な負債項目の唯一の違いは、要件が顧客からではなく、開発チームからのものであることです。それはまだ作業項目であり、他の作業項目に対して優先順位を付けることを含め、管理する必要があります。これは、技術的な負債項目がテストを必要とする場合に特に当てはまります。その場合、通常の機能とまったく同じQAプロセスを実行する必要があります。
プロジェクトごとに1つのバックログのみが存在する必要があるという点でOnnoに同意します。それ以外の場合、チームは基本的に自分の手でいくつかの決定を行い、それは当然のことながら製品所有者に属します。
「純粋に技術的な」アイテムであっても、ユーザー（および製品所有者）がスプリントバックログの対象となるには、実用的な値が必要です。これらの利点を製品所有者に説明し、コストを正当化する付加価値を彼/彼女に納得させるのはあなたの仕事です。そして、このプロセスでは、これらの問題を熟考し、最小限の労力でプロジェクトに最大の価値をもたらす技術変更を選択する必要があります。
上記のすべての回答に同意します。商業的現実の猛暑の中で、POは機能的なストーリーを技術的なストーリーよりも優先していきます。しばしばチームの欲求不満に。チームは、ユーザーの価値のないテクニカルストーリー（スピードが問題ではない場合、最適化を気にする人）を控え、機能的なストーリーに含まれる他の特定のテクニカルタスクを確認する必要があります。 「完了の定義」も大きな役割を果たします。残りの機能的なストーリーは、POが優先するバックログに入ります。
例えば。技術文書：技術文書（該当する場合）の可用性は、D.O.Dに属する典型的なアイテムです。そのため、更新はすべての機能的なストーリーに含まれています。
例えば。コードのリファクタリング：製品開発に役立つ場合に実行する必要があります。早い段階ではなく（製品がどの方向に進化するかをチームが想定するべきではありません）、すでに技術的な負債になっているときも遅くありません。デザインのレビューもDoDの一部になる可能性があります。
MelRに同意します。 「技術的」なものがある場合は、なぜそれを行っているのか、あるいは短期的および長期的には何であるかを確認する必要があります 原因と影響 （ユーザーにとって）?。
いわゆる「テクニカルタスク」をビジネス価値のような方法で簡単に記述できる多くのバックログを見てきました。
多くの場合、技術的なタスクは、大規模な分割されたストーリーの結果です。しかし、これにより、真の付加価値（またはフィードバックの機会）の反復が遅くなり、スプリントの失敗がさらに悪化する可能性があります。
Patrickが言うように「侵食され、リファクタリングされるべきコード」に関して、私たちは尋ねる必要があると私は信じています-そのコードがシステム機能のどの領域に影響を与えているのですか？そして、今リファクタリングしないと、ユーザーに長期的にどのような影響がありますか？
次に、長期的な技術的負債を減らすために、「見つけた方法よりも少し良いものを残す」という主題があります。これは、より広いプロジェクトにあまり影響を与えずに、各スプリントの小さなストーリーの一部として行うことができますか？
結局、2つのバックログが必要だとは思えません。これにより、適切に優先順位付けされたニーズを遅くする機会が開かれます。ストーリーを垂直方向に分解する-アドビは 垂直方向のスライス について適切な説明を提供しています。
いいえ、テクニカルストーリーを作成することはできません。これは一般的なエラーです。ストーリーはビジネス要件を反映している必要があります。技術的なものは、ビジネス要件からのものではありません。これは、スクラムマスターとチームが、目的またはストーリーに到達するために行う必要があるすべての技術的タスクを評価する役割です。
たとえば、ログイン画面の作成に関するストーリーの場合、まだ作成されていない場合でも、データベースの作成を検討する必要があります。
私は、POを使用して、ITチームがユーザーであるタスクを作成する問題を認識していません。タスクがPOによって理解でき、ビジネス価値の観点から評価できる場合、はい、一種のテクニカルストーリーを作成する方法があります。システムを使用するだけです。