meeting/04.5/PanelDiscussion - Shibuya.trac Wiki - Shibuya.trac

Shibuya.trac 第 4.5 回勉強会 パネルディスカッション：TiDDのふりかえり

パネラーが下記のようなKPTの観点で経験談を話して、パネルディスカッションを行った。

良かったこと：TiDDを実践して良かった事、変化したこと。

問題点、課題、苦労話：TiDDの課題。問題点。苦労した経験談。

これから試したいこと：TiDDでこれから試したいこと。TiDDの可能性を探る。

パネラー： あきぴーさん A、まちゅさん M 、Oかもとさん O、はっさくさん H、こえださん K、かおるんさん。自己紹介。

UStreamの動画： shibuya.trac meeting 4.5 09/11/09 19:00-21:15(JST)(1:45～2:00の時間帯)

良かったこと

O チケット駆動開発してない…。社内標準でツール決まっちゃうとやりにくいから打破したい。

K 仕様は数えられると品質が上がる。仕様がチケットになると上がるのでは。品質保証部門と開発部門の対立をやわらげる道具として期待。ウオーターフォールではできたものをテストするが、チケット駆動開発では最初からテスターが入るのがよい。

M エクセルがたいへんだった。それを自動化するので楽になった。他の人の作業がみえるようになった。

A 開発者や若い人がやりやすい。リーダーにはうけがわるい。イテレーションのリズムができるのがよい。永遠に続く開発ではなく、頻繁にリリースのタイミングなどの区切りがある。

H 機能ごとに設計書を一覧にしてた。それに付箋をつけてタスクにしてた。数えるのが大変。Redmine で管理すると見やすいので良かった。

問題点、課題、苦労話

O TracLightning ではチケットでやろうとしたがめんどくさくなってやってない。

K 一人でやってると、誰が入れた問題なのかわからなくなる（全部自分が入れるから）。全体に浸透させないと行けない。

M 入力面倒。出力が貧弱。

A 要件管理がしにくい。

H チケットの粒度問題。PM はタスクは 80 時間で作る。でも現場はもっと短い。お互いにわかり合う必要がある。

これから試したいこと

O まだ知名度がない。上の人が決めるから、もっとチケット駆動開発を有名にしていきたい。

K 集計をもっとしっかり。上司に情報をはっしんできるようなものがいる。

M ソースコードのレビューをしたい。

A 現場の意志決定者の意志決定支援ツールにしたい。いろんなツールから情報を集め、統計などをとったりして、意志決定に必要な情報をだせるようにしたい。コンサルとかやりたい。

H 上司に紹介するようなのを出力したい。上司を納得させられれば広げやすい。そういうのを作ってみたい。TracLightning で。

しつもーん

ソースレビューは Redmine のプラグインであるよ。でも、現場で顔合わせてやった方が効率的なので、あまり使わない。Trac にもあって、TracLightning だとすぐできるよ。

テスターに聞いた。エクセルから乗り換えるメリットがまったく見つからない。項目内容が俯瞰しにくい。レスポンスが悪い。

A エクセルは集計が大変。一日作業してもらった結果を受け取ったらマネージャが残業で集計。TestLink はそれが楽。

H TestLink はインポートが面倒。エクセルで、TestLink にあうような形で作り、マクロで一括インポート。

M 同じテストケースで繰り返しをやるとき、前のバージョンでのテストの比較の集計とかがやりやすい。

デザイナー、コーダー等関連者がたくさんいて、チケットをわけるとディレクターがおいづらい。親子関係が見づらい。複数人で並行してやりたいときはどうすれば？

M ワークフローを決めて、ひとつのチケットでやる。

A チケットを細かくする場合は、関連チケットのリンクを作っておく。関連チケットで確認する。

デザイナーの方はチケットをつかいたがらないのは？

H ツールを拒絶される。

Trac でチケットが登録されたとき、チケットの状況は見ないとわからない。レポートみたいなのをメールでとばしたい。

H 朝会で進捗確認をするのはよくある。10日の予定で8日経ったとき、あと何日でできる？ときく。 2日といわれたら予定通り、3日といわれたら遅れている。

A メールは見なくなるからダメ。基本は RSS で見ながらやる。でも朝会は重要。コミュニケーションはちゃんととろう。 ワークフローや運用は改善できるので、ツールありきではなく人と人でやっていこう。