2012-01-09 72 views
2

FogBugzのケースでは、どのような種類の情報が必要なのか、私が働いているところで議論してきました。私は、新しいバグを作成したとき、または既存のケースで編集を押したときに、 "Opened by"テキストのすぐ下にある大きなフリーテキストフィールドについて話しています。FogBugzのケースにはどのような情報を入れるべきですか?

たとえば、バグの詳細な説明がそこに属していることに同意します。最初にバグを作成するときには、その説明を挿入します。しかし、後の編集では、そこに置くことができる/できなければならない情報のタイプは何ですか?

私たちがすべて同意しない最大の問題は、デザインの議論がそこに属しているかどうかということです。このような何か:

FEATURE 714 
    Opened by 'Person A' 
    We need to provide a user with the ability to quiggle-fy the doodad. 

    Edited by 'Person B' 
    Do you think this will involve changing the crabbadonk interface as well? 

    Edited by 'Person C' 
    No, the crabbadonk is already quiggle-fied. 

私たちは皆、どのような人Aが言ったことが属していることを同意するが、私たちは人Bと人物Cの間の会話が同様にそこにあるようにするために、それは理にかなっているかどうかわかりません。

他の会社は何をしていますか?そこにはどんな種類の情報が属しているかについて一般に認められている原則はありますか? FogBugzの方がいいですか?または、それに使用する別のツールがありますか? FogBugzのために

+0

多くの人がFogBugzよりツール_other_を使用しているので、この質問を一般的なバグ追跡ソフトウェアに一般的に適用できるようにすることができれば幸いです。 – cdeszaq

+0

私はそれについて考えましたが、これは他のバグ追跡ソフトウェアには必ず当てはまるとは確信していません。たとえば、私の以前の仕事では、Mantisを使用しました。 Mantisには説明フィールドがあり、この種のものが属していることがより明白だと私は思う。 Mantisは、フィーチャー/バグの説明とそのディスカッションをより詳細に示しています。しかし、あなたは正しいかもしれません。 「バグ追跡ソフトウェアには機能設計に関する議論が含まれていますか?」というより一般的な質問があります。 – rbwhitaker

+0

私はJira、Trac、Bugzillaについて、最初の記述やコメントのためにすべて同じ大きなテキスト領域を持つことをもっと考えていました。 – cdeszaq

答えて

1

は、ここで私は私のプロジェクトでやりたいものです:

  1. ディスカッションは、エンド設計を実装するためのWiki
  2. でタスクを行くべき
  3. ディスカッションボードに行く必要がありますデザインは、これは、彼らが最高の仕事の方法で様々な「形式」を使用する利点があり、またたくさん Oを提供例

なされるべきです柔軟性。物事の間を行き来できるようにする必要がある場合は、これを簡単にするプラグインが既にあります。また、自分で作成することも難しくありません(bugmonkeyスクリプトまたはプラグインとして)。

+0

私はその組織が理論的には好きですが、私たちはディスカッション掲示板やwikiを持っていません(もちろん、FogBugzがwikiを提供しても、完全に使用されていません)。私はそれを実現させる強い影響力を持っていません。しかし、そういうわけで、「設計上の議論はバグ/フィーチャートラッキングソフトウェアに入りません」という一般的なルールに従っているか、それとも従っていますか? – rbwhitaker

+0

並べ替えそれは手元の問題の範囲と規模に依存します。小さな小さなもの、特に1人のデザイナーと1人の開発者の間で取り組まれているものは、ケース自体の中でちょっと繰り返すかもしれませんが、カップル以上のものになるか、特定の詳細以上です(例えば。2つ以上の特定のケースに影響を及ぼす可能性がある場合)、他の場所で処理されます。 – cdeszaq

関連する問題