「いつ」解決されるべき増え続ける問題の山をどのように処理しますか？

JIRAを使用して、ソフトウェアプロジェクトの問題を追跡しています。私たちが気づいた1つの効果は、新しい問題を頻繁に作成することですが、問題がいつ修正されるのか/いつ修正されるのかはまだわかりません。そこで、そのような問題に割り当てられる偽の「遠い未来」マイルストーンを発明しました。

偶然にも、このマイルストーンに割り当てられた問題の山は常に増え続けているため、これは良いアプローチではないようです。それらの多くは今では非常に多くあるため、それらすべての妥当性を確認するのは非常に多くの作業になりました。それらの一部は、それらに関連するコンポーネントが削除されたため無効になりました。それらのいくつかは他の問題によって複製されました。それらのいくつかは、彼らがもう何についてであるかを本当に誰も本当に知らないほど不十分に表現された説明を持っています。

他のソフトウェア開発チームは、有効であるが、いつでも修正されないかもしれない問題にどのように対処しますか。まったくわざわざ録音しますか？それらを次の計画バージョンに割り当て、次のリリースが近づくにつれてそれらを再度確認しますか？他に何か？

これらは、あなたの会社に入社したばかりの新しい開発者のために修正するのに良い最初の連絡先バグです。または、ジュニア開発者がシステムの知識を消費する場合。

そうでない場合、修正にかかる時間を正当化するほど深刻ではない場合、「修正しない」とマークすることができます。

バグを修正する必要があるのは、アプリケーションがバグなしでより価値がある場合のみです。

テキストフィールドの位置がずれていて、修正に3日かかる場合は、おそらくコストが高すぎるため、そのままにしておく必要があります。反対に、ユーザーがテキストフィールドにまったく書き込めない場合は、すぐに修正する必要があります。

一般に、問題が発見された直後に修正する方が簡単です。時間が経てば、開発者はコードのその部分がどのように機能するかを忘れる可能性があり、バグの修正に時間がかかり、したがってより高価になります。

一部の企業は、まだ保留中のバグがある場合、新しいコードの行を作成しません。他の人は、配信前のテスト段階まで気にしません。

あなたの会社では、新しいバグを修正する前に明らかに多くの時間を費やしているので、それらは蓄積されています。また、チームの士気がバグの膨大なリストを見ることは悪いことです。

既存のバグを整理するためだけに1日を費やし、修正する価値のあるものとそうでないものを決定し、次のマイルストーンの前に問題を解決する目的で既存のチームメンバーに修正するものを割り当てることをお勧めします。

問題追跡では、ステータスが「時間制限」になっています。問題が数か月または数年前であり、クライアントが問題を促したり修正したりしない場合、このステータスは最終ステータスとして使用されます。これは自動的に行われるのではなく、マネージャーが未解決の問題をクリーンアップするように依頼するたびに手動で行われます。また、このプロセス中に、修正が容易であるか比較的重要であるため（いくつかの問題は（推奨または修正されていないにもかかわらず）修正される可能性があります）。

私はJIRAを使用していません。fogbugzを使用していますが、これはほとんどのバグトラッカーに適用されると確信しています。これを書いている間、私は自分の仕事のやり方が滝よりも機敏であることに気づきました、締め切りは私にとって具体的ではなく、重要なことは優先事項です。

• 上司が開いているチケットの数が多すぎることを気にしている場合は、そもそもささいなチケットを作成しないでください。実用的で、メリットのない機能や修正を追加しないでください。コードを洗練したりUIを微調整したりするのが楽になる場合は、追加してください。製品の軽微な欠陥を修正しようとするだけで自分で作業するのではなく、完璧なものはありません。
• 重要でないバグ/機能を現在のマイルストーンに入れますが、優先度は低くします。問題に関する苦情/リクエストがさらに記載されている場合は、優先順位を上げることができます。
• 修正できないもの、再現できないもの、複製できないものなど、できることをクローズ/解決します。バグの中には、修正するにはささいなものや、非常に時間がかかる機能要求があります。これらの修正/機能をリクエストしている人に「いいえ、時間はありません」と伝える必要がある場合があります。
• 必要に応じてバグに優先順位を付け、チケットリストを優先度とマイルストーンでソートします。
• 彼らがマイルストーンを作らない場合は、将来のマイルストーンに移動します。
• チケットが完了中の他のチケットに依存している場合、チケットをブロック済みとしてマークするか、チケットを階層に整理して、ticket-xとticket-yが関連していることを明らかにします。
• チケットに誰かからのフィードバックが必要な場合、チケットをその人に割り当てます。

最終的には、常に優先度の低いチケットがたくさんありますが、上記のポイントはそれを最小限に抑えるのに役立つはずです。

JIRAを使用し、追加の解決状態があります Suspendedあります。機能/バグがしばらくあきらめなければならないものである場合、一時停止として解決されます。そうすれば、注意を払う必要がある現在アクティブな問題のリスト、または満足のいくように処理されたことがわかっている解決済みの問題のリストと混同せず、データベースに残っています。

一時停止された問題のリストは、必要に応じて再開するために定期的に（ただしそれほど頻繁ではありませんが）レビューします。

正しいJIRAの用語は定かではありませんが、各「チケット」に有効期限を設けることを検討してください。機能のニーズやバグの重大度によって、一定の時間内に実装にエスカレートされていない場合、そもそもそれほど重要ではなかったでしょう。これにより、パイルが自動的にトリミングされたままになります。私はよく「いいだろう」または「これは私が望むように完全には機能しません」に基づいてチケットを取得します。誰もそれを十分にプッシュしていない場合、またはそのユーザーに十分な影響力がない場合、それは完了せず、数か月後にチケットを閉じます。