バグ追跡/問題追跡ソフトウェアを使用して、設計に関する質問、新しいツールなどについて話し合う

bugzilla、mantis、またはJIRAなどのバグ追跡/問題追跡ソフトウェアを、バグやタスクだけでなく、最終的に決定につながる議論を開始および維持するために使用した経験はありますか？

たとえば、開発者は、すべての保護フィールドを廃止し、それらにアクセスする保護メソッドを持つプライベートフィールドに変更する必要があると考えています。それは彼の呼び出しではなく、彼はそれを議論したいと思います。通常、彼は次の開発者会議でポイントを持ち出し、最後に決定が下されます。代わりに、私の考えは、彼が特定のタイプの「決定」の問題を開き、通常はバグやタスクを説明するように彼の意図を説明することでした。

他の開発者は、自分がそう思うとコメントすることができ、最終的に、問題は「受け入れられた」または「拒否された」としてクローズされます。

私がこれで見る利点：

• 非同期通信：決定のすべての影響を監督する時間がまだないときに、会議で意見を述べることを強制される人はいません。
• 決定に至る考慮事項の記録されたログ。後でその質問を再度提起した場合、彼はそれを参照することができます。
• 他の問題との関係を作ることができます。たとえば、タスクをフォローして決定に戻ることができます。
• コミットなどのバージョン管理ソフトウェアとの統合は、決定にまでさかのぼることができます。

短所：

• 金色のハンマーの激しい匂い：通常、問題追跡ソフトウェアは実用的なアイテムを追跡するために使用されます
• 組織のオーバーヘッドは不均衡な場合があります。小さな非公式の会話の代わりに、書面でアイデアを伝える必要があります。

作業方法、問題追跡はすべての問題を追跡する必要があります。分析されるまで、どの問題が実行可能かはわかりません。追跡システムに実行可能な問題のみが含まれている場合、問題のトリアージが早すぎている可能性があります。つまり、議論や決定はすべて失われます。そうでなければ、問題は可視性なしに繰り返し発生する可能性があるため、すべてのものを取り入れる必要があります（とにかくワークフローで）。

「リスク」のJira実装にカテゴリがあるため、Jiraを使用して、アクション可能ではないが何らかの方法でソフトウェアを危険にさらす可能性のあるアイテムを追跡しています。アイテムに関する議論が追跡され、リスクがなくなる（または軽減される）と、問題は解決します。あなたが与えた例は、リスクカテゴリに簡単に入れることができます。

このようなことが議論され、追跡され、決定が記録されることが重要です。開発者が数か月後に問題を再評価すると、「質問と回答」の回答に正当な理由があります。

私が間違っている場合は修正してください。しかし、私はあなたがそれについて話していると思います-「バグ追跡/問題追跡システムを使用して「決定追跡」も行うことができます。それは何かですか？

最初は、これは本当に素晴らしいアイデアだと思います。厳密に上記の方法で使用するわけではありませんが、追跡の目的で使用することは理にかなっています。私たちの場合、メールの長いスレッド-フォーラム/メーリングリストとしての続きです。

ただし、より広い意味での質問は、意思決定を効果的に行い（および管理し）、作業の意味を、より良い洞察をもたらす決定に戻す方法です。

私が言ったように、それが人々を助けるならば、それは素晴らしいアイデアです。それについて何も悪いことはありません。しかし、効果的に意思決定/管理を行うには、具体的なものはほとんど必要ありません。

1. ほとんどの決定は、決定に基づく前にすべての重要な側面が適切に扱われ、適切に計量されるように、幅広いベースの包括的努力であるべきであるということは事実です。したがって、どのツールを使用する場合でも、関係者全員への情報への透過的なアクセスが有効になっている必要があります。情報を伝達および収集する非同期モードは、人々が提案を出す前に時間を置くことができるので役立ちます。事前の回答を求められた場合-通常、会議で、十分な宿題をしている同じ人と比較して、判断が同等に正しくない場合があります。

2. しかし、これは必ずしもすべての票が等しい「純粋な民主主義」を意味するわけではありません。一般に、意思決定者は1人または数人である必要があります。すべての意見を取りましたが、意見を提供したすべての人ではなく、個々に意思決定の責任を負う必要があります。

3. ほとんどの決定は実行可能でなければなりません。これは矛盾を避けるのが難しいかもしれません。しかし、決定は実行可能ではなく、主観的であるという事実は、将来の（誤った）解釈の可能性があることを意味します。

4. 決定のレベルと範囲を分類することが重要です。最も重要なことは、特定の設計問題やコードの特定の側面、プロセスの側面を議論しているかどうか、またはこれらのプロジェクトが関連する問題を計画および追跡しているかどうかを識別する必要がありますか？生産コードから問題が発生する場合は非常に頻繁に発生します。これらはすべて適用可能ですが、これらの決定を効果的に管理できるように、すべての異なる側面を区別して独立できる必要があります。

5. 時には、特定のシステムを使用するか、個人の役割と責任を使用するかを決定することができます。掲示板タイプのフォーラムで特定の決定をコーディングすると同時に、これらの決定を行うのは厳しいかもしれません。

6. 追加の逸話だけ。すべてのチームは、コードレビューとデザインレビューを単独でプロセスとして配置する必要があります。これは、引用した例のような多くの問題を網羅的にカバーします。それらは、決定を追跡する決定が他の事柄を扱うかどうかに関係なくなければなりません。

優れた意思決定の実践には、情報をまとめる方法に関する多くの規律が含まれており、意思決定が正しい精神で実装されていることを確認します。

ツールは、それ以上ではなく、情報をより提示しやすくするのに役立ちます。しかし、それがあなたのために働くなら、それは良い助けかもしれません。

FogBugzがその方法です。無料ではありません。最新の機能により、アジャイル手法の実装がさらに簡単になります。

よりシンプルで自由な方法は、Asanaです。

どのツールを使用しても、プロジェクトを成功させるためにはチームのコミュニケーションが最も重要です。