チケット駆動開発は仕事をさばく仕組み #agileto2010 #tidd

10/30に行われたAgileTourOsakaのライトニングトークスで、@kami_teruさんのLTがとても興味深かったのでメモ。
下記のUstreamで見れます。

【元ネタ】
AgileTourOsaka2010 LT, Recorded on 10/10/30 tetsu_m on USTREAM. 会議

Atsuteru Kamiya (kami_teru) on Twitter

「チケット駆動開発をやってみて」というタイトルで、@kami_teruさんのチケット駆動開発の導入経験談。
率直な感想は、とても面白いし、とても興味深かった。

@kami_teruさんによれば、XP祭り関西2010のチケット駆動開発セッションを聞いたのが、Redmineによるチケット駆動開発をやるきっかけだったとのこと。
詳細は上記のUstreamを見て頂きたい。僕が興味を惹いたのは2つ。

一つは、いきなりチケット駆動開発を導入するのではなく、小さく始めること。
彼の話を聞くと、現場リーダーらしく現場への導入方法がうまいなあと思った。

まず、RedmineをToDo管理としてメンバーに使ってもらって、慣れてもらった。
そして、コードレビュープラグインを入れて、コードレビューに使ってもらった。

r-labs - Code Review - Redmine

コードレビュープラグインによる生産性はとても高かった、という指摘が興味深い。

更に、作業工数もお願いして入れてもらって、2週間後には、必ず工数を入れないと実績として扱わないと強権発動した(笑)、とのこと。

最後は、チケットで全てのタスク管理やイテレーション管理、SCM連携、カテゴリ別のチケット集計、バックログのチケット化など、手を変え品を変えて現場にチケット駆動開発を導入していった、とのこと。
それらの導入も、理由があって意図的に少しずつ運用を始めた、と彼が話している途中で切れてしまったので、個人的には、運用を始めた理由や意図を詳しく聞きたかった。

Redmineだけでなく、TracやJiraなどでチケット駆動開発を導入しようと考えている現場リーダーには、とてもよい参考例になると思う。

もう一つは、チケット駆動開発で仕事をさばく仕組みができたこと。
彼の話によれば、突然の仕様変更やバグ修正が来てもう無理だと思った時に、上記のチケット駆動開発の環境が揃っていたので、SEがチケットに優先度と期限を付けてくれていた。
だから、メンバーはそのチケットに従って作業をこなせば良かったから、最終的には20日間で約170枚のチケットを全て完了させたらしい。

場所や人にとらわれず、チームが自律的に仕事をさばく仕組みができた、とのこと。
これはまさに、ScrumやリーンSW開発の自己組織化そのものだ。

彼のチームは7人で、うち3人も新卒がいたらしく、大変だっただろうと思う。
でも、彼の会社の方も来られていて、懇親会などで話を聞いたら、チケットでタスク管理するのはすぐに慣れて、むしろチケット無しでやるのは考えられないという感想を話していた。
新人の女性にもチケット駆動開発の感想を聞いたら、タスクをチケットに起票してから始める(チケットファースト)や、ソースのコミットログにチケットNoを書く(No Ticket, No Commit)運用ルールは既に習慣となっているらしく、それほど難しくなかったです、と言っていた。
他の普通のプロジェクトがどんなルールでやっているか分かりませんけど、と言っていた。

良い習慣を身に付けた開発者は品質の良いプログラムが書けるようになるはずだから、彼女は今後も成長するだろうなと思う。
PSP(Personal Software Process)では自分の作業記録を残しながら、自分の作業を改善していく手法を取るけど、そのやり方に何となく似ている気がする。
チケットに作業履歴を残す習慣があれば、他人と情報共有できるだけでなく、自分自身の作業を振り返る時にチケットが役立つだろうから。

僕個人の経験では、30代以上ですでに自分のやり方を持っていて、Excelで管理するのが大好きな人には、チケット駆動開発に拒否反応を起こす。むしろ新人や若手の方がスムーズに導入できるし、SEやマネージャよりもプログラムをガンガン書く開発者の方がチケット駆動開発に慣れてくれる。

こういうチケット駆動開発の事例がもっと増えると、プラクティスやアンチパターンなども共有できてくるので面白いと思う。