チケット駆動開発の使い道 #tidd

チケット駆動開発を運用した記事を見つけたのでメモ。

【元ネタ1】
チケットドリブン拡大中 - ついついネット

Redmineによるチケット駆動開発を社内のタスク管理、ToDo管理や営業の管理などに使っているようだ。
面白いと思ったのは2点ある。
一つは、チケットファースト(チケットがトリガーとなって仕事を行う)を徹底すると、部下は上司の横暴に対向できる口実が出来ること。
仕事を依頼される側でチケットがあふれれば、オーバーワークになり、進捗が滞り、ミスが増えてしまうのは当然だ。

(引用開始)
逆にチケットが無いと受けない。口頭で仕事をしない。これを徹底する（ちょっとコピーとって・・くらいは口頭で。量が「ちょっと」でないときはチケットを）。
これは非常に重要なポイントで、部下が上司に対して「チケットが無いと受けません」とは言いにくいのが普通だろう。これを最初に全員に理解してもらい、部下は「受けません」と言ってよく、言われた上司は言い訳無用で改めることを徹底してもらう。どうしても逼迫している仕事があったりしてチケットを発行できないケースもあるだろうから、杓子定規の話しではなく「代わりに部下がチケットを発行する」ことを許可する。ただし簡易な依頼のみに限定する。チケットの良いところは、「口頭依頼だと、忘れ／伝言ミス／解釈ミスが起こる」ことを排除する目的もあるからだ。
受ける側が切るチケットが多すぎるようであれば、依頼する側がオーバーワークになっているということなので、業務／体制を見直す必要がある。そのような状態では、ミスが多発することは自明の理だ。
(引用終了)

もう一つは、チケットを通じてコミュニケーションの品質が上がり、それによって仕事の調整がやりやすくなること。

(引用開始)
コミュニケーションが減るというデメリットがあるかも知れないが、それは逆だ。
コミュニケーションのために双方が同じ時間を空けなければならなかったり、力関係があるだろうから、弱い側が今どんなに忙しくても、強い側が手を止めさせて仕事を頼むといった、受ける側のストレスが減る。チケットで概要は互いに解っているので、コミュニケーションするにも要点のみに絞れて効率がよい（コミュニケーションが必要だった部分はチケットの発行の仕方に工夫の余地があることを示唆している）。
効率があがった分、建設的なコミュニケーションの時間を増やせばよい。というか時間の調整、言いまつがい、聞きまつがい（これは糸井重里さんの絶妙な言葉だ）による仕事のバックデートが減るので、必然的にそうなってゆく。
小さな会社ほど、口頭で作業が進んでいると思うので、ちょっとの労力をかけることで多大なメリットがある。
(引用終了)

バックデート(backdate)とは、スケジュールを後から変更する行為を指す。
駄目なプロジェクトでは、発行したタスクの見積もりが甘く、作業するほど漏れを見つけては手直しして、当初の期限をはるかにオーバーしてしまう。
チケット駆動ならば、最初にゴールを決めたものの、当初よりも工数が膨らむならば、チケットを分割して複数人で並行作業できるように調整すればいい。
PMBOKで言うファストトラッキング(Fast Tracking)やクラッシング(Crashing)をチケット管理で自然に行えるのがチケット駆動開発の強みだ。

【元ネタ2】
チケット管理ツールを比較 - 掘った穴に入るのはオイラか？ - Yahoo!ブログ

開発案件にRedmine又はTracを導入して、チケット駆動開発を実践した感想が述べられている。
WF型開発の場合、設計→開発までは順調に進むが、結合テスト→総合テスト→受入テストで障害管理していく時にMS Projectではプロジェクト管理が力不足という点は、TiDDを実践している人なら当たり前だろう。

(引用開始)
2年前、Tracというツールを使おうと準備していたのだが、今一つ使い方がわからず、断念した。
折しもその頃は、社内でMSProjectで管理しましょう！という風潮であり、ガントチャートメインの開発管理スタイルを勧めていた。
MSProjectはどういうツールかというと、1つの仕事に人と期間が割り当てられ、仕事同士の時間的な関連を見やすくしたツールだ。
この特徴は。順次進める仕事A,B,Cがあり、Aが遅延した場合、自動的にB,Cの着手、終了日が変化するといったシステムだ。
年単位の長期間で詳細な計画を立てる場合、計画実行中の遅延を瞬時にガントチャートに反映できる点はとても有益だ。これをTracでやろうとした場合、管理工数が増えるばかりのため、採用を止めてしまった。
しかし、いつも悩むのが開発の後半。不具合対応がメインとなる後半戦を、ガントチャートで管理するのは無謀だ。結局、Accessで作成した不具合管理票と、Excelの課題進捗管理表での管理となる。
(引用終了)

興味深いのは、RedmineよりもTracの方が使いやすいという指摘。
特に、Tracの強力なチケット集計機能に魅力があるとのこと。
確かに、複雑なSQLを書くスキルがあれば、RedmineよりもTracの方が各種レポートを自分で簡単に作ることができる。
マネージャならば、チケットに貯められた情報を週1回は色んな観点で集計して、進捗や品質の改善対策に役立てたいものだ。

チケット駆動開発の事例についてもっと集めてみたい。