【公開】AgileTourOsaka2010講演資料 "Why Ticket Driven Development is Agile? : No Ticket, No Commit!" #agileto2010 #tidd: プログラマの思索 http://forza.cocolog-nifty.com/blog/2010/10/agiletourosak-1.html AgileTourOsaka2010講演資料 "Why Ticket Driven Development is Agile? : No Ticket, No Commit!" 【Event】AgileTourOsaka2010 - XPJUG関西wiki http://www.xpjug.jp/cgi-bin/main_wiki/wiki.cgi?page=%A1%DAEvent%A1%DBAgileTourOsaka2010

1. Why Ticket Driven
Development is Agile ?
No Ticket, No Commit !
2010/10/30
akipii＠XPJUG Kansai, Japan
(copyright2010 akipii@XPJUG関西)
1

2. チケット駆動開発が
Agileになる理由
No Ticket, No Commit !
2010/10/30
あきぴー＠XPJUG関西
(copyright2010 akipii@XPJUG関西)
2

3. 自己紹介
HN：あきぴー
チケット駆動開発の本を出
版しました (世界初？)
Redmineを使って、
チケット駆動開発による
Agileな開発方法について
解説しました
現在 絶賛販売中
(copyright2010 akipii@XPJUG関西)
3

4. Agenda
第1部 チケットファーストでAgile開発！
SW開発の問題点
Agile開発の課題
チケット駆動開発とは
TiDD運用後
第2部 チケット駆動開発がAgileになる理由
【理由その1】タスク管理
【理由その2】変更管理
【理由その3】並行開発
第3部 Agile開発のアンチパターン
まとめ
(copyright2010 akipii@XPJUG関西)
4

5. 第1部
チケットファーストでAgile開発！
タスクはチケットに
分割して統治せよ
(copyright2010 akipii@XPJUG関西)
5

6. SW開発の諸問題
ExcelやMS Projectのガントチャート保守が大変
や
のガントチャート保守が大変
残工数や残作業の計算に半日以上かかる
顧客の要求やソース修正の速度にガントチャート保守が追いつかない
突発的な変更に対応しにくい
SW開発は突然の仕様変更や緊急の障害修正が多い
フィードバックが多すぎて手戻り作業ばかり増える
頻繁なリリースに耐えられない
安易な変更がデグレを起こす
プロジェクトにスピード感や
リズム感がない
(copyright2010 akipii@XPJUG関西)
6

7. Agile開発の課題
頻繁に変わるタスク管理
頻繁なリリースでタスク管理が大変
アナログのPostIt、かんばんだけでは進捗管理しづらい
継続的な修正と頻繁なリリース管理
継続的な修正と頻繁なリリース管理
と頻繁なリリース
継続的なリファクタリングや機能追加を制御するのは難しい
短期間に順次リリースするプロセスはやっぱり大変
ソフトウェアプロダクトラインに似た並行開発
ソフトウェアプロダクトラインに似た並行開発
一度リリースしたソースは
本番ブランチとして生き続ける
常に本番運用・開発中の
二つのコードラインを
保守するのは大変
かんばん
(copyright2010 akipii@XPJUG関西)
7

8. チケット駆動開発の発端(1)
チケット駆動開発はTracのチケット管理から生まれた
(まちゅさん)
ITpro Challenge のライトニングトーク(2007/9)
http://www.machu.jp/diary/20070907.html#p01
正式名称：Ticket Driven Development (まちゅさん)
BTSを障害管理だけでなくタスク管理に使う(まちゅさん)
(copyright2010 akipii@XPJUG関西)
8

9. チケット駆動開発の発端(2)
Redmineでアジャイル開発を初めて実践できた(あきぴー)
チケット駆動開発の略称「TiDD」 (えと～さん)
チケット駆動開発はAjaxみたい (上田さん)
中身(BTS)は古いが新しい衣(TiDD)を被ったアジャイル開発
(copyright2010 akipii@XPJUG関西)
9

10. チケット駆動開発とは(1)
障害も仕様変更も作業もチケットで扱う (Issue Tracking)
チケットはSW開発の作業指示書 (Ticket First)
BTSチケットをXPのタスクカード
のタスクカードのように扱う(阪井さん)
のタスクカード
タスクは作業しやすい単位のチケットまで分割する(判谷さん)
BTSの運用対象を
拡大する
(copyright2010 akipii@XPJUG関西)
10

11. チケット駆動開発とは(2)
成果物の変更をチケットで追跡する(Ticket Tracking)
チケットへ構成管理情報を付与する
チケット無しのソースコミット不可 (No Ticket, No Commit !)
(まちゅさん)
チケット経由で要件からビルドモジュールまで追跡可能 (Traceability)
見積/実績工数・作業期間をチケットで追跡も可能 (Time Tracking)
(copyright2010 akipii@XPJUG関西)
11

12. チケット駆動開発とは(3)
並行開発をチケットで管理する
新規開発(trunk)とその分岐である本番運用(branch)で
チケットを使い分ける (MainLine Model)
ソース修正やマージ作業はチケットで追跡する
(copyright2010 akipii@XPJUG関西)
12

13. TiDD運用後
プロジェクトの問題や進捗を見える化できた
残タスク、進捗率がリアルタイムに一目瞭然
プロジェクトのゴールや問題点、改善点をチームで共有できる
TiDDが自然に
が自然にAgile開発になった
が自然に
開発になった
ロードマップがリリース計画に相当する
チケットの取捨選択こそがXPの計画ゲーム
チケットの取捨選択こそが の計画ゲーム
チケットの取捨選択が本来のマネジメント(えと～さん)
開発のリズムが生まれた
イテレーション単位でリリースするから開発のリズムが生まれる
開発者は必ずチケットを登録してから作業を始める
チケットによるワークフローが自然にペア作業になる
リリース後のふりかえりミーティングで運用ルールを改善していく
(copyright2010 akipii@XPJUG関西)
13

14. 開発者の1日(例)
9:00 出社後、チームの朝会
【チケットのステータス】
新規→担当
9:30 担当タスクをチケット登録後、作業開始
12:00 昼食
担当→解決
15:00 チケットを解決したので
チケットを解決したのでSVNコミット
コミット
17:00 テスターが検証後、チケットを完了
解決→完了
18:00 退社
(copyright2010 akipii@XPJUG関西)
14

15. イテレーションの開発サイクル
ユーザ
PL
次バージョンへ
バージョン登録
問合せ
Redmine
チケット更新
集計表示
バージョンClose
バージョン
開発チーム
PG
(copyright2010 akipii@XPJUG関西)
15

16. TiDDはPFと相性が良い
PFの各種ツールはTiDD上で実現可能
かんばんはステータスごとのチケット集計結果
ニコニコカレンダーはRedmineプラグインで実現済み
PFの朝会、ふりかえりはプロセス改善に有効
朝会でロードマップを見ながら、ゴールをチームで共有
リリース後のふりかえりで、開発プロセスの改善点を洗い出す
TiDDとPFを組み合わせれば、
と を組み合わせれば、
チーム力を強化できる
(copyright2010 akipii@XPJUG関西)
16

17. 第2部
チケット駆動開発が
Agileになる理由
チケット駆動開発の
構造を解き明かす
(copyright2010 akipii@XPJUG関西)
17

18. 【理由その1】タスク管理
BTSのチケットをXPのタスクカードのように使う(阪井さん)
XPのタスクカードをデジタル化する
チケットへ作業内容、進捗情報を付与する
計画に基づかない突然のタスク管理がやりやすい
BTSは本来、突然発見したバグの管理のためのツール
XP
BTS
かんばん
チケット一覧
置き換え
チケット
タスクカード
(copyright2010 akipii@XPJUG関西)
18

19. 強力なイテレーション管理
BTSチケット集計結果をかんばんのように扱う(阪井さん)
XPのタスクボードは最新化・集計が面倒
TiDDは、BTSに仕様や進捗の情報を集約できる
イテレーションのタスク管理を色んな観点で分析しやすい
ワークフロー、ステータス、カテゴリ、担当者、イテレーション
かんばん
(copyright2010 akipii@XPJUG関西)
19

20. 小規模リリース
2~4週間の間隔で、小刻みに機
能拡張しながらリリースする
リリース予定バージョンがイテレー
ションに相当する
長期のリリース計画はロードマッ
プ
短期のリリース計画はイテレー
ション計画
リリースバージョン、終了チケット
は変更履歴に残る
自然に繰り返し開発
になるのがポイント
(copyright2010 akipii@XPJUG関西)
20

21. 小規模リリース
2~4週間の間隔で、小刻みに機
能拡張しながらリリースする
リリース予定バージョンがイテレー
ションに相当する
長期のリリース計画はロードマッ
プ
短期のリリース計画はイテレー
ション計画
リリースバージョン、終了チケット
は変更履歴に残る
自然に繰り返し開発
になるのがポイント
(copyright2010 akipii@XPJUG関西)
20

22. Ver1.0
リファクタリング
柔軟なチケット管理
Ver1.0
バグ修正
ワークフロー変更
Ver1.0
機能Aの修正、
機能Bの修正
チケットを チケット
起票
更にチケットを分割
Ver1.1
バグ修正
バージョン変更
(copyright2010 akipii@XPJUG関西)
21

23. 【理由その2】変更管理
ロードマップをリリース計画のように扱い、小規模リリー
スを運用する開発プロセス
Redmineによるチケット駆動開発は、XPの開発ライフサイク
ルに似たアジャイル開発！
(copyright2010 akipii@XPJUG関西)
22

24. ワークフローで変更管理
(copyright2010 akipii@XPJUG関西)
23

25. ワークフローで変更管理
ソフトウェア開発のワークフローは
BTSのワークフロー機能で
制御できる
ユーザ権限と
チケット種類の単位で
ステータスの現在・移行先を
指定する
ステータスの移行先
現
在
の
ス
テ
ー
タ
ス
(copyright2010 akipii@XPJUG関西)
23

26. コミット時にチケットとSCM連携
SVNコミットログに下記のキーワードを
コミットログに下記のキーワードを
書くとチケットと連携できる。
はチケットNo)
例1： refs #11 (11はチケット
：
はチケット
例2： fixes #11
：
(copyright2010 akipii@XPJUG関西)
24

27. SCM連携でトレーサビリティ
(copyright2010 akipii@XPJUG関西)
25

28. SCM連携でトレーサビリティ
No Ticket, No Commit!
チケット無しのソースコミット不可！
チケット無しのソースコミット不可！
→チケットにソース修正履歴が残る
(copyright2010 akipii@XPJUG関西)
25

29. チケットの親子関係で要件管理
親チケット＝ストーリーカード、
子チケット＝タスクカード でグループ化する
親チケットの
属性に
子チケットの
情報を
ロールアップ
親チケットか
ら詳細を
子チケットへ
ドリルダウン
(copyright2010 akipii@XPJUG関西)
26

30. 【理由その3】並行開発
Agile開発は自然に並行開発になる
開発は自然に並行開発になる
(copyright2010 akipii@XPJUG関西)
27

31. リリースブランチとタスクブランチ
ブランチのタスク
管理をTiDDで
管理を
で
運用する
(copyright2010 akipii@XPJUG関西)
28

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

33. 第3部
Agile開発のアンチパターン
Agile開発の落とし穴
(copyright2010 akipii@XPJUG関西)
30

34. 【パターン1】変化に追いつけない
名前
変化に追いつけない
頻出場所
タスク管理
再構想解の
プラクティス
チケットファースト、No Ticket, No Commit!
チケットファースト、
棚卸し
根本原因
・タスクが見える化されていない
・タスクが優先順位付けされてない
挿話証拠
「タスクがどんどん溜まっていくね」
症状と結果
チケットが最新化されない
再構想による解
決
・チケットと成果物を紐づける
・定期的に棚卸しする
変種
・乱発されたチケット
・放置されたチケット
(copyright2010 akipii@XPJUG関西)
31

35. 【パターン2】イテレーションを運用できてない
名前
イテレーションを運用できてない
頻出場所
リリース計画
再構想解の
プラクティス
小規模リリース
根本原因
チケットの納期が意識されてないからリリースが１回だけ
挿話証拠
「残業や休日出勤が多いね」
症状と結果
・数えられないぐらいチケットが溜まっている
・開発のリズムが無い
再構想による解
決
・イテレーションをリリース予定バージョンに紐づける
・リリース計画を立てて頻繁に改良する
変種
・空っぽのロードマップ
・リリースは１回だけ
(copyright2010 akipii@XPJUG関西)
32

36. 【パターン3】並行開発できてない
名前
並行開発できていない
頻出場所
構成管理
再構想解の
プラクティス
・メインラインモデル
・タスクブランチ
・トピックブランチ
根本原因
並行開発の構成管理が不十分
挿話証拠
「リリース作業が大変だね」
症状と結果
・マージ作業が大変
・リリース作業が長引く
再構想による解
決
メインラインモデルのタスク管理をチケットで行う
変種
・trunkしかないソース管理
しかないソース管理
・野放図にたくさんあるブランチ
(copyright2010 akipii@XPJUG関西)
33

37. まとめ
ツールがサポートすれば、
ツールがサポートすれば、
行動が変わっていく。
行動が変わっていく。
行動が変われば
が変われば、
行動が変われば、
考え方も変わっていく
も変わっていく。
考え方も変わっていく。
考え方が変われば
考え方が変われば
チームも変わっていく。
人もチームも変わっていく。
チケット駆動開発でアジャイル開発を実践してみよう
BTSがあれば誰でも運用できる
「No Ticket, No Commit !」から始めよう
(copyright2010 akipii@XPJUG関西)
34