読者です 読者をやめる 読者になる 読者になる

Natural Software

KinectなどのDepthセンサーを中心に活動しています

Shibuya.trac 第12回勉強会 〜 チケット管理システム大決戦 第二弾 〜 に行ってきました #shibutra

Trac 勉強会

6月30日 Shibuya.trac 第12回勉強会 【通常枠】(東京都)
みなさん、ありがとうございました。


対決の内容は置いといて、対決の意味はこんなとこかなーと感じました。

を受けて、

自分の中での、各ツール比較

今日の話の内容と、自分の今までの経験から、各ツールの使いどころを考えてみました。自分が使ってるまたは、使おうとしていうツールも、おまけでつけてみました。
あくまでも僕の考えです

Trac
  • 数人〜数十人のチーム、組織
  • プロジェクト間の連携が必要ない
    • Tracは、複数プロジェクトに対応しているが、複数プロジェクト間の連携には対応していない
  • プロジェクトの物理的な移動が発生する
    • 自社内とお客さん先での作業をいったりきたりする場合。プロジェクトが独立しているTracは、プロジェクトフォルダごと移動すればOK。プロジェクトを跨いで一意にデータベースが作成されるRedmineにはできない。
Redmine
JIRA
  • 数人〜数千のチーム、組織
  • 実業務であれば"予算が許せば"、一番人気
Backlog
  • 数人〜数十人のチーム、組織
  • 機能横断チーム(デベロッパーやデザイナーなどの混成)
  • ベースはTracなのだと思っている
Microsoft Team Foundation Server
  • 数人〜数千人のチーム、組織
  • Windows アプリケーションの開発であれば、ほぼ一択
  • Eclipseからも利用できるので、Javaなどの開発者でも利用できるが、ベースはWindowsアプリケーションの開発者になると思う
Excel

まとめ

ツールの得意、不得意を理解して、自分たちのチーム、組織に合ったツールを選ぶことが大切なんだと思います。
第二部のプロセス(使い方)が対決にならなかった通り、考え方はみんな似通っていて、それを元に自分たちの環境にあったツールを使っているのだと思います。

おまけ・2

原田さんの一言(意訳)
"WBS進捗管理のためのものじゃない。工程を確認するものである。WBSからガントチャートに分けるのは、使い方が違うため、たいていの場合に失敗する"

おまけ・3

当日の資料やモデレータのRyuzeeさんのまとめはこちら

テーマ1・使ってるツールの良いところ、悪いところ

テーマ2・開発プロセスへどのようにツールを適応させているか