ブログ@kaorun55

HoloLensやKinectなどのDepthセンサーを中心に書いています。

Trac と MS-Project を連携させない方が良い理由

Trac

Trac と MS-Project は連携させない方が良いと思っている。
先日、Trac のチケットを MS-Project に取り込むアドインを作ったときにおかもとさんが書いていた。

私はMS Projectでは、Tracのチケットより粒度が荒いタスクを扱うと思っているので書きました。MS Projectはマネージャに報告するためのもので、チケットは単に担当者の作業や課題を管理するためのものと。

http://tidus.ultimania.org/diary/?date=20090302#p01


僕はまた"管理"の入り口に立ったばかりなのでピンとこなかったが、あきぴーさんの記事でなんとなく見えてきた。

3-1・管理者(PL)の視点
→ストーリーカード
→フィーチャー(機能)、工程、WBS
→MS Project


3-2・開発者(PG)の視点
→タスクカード
→成果物に対する作業
→Trac/Redmine

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索


MS-Project で扱うタスクは

  • プロジェクト活動に必要なすべての作業を管理可能な単位に分割
  • 粒度は２週間分の作業が目安


Trac/Redmine で扱うチケットは

  • 担当者がひとつの区切りとしての作業単位
  • 粒度は数日以内またはバグ単位


プロジェクトによって増減するだろうけどこんなところなのではないか。
結局視点が違うので粒度も違い、それを無理して一緒にしようとすると、ひずみができる。


なので、Trac と MS-Project を連携させない方が良いということ。

改善案

あきぴーさんは Trac と MS-Project のタスクを混ぜない管理で書かれていたので、混ぜて管理するという前提で考えてみた。

それぞれのタスクをチケットの親子関係で表現できないか。

ルートのチケットに WBS のワークパッケージを置き、その下にぶら下げる形で 従来の Trac のチケットを置いていく。
進捗（というか稼働時間）管理は Trac のチケットに時間を記入することでそのトータルが親チケットに積算されていくことで管理できそう。
＃Trac だと MasterTicket ＋ Timing And Estimate ＋ α みたいなイメージ


MS-Project には親チケットのみ引き出せばマネージャ管理用として使えるし、MS-Project から Trac のタスクへとシームレスに流れそう。

まとめ

"分ける"とか"二重に"とかいったやり方は経験上（性格上）、長続きしないのでできる限りシンプルな方法になるようにしたい。
今は過渡期と思ってるのでそれでも良いかもしれないが、最終的な到達点は"だれでも"、"かんたんに"、"あきずに"できることを目指したい。


せっかくなのでこういった議論、思いのたけを出していくうちに、自ずと解が見えてきてはこないだろうか。


いろいろ試行錯誤してみても BTS という特性上、どうしても管理という面ではムリが出てくるのかもしれない。
そういう意味では Trac/Redmine とは違った、上流工程も含んだ第三勢力が出てくることにも期待したい。



＃個人的にはこの２つの違いと歩み寄りをゆーじさんがどう考えているのか、非常に興味があります:)

参考サイト