増え続ける問題を「いつか」解決するためにどのように処理しますか？
JIRAを使用して、ソフトウェアプロジェクトの問題を追跡しています。私たちが気付いた1つの影響は、新しい問題を頻繁に作成することですが、問題が完全に修正される時期と時期はまだわかりません。そこで、そのような問題が割り当てられる偽の「遠い未来」のマイルストーンを発明しました。
たまたま、このマイルストーンに割り当てられた問題の山は常に成長し続けているため、これは良いアプローチではないようです。それらの数が非常に多くなっているため、すべての妥当性を確認するのはかなりの作業になります。それらのいくつかは、それらに関連するコンポーネントが削除されたために無効になりました。それらのいくつかは他の問題によって複製されました。それらのいくつかは、もはや彼らが何についてであるかを本当に誰も知らないほど下手な言い回しをしています。
他のソフトウェア開発チームは、有効であるがいつでも修正されない可能性がある問題にどのように対処しますか？そろそろ録音しちゃうんですか？それらを次の計画バージョンに割り当ててから、次のリリースが近づいたときにそれらをもう一度見ますか？他に何か？
これらはあなたの会社に参加したばかりの新しい開発者のために修正するための良い最初の連絡バグです。または、ジュニア開発者がシステムに関する知識を費やすために。
そうでない場合は、修正にかかる時間を正当化するほど深刻ではない場合は、「修正しない」とマークできます。
アプリケーションがバグなしでより価値がある場合にのみ、バグを修正する必要があります。
テキストフィールドの位置がずれていて、修正に3日かかる場合は、コストが高すぎる可能性があるため、そのままにしておく必要があります。逆に、ユーザーがテキストフィールドにまったく入力できない場合は、すばやく修正する必要があります。
一般に、問題が発見された直後に問題を修正する方が簡単です。時間が経つと、開発者はコードのその部分がどのように機能するかを忘れてしまう可能性があり、バグの修正には時間がかかるため、コストが高くなります。
まだ保留中のバグがある場合、一部の企業は新しいコードの行を記述しません。他は配達の前のテスト段階まで気にしません。
あなたの会社では、新しいバグを修正して蓄積する前に、明らかに多くの時間を費やしていることになります。チームの士気がバグの膨大なリストを見るのも悪いことです。
既存のバグを整理するためだけに1日を費やすことをお勧めします。修正する価値のあるものとそうでないものを決定し、次のマイルストーンの前に問題を解決することを目的として、修正するものを既存のチームメンバーに割り当てます。 。
私たちの問題追跡では、「時間制限」というステータスがあります。問題が数か月または数年前であり、クライアントが問題を要求または再整理しない場合、このステータスが最終ステータスとして使用されます。これは自動的には行われず、手動で、マネージャーが未解決の問題のクリーンアップを要求するたびに行われます。このプロセス中に、修正が簡単で比較的重要な問題がいくつかあるために修正される可能性もあります（促されたり、整理されたりしていないにもかかわらず）。
JIRAを使用し、Suspendedと呼ばれる追加の解決状態があります。機能/バグがしばらくあきらめなければならない場合、一時停止として解決されます。そうすることで、注意が必要な現在アクティブな問題のリスト、または問題なく処理されていることがわかっている解決済みの問題のリストと混同せず、データベースに残っています。
一時停止中の問題のリストは、必要に応じて再開するために定期的に（あまり頻繁ではありませんが）確認するものです。
私はJIRAを使用していません。fogbugzを使用していますが、これはほとんどのバグ追跡に当てはまると確信しています。これを書いているとき、私は自分の仕事のやり方が滝よりも機敏であることに気づきました。締め切りは私にとって具体的ではなく、重要なことは優先事項です。
- 上司が開いているチケットが多すぎることに関心がある場合は、そもそも簡単なチケットを作成しないでください。客観的で、メリットのない機能や修正を追加しないでください。コードを磨いたり、UIを微調整したりすることが簡単になる場合は、追加してください。製品の小さな欠陥を修正しようとするだけで自分のために仕事をするのではなく、完璧なものはありません。
- 重要ではないバグ/機能を現在のマイルストーンに置きますが、優先度は低くします。問題についてより多くの苦情/要求が言及されている場合は、優先度を上げることができます。
- 修正できないもの、再現できないもの、複製できないものなどをクローズ/解決します。一部のバグは修正が簡単ではないか、非常に時間がかかる機能のリクエストです。これらの修正/機能をリクエストしている人に「申し訳ありませんが、時間はありません」と伝える必要がある場合もあります。
- 必要に応じてバグに優先順位を付け、優先順位とマイルストーンでチケットリストを並べ替えます。
- マイルストーンを作成しない場合は、将来のマイルストーンに移動します。
- チケットが完了している他のチケットに依存している場合は、チケットをブロック済みとしてマークするか、チケットを階層に整理して、ticket-xとticket-yが関連していることを確認します。
- チケットが誰かからのフィードバックを必要とする場合、その人にチケットを割り当てます。
最終的には、常に優先度の低いチケットがたくさん集まりますが、上記のポイントはそれを最小限に抑えるのに役立ちます。
JIRAの正しい用語はわかりませんが、各「チケット」に有効期限を設定することを検討してください。機能の必要性やバグの重大度によって、特定の時間内に実装にエスカレーションされていない場合、そもそもそれほど重要ではなかったと考えられます。これにより、パイルが自動的にトリミングされます。 「いいね」や「思ったように動かない」でチケットをよく購入します。他の誰もそれを十分にプッシュしない場合、またはそのユーザーに十分な影響力がない場合、それは完了せず、数か月後にチケットを閉じます。