私たちは MS Sharepoint を持っています -- これは、タスク リストを管理するのに悪いことばかりではありません。データは公開されており、変更や割り当てが通知されます。
Bugzilla は、管理とレポートの目的で少し簡単かもしれないと思います。優れたオープン ソース スクラム管理ツールがいくつかありますが、私は自分の政治資本の多くを使い果たしたので、今あるもの以上のものを求めることはできません。目的はお金ではなく、明らかに、私のチームには特殊なツールが多すぎるという考えです。
Bugzilla は、バグ修正以外の、より一般的なプロジェクト管理ツールとして機能しますか?
ひどくがっかりして、何か他のものをダウンロードして、より優れたプロジェクト管理ツールを求めていたらよかったのにと思いますか?
Bugzilla は優れたバグ追跡システムです。他のプロジェクト管理タスクに使用しようとしましたが、結果はそれほど優れていません. あなたの目標を念頭に置いて設計されたものを見つけることをお勧めします.
自分で試してみてください。
wush.netで月額$15のアカウントを取得し、しばらくの間自分で使用します（満足している顧客以外のビジネス関係はありません）。
Bugzillaは強力で、多くの構成オプションがあり、混乱を招く可能性があります。
私は3年前に自分が取り組んでいたプロジェクトでそれを個人的に使用しました。私にはプロジェクトマネージャーがいなくて、開発者だったので、非常に軽いオーバーヘッドシステムが必要でした。Bugzillaは私にそれをくれました。私は自分の主な目標を拡張「本番システム」として置き、それからそのポイントに到達するために依存関係を作りました。結局、160個のノードがすべて相互に依存することになりました。これは本質的に作業分解図でした。私は時間の見積もりを気にせず、他の種類のプロジェクトドキュメントを作成することも気にしませんでした。
クールな利点は、コーディング中に何かを行う必要があることに気付いた場合、それをBugzillaにポップし（セットアップ後20秒のプロセス）、依存関係として結び付けて、実行していたことに戻ることでした。
タスクを完了するたびに、依存関係の図を見て、最も外側の葉（他をブロックしたが、それ自体はブロックされなかったバグ）を見つけて、それに取り組みました。
この方法の利点は、タスクが単純に見え、1つのノードが関連付けられている場合でも、それ自体を実行すると、タスクがより複雑であることに気づき、タスクを異なるサブタスクに分割するだけであるということです。これには1分しかかからず、プロジェクトマネージャーとのミーティングはまったく必要ありませんでした。
チームの他の人々は、未解決のバグ、日付でソートされた未解決のバグなどを調べることで、私の進捗状況を追跡できました。彼らは行動を見て、私を放っておいてくれました。私が外部の依存関係を持っていたとき、私はバグを作り、仕事を詳述し、その人に電子メールでリンクを送りました。次に、依存関係の図を見ると、なぜこれが必要なのかがわかります。
以前に合意されていない限り、私は彼らにバグを割り当てなかったことに注意してください。
それは本当にうまく機能し、システムは1か月早く準備ができていました。
SCRUMとどのように連携しますか？スクラムをざっと見ただけではわかりません。しかし、それは私の経験でした。
専用ホストを使用すると、次の3つのことが可能になります。
bugzillaにはあらゆる種類のセキュリティ機能があるため、ユーザーを必要なものに簡単にロックダウンできることに注意してください。
私のスタンドアロン ソリューションは、比較的簡単に統合できる DokuWiki + MantisBT + Subversion + Review Board です。ホストされている代替手段は Bitbucket.org です。その根拠は、Wiki でユーザー ストーリーを作成し、それらの特定のタスクを参照できることです。より大きなバグは共同で設計することができ、「wiki」リンクは Mantis によるバグ レポートで提供されます。レビュー ボードを使用すると、変更がコミットされる前に、svn diff に対してピア コード レビューを行うことができます。
Trac と Subversion を使用して、いくつかのプロジェクトで成功を収めてきました。
ここでの主な利点は、管理者に情報を提供するために、スクラム固有のレポートを調整できることです。