プログラマの思索

チケット駆動開発を運用する上で、あった方がよいと思う運用ノウハウをプラクティスとしてピックアップしてみる。
なお、下記には、他の人のアイデアも含まれているので、引用先をリンクしておく。

【元ネタ】
脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所

チケット駆動開発のベストプラクティスを収集したい: プログラマの思索

チケット駆動開発のFAQ: プログラマの思索

チケット駆動開発 - Live a meaningful Life

チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11)

2009-09-17 gitだからこそできるチケット駆動開発のやり方- kunitの日記

チケット単位に並行開発する事例: プログラマの思索

[tech]チケット駆動開発 - Kazumi007の日記

１・チケット・ファースト(Ticket First)

プロジェクトの作業はチケットを受け取ってから始める。
作業が発生したら、まずチケットに起票してから始める。
このルールが徹底されて初めて、チケット駆動開発が始まる。

そして、チケットはXPのタスクカード(作業指示書)として扱う。
すると、チケットに作業履歴が残り、運用保守で検索しやすくなる。
進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアルタイムに進捗情報を出力できる。

チケットを成果物の単位で作ると、作業しやすくなる。
例えば、「設計書を作る」「機能Aを作る」「バグを直す」「テスト仕様書を作る」など。
つまり、チケットはWBSから作り出すこともできる。
この手法はPMBOKにも流用可能のはず。

２・チケットはシンプルに

チケットの入力項目やワークフローは必要最低限にし、シンプルにしておく。
チケットに必須項目や入力項目が多いと、開発者がチケットの更新に億劫になり、チケットに最新の状態が反映されなくなってしまう。
特にワークフローが複雑な場合、メンバーが慣れるのに時間がかかり、TiDDの威力が半減する。

リリース後のKPTによるふりかえりMTが、チケットの運用を見直すタイミングになる。
リリースをこなしながらチケットを改善していけばいい。

３・分割統治(Divide and Conquer)

プログラミングと同様に、タスクは分割して統治する発想が大事。
複雑なタスクはWBSでツリー構造に階層化したり、分割する。
この時、分割統治の観点として、チケット・イテレーション・プロジェクトの3つがあると考える。

3-1.チケットで分割統治

僕の経験では「一つの成果物を一人の担当者が１～５人日以内で完成させる作業」まで細分化するのが良いと思う。

実際は、リリース後にチケットを集計してみると、チケット1個の工数は1人日以下になっている時が多いと思う。
理由は、新規開発後のテストでバグ修正や、顧客からの問合せ(障害修正・改善要望)など、開発チームが予想していたタスクの規模を超える時が多いから。
タスクが増えすぎた場合は、小規模リリースやチケットの関連付け、他の分割統治のプラクティスで対応する。

又、遅延したチケットは作業しやすいように分割した方がいい。
例えば、機能追加のタスクなのにリファクタリングに時間がかかっているチケットは、リファクタリングと機能追加のタスクに分ける。
開発者が作業しやすいように、コミュニケーションを取りながら、臨機応変に行えばいい。

他に、GitやMercurialのような分散バージョン管理を使っているならば、2009-09-17 gitだからこそできるチケット駆動開発のやり方- kunitの日記のように、チケット単位でトピックブランチを作る運用方法もあるだろう。

3-2.イテレーションで分割統治

細分化されたチケットは、リリース計画やイテレーション計画に基づいて、各イテレーションにアサインされる。
チケット駆動開発やRedmineでは、イテレーションをリリースバージョンと同一視するため、小規模リリースを実現でき、自然にアジャイル開発になる。
チケットをどのバージョンでリリースするか、という取捨選択や、イテレーション内部でのチケットの優先順位付けがプロジェクトマネジメントそのものになる。

アジャイル開発と同様に、チケット駆動開発でも、イテレーションを上手に使うのが重要だ。
僕がよく使う手法として、バージョンと対応されない特別なイテレーションとして、「バックログ」や「内部課題」を作っている。

「バックログ」は、顧客から寄せられた改善要望のチケットを貯めるイテレーション。
例えば、リリース直後に寄せられた膨大な改善要望は、バックログに溜め込んで保留とし、障害修正など、本番運用の安定に力を注ぐ。
そして、本番運用が落ち着いたら、バックログに溜まったチケットの難易度や優先度、予定工数などを洗い出し、リリース計画を立てて、チケットを各イテレーションへアサインしていく。

つまり、「バックログ」はScrumのプロダクトバックログのように、要望を一旦受け付けてフィルタリングし、リリース計画を立てる場とする。
即ち、XPの計画ゲームをバックログのイテレーションで行っているようなものだ。

又「内部課題」は開発者から寄せられたチケットのうち、優先順位が低い作業やいつやるか未定の作業を溜め込むイテレーション。
例えば、このソースはリファクタリングした方がいいが今手を付ける必要はない、とか、だいぶ先の予定作業などの備忘録。
そして、リファクタリングした方がいい機能を修正するタイミングで、進行中のイテレーションへチケットを移動して、リファクタリングも同時に行う。
あるいは、来るべき時が来たら、チケットをイテレーションへアサインしていく。

つまり、「内部課題」は開発チームのリスク管理を行うイテレーションだ。
「内部課題」のイテレーションを備忘録として使い、作業漏れをなくす。
特に、リファクタリングが必要な箇所はファウラーが言う技術的負債そのものだから、工数見積もりのリスクに直結する。
故に、システムのリスクに直結する情報は積極的にチケットへ登録する雰囲気作りが重要だと思う。

「バックログ」も「内部課題」も終了期限の無い特別なイテレーションとして扱うのに注意。

3-3.プロジェクトで分割統治

プロジェクト単位でチケット管理する状況は、顧客からの問合せと開発のタスクを分けたい時が多いだろう。
つまり、インシデント管理と実際の開発は、BTSの複数プロジェクト機能を使って、プロジェクト単位で管理する。
この方法によって、開発チームは、開発と無関係なインシデントのチケットを意識することなく作業すればいい。

他の例としては、大規模プロジェクトで、サブチームごとにタスク管理したい場合や、サブシステムやコンポーネント(jar, dllなど)の単位でタスク管理したい場合があげられるだろう。

４・No Commit, No Ticket

TiDD提唱者のまちゅさんが「チケット無しの成果物のコミットは不可」というルールをこのプラクティスで呼んでいたので、引用させてもらった。
チケットファーストのルールに従うと、必ずコミットする時にチケットNoは存在する。
つまり、修正意図の不明なコミットを排除する意味が込められている。

このルールのおかげで、運用保守時にリバースエンジニアリングしやすくなる利点がある。

５・チケットは常時最新に

八朔さんがTiDDで最も重要だと述べたプラクティス。
チケットに登録したとしても、進捗や情報が更新されないと、BTS上で最新の進捗情報を確認できなくなる。
特に、リリース直後に問合せや障害が大量に発生して、チケットが乱発されたり、放置されたりする時に起きやすい。

だから、チケット管理の責任者が常にチケットの状況を見ておく必要がある。普通はプロジェクトリーダーがその役割を担っているだろう。
大規模プロジェクトでは、専門のチケット管理者を配置して、進捗確認させるといいだろう。
また、チケット更新やSVNコミットのタイミングで関係者へメール送信する機能を使えば、気付きやすくなる。

他に、RedmineやTracでは、活動欄でSVNリポジトリ・チケット更新・Wiki更新などの履歴が表示されるので、最新情報を見る事ができる。
故に、活動ログの活発具合が開発チームの活発度に直結するので、注意した方がいい。

６・チケットは関連付ける

八朔さんの運用方法では、チケットは、要件-成果物-作業のツリー構造で関連付けられる。
このやり方ならば、チケットをタスクカードだけでなく、ストーリーカードとして扱う事もできる。

あるいは、複雑な機能を実装するチケットを分割した場合、関連するチケットをまとめるために、Redmineの関連リンク機能を使えばいいだろう。

僕がよく使う方法は、マージ作業が発生した場合、マージ作業のチケットに発生元のチケットを関連リンクさせておく。
これによって、マージ作業の意図を関連元のチケットから理解しやすくなる利点がある。

７・小規模リリース(Small Releases)

チケット駆動開発では、リリースバージョンをXPのイテレーション、Scrumのスプリントと同一視してアジャイルに開発していく。

RedmineやMantisでは、ロードマップ画面がイテレーション計画を行う機能になる。
そして、リリースされたイテレーションに紐づくチケットは、変更履歴画面でChangeLogとして残る。
この2つの機能おかげで、BTS上でリアルタイムに進捗情報や、リリース履歴を簡単に確認できる。

８・朝会

チケット駆動開発を実践すると、自然に朝会をするようになった。
朝会でロードマップ画面を見ながら、誰がどのチケットを担当していて、進捗が遅れているなら何が問題なのか、を議論する場になる。

朝会は、コミュニケーションが始まる場であり、リスク管理を行う場でもある。

９・ペア作業

Redmineの柔軟なワークフロー機能を使っていると、チケットは必ず2人の手を経て終了するようになった。
例えば、チケットを終了できる権限はプロジェクトリーダーのみとし、彼が承認したら終了できる。
あるいは、バグ修正のチケットは、開発者とテスターが交互にステータスを更新しながら検証していく。

XPのペアプロと異なるが、1枚のチケットを2人以上の手が加えられているので、ペア作業と呼んでいる。
ペア作業の利点は、自然な品質チェックと、自然なペアプロ。

１０・ふりかえり(Retrospect)

チケット駆動開発を実践して、イテレーションをリリース後、自然にふりかえりMTを行うようになった。
KPTで行ってみると、開発者も管理者も色んな思いが出てくる。
バグが多かった、無事に終わったけれどこうすればもっと良かった、このプロセスがやりにくかった、など。
チケット集計結果を見ながらKPTすると、チケットやワークフローの運用改善のアイデアが出てきて効果的。

他にも色々あると思うので、収集してみたい。