2008年10月18日土曜日

Shibuya.trac勉強会0.11に参加してきた

初めてShibuya.tracの勉強会に参加してきた。Tracは社内でも随分使っていて、customフィールドとかで色々やったりはするものの、プラグインを作るきっかけが中々自分の中に生まれない、といった事もあるし、他の人の使用例とかその感想とかも聞ければいいなーと。あと、TestLinkについての話も出るようだったのも大きかった。
会場は株式会社豆蔵様のトレーニングリームで行われた。すばらしい会場をありがとうございました!かぬさんのあいさつの中の話によると、最初はカンファレンスの予定だったものを勉強会に格下げ、しかし47人も集まった、という背景があったらすぃ。

打倒!スーツ(笑)のおやじたちTracLightning 社内標準化までの道のり(かおるんさん)

  • 社内標準となるまでの手順とか
    • まずは自分で使う
    • チームメンバを巻き込む。社内勉強会やったりとか。マネージャに紹介とか。
    • 実案件で試験導入するとか、徐々に勢力を拡大する。業務用の勉強会とか。
    • 最後の業務用の勉強会をやっている時に、社長が気に入って導入が確定。
  • お客さんに見せるためにも使用している
  • 今後の課題
    • サーバがPCサーバなので、その信頼性の向上(15プロジェクト?ほどが一台に乗っている)
    • バックアップ体制の強化
    • 設計、テスト工程にも適用する?
      • UMLツールとしてEnterprise Archtectureを使用しているのでそれをSVNと連携
      • TestLinkとの連携
      • CIツールも使って、ラクに管理しつつ品質も確保して行きたい
  • [Q]社長が気に入った点とは?→[A]WikiやTicketを使ったコミュニケーションとか。バージョン管理とか。お客さんにも見せられる事も気に入ったのだと想像してる。
  • [Q]運用ルールとか決めてやっているか?→[A]ソースを弄る前に必ずTicketを発行するとか。まずは使ってみるという事で、その程度しか決めていない。
  • [Q]Tracを教育する対象となる新人のレベルは?→[A]プログラミング経験も無いしろうとさん。
導入の手順は自分とまったく同じだし、この後の発表でも同様の話があった。皆同じなんだなぁ、とおもしろかった。
自分的に興味を持ったのは「お客さんに見せる(プロジェクト状態の社外への可視化)」という点と、「ソースコードのコミット単位でticketが存在する(小さい単位でのticket)」という点の2点。自分が使って困っているのは、Ticketの単位が細かくなりすぎると、ソースを触る事がない立場の人が見た時に、ticketの意味がわからなくなってしまうという事。そういう意味では自分的には同居する事ができない2点なんだけど、何か便利な運用をしているのかな?マイルストーンをうまく使っているとか、何か運用で工夫しているのか、ticketの内容までは興味を持たずにスルーさせるのか?

Trac入門執筆うらばなし(すがのさんこんどうさん)

  • どんなスケジュールだったか、苦労したか、とか。
  • 各フェーズで役に立ったサービス色々を紹介
    • PDF X Change Viewer
実は、この白本は一度本屋で手に取ったものの「プラグインの作成方法が書いてない」という事で買わずに帰った経緯があるんです、すいません。でも、自分のTracに対する知識を…という方向ではなく「Tracを導入させる手段を知る」という意味で役に立つかもしれない!と思った。そして、帰りにその本屋へ行ったら、赤本しか残っていなかった><
PDF X Change Viewerは、まさに自分が探していたサービス!これの話の印象が強すぎた。他のサービスは結構使っているものばかりだったし、まぁおk。
欲しいプラグインとして案が上がった「更新が滞っているTicketのAlert」は、確かにあると便利だと思う。0.11なら、ワークフローの中に「滞ってるよ」みたいなものを作って、定期バッチで対象Ticketのフローをそこへ自動的に遷移させる。Tracのトップページにその一覧を常に表示…とかでもいいかも。

自作プラグインの紹介とか(hirobeさん)

  • WL Writer Plugin。Windows Live WriterでWikiの編集を出来るようにする。XML-RPCを使ったプラグイン。
  • Query Chartプラグイン。Ticketのバーンダウンチャートを表示する。Wikiのマクロとして作成しているので、Wikiが使えるページならどこでも使う事が出来る。
  • プラグインを作るのもいいけど、まずはTracのソースを直接書き換える方が早いし、それからプラグインをやるというプロセスでもいい。

TracとTestLinkの合わせ技(川西さん)

  • TestLinkの実績が増えてきた。中国でも増えてきている。
  • Test要件の管理もできる
  • WordやExcelでの出力もできる。
  • TestLinkのデモ
  • Trac+TestLinkの話
    • テストをTestLinkで管理しても、バグをExcelで管理していたのでは意味が無い
    • Testケースとバグの連携
    • TracのTicketの状態遷移がTestLinkからも確認できる
  • TestLinkの今後
    • 要件管理のプラグインを作成したい
    • XP,リーンのストーリー、SCRUMのプロダクトバックログ→要件
    • SCRUMのスプリントログ→Ticket
  • [Q]テスト失敗の報告と同時にTracのTicketが自動登録に上がったら便利ですよね?→[A]次のバージョンでXMLRPCが仕様できるようになり、その次のバージョンでプラグインを作成できるようになる。
  • [Q]TestLinkの日本語化について。色んな言語が混在している現場では?→[A]ユーザ毎に言語を設定できる
チュートリアルっぽいデモがあったのは非常に良かった。
要件をTestLink側で管理するという点については、いいかもしれない。Tracには小さいTicketのみ、TestLink側で要件とそれを構成するTracのTicketを結んでくれるなら、それはTicketの粒度で悩んでいる自分へのひとつの回答かもしれない。
テスト計画については、システムの手順を順にした計画を作ればオペレータの教育計画としても使えるかも?と思った。

Tracでバグ収束曲線?(yuroyoroさん)

  • ある日「バグ収束曲線を出せ」と言われたところから始まった
  • TracのDBからcronでCSV出力して対応。しかし手動でCSVをExcelに貼付けるのが面倒。しかもサーバがたまに落ちていて、スクリプトが動作していないとかもあった。
  • そこでTicketMetricsプラグイン!→0.11でしか動作しない。使っているのは0.10.4。
  • QueryChartマクロ!→0.11
  • 作ることにした
    • デモとか
    • Excelでは出ません→Excelにはっちゃえばイーンダヨ!
    • グラフにはFusionChartというFlashベースのグラフコンポーネントを使っている。XMLでデータを渡す。
    • TracのTicketのレコードの持ち方のためにSQLで苦戦した。
ここまでの発表者も含めて皆が皆「スーツ相手にはExcelとグラフを出しておけばイーンダヨ」みたいな話でワロタ。自分もそう思ってるけどw
グラフというと「Hudson+Mavenによる各種レポート」も結構いけますよー!

職場で使えるドラクエ呪文(okamotoさん)

  • 難易度1: アストロン、ラリホー
  • 難易度2: トヘロス、ルカナン、マホトーン
  • 難易度3: マヌーサ
  • 難易度4: マホカンタ、イオナズン、メガンテ、パルプンテ、ザラキ、ラナルータ
  • 難易度5: ミナデイン、バシルーラ
あまりドラクエの呪文とかわからないので、難易度だけをメモった。呪文の意味をしっている方であれば、対応するIT的手法と効果はおそらく想像できる通り。ただ、副作用にはご注意といぅ事で、詳細は公開されるであろうスライドにて確認すると良いと思う。とりあえずは、TracLightningで大変助かっております、ありがとうございます。

プラグインを改造してみる(akihiroxさん)

  • かぬさんのTDD(他人のふんどし DE Development)を実践!
  • 組み立てラインのシステムの寿命は10年。システムサポートもエンドレス。問題、改善要求もドンドン!
  • 現実的にBTSなしではやっていけない
  • そんなウチに、中には使い込んでいくプラグインもある
  • よろしい、ならば改造だ!
  • ファイルを探して、ソースを変更し、eggにして、installすりゃー動きます。
  • 自分の環境は、自分で改善して行こう!で、幸せなループに入ろう!
自分に取っては偉大なプレゼンとなった。ここまで「結構プラグインもさわれそうだな」と思わせたのはスゴイ。

Silverlight2でつくるリッチなTrac用UI(zoetropeさん)

  • UIをリッチに!
    • Ticketの操作や編集を便利に
    • グラフで可視化
  • XMLRPCで通信
  • wikiマクロとして作成
  • 機能は募集中!
これを見て、WEBでやる意味があるか?という、プラグインに対する一歩引いた視点を持てた。

時間があれば事例紹介(u-zさん)

  • 社内システムが嫌い。外部に向けたAPIが無いとか、項目の追加ができないとか。
  • Trac月を発見した。
  • が、CMMIレベル2を取得するためにSVNやTicketのトレーサビリティの確保などの課題が。
  • Tracで見える化
    • 必ずExcelで出力する必要があった
    • Pythonとかわからんし、WEBはあきらめてできるトコからやる
    項目の変化等をトレースする必要がある。
  • ソースのコミット量を測る→あんまりまじめにやってない人がいると…
  • バーンンダウンチャート→どうやって完了したのか?がわからない。例えば、メチャクチャ残業してこなしたのか、とか。
  • 改良バーンダウン→時間の記録もする事で、かなり見えるようになった。
  • まだまだ改良する。
  • Ticketの更新漏れとかが悩み。
自分の中では最も感心したプレゼンだった。そして「やっぱ無理にTrac側に色々組み込む必要は無いんだなー」と思った。

懇親会

JJUGCCCの時と同様に、風邪で体調がイマイチなので自重。しかし、いくつか心配が。川口さん交流会でご一緒した方に異変が見られたのだ。
  • 参加予定だったさぼてん先生が体調不良で不参加。
  • yuroyoroさんも風邪気味との事
…15日の川口さん交流会で俺がうつしてしまったのか!?

Tracプラグインについて感想

今回の勉強会に参加する事で「プラグインを作れそうだ!(難易度的な話)」「作ってみよう!(多数の方が作っているという事実がわかってのモチベーション的な話)」と感じた。だが一歩引いて考えてみると、同時に「Tracプラグインは作る必要が無いな」とも感じて、結局それが結論となりそうだ。例えばTimeTrackingのためのWEBサービスであるSlimTimerのクライアントはAIRで存在する(自分は最初の頃にAS3とSlimTimerAPIの通信部分を少しやっただけw)。TracのTicketの編集だって普段はMylynを使って便利に運用している(ソースコードとTicketの関連づけとか、手放せない)。つまり何も、無理に色々WEB上でやる必要はちっとも無いワケで、デスクトップアプリで問題無い。TestLinkもそうだ。TestLinkとTracのそれぞれにプラグイン云々するんじゃなくて、AIRで素のTestLinkと素のTracをマッシュアップすれば良い、自分の中ではそういう結論に達した。

Shibuya.trac的な感想

MylynとTracの連携が便利だよー的な話であれば、15分程度の発表ができるかもしれない。案外使っていない人も多いのか?とか思ったので(Javaでない人も多かったから当たり前だけど)。
無線LAN、プロジェクタ系、ホワイトボードはもちろん、Ustの環境(スピーカーとスライド)も整備済みのOSSや非営利コミュニティ向けの会議室の貸し出しをどこかの豪儀な会社がやってくれんかな?とか思ったりもした。広告になるんじゃないですか?ちなみに、来月に引っ越す先のマンションには小規模な会議室の貸し出しがあるようで、使い勝手が気になる。

0 件のコメント: