Why Ticket Driven Development is Agile? : No Ticket, No Commit!

  • 3,302 views
Uploaded on

【公開】AgileTourOsaka2010講演資料 "Why Ticket Driven Development is Agile? : No Ticket, No Commit!" #agileto2010 #tidd: プログラマの思索 …

【公開】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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,302
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
23
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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】イテレーションを運用できてない 名前 イテレーションを運用できてない 頻出場所 リリース計画 再構想解の プラクティス 小規模リリース 根本原因 チケットの納期が意識されてないからリリースが1回だけ 挿話証拠 「残業や休日出勤が多いね」 症状と結果 ・数えられないぐらいチケットが溜まっている ・開発のリズムが無い 再構想による解 決 ・イテレーションをリリース予定バージョンに紐づける ・リリース計画を立てて頻繁に改良する 変種 ・空っぽのロードマップ ・リリースは1回だけ (copyright2010 akipii@XPJUG関西) 32
  • 36. 【パターン3】並行開発できてない 名前 並行開発できていない 頻出場所 構成管理 再構想解の プラクティス ・メインラインモデル ・タスクブランチ ・トピックブランチ 根本原因 並行開発の構成管理が不十分 挿話証拠 「リリース作業が大変だね」 症状と結果 ・マージ作業が大変 ・リリース作業が長引く 再構想による解 決 メインラインモデルのタスク管理をチケットで行う 変種 ・trunkしかないソース管理 しかないソース管理 ・野放図にたくさんあるブランチ (copyright2010 akipii@XPJUG関西) 33
  • 37. まとめ ツールがサポートすれば、 ツールがサポートすれば、 行動が変わっていく。 行動が変わっていく。 行動が変われば が変われば、 行動が変われば、 考え方も変わっていく も変わっていく。 考え方も変わっていく。 考え方が変われば 考え方が変われば チームも変わっていく。 人もチームも変わっていく。 チケット駆動開発でアジャイル開発を実践してみよう BTSがあれば誰でも運用できる 「No Ticket, No Commit !」から始めよう (copyright2010 akipii@XPJUG関西) 34