課題追跡システムのバックログを管理する方法
私たちはここ数年Tracを忠実に使用しており、「アクティブチケット」リストは約200アイテムに増えました。これには、優先度が低すぎて今のところ修正するには複雑すぎるバグ、延期された機能リクエスト、実際には苦情が発生したことはないが、いつか修正する必要があることに誰もが同意する問題、計画されたコードリファクタリング、その他の設計上の欠陥が含まれます。失くしたいなど.
その結果、これらの問題の約200と、リストはほとんど圧倒的です。現時点で取り組む必要のあるもののソースとしてはもはや役に立ちません。
この種の問題を追跡するための最良の方法は何ですか？
問題の一部は、これらの問題のいくつかは優先度が非常に低いため、決して実行されない可能性があることです。私はこれらのアイテムを見失うのが嫌いです（いつか必要になるかもしれない場合に備えて、家から何かを捨てたくないのと同じです）。 （Wontfixとしてマークすることにより）関係なくそれらを破棄する必要があり、将来的に必要になった場合にそれらを見つけることができると想定しますか？
まず、各開発者に各アイテムを見てもらい、各アイテムを確認/テストして、それがまだ問題であるかどうかを確認してもらいます（これらを複数のユーザーに分割するのが最も効果的です）。次に、問題がなくなったもの、または他の開発作業ですでに処理されているものをすべて閉じます。
ここで、それぞれが大、中、または小の開発作業としてマークされていることを確認します。これは非常に大まかな見積もりであり、プロジェクトをより簡単に分類し、物事をまとめるのに役立ちます。すべてがすでに見積もられている場合、それは役立ちますが、時間にこだわらないでください。簡単な腸のチェックをしてください。多くの場合、開発者を部屋に連れて行き、各項目を調べて、大多数の人々が適切だと感じる努力をするように働きます。
3つの取り組みグループのそれぞれを確認し、グループ内の各項目に、重要、高ビジネス価値、高技術価値、中価値、低価値、および修正しないという優先度を付けます。
この時点で、リストを完全に理解し、バックログに関係する作業を本当に理解しているので、アイテムをどう処理するかを本当に決定し始めることができます。修正しないとマークされているすべてのアイテムを取得し、バックログからアーカイブします。
これで、アイテムを次のリリースに入れるようにスケジュールするときに、重要で重要度の高いアイテムをリリースのコアとして使用できます。優先度が中および低のアイテムのリストを確認し、リスト内の他のアイテムと同時に作業できるものを追加します。これは、開発者がシステムのその部分ですでに作業しているためです。
優先度が中または低の項目のリストは、少し暇なときに取り組むべきもののリストとして、または新入社員のトレーニングとして使用できます。私はいつも、すべての反復中にチームに1人の人がこれらの項目に取り組み、必要に応じてチームの他のメンバーを支援するのは素晴らしいことだと思っています。このように、あなたはまだ現在の反復で作業を完了していますが、柔軟性があり、必要なときに火を消すのを助けることができるが、通常は注目されない問題を処理している誰かがいます。
私たちが見つけた1つのことは、各反復の間に、チーム全体が小さな開発努力でマークされたアイテムにのみ取り組む短い2週間の期間があったということでした。短時間で大量のチケットを閉じることに集中します。
Tracには優先設定がありますか？主要なショーストッパーの場合は1、いつか行ってよかったと思うことの場合は5程度ですか？
優先度でソートできる場合は、今のところ優先度の低いものは無視できます。
読む： http://en.wikipedia.org/wiki/5S_%28methodology%29
それらを屋根裏部屋に置き、1年待ってから家を移動します。それが私がすることです。
真剣にそれを修正するつもりがないなら、それを忘れてください。エクストリームプログラミングを参照してください。
しかし、コードに関する項目については。マイナーな観察として、それらをコードレビューシステムに入れることができます。このシステムは、システムのその部分が編集されたときに問題を報告するように設定できます。これは同僚としては機能しないことがわかりました。これは予期されていることであり、レビューの観察には対応していません。
それを行う唯一の方法は、冷酷な優先順位付けです。今それをするか、気にしないでください。
これは実際にはバージョン管理の質問ではなく、ワークフローとビジネスの優先順位の質問です。間違っていることがわかっているものを追跡することは、「いつまでも」修正される可能性が低いとしても、いくつかの利点があります。 1つには、QA（別のQAチームがある場合）が新しいバグを記録しないことを知っていることを意味します。もう1つの利点は、新しい問題が発生したが、その根本原因がこれらの「わかっているが優先度が低い」問題の1つが原因である場合、修正に関する分析はすでに追跡されていることです。これにより、新しい問題がより高くなる可能性があります。修正がはるかに簡単なバグの優先バージョン。
これのもう1つの側面は、現在または将来のいずれかで、この作業の一部に取り組む余裕がある可能性があることです。いつかあなたはインターンを取得し、コードベースで彼らの足を濡らすための紹介として、より単純なもののいくつかを彼らに割り当てることができるかもしれません。
開発者がこれらの問題を修正するのが良いと感じた場合（たとえば、技術的負債を表し、コードベースを修正するための作業が容易になるが、ビジネス上の価値がない場合）、それについて議論する価値があるかもしれません。ビジネスの利害関係者と協力し、それらのバックログ項目が時折取り上げられる合意に達することができるかどうかを確認します。私は、スクラムチームが「テクニカルバックログ」アイテムのスプリントごとに3〜5ポイントの速度をブロックするようなことをしているのを見てきました。これには、開発チームとビジネスの利害関係者の関係によっては、政治的な調整が必要になる場合があります。それは非常にうまく機能します。
これは本当にいくつかのことに依存します。
- チームの規模：チームの規模が十分に大きい場合は、優先度の低いアイテムを完了できるような方法でチケットを割り当てることができます。
- どのくらいの頻度でリリースを行いますか？リリースサイクルが十分に長い場合は、すべてのチケットが解決されるまで、リリースを延期したり、追加したりできます。