プログラマの思索

チケット駆動開発(TiDD)について考えていることを書く。

※注意：チケット駆動開発(Ticket Driven Develpment)の略語は、「TDD」だとテスト駆動開発(Test Driven Develpment)と間違えやすいので、「TiDD」と以降呼ぶことにする。(命名者：えと～さん)

【元ネタ】
チケット駆動開発は、まちゅさんによって提唱されている。

チケット駆動開発 … ITpro Challenge のライトニングトーク (4)

【1】チケット駆動開発のプラクティス

チケット駆動開発は定義そのものがあやふやなのだが、僕は下記4個ののプラクティスがあると思う。
※注意・下記のプラクティスはあくまでも僕個人の考えであることを断っておく。

【1-1】チケット・ファースト(Ticket First)
　プロジェクト内部の作業は、チケットを受け取ってから始まる。
　つまり、工数が発生する作業は全てチケットに作業内容を書き、その後の作業履歴もコメントで追記していく。
　
　チケット無しの作業は禁止。
　チケット無しのSVNコミットも禁止。
　このルールによって、Redmineのロードマップ、チケット一覧を見れば、今誰がどんな作業をしているか、今どんな作業状態なのか、すぐに判別できる。

　全てはチケットありき。

【1-2】チケットで分割統治(Divide and Conquer by Ticket)

　garyoさんに教えてもらった。
　チケットの工数や規模は、プログラミングの分割統治アルゴリズムのように、制御しやすいサイズまでチケットを分割する。
　チケットは仕様書ではなく、作業指示書であり、タスクカードだ。
　だから、チケットの規模は1週間以内になるように調整している。
　
　実際のチケットは、WBSを細分化したタスクに相当するだろう。

【1-3】小規模リリース(Small Releases)

　Redmineのロードマップ画面で、大まかなイテレーション計画を作る。
　つまり、バージョン毎にチケットをグループ化し、バージョンのリリース日にマイルストーンを設定する。
　
　Redmineを運用して分かったことは、Redmineのロードマップ機能は、XPのイテレーション計画であり、Scrumのスプリントに該当することだ。
　プロジェクトリーダーは、このイテレーション計画に従って、システムの機能を分割し、小規模なサイズで、短いサイクルで小刻みにリリースしていく。
　小刻みなバージョンアップ戦略によって、XPのイテレーション、Scrumのスプリントを実現できる。

【1-4】ふりかえり(Retrospect)

　プロジェクト内部の作業ログを全てチケットに記録すると、自然にRedmineのDBに格納される。
　成果物はSubversionの管理下に置けるから、Redmine＋Subversionで構成管理DB(CMDB)の管理下に置かれている。
　この基盤があるから、信頼度成長曲線、バーンダウンチャート、SVNソース行数、SVNコミットログ回数などのソフトウェア・メトリクスを簡単に集計できる。
　バージョンをリリースするごとに、これらのメトリクスを使って、メンバー全員でKPTを行い、次バージョンへ向けて改善していく。

　これらのプラクティスはXPやアジャイル開発に当然、影響を受けている。
　他にもあると思うので更に考えたい。
　

【2】バージョンの概念をもう一度見直そう

　Redmineを運用して分かったことは、チケット駆動開発はソフトウェア構成管理と密接に関係していることだ。
　実際、Redmine＋Subversionが構成管理DB(CMDB)になり、この基盤があるからこそ、成果物のバージョン管理だけでなく、作業記録や作業理由、ソース変更理由をRedmineで管理できる。

　つまり、Redmine＋Subversionはバージョン管理と変更管理を自然に実現するインフラになっている。
　ここで、バージョンという概念をもう一度見直してみよう。
　バージョンとはそもそも一体何なのか？
　
　僕の考えでは、バージョンは本来の意味でのベースラインである。
　つまり、2種類の意味があると思う。

【2-1】ある時点のシステムをいつでも再現できるポイント(タグ、バージョン)

　構成管理の観点に相当する。
　例えば、導入や変更で失敗した時の切り戻しポイント、あるいは将来の作業のための信頼できる作業ポイント。
　本番リリースしたものの、致命的な障害が発生して前のバージョンに戻さざるを得なかった時に良く使うだろう。
　Rollbackできる切り戻しポイントそのものだ。

　だが、ビルド作業が手作業の現場では、前のバージョンをビルドして再現するのが難しかったりするだろう。
　タグ付けという作業を行わない現場では、前のバージョンの成果物そのものを提示すらできないだろう。

【2-2】ある時点でステークホルダー(顧客、開発者など)が要件や仕様などで合意した状態

　変更管理の観点に相当する。
　変更管理はそもそも、顧客から変更要求(Request for Change)が発生して、元々確定していた要件や仕様が変更されることを管理するためにある。
　そもそもRequest(依頼)なのだから、対応せずに却下する時もありうる。

　だから、変更要求がどんな経緯で発生し、どんな議論が生じて、どの仕様で合意したのか、を記録する必要がある。　
　当然、開発チームは、工数や技術上の難しさなどの観点から、口を挟む権利はある。

　しかし、マネジメントの弱い開発チームは、開発チームの立場の意見を言わずに顧客の言いなりで全てを抱え込んでしまい、合意を取らないまま開発を進めて、リリース間際になって火を噴くことが多いだろう。
　あるいは、顧客と合意した内容や履歴をきちんと記録していないために、無駄に時間を浪費したり、他システムへの影響を把握できずに、リリース後に障害を発生させたりするだろう。

　バージョンという概念は、単なるタグだけでなく、合意というマネジメント要素も含んでいる。

【3】チケット駆動開発の本質はバージョン・ファースト(Version First)

　チケット駆動開発が短期リリース、小規模リリースできる理由は、バージョンという概念をきちんと管理できているからだ。
　チケット駆動開発のライフサイクルについて考えてみよう。
　
　まず、チケット・ファーストのプラクティスで、顧客など利害関係者が合意した仕様をターゲットバージョンとして定め、詳細化した仕様から作業内容を定めて、チケットへアサインして、バージョン単位に振り分ける。
　そして、分割統治のプラクティスで、開発者が作業しやすいスコープや工数までチケットを分割して紐付けて、アサインする。
　更に、短期リリースのプラクティスは、ターゲット・バージョンのチケット全てが終了状態になったら、リリースする。
　最後に、リリース後にバージョン単位のチケット集計結果、SVNリポジトリ統計を材料として、開発メンバー全員でふりかえり、Keep(良かった点は次回に続ける)・Problem(問題点)・Try(次に挑戦する)を洗い出して、次のバージョンに向けて改善すべきものは改善していく。

　このように、チケット駆動開発はチケット・ファーストから始まるが、本質はバージョン・ファースト(Version First)だと思う。
　ウォーターフォール型開発は最後のリリースまでバージョンという概念が無いが、アジャイル開発は小刻みなバージョンアップでシステムを育てていく。
　バージョンという概念こそ、ソフトウェア構成管理の根本概念に当たると思う。