XP祭り関西2010発表資料「チケット駆動開発のプラクティス集」

XP祭り関西2010
チケット駆動開発セッション

2010/2/6
XPJUG関西
(copyright2009 akipii@XPJUG関西)

1

セッションの目的
背景
2005年頃から第2期Agileブーム(Agile2.0と呼ばれる)
Agile開発で時代を先取りするビジネス
スクリプト言語、軽量フレームワークの普及
TDD、CI、PFなどのAgileプラクティスの伝播
SIerやツールベンダーがAgile開発に注目

しかし、実際の開発現場ではAgile開発の運用は難しい

目的
WikiやBTSを基盤にしたOSSのプロジェクト管理ツールを用いて、
Agile開発の運用を支援する
その一例として、チケット駆動開発を説明して共有したい


2

セッションのスケジュール
1.
2.
3.
4.

説明
チケット駆動開発のプラクティス集 by あきぴー
元気が出るチケット駆動開発 by 阪井さん
チケット駆動開発を用いたソフトウェア品質改善事例
by 小枝さん

5. パネルディスカッション～チケット駆動開発の体験談
1. 倉貫さん、阪井さん、小枝さん、あきぴー(司会)
2. KPT形式で体験談を話して比較します
3. 質疑応答

3

チケット駆動開発の
プラクティス集

2010/2/6
あきぴー＠XPJUG関西

4

自己紹介
ＨＮ：あきぴー
簡単な職歴
業務系Webシステムの開発部隊に所属

興味
チケット駆動開発(TiDD)、Redmine、TestLinkで
アジャイル開発を改善する

活動コミュニティ
XPJUG関西、SEA関西、TEF関西など

5

Agenda
アジャイル開発の特徴
アジャイル開発の課題
チケット駆動開発の発端
チケット駆動開発とは
TiDDがAgileになる理由
が
になる理由
TiDDプラクティス集～個のプラクティス
プラクティス集～10個のプラクティス
プラクティス集～
まとめ


6

超短期間のインクリメンタル型開発
イテレーション単位に頻繁にリリースする(小規模リリース)
顧客からのフィードバックに早期に対応可能
頻繁なリリースでビルド漏れ等のリスクに早期に対応可能

開発作業の自動化
テスト駆動開発(TDD)⇒単体テストの自動化
継続的インテグレーション(CI)⇒ビルド作業を自動化

メインラインモデルによる並行開発
リリースした本番運用のソースは本番ブランチとして生き続ける
次のMajorVersionで本番ブランチが切り替わる
障害修正はbranch、機能追加はtrunkに分けて品質を維持する


7

頻繁に変わるタスク管理
頻繁なリリースの為イテレーション管理が大変
アナログのタスクボードだけでは進捗管理しづらい

継続的な修正と頻繁なリリース管理
継続的なリファクタリングや機能追加を制御するのは難しい
短期間に順次リリースしていくのはやっぱり大変

複数のコードラインを常時保守する並行開発
一度リリースしたソースは本番ブランチとして生き続ける
常に本番運用・開発中の二つのコードラインを保守するのは大変


8

チケット駆動開発の発端
TiDDはTracのチケット管理から生まれた(まちゅさん)
ITpro Challenge のライトニングトーク(2007/9)
http://www.machu.jp/diary/20070907.html#p01

正式名称：Ticket Driven Development
BTSを障害管理だけでなくタスク管理に使う(まちゅさん)

Redmineでアジャイル開発を初めて実践できた(あきぴー)
チケット駆動開発の略称「TiDD」 (えと～さん)
「TDD」だと「テスト駆動開発」と間違えそう

チケット駆動開発はAjaxみたい (上田さん)
中身(BTS)は古いが新しい衣(TiDD)を被ったアジャイル開発

9

チケット駆動開発とは(1)
障害も仕様変更も作業もチケットで扱う (Issue Tracking)
チケットの対象は、SW開発に関する作業全般
BTSチケットをXPのタスクカードのように扱う

BTSの運用対象を
拡大する

10

成果物の変更をチケットで追跡する(Ticket Tracking)
チケットへ構成管理情報を付与する
チケット経由で要件からビルドモジュールまで追跡可能
見積/実績工数・作業期間をチケットで追跡も可能(Time Tracking)


11


並行開発をチケットで管理できる
新規開発(trunk)とその分岐である本番運用(branch)で
チケットを使い分ける
マージ作業とその発生源の修正作業のチケットを連携し
てワークフロー管理する

12

TiDDがAgileになる理由(1)
BTSのチケットをXPのタスクカードのように使う(阪井さん)
XPのタスクカードをデジタル化する
チケットへ作業内容、進捗情報を付与する
計画に基づかない突然のタスク管理がやりやすい

XP

BTS

タスクボード

チケット一覧

置き換え
チケット

タスクカード


13

BTSチケット集計結果をタスクボード・かんばんのように扱う(阪井さん)
XPのタスクボード・かんばんは、物理的制約がある
XPのタスクボード・かんばんは最新化・集計が面倒だが、TiDDはBTSに情
報を集約できる
チケット集計結果を進捗報告だけでなく、PLの意思決定支援に使う

かんばん

14


ロードマップをリリース計画のように扱い、小規模リ
リースを運用する
TiDDはXPの開発ライフサイクルに似たアジャイル開発！

15


チケットの作業をトピックブランチ上で行う手法もある
MercurialやGitを使った並行開発
担当者はトピックブランチ作成後、ガンガン開発&修正する
トピックブランチが検証完了になって初めてtrunkへpushする
ブランチの作業状態をチケットのステータスで管理できる
複数のチケットの作業順とリリース順が異なる場合に有効

16

TiDDプラクティス一覧(あきぴーの提案)
1・チケットファースト
・チケットファースト
2・分割統治(プロジェクト・
・分割統治プロジェクト・
イテレーション・チケット)
イテレーション・チケット
3・チケットはシンプルに
・

次バージョンへ
バージョン登録
問合せ

Redmine
チケット更新
集計表示

バージョンClose
バージョン

8・見える化
・見える化
9・朝会
・朝会
10・ふりかえり
・ふりかえり

4・No Ticket, No Commit !
・
5・ペア作業
・
6・小規模リリース
・小規模リリース
7・棚卸し
・

17

【1】チケットファースト
入力

チケット

出力

　作業

ソース・設計書

担当

開発者
開発者はチケットを受け取ってから作業を開始する
入力：チケット
出力：ソース・設計書等

チケットをXPのタスクカードのように扱う
チケットに作業内容・作業履歴・進捗情報・構成管理情報を残す

18

【2-1】チケットで分割統治(判谷さん)
粒度は1人が1週間以内に1個の成果物を作るタスク
チケットは仕様書ではない。作業指示書である。
実際は1人日以内の作業が多い

チケットを分割する観点
WBS単位(成果物の単位)
ワークフローはチケットの種類で切り替える
Redmineならトラッカー

チケットを登録後に分割するタイミング
当初よりも作業が複雑だったと判明した
修正作業にリファクタリング作業が含まれる

19

【2-2】イテレーションで
分割統治
イテレーションとリリース予定バージョン
を同一視する
マイルストーンとバージョンを同一視

リリースしたバージョンはビルド番号を
付与する
例：Major . Minor . Build (. Revision)

バックログのイテレーションを作る
顧客からの改善要望

内部課題のイテレーションを作る
開発チームの課題、ToDo
優先度の低いリファクタリング作業


20

【2-3】プロジェクトで分割統治
プロジェクトに分割する観点
サブチーム単位(1チーム約5人)
サブシステム単位(モジュール、コンポーネント)
ワークフロー/工程単位
問合せや仕様確認と開発は分けた方が管理しやすい
ブランチ単位(コードライン)
本番運用ソースと新規開発ソースは分けた方が管理しやすい
Trunkへのマージ作業はbranchのチケットとリンクしておく

大規模プロジェクトでは、ノウハウが必要
サブチーム・工程単位でプロジェクトに分割してタスク管理
チケット管理だけの専門担当者(PL)をアサイン
チケットの方針決定は、変更管理会議(CCB)で調整する

21

【3】チケットはシンプルに
最初から複雑なワークフローで運用しない
開発者が作業しづらいとチケットが更新されなくなる
厳格なワークフロー管理も大事だが、確実なリリースがもっと大事
リリース後のふりかえりMTで運用を少しずつ改善する

進捗率は運用ルールを決める
チケットが停滞すると作業状況が分からなくなる
例：0%(未着手)-50%(担当)-100%(解決・完了)
例：0%(未着手・担当)-100%(解決・完了)

頻繁なタスク追加に耐えれるように運用する
タスク漏れが一番怖い⇒チケットファーストが重要！
チケットファーストが重要！
当初のWBSよりもチケットは必ず(かなり
かなり)増える
かなり
開発チームのゴールは、厳密な管理よりも確実なリリース
確実なリリース


22

【4】No Ticket, No Commit !(まちゅさん)


23

【4】No Ticket, No Commit !(まちゅさん)
チケット無しのソースコミット不可！
→チケットからパッチの理由を検索可能


23

【5】ペア作業

担当者の作業を
チケットの状態遷移図
で管理できる

チケットは2人以上の担当者がキャッチボールして終わる
開発者がバグ修正後、テスターがバグ検証する
開発者が作業完了後、管理者が承認する
開発者が仕様を質問後、設計者が回答する

24

【6】小規模リリース
2~4週間の間隔で、小刻みに機
能拡張しながらリリースする
リリース計画をあらかじめ立てて
おく
リリースのタイミングは、イテレー
ションに属するチケットが全て終
了ステータスになること
リリースバージョン、終了チケット
はChangeLogに残る
自然に繰り返し開発＆並行開発
になるのがポイント


25

【7】棚卸し
定期的にチケットの状態を最新にする(東さん)
チケットが乱発・放置・停滞されないように保守する
PLがチケット管理の最終担当者

大規模プロジェクトでは変更管理会議(CCB)を開く
ステークホルダー全員でチケットを棚卸しする
チケット管理の専門担当者が議長になって開催する
サブチーム間でチケット解決を調整する時もある

棚卸し会議はリリース計画を立てる場でもよい
今後のリリース予定のバージョンを立てる
チケットの優先順位をステークホルダー全員で議論する


26

【8】プロジェクトの見える化
例：Redmine_chartsプラグイン
http://github.com/mszczytowski/redmine_ch
arts

↓
・スケジュール差異(SV)を表示
・最終的にはEVMも可能(?)

BTSのチケット自動集計・Wiki機能を使って見える化する
バーンダウンチャート、予定・実績工数比較、活動ログで進捗管理
Wiki、フォーラム、ニュースで情報共有

27

【9】朝会
1日の初めに各自の仕事と役割を確認する
ロードマップを見ながらチームのゴールを確認
チケットの相互関係から連携作業を意識付け
一人の遅れを皆で支え合う気持ちが大事

朝会は進捗報告の場ではない
BTS上でいつでも進捗確認できる

リスクは嗅ぎ取るが、問題解決は後で行う
割り込み作業や隠れ作業をなくす
開発者の不安を聞き取り、内部課題へチケット登録
問題解決の方針は関係者だけの会議を開く

28

【10】ふりかえり
リリース後にKeep，Problem，Try
にまとめる
チケット集計結果があると効果的
メンバー全員の意見を残す
特に若手・女性が発言しやすいよ
うに

チケットやワークフローの運用を見
直す絶好のタイミング

KPT

開発者の意見は大切

(ふりかえり)

少しずつプロセス改善する
一気に大きく運用を変えるのは難
しい
ProblemからTry、TryからKeepへ
移るように

29

まとめ
ツールがサポートすれば、
行動が変わっていく。
行動が変わっていく。
行動が変われば、
行動が変われば、
考え方も変わっていく。
チケット駆動開発でアジャイル開発を実践してみよう
BTSがあれば誰でも運用できる
TiDDはレコーディングダイエット
記録するだけでプロセス改善できる

SW開発の諸問題はソフトウェアで解決していこう！
開発の諸問題はソフトウェアで解決していこう！

30

XP祭り関西2010発表資料「チケット駆動開発のプラクティス集」

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a XP祭り関西2010発表資料「チケット駆動開発のプラクティス集」

Semelhante a XP祭り関西2010発表資料「チケット駆動開発のプラクティス集」 (20)

Mais de akipii Oga

Mais de akipii Oga (20)

XP祭り関西2010発表資料「チケット駆動開発のプラクティス集」