前回のゲストブログ Part 1 に続き今回は Part 2 をお届けします。今、日本のソフトウェア開発において注目されており、先日書籍も出版された「チケット駆動開発」について紹介するシリーズの後編です。Part 2 はもう一人の著者である akipii 様から寄稿頂きました。
akipii / XPJUG Kansai (eXtreme Programming Japan User Group at Kansai)
概要
チケット駆動開発 (TiDD) とは、JIRA や Redmine などのチケット管理から生まれたプロジェクト管理の技法の一つです。「ソフトウェア開発に現れる全ての作業や課題はチケットに起票してから開発する」という原則 (Ticket First) を守り、チケットを中心に開発する手法です。
従来の Excel によるガントチャートでの進捗管理よりも、頻繁な作業の変更に対応しやすく、作業を見える化でき、アジャイル開発と相性が良い特徴があります。
本記事では、筆者がチケット駆動でアジャイルに開発できた経験を元に、チケット駆動開発を上手に運用するための基本プラクティスを解説します。
以下のプラクティスが全てではありませんが、どんな規律を持ってチケット駆動開発を運用すればよいか、迷う時にご参考になさってください。
プラクティス 1. チケット無しのコミット不可 (No Ticket, No Commit)
プログラムなどの成果物を変更する場合、必ずチケットに変更履歴を残します。
バージョン管理のコミットフック機能 (post-commit-hook) を利用して、プログラムをコミットする時、必ずコミットログにチケット番号を記録する運用から生まれた基本ルールです。作業の変更管理を強化し、プログラムの変更履歴をチケット経由で追跡できる利点 (traceability) があります。
また、開発者は、1 日の作業の開始前にチケットを登録 (No Ticket, No Work) して、チケットに基づいてプログラム修正を行い、プログラムのコミットと同時にチケットを完了するという開発のリズムが生まれます。
プラクティス 2. チケット無しの作業不可 (No Ticket, No Work)
作業を開始する前に、必ずチケットに作業内容を登録してから作業を開始します。そして、チケットは仕様書ではなく、作業指示書になります。
作業履歴がチケットに必ず残るため、他の開発者が参照できたり、収集したチケットから予定・実績の工数集計、進捗・障害の集計結果が得られるため、原因分析や是正対策作りに役立てることができます。
プラクティス 3. イテレーションはリリースバージョンである (Iteration is Version)
イテレーションはソフトウェアのリリースバージョン、プロジェクトのマイルストーンと一致させます。
XP のイテレーション (Scrum のスプリント)をバージョン管理の配下にあるブランチのリリースバージョンと同一視することで、イテレーション終了時には必ずソフトウェアをリリースできるというリリース完了条件が導かれます。
また、開発チームは、イテレーション単位に定期的に小規模リリースしていくことによって、システムを漸進的に開発していくリズムが生まれます。
プラクティス 4. チケットは製品に従う
ITS プロジェクトというチケット管理の集合は、リリースされる製品の構成 (アーキテクチャ) に従属するように対応付けます。
機能追加や障害修正のチケットはソースに対して管理する (No Ticket, No Commit) ため、製品の構成に基づくバージョン管理リポジトリと対応付けるように、ITS プロジェクトを作る方が管理が楽になります。そして、Conway’s Law (組織はアーキテクチャに従う)に従えば、開発組織はチケット管理の階層構造に組み込まれて、チケット駆動で開発しやすい組織体制の変化が促されます。
パッケージ製品を顧客ごとにカスタマイズする派生開発や、複数の製品系列の開発であるソフトウェアプロダクトライン (SPLE) にも適用できます。
プラクティス 5. タスクはチケットで分割統治 (Divide and Conquer)
チケットの粒度が大きい場合、タスクの分割という観点から、開発者が作業しやすいようにチケットを分割します。
チケット駆動で運用するといつも迷ってしまうのは、チケットの粒度です。基本的な運用方針としてはチケットの粒度は 1 ～ 5 人日程度まで細分化します。なぜならば、1 日の開発リズムが生まれやすいため、開発者は作業しやすいからです。従って、チケットの作業内容が大きすぎると気づいたら、たとえチケットが登録された後でも、作業しやすい粒度までチケットを分割します。
プラクティス 6. チケットの棚卸し
定期的に、放置された未完了チケットを精査して最新化します。
チケット駆動を中心にプロジェクトを運営すると、チケットはどんどん登録され更新されるため、何らかの規律がなければ、乱発・放置されるチケットの重みで開発速度が遅くなってしまいます。
その状況を打開するために必要な作業である「チケットの棚卸し」には以下の 4 つの注意点があります。
(1) 役割分担
開発チームのリーダーがチケット管理の最終責任者であると認識し、リーダーは定期的に、誰も手を付けない作業やチームの開発の支障となる課題を優先順位付けしたり、ステータスを最新化したりします。
(2) 棚卸しのタイミング
例えば、毎日の朝会やリリース後のふりかえりミーティングのように、棚卸しのタイミングを故意に作ります。
(3) チームの開発速度 (Velocity) を超えるチケットは後回し
現状のメンバーの技術力やチームの成熟度の観点では、どう考えても実施不可能なほど大量のチケットであふれている状況があります。その場合、チームの開発速度 (Velocity) を超えるチケットはイテレーションから削減し、チームが消化できるレベルのチケットの枚数になるように調整します。
(4) 作業不要のチケットは、リリース未定の特別なイテレーションへ移す
作業不要のチケットは、別のイテレーションへ延期したり、リリース期限が未定の特別なイテレーションへ移動して除去します。この特別なイテレーションは、「Unplanned」「バックログ」「Icebox」などとも呼ばれ、次のイテレーション計画作成中に必要なチケットがあると判断されれば、そのチケットを取り込む運用になります。
プラクティス 7. ペア作業 (Pair Work)
一つのチケットを二人以上で連携する作業です。
XP のペアプログラミングでは必ず二人が同時間帯に一つの机で作業しますが、ペア作業では一つのチケットの作業結果を受けて、チケットのステータスを更新しながら非同期にペアで作業します。例えば、障害修正において開発者とテスト担当者が交互に修正と検証を行ったり、コードレビューをレビューアと開発者 (レビューイ) が交互にレビューと指摘事項の反映を行ったりする時に使われます。
一つのチケットを二人以上の目を通してチェックし、成果物の品質を向上できる利点があります。
まとめ
チケット駆動開発はソフトウェア開発以外のタスク管理や事業部全体のような大規模組織の作業管理にも適用でき、以上のプラクティスを実践すると、アジャイルな効果の恩恵も受けられます。
書籍「チケット駆動開発」や本ブログの読者らとともにより良いソフトウェア開発を目指すために、チケット駆動開発を更に改善していきたいと考えています。
以上でゲストブログ Part 2 を終わります。Part 1 「なぜ日本ではチケット駆動開発が注目されるのか?」と合わせてご覧ください。「チケット駆動開発」で日本のソフトウェア開発がどう変わるのか？今後もウォッチしていきたいと思います！