チケットファーストでアジャイル開発！～チケットに分割して統治せよ

XPJUG関西(Copyright Akipii)1
チケットファーストでチケットファーストでチケットファーストでチケットファーストで
アジャイル開発！アジャイル開発！アジャイル開発！アジャイル開発！
2009/01/24 あきぴー
チケットに分割して統治せよチケットに分割して統治せよチケットに分割して統治せよチケットに分割して統治せよ

自己紹介
ＨＮ：あきぴー
主な職歴
業務系Webシステムの開発部隊に所属
プログラミングからプロジェクト管理まで何でも
興味
XP、Scrumなどのアジャイル開発

第第第第1部部部部
チケット駆動開発の発端チケット駆動開発の発端チケット駆動開発の発端チケット駆動開発の発端
チケットはチケットはチケットはチケットは
XPのタスクカードのタスクカードのタスクカードのタスクカード

アジャイル開発の利点
要望から実装・リリースまでの期間が短い
イテレーション単位に小さく作ってリリースする繰り返し開発
早めにリリースするから重大な問題を早く検知できる
リリース後も継続的な修正を受け入れる
次のイテレーションで改善要望を機能追加できる
小さく作るからリリースのリスクが小さい
SW構成管理(SCM)の重要性を再認識させた
ソース共同所有でいつでも誰でもソースを修正可能
テスト駆動開発(TDD)で単体テスト品質を保証
継続的インテグレーション(CI)で常時リリース可能

アジャイル開発の運用の課題
進化的保守
イテレーション計画は流動的な為、細かなタスク
変更が多く、リアルタイムな進捗管理が難しい
並行開発
継続的な機能追加によってソースの修正が多い
本番・開発中各々のソース管理に手間がかかる
変更管理
リファクタリング、バグ修正、機能追加等の色々
な変更が混在する為、品質を制御しにくい

チケット駆動開発の発端
ルーツはバグ管理システム(BTS)
BTSは本来、障害管理として昔から使われてきた
Bugzilla(Perl製)、 Mantis(PHP製)など
最近はガントチャート等のプロジェクト管理機能を持つ
Trac：Python製BTS
Redmine：：：：Ruby on Rails製製製製BTS (←運用中運用中運用中運用中)
Tracのチケット管理から生まれた(まちゅさん)
ITpro Challenge のライトニングトーク(2007/9)
http://www.machu.jp/diary/20070907.html#p01
正式名称：Ticket Driven Development
チケット駆動開発の略称「TiDD」 (えと～さん)
「TDD」だと「テスト駆動開発」と間違えそう

チケット駆動開発とは(1)
BTSのチケットをXPのタスクカードのように使う
XPのタスクカードをデジタル化する
( 阪井さん@SRA先端技術研究所から )
障害も要望もチケットで扱う(Issue Tracking)
作業状態、進捗情報はチケットで一元管理
ガントチャート、バーンダウンチャートで進捗管理
バグ修正や機能追加等をワークフロー管理
チケット集計結果からバグ収束曲線等で品質管理

チケットの概念モデル(Redmine)

ソースの変更はチケットと関連付ける
チケットからソースの修正理由を追跡できる
例：ソースAの修正で影響を受けるソースは？
ソースソースソースソースAのコミット履歴のコミット履歴のコミット履歴のコミット履歴
からチケットを探すからチケットを探すからチケットを探すからチケットを探す

並行開発をチケットで管理する
新規開発(trunk)とその分岐である本番運用(branch)
でチケットを使い分ける
コードライン単位で異なる目的の作業をチケット管理で
きる

TiDDの運用サイクル(Redmine)
Redmine
PL
ユーザ
PG
開発チーム
バージョン登録
チケット更新
集計表示
問合せ
バージョンClose
次バージョンへ

チケット駆動開発のプラクティス
キャッチフレーズは「チケットに分割して統治せよチケットに分割して統治せよチケットに分割して統治せよチケットに分割して統治せよ」
1. チケット・ファースト(Ticket First)
プロジェクトの作業はチケットを受け取ってから始める
チケット無しで成果物の更新不可
2. チケットで分割統治(Divide and Conquer)
チケットの粒度は追跡可能なタスクまで細分化する
バージョン毎にチケットをグループ化してまとめる
3. 小規模リリース(Small Releases)
バージョン毎に小さく作って小刻みにリリースする
リリース結果は終了チケットの履歴として残る
4. ふりかえり(Retrospect)
チケット集計結果から次バージョンへ向けて改善しよう

第第第第2部部部部
チケット駆動開発の実践チケット駆動開発の実践チケット駆動開発の実践チケット駆動開発の実践
Redmineの運用例の運用例の運用例の運用例

チケット駆動開発の機能構成図(例)
バージョン管理バージョン管理バージョン管理バージョン管理ビルド管理
変更管理変更管理変更管理変更管理マネジメントマネジメントマネジメントマネジメント
継続的インテグレーション継続的インテグレーション継続的インテグレーション継続的インテグレーション
テスト駆動開発テスト駆動開発テスト駆動開発テスト駆動開発
ソース共同所有ソース共同所有ソース共同所有ソース共同所有
メインラインモデルメインラインモデルメインラインモデルメインラインモデル
チケット駆動開発チケット駆動開発チケット駆動開発チケット駆動開発

(1-1)ワークフロー管理ロール、トラッカー、ステータスロール、トラッカー、ステータスロール、トラッカー、ステータスロール、トラッカー、ステータス
でワークフローを切り替え可能でワークフローを切り替え可能でワークフローを切り替え可能でワークフローを切り替え可能
↓
1.ロール：管理者、開発者ロール：管理者、開発者ロール：管理者、開発者ロール：管理者、開発者etc
2.トラッカー：バグ、新規開発トラッカー：バグ、新規開発トラッカー：バグ、新規開発トラッカー：バグ、新規開発etc
3.ステータスは先行と移行先のステータスは先行と移行先のステータスは先行と移行先のステータスは先行と移行先の
マトリックスで一覧表示マトリックスで一覧表示マトリックスで一覧表示マトリックスで一覧表示

(1-2)チケットの状態遷移図(Redmine)

(1-3)運用フロー(Redmine)

(2)ロードマップ作成
Redmineのバージョンがイテレーションに相当する。のバージョンがイテレーションに相当する。のバージョンがイテレーションに相当する。のバージョンがイテレーションに相当する。
バージョン単位で進捗率、関連チケットを表示する。バージョン単位で進捗率、関連チケットを表示する。バージョン単位で進捗率、関連チケットを表示する。バージョン単位で進捗率、関連チケットを表示する。
→プロジェクトの進捗はイテレーションで管理する。プロジェクトの進捗はイテレーションで管理する。プロジェクトの進捗はイテレーションで管理する。プロジェクトの進捗はイテレーションで管理する。

(3) チケット登録 1.トラッカー：チケットの種類トラッカー：チケットの種類トラッカー：チケットの種類トラッカー：チケットの種類
2.ステータス：チケットの作業状態ステータス：チケットの作業状態ステータス：チケットの作業状態ステータス：チケットの作業状態
3.TargetVersion：：：：マイルストーンマイルストーンマイルストーンマイルストーン
4.開始日、終了日：作業期間開始日、終了日：作業期間開始日、終了日：作業期間開始日、終了日：作業期間
5.カテゴリ：機能の単位。カテゴリ：機能の単位。カテゴリ：機能の単位。カテゴリ：機能の単位。

(4)ガントチャートチケットに開始日、終了日を記入すれば、チケットに開始日、終了日を記入すれば、チケットに開始日、終了日を記入すれば、チケットに開始日、終了日を記入すれば、
ガントチャートを自動生成してくれる。ガントチャートを自動生成してくれる。ガントチャートを自動生成してくれる。ガントチャートを自動生成してくれる。

(5-1)バージョン管理と連携
SVNリポジトリを一覧表示。リポジトリを一覧表示。リポジトリを一覧表示。リポジトリを一覧表示。
プロジェクトとソースリポジトリがプロジェクトとソースリポジトリがプロジェクトとソースリポジトリがプロジェクトとソースリポジトリが1対対対対1対応。対応。対応。対応。

(5-2)コミット時にチケットと連携
SVNコミットログに下記のキーワードをコミットログに下記のキーワードをコミットログに下記のキーワードをコミットログに下記のキーワードを
書くとチケットと連携できる。書くとチケットと連携できる。書くとチケットと連携できる。書くとチケットと連携できる。
例例例例1：：：： refs 11
例例例例2：：：： fixes 11 (11はチケットはチケットはチケットはチケットNo)

(5-3)チケットにリビジョン表示
チケットにチケットにチケットにチケットにSVNリビジョンを表示リビジョンを表示リビジョンを表示リビジョンを表示
↓
ソースから変更理由を追跡できるソースから変更理由を追跡できるソースから変更理由を追跡できるソースから変更理由を追跡できる

(6) リリース後にニュースで告知

(7-1)サマリ(チケット集計結果)
トラッカーやバージョン毎に、残チケットの作業状態を表示。トラッカーやバージョン毎に、残チケットの作業状態を表示。トラッカーやバージョン毎に、残チケットの作業状態を表示。トラッカーやバージョン毎に、残チケットの作業状態を表示。
開発チームの成績表に相当する。開発チームの成績表に相当する。開発チームの成績表に相当する。開発チームの成績表に相当する。

(7-2)リポジトリ統計
SVNリポジトリの月別リビジョン回数、コミット回数を表示。リポジトリの月別リビジョン回数、コミット回数を表示。リポジトリの月別リビジョン回数、コミット回数を表示。リポジトリの月別リビジョン回数、コミット回数を表示。
開発チームの活発度合いが分かる。開発チームの活発度合いが分かる。開発チームの活発度合いが分かる。開発チームの活発度合いが分かる。

TiDDをRedmineで運用後
プロジェクトの問題や進捗を見える化できた
残タスク、進捗率がリアルタイムに一目瞭然
遅延タスクが明確なので進捗管理しやすくなった
アジャイル開発をようやく理解できた
RedmineロードマップがXPのイテレーション計画に相当する
プロジェクトの進捗はイテレーションで制御する発想
チケットの取捨選択が重要(本来のマネジメント)
開発者の受けもいい
変更理由はチケットに書くのでソースが綺麗
バグを見つけたら自発的にチケット登録してくれる
チケット管理の課題が見えてきた
チケットをリアルタイムに保守しなければ、BTSは無意味
プロジェクト管理をチケット管理に置き換える発想

チケット駆動開発の特徴
タスクをToDo(課題)として管理する
顧客の要望と開発者の工数見積のバランスで優先順位付け
チケットの取捨選択でイテレーション計画は頻繁に変わる
ソースから作業理由・要件を追跡しやすい
例えば過去のパッチの意図を検索できる
要件→仕様→【チケット】←ソースのトレーサビリティが可能
自然に強力なSW構成管理のインフラになる
変更管理、構成管理、メトリクス収集が自動化される
開発者はチケットだけ意識すればいい
メインラインモデルとチケット駆動開発は相性が良い
バグ修正と機能追加はチケットの種類を変える

チケット駆動開発の運用の注意点
チケットを乱発・放置しない運用は何か？
リリース時期が不明なチケットは内部課題で一旦保留
遅延したチケットは更にチケットを分割する
SW開発の全業務をカバーできるか？
インシデント管理はバグと異なる別種類のチケットにする
基本は成果物を作る作業をチケットに対応付ける
大規模チームで運用できるか？
チケット管理だけの専門担当者を置く
構成管理会議(CCB)でチケット解決の方針を決定する
チケット集計結果から得られたメトリクスを過信しない
メトリクスの意味を正しく理解して、意思決定に使いましょう

まとめ・謝辞
アジャイル開発はチケット・ファーストから始めよう
タスクはチケットに分割して統治せよ
アジャイル開発は高度なSW構成管理ツールを必要とする
チケット駆動開発は、Ajaxみたい
中身(BTS)は古いが新しい衣(TiDD)を被ったアジャイル開発
謝辞
チケット駆動開発の提唱者まちゅさん
勉強会で一緒に議論してくれた仲間へ
えと～さん、東さん、よしうみさん、たけぷ～さん、うえださん、Tanigon
さん、せりまささん、判谷さん、猪原さん、阪井さん
講演の場を提供してくれたXPJUG関西へ

チケットファーストでアジャイル開発！～チケットに分割して統治せよ

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Plus de akipii Oga

Plus de akipii Oga (20)

Dernier

Dernier (7)

チケットファーストでアジャイル開発！～チケットに分割して統治せよ