チケット駆動開発の研究と実践

カテゴリ
ブックマーク数
このエントリーを含むはてなブックマーク はてなブックマーク - チケット駆動開発の研究と実践
このエントリーをはてなブックマークに追加
こんにちは、そろそろ花粉のシーズンが近づいてきて戦々恐々としている金子です。

今年も花粉対策グッズの CM に注目しているのですが、花粉鼻でブロックがいいんじゃないか?と思っています。

花粉症のくしゃみ鼻水は、本人が辛いのはもちろんですが周囲にとっても気分の良いものではありませんよね。エチケットとしても花粉対策は怠らないようにしたいものです。

チケットついでに今回はチケット駆動開発の話をします。想定読者は Trac をリポジトリブラウザとして利用しているがチケットは使ったことがない人です。TracIssue Tracking System という用語に馴染みのない方は、それぞれ関連リンクを用意しましたのでそちらをご覧ください。

以下、僕の経験に基づき「チケット駆動開発とは何か」「何が目的か」「どう実践したか」「結果が出たか」についてレポートします。だいたいここ二週間くらい、チームではなく個人で実験的に導入しました。

チケット駆動開発とは何か



チケット駆動開発とは、次のような仕事の進め方のことです。

  1. 仕事を細かいタスクに分割し、タスクを書き出す(チケットの発行)
  2. タスクを一つ選び、実装する
  3. 差分をコミットし、完了する(チケットのクローズ)
  4. タスクがなくなるまで、 2 ~ 3 を繰り返す
  5. タスクがなくなったら 1 へ戻って新しい仕事に取りかかる


何が目的か



目的は「タスクを分割して作業量や優先順位を正しく見積りながら仕事を進める」ことと「作業の進捗を見えやすくする」ことです。

まず一つ目ですが、僕は仕事の見積りが下手で、予想よりも時間をかけすぎてあとで困ったり、急ぎの仕事を後回しにしてあとで困ったりすることがよくありました。何故そうなるのか考えてみると、判断ミスをするときは大抵自分が何をすればいいのかわからないままに仕事に取りかかっているときだった、と思い当たりました。仕事が抽象的で大きな単位のままだと頭の中で把握しきれなくなり判断ミスをしてしまいます。そこで仕事を細かく分けて各個撃破していけば良いと考えました。

次に二つめですが、黙々とプログラムを書く日々を送っていると、全体として何をしているのかを見失うことがあります。いつまでに何がどれくらいできていれば良いのか、今までにどれくらいできているのかを把握できなければいけません。これは個人のペース配分という意味でも、チーム内の情報共有という意味でも大切です。

どう実践したか



目的を決めたら実践していきます。チケット駆動開発 … ITpro Challenge のライトニングトーク (4) のスライドでは、「チケットと無関係のコミットを禁止する」というルールに重点を置いていますが、今回は「タスクの整理」と「進捗の把握」ができれば良いのでコミット連動の自動チケットクローズができなくてもよしとします。(実際には、やろうとしたのですがコミットフックが上手く動かず自動クローズできませんでした)

チケットを発行する単位、タスクの粒度ですが、これは自分が一番やりやすいと感じる塩梅を見つけるまでいろいろ試してみます。仕事をタスクに分割するこの段階が一番大切なので、ここは手抜きをせずによく考えてチケットを作ります。ここで上手に仕事を分割できると、あとはぐっと楽になります。ちなみに僕の場合、具体例をあげると「メッセージ送受信機能」を実装するならば「送信/返信/削除/削除(一括)/受信箱一覧/受信箱一通/送信箱一覧/送信箱一通」と八個チケットを発行しています。

実装が完了したらコミットしてチケットをクローズします。完了していなくても、進捗があればコメントに追記していきます。コンポーネントは先の「メッセージ送受信機能」のように、分割前の仕事の単位で作っていきます。マイルストーンは週次の会議を設定し、進捗を報告できるようにします。すでに実装済みの部分にバグが見つかったら、バグとして別チケットを発行します。解決済みのチケットをアサインしなおすやり方も試しましたが、把握しづらいと感じたのでやめました。

結果が出たか



まだあまり日がたっていませんが、導入前に比べて自分が今なにをしているか、次に何をすべきかを正しく把握できるようになりました。現状認識がしやすくなったので、適切な判断を下してタスクを片付けられるようになり、仕事の能率がすこし上がりました。作業の最中や合間に集中力をなくしてしまい時間を無駄にすることが少なくなりました。

進捗の把握にはロードマップを利用しています。次の定例会議までにあとどれくらい進めればいいかがグラフで見えるので緊張感が生まれます。今まで何をしたかがチケットの数ではかれるので達成感があります。それも、プロジェクトの完了を待たずに、毎週、毎日小さい達成感を積み上げられます。これは嬉しい成果でした。

チームのメンバーには、ロードマップやタイムライン、未解決チケットのリストを見せて自分の進捗を説明しやすくなりました。僕は Trac の wiki 記法はあまり好きではないですが、それでもちょっとしたメモをすぐに残せるので文書化もしやすくなったと思います。

メリットばかりではなくデメリットもあります。チケットを発行するときは楽しいのですが、クローズしたりステータスを変更するときはチケットが多いほど手間がかかります。個人で数十個のチケットを扱っているうちは良くても、何人もが関わる大きなプロジェクトになるとチケットを含めた全体の開発を取り仕切る専門家が必要になります。プロジェクトマネージャのような立場の人をおくと、大きなチームでチケットを最大限活用できそうだと思いました。


以上、チケット駆動開発を試してみた過程と結果をまとめました。私の職場ではこういう風に使っているよ、という事例や、こうすればコミットフックが動くよ、というアドバイスなど、是非みなさんのご意見を聞かせてください。