課題追跡のバックログを管理する方法

私たちはここ数年Tracを忠実に使用しており、「アクティブチケット」リストは約200アイテムに増えました。これらには、優先度が低すぎて複雑すぎて現時点では修正できないバグ、延期された機能リクエスト、実際に苦情が発生したことはないが誰もがいつか修正すべきであることに同意している問題、計画されたコードリファクタリング、およびその他の設計上の問題失くしたいなど

その結果、これらの問題の約200と、リストはほとんど圧倒的です。現時点で取り組む必要のあるもののソースとしてはもはや有用ではありません。

この種の問題を追跡する最良の方法は何ですか？

問題の一部は、これらの問題のいくつかは優先度が非常に低いため、実行できない可能性があることです。私はこれらのアイテムを見失うのが嫌いです（いつか必要になる場合に備えて、家から何かを捨てたくないのと同じです）。（Wontfixとしてマークすることにより）関係なくそれらを破棄する必要があり、将来必要になった場合にそれらを見つけることができると想定しますか？

まず、各開発者に各アイテムを見てもらい、各アイテムを確認/テストして、それがまだ問題であるかどうかを確認してもらいます（これらを複数のユーザーに分割するのが最適です）。次に、問題ではなくなったもの、またはすでに他の開発作業で対処されているものを閉じます。

次に、それぞれが大、中、または小の開発作業としてマークされていることを確認します。これは非常に大まかな見積もりであり、プロジェクトをより簡単に分類し、物事をまとめるのに役立ちます。すべてがすでに見積もられている場合、それは役立ちますが、時間にこだわらないでください。クイックガットチェックを行ってください。多くの場合、開発者を部屋に引き込み、各項目を調べて、大多数の人が適切であると感じる努力を使用します。

3つの作業グループのそれぞれを確認し、グループ内の各項目に、重要、高ビジネス価値、高技術価値、中価値、低価値、および修正予定なしの優先順位を付けます。

この時点で、あなたはリストを完全に理解し、バックログに関係する作業を本当に理解しているので、アイテムをどうするかについて本当に決定を始めることができます。修正しないとマークされているすべてのアイテムを取得し、バックログからアーカイブします。

アイテムを次のリリースに入れるようにスケジュールするとき、リリースのコアとしてクリティカルおよび高重要度のアイテムを使用できます。優先度が中および低の項目のリストを確認し、リストの他の項目と同時に作業できる項目を追加します。これは、開発者がすでにシステムのその部分で作業しているためです。

優先度が中または低のマークが付けられたアイテムのリストは、少し時間があるときに取り組む人々のリストとして、または新入社員のトレーニングとして使用できます。私はいつも、イテレーションのたびに1人のスタッフがこれらの項目に取り組み、必要に応じてチームの他のメンバーを支援することは素晴らしいことだと思います。このようにして、現在のイテレーションで作業を完了していますが、柔軟性があり、必要なときに火を消すのに役立つが、通常は注意されない問題を処理している人がいます。

私たちが見つけた素晴らしいことの1つは、各イテレーションの間に2週間という短い期間があり、チーム全体が小さな開発作業でマークされたアイテムのみを処理するということでした。短時間で多数のチケットをクローズすることに焦点を当てます。

Tracには優先設定がありますか？メジャーショーストッパーの場合は1のように、いつかやってみたいと思うものの場合は5程度でしょうか。

優先度でソートできる場合は、今のところ優先度の低いものは無視できます。

読む：http : //en.wikipedia.org/wiki/5S_%28methodology%29

それらを屋根裏部屋に置き、1年待ってから家を移動します。それが私がすることです。

真剣にそれを修正するつもりがないなら、それを忘れてください。Extremeプログラミングを参照してください。

ただし、コードに関する項目については。マイナーな観察として、コードレビューシステムにそれらを置くことができます。このシステムは、システムのその部分が編集されたときに問題を報告するように設定できます。これは同僚としては機能しないことがわかりました。これは予期されたものであり、レビューの観察には対応していません。

それを行う唯一の方法は、冷酷な優先順位付けです。今それを行うか、気にしないでください。

これは実際にはバージョン管理の問題ではなく、ワークフローとビジネスの優先順位の問題です。間違いであることがわかっているものを追跡することは、「いつまでも」修正される可能性が低いとしても、いくつかの利点があります。1つには、QA（別のQAチームがある場合）が新しいバグを記録しないことを知っていることを意味します。別の利点は、新しい問題が発生しても、その根本的な原因がこれらの「私たちはそれを知っているが優先度が低い」問題のいずれかが原因である場合、修正に関する分析はすでに追跡されており、これにより、より新しい、より高いバグの優先バージョンは修正がはるかに簡単です。

これの別の側面は、現在または将来のいずれかで、この作業の一部に取り組む余地があるかもしれないということです。多分いつかあなたはインターンを取得し、コードベースで彼らの足を濡らすための紹介として、より簡単なもののいくつかを彼らに割り当てることができます。

開発者がこれらの問題を修正するのは良いことだと感じた場合-たとえば、それらが技術的負債を表し、コードベースを修正するための作業が容易になるが、ビジネス上の価値がない場合-議論する価値があるかもしれませんビジネスの利害関係者と協力して、バックログ項目が時折取り上げられる合意に到達できるかどうかを確認します。私は、スクラムチームが「テクニカルバックログ」アイテムのスプリントごとに3〜5ポイントの速度をブロックするようなことをしているのを見てきました。これには、開発チームとビジネス利害関係者の関係によっては、政治的な調整が必要になる場合があります。それはとてもうまくいきます。

これは本当にいくつかの事柄に依存します。

1. チームの大きさ：チームが十分に大きい場合は、優先度の低いアイテムを完了できるようにチケットを割り当てることができます。
2. どのくらいの頻度でリリースしますか？リリースサイクルが十分に長い場合は、すべてのチケットが解決されるまで、リリースを延期したり、追加したりできます。