BTSを導入する場合の経験談色々

Daichi @normalian

Trac派かRedmine派かって、なんとなくPython派かRuby派かなだけのイメージがあるけど、違うのかな？

Daichi @normalian

個人的にTrac派、理由はTracLightningが有るからの一択

なやみ雑用屋の奇蹟 @LightningX

Redmineを使ったことありますが、使いやすいWikiとレポートのカスタマイズ性の高さでTracがいいですね。RT @normalian Trac派かRedmine派かって、なんとなくPython派かRuby派かなだけのイメージがあるけど、違うのかな？

なやみ雑用屋の奇蹟 @LightningX

WindowsならTracが楽ですが、Linux上で構築したいのであればRedmineの方が最初から色々入っているので環境構築が楽だと思います。Ruby/PythonよりLinuxかWindowsかで選択している人が多いような気はします。

Daichi @normalian

@LightningX TracWikiは使いやすいですね、アレで大分ノウハウをまとめました。BTS系は環境構築＆運用ノウハウを継承させるのが大変なのですが、Trac以外はTrac Lightning的なものがないので、人に進めるときはTrac一択ですねー

wyukawa @wyukawa

Tracだと工程別にマイルストーン切ったりするかなあ。＞TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索 http://bit.ly/dQafMg

wyukawa @wyukawa

パッケージ開発のときはリリースごとにマイルストーン切ってたかな。例えばバージョンとして3.0があって、QAに渡すタイミングでv3.0-IR-01みたいな内部リリース用タグ打ってマイルストーンも同名にする感じだったかな。

wyukawa @wyukawa

チケットを運用すんのって難しいよな。俺も一人プロジェクトとか自分がPMの小規模少数精鋭プロジェクトなら運用できるんだが、そうでないと難しい。一回自分が応援という立場で入ったプロジェクトで軽く提案してみたら面倒くさい人だと思われたので、それ以来自分から提案することは無くなったな。

Naoki Takezoe @takezoen

うちは毎月とか期間で切ってます。 RT @wyukawa: Tracだと工程別にマイルストーン切ったりするかなあ。＞TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索 http://bit.ly/dQafMg

なやみ雑用屋の奇蹟 @LightningX

@normalian そう言っていただけるとありがたいです。

wyukawa @wyukawa

ま、大規模プロジェクト（に限らないか？）だとPM、リーダ層の意識をあわせてトップダウンで運用しないとチケットは難しいよね。だから導入の順序としては、SVN→リポジトリブラウザ→wiki→チケット→マイルストーン、バージョン→プラグイン導入等のカスタマイズって感じかな。

wyukawa @wyukawa

@takezoen 期間かあ。その観点は無かった。スクラムっぽいですね。

なやみ雑用屋の奇蹟 @LightningX

@wyukawa 私の場合は、新しい担当に異動になった場合は、まずWikiを導入。Wiki似なれたら次に問題・課題管理をチケット、製造フェーズになったらSubversionを利用。バグは政治的な事情で利用しませんが、運用フェーズのインシデントとバグはチケットでみたいな感じです。

なやみ雑用屋の奇蹟 @LightningX

一気に全部導入しようとせずに、段階的に導入するのは失敗しないコツかと。

Naoki Takezoe @takezoen

最初はアジャイルプロジェクトでイテレーション毎にマイルストーンを切っていたのですが、それが運用しやすかったので自然とそういう感じでやるようになりました。 RT @wyukawa: @takezoen 期間かあ。その観点は無かった。スクラムっぽいですね。

なやみ雑用屋の奇蹟 @LightningX

ちなみに、タスク管理はMS Projectですね。

なやみ雑用屋の奇蹟 @LightningX

経験上、既にプロセスが確立されているところは手をつけずに確立されていないところから改善するのがよさそうです。RT @wyukawa 一回自分が応援という立場で入ったプロジェクトで軽く提案してみたら面倒くさい人だと思われたので、それ以来自分から提案することは無くなったな。

なやみ雑用屋の奇蹟 @LightningX

確立されているプロジェクトを変えるのは激しい抵抗にあうので、確立されていない部分を改善しながらチケットの便利さを知ってもらって、ほら、これって○○にも××にも使えるでしょって感じで。

wyukawa @wyukawa

@takezoen なるほど。期間固定というのは良さそうですね。スコープが可変という条件もつきそうですが、その辺は受託、自社製品開発等のプロジェクトのコンテキスト次第か。

Daichi @normalian

その通り過ぎる… RT @LightningX: 確立されているプロジェクトを変えるのは激しい抵抗にあうので、確立されていない部分を改善しながらチケットの便利さを知ってもらって、ほら、これって○○にも××にも使えるでしょって感じで。

wyukawa @wyukawa

@LightningX なるほど。バグ管理としてのチケットのほうがやりやすそうですけどね。

なやみ雑用屋の奇蹟 @LightningX

×プロジェクト ○プロセス RT @LightningX 確立されているプロジェクトを変えるのは激しい抵抗にあうので

wyukawa @wyukawa

@LightningX なるほど。あのときプロセスが確立されているようには見えなかったが実はされていたのかもしれないw

なやみ雑用屋の奇蹟 @LightningX

@wyukawa それなりの規模のベンダだと、品質管理ツールとか標準で持ってません? 標準で決まっている部分への適用は難しいですね...

なやみ雑用屋の奇蹟 @LightningX

@wyukawa プロセスが正しいかどうかは関係なく、彼らにとっては手順が確立されていて、その通りやることが重要。だから抵抗に合います。多分。