特定のユーザーにバグを割り当てない
私の質問：特定の開発者にバグを割り当てないことには利点がありますか？全体としてチームに任せますか？
私たちの部門は、バグ/欠陥を個人に割り当てないことで、よりアジャイルになることを決定しました。 Team Foundation Server 2012を使用して、すべてのバグを開発チームの「領域」に配置しますが、「割り当て先」フィールドは空白のままにします。アイデアは、チームが個人に割り当てられるタスク作業項目を作成し、タスクがバグにリンクするというものです。したがって、チーム全体が、個人ではなくバグの責任を負い、スクラムに合わせます-明らかに。
マイナス面が見えます。 TFSに組み込まれているレポートツールは、ユーザーのバグが割り当てられている並べ替えはもちろん、割り当て済みと未割り当てで並べ替えることができない場合、あまり役に立ちません。
見えないメリットはありますか？個人ではなくチーム全体に責任を負わせることでチームワークを促進することに加えて？
アイデアは、チームが個人に割り当てられるタスク作業項目を作成し、タスクがバグにリンクするというものです。
したがって、バグに割り当てられた個人が存在するため、唯一の問題は、その情報がバグ追跡システムに配置されるかどうかです。
あなたは、関連するものを処理するいくつかのシステムがあり、いくつかに設定できるものをどこに置くべきか疑問に思っている状況にあります。冗長な情報があることは悪いことですが（特にリンクが手動の場合は、それ自体が非同期になる傾向があります）、必要な場所に必要な情報がないことはしばしば悪いことです。
問題は、バグ追跡システムの目的についてです。チームにとって、それはバグを管理する方法です。しかし、それはリクエスターと通信する方法でもあり、そのように使用している場合は、バグ追跡システムのフィールドに入力しないと（担当者、計画情報、推奨される回避策など）、その通信が途切れてしまいます。バグが無視されているという印象。特に、要求者がアクセスできないシステムでのみ情報が利用できるようになった場合。また、バグシステムを使用して、バグに関連するNDA）の下で顧客データにアクセスする権利を持っている人を追跡する場合は、それを入力する必要があります。
TLDR：それは、バグ追跡システムを何に使用しているかによって異なります。私がよく知っているフローでは、賢明ではありません。
ソフトウェアの各領域で作業できるチームメンバーが複数いる場合、個々の開発者に問題を割り当てないことの利点の1つは、特定の開発者が問題で過負荷になる可能性について明確に考える必要がないことです。彼らはそれらのほとんどにとって自然な選択だからです。代わりに、ワークロードはチーム全体に均等に分散される傾向があります。これは、誰もが自分が処理できると思うものを手に入れるためです。
レポートツールをより便利に保つために、個別のタスク作業項目を作成しないことをお勧めします。代わりに、開発者がバグの作業を開始するときは、バグを自分に割り当てて、そのアイテムに取り組んでいることを明確にする必要があります。
私は、ユーザーストーリーやバグの割り当てを、1人の開発者に単独の責任を割り当てることとは考えないようにしています。それを解決するために必要な努力を推進する責任がある誰かを割り当てることとしてそれを考えてみてください。必要に応じて誰でも引き込むことができ、その努力をキャプチャするタスクが割り当てられる可能性があります。
サブチームによって駆動されるエリアパスを使用する大規模なチームの場合、バグまたはユーザーストーリーを割り当てずに、チームベースのエリアパスに添付することができます。
チームメンバーがバグを修正するタスクを引き受けることを決定したら、誰もが知っている必要があります。そうしないと、複数の開発者が同じ問題を修正してしまう可能性があります。何かが発生した場合は、タスクから離れてください。
経営陣は、報告に関係なく、アイデアに賛同する必要があります。チームAがDeveloperXがバグを修正しないことに満足している場合、チームのパフォーマンスの低下をこの事実に基づいて非難しない限り、問題はありません。
哲学はすべてうまくいっていますが、管理者による監視が必要です。これは、誰も修正したくない特定のバグ（複雑すぎる、悪いレガシーコード、またはそれらの「時々」のバグの1つ）がある場合に重要です。ボランティアを促すか、割り当てます。
目標は物事を成し遂げることです。失敗の理由として「アジャイル」を使用することはできません。