• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Why Ticket Driven Development is Agile? : No Ticket, No Commit!
 

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

on

  • 3,556 views

AgileTourOsaka2010講演資料 "Why Ticket Driven Development is Agile? : No Ticket, No Commit!" ...

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

Statistics

Views

Total Views
3,556
Views on SlideShare
3,165
Embed Views
391

Actions

Likes
2
Downloads
23
Comments
0

3 Embeds 391

http://forza.cocolog-nifty.com 386
http://webcache.googleusercontent.com 4
http://translate.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • Why Ticket Driven Development is Agile ? No Ticket, No Commit ! 2010/10/30 akipii@XPJUG Kansai, Japan (copyright2010 akipii@XPJUG関西) 1
    • チケット駆動開発が Agileになる理由 No Ticket, No Commit ! 2010/10/30 あきぴー@XPJUG関西 (copyright2010 akipii@XPJUG関西) 2
    • 自己紹介 HN:あきぴー チケット駆動開発の本を出 版しました (世界初?) Redmineを使って、  チケット駆動開発による  Agileな開発方法について  解説しました 現在 絶賛販売中 (copyright2010 akipii@XPJUG関西) 3
    • Agenda 第1部 チケットファーストでAgile開発! SW開発の問題点 Agile開発の課題 チケット駆動開発とは TiDD運用後 第2部 チケット駆動開発がAgileになる理由 【理由その1】タスク管理 【理由その2】変更管理 【理由その3】並行開発 第3部 Agile開発のアンチパターン まとめ (copyright2010 akipii@XPJUG関西) 4
    • 第1部 チケットファーストでAgile開発! タスクはチケットに 分割して統治せよ (copyright2010 akipii@XPJUG関西) 5
    • SW開発の諸問題 ExcelやMS Projectのガントチャート保守が大変 や のガントチャート保守が大変 残工数や残作業の計算に半日以上かかる 顧客の要求やソース修正の速度にガントチャート保守が追いつかない 突発的な変更に対応しにくい SW開発は突然の仕様変更や緊急の障害修正が多い フィードバックが多すぎて手戻り作業ばかり増える 頻繁なリリースに耐えられない 安易な変更がデグレを起こす プロジェクトにスピード感や   リズム感がない (copyright2010 akipii@XPJUG関西) 6
    • Agile開発の課題 頻繁に変わるタスク管理 頻繁なリリースでタスク管理が大変 アナログのPostIt、かんばんだけでは進捗管理しづらい 継続的な修正と頻繁なリリース管理 継続的な修正と頻繁なリリース管理 と頻繁なリリース 継続的なリファクタリングや機能追加を制御するのは難しい 短期間に順次リリースするプロセスはやっぱり大変 ソフトウェアプロダクトラインに似た並行開発 ソフトウェアプロダクトラインに似た並行開発 一度リリースしたソースは  本番ブランチとして生き続ける 常に本番運用・開発中の  二つのコードラインを  保守するのは大変 かんばん (copyright2010 akipii@XPJUG関西) 7
    • チケット駆動開発の発端(1) チケット駆動開発はTracのチケット管理から生まれた (まちゅさん) ITpro Challenge のライトニングトーク(2007/9) http://www.machu.jp/diary/20070907.html#p01 正式名称:Ticket Driven Development (まちゅさん) BTSを障害管理だけでなくタスク管理に使う(まちゅさん) (copyright2010 akipii@XPJUG関西) 8
    • チケット駆動開発の発端(2) Redmineでアジャイル開発を初めて実践できた(あきぴー) チケット駆動開発の略称「TiDD」 (えと~さん) チケット駆動開発はAjaxみたい (上田さん) 中身(BTS)は古いが新しい衣(TiDD)を被ったアジャイル開発 (copyright2010 akipii@XPJUG関西) 9
    • チケット駆動開発とは(1) 障害も仕様変更も作業もチケットで扱う (Issue Tracking) チケットはSW開発の作業指示書 (Ticket First) BTSチケットをXPのタスクカード のタスクカードのように扱う(阪井さん) のタスクカード タスクは作業しやすい単位のチケットまで分割する(判谷さん) BTSの運用対象を 拡大する (copyright2010 akipii@XPJUG関西) 10
    • チケット駆動開発とは(2) 成果物の変更をチケットで追跡する(Ticket Tracking) チケットへ構成管理情報を付与する チケット無しのソースコミット不可 (No Ticket, No Commit !) (まちゅさん) チケット経由で要件からビルドモジュールまで追跡可能 (Traceability) 見積/実績工数・作業期間をチケットで追跡も可能 (Time Tracking) (copyright2010 akipii@XPJUG関西) 11
    • チケット駆動開発とは(3) 並行開発をチケットで管理する 新規開発(trunk)とその分岐である本番運用(branch)で チケットを使い分ける (MainLine Model) ソース修正やマージ作業はチケットで追跡する (copyright2010 akipii@XPJUG関西) 12
    • TiDD運用後 プロジェクトの問題や進捗を見える化できた 残タスク、進捗率がリアルタイムに一目瞭然 プロジェクトのゴールや問題点、改善点をチームで共有できる TiDDが自然に が自然にAgile開発になった が自然に 開発になった ロードマップがリリース計画に相当する チケットの取捨選択こそがXPの計画ゲーム チケットの取捨選択こそが の計画ゲーム チケットの取捨選択が本来のマネジメント(えと~さん) 開発のリズムが生まれた イテレーション単位でリリースするから開発のリズムが生まれる 開発者は必ずチケットを登録してから作業を始める チケットによるワークフローが自然にペア作業になる リリース後のふりかえりミーティングで運用ルールを改善していく (copyright2010 akipii@XPJUG関西) 13
    • 開発者の1日(例) 9:00   出社後、チームの朝会 【チケットのステータス】 新規→担当 9:30   担当タスクをチケット登録後、作業開始 12:00   昼食 担当→解決 15:00   チケットを解決したので    チケットを解決したのでSVNコミット コミット 17:00   テスターが検証後、チケットを完了 解決→完了 18:00   退社 (copyright2010 akipii@XPJUG関西) 14
    • イテレーションの開発サイクル ユーザ PL 次バージョンへ バージョン登録 問合せ Redmine チケット更新 集計表示 バージョンClose バージョン 開発チーム PG (copyright2010 akipii@XPJUG関西) 15
    • TiDDはPFと相性が良い PFの各種ツールはTiDD上で実現可能 かんばんはステータスごとのチケット集計結果 ニコニコカレンダーはRedmineプラグインで実現済み PFの朝会、ふりかえりはプロセス改善に有効 朝会でロードマップを見ながら、ゴールをチームで共有 リリース後のふりかえりで、開発プロセスの改善点を洗い出す TiDDとPFを組み合わせれば、 と を組み合わせれば、 チーム力を強化できる (copyright2010 akipii@XPJUG関西) 16
    • 第2部 チケット駆動開発が Agileになる理由 チケット駆動開発の 構造を解き明かす (copyright2010 akipii@XPJUG関西) 17
    • 【理由その1】タスク管理 BTSのチケットをXPのタスクカードのように使う(阪井さん) XPのタスクカードをデジタル化する チケットへ作業内容、進捗情報を付与する 計画に基づかない突然のタスク管理がやりやすい BTSは本来、突然発見したバグの管理のためのツール XP BTS かんばん チケット一覧 置き換え チケット タスクカード (copyright2010 akipii@XPJUG関西) 18
    • 強力なイテレーション管理 BTSチケット集計結果をかんばんのように扱う(阪井さん) XPのタスクボードは最新化・集計が面倒 TiDDは、BTSに仕様や進捗の情報を集約できる イテレーションのタスク管理を色んな観点で分析しやすい ワークフロー、ステータス、カテゴリ、担当者、イテレーション かんばん (copyright2010 akipii@XPJUG関西) 19
    • 小規模リリース 2~4週間の間隔で、小刻みに機 能拡張しながらリリースする リリース予定バージョンがイテレー ションに相当する 長期のリリース計画はロードマッ プ 短期のリリース計画はイテレー ション計画 リリースバージョン、終了チケット は変更履歴に残る 自然に繰り返し開発 になるのがポイント (copyright2010 akipii@XPJUG関西) 20
    • 小規模リリース 2~4週間の間隔で、小刻みに機 能拡張しながらリリースする リリース予定バージョンがイテレー ションに相当する 長期のリリース計画はロードマッ プ 短期のリリース計画はイテレー ション計画 リリースバージョン、終了チケット は変更履歴に残る 自然に繰り返し開発 になるのがポイント (copyright2010 akipii@XPJUG関西) 20
    • Ver1.0 リファクタリング 柔軟なチケット管理 Ver1.0 バグ修正 ワークフロー変更 Ver1.0 機能Aの修正、 機能Bの修正 チケットを チケット 起票 更にチケットを分割 Ver1.1 バグ修正 バージョン変更 (copyright2010 akipii@XPJUG関西) 21
    • 【理由その2】変更管理 ロードマップをリリース計画のように扱い、小規模リリー スを運用する開発プロセス Redmineによるチケット駆動開発は、XPの開発ライフサイク ルに似たアジャイル開発! (copyright2010 akipii@XPJUG関西) 22
    • ワークフローで変更管理 (copyright2010 akipii@XPJUG関西) 23
    • ワークフローで変更管理 ソフトウェア開発のワークフローは BTSのワークフロー機能で 制御できる ユーザ権限と チケット種類の単位で ステータスの現在・移行先を 指定する ステータスの移行先 現 在 の ス テ ー タ ス (copyright2010 akipii@XPJUG関西) 23
    • コミット時にチケットとSCM連携 SVNコミットログに下記のキーワードを コミットログに下記のキーワードを 書くとチケットと連携できる。 はチケットNo) 例1: refs #11 (11はチケット : はチケット 例2: fixes #11 : (copyright2010 akipii@XPJUG関西) 24
    • SCM連携でトレーサビリティ (copyright2010 akipii@XPJUG関西) 25
    • SCM連携でトレーサビリティ No Ticket, No Commit! チケット無しのソースコミット不可! チケット無しのソースコミット不可! →チケットにソース修正履歴が残る (copyright2010 akipii@XPJUG関西) 25
    • チケットの親子関係で要件管理 親チケット=ストーリーカード、 子チケット=タスクカード   でグループ化する 親チケットの 属性に 子チケットの 情報を ロールアップ 親チケットか ら詳細を 子チケットへ ドリルダウン (copyright2010 akipii@XPJUG関西) 26
    • 【理由その3】並行開発 Agile開発は自然に並行開発になる 開発は自然に並行開発になる (copyright2010 akipii@XPJUG関西) 27
    • リリースブランチとタスクブランチ ブランチのタスク 管理をTiDDで 管理を で 運用する (copyright2010 akipii@XPJUG関西) 28
    • トピックブランチ チケットの作業をトピックブランチ上で行う手法もある MercurialやGitを使った並行開発 担当者はトピックブランチ作成後、ガンガン開発&修正する 検証完了になって初めてtrunkへpushする ブランチの作業状態をチケットのステータスで管理できる 複数のチケットの作業順とリリース順が異なる場合に有効 (copyright2010 akipii@XPJUG関西) 29
    • 第3部 Agile開発のアンチパターン Agile開発の落とし穴 (copyright2010 akipii@XPJUG関西) 30
    • 【パターン1】変化に追いつけない 名前 変化に追いつけない 頻出場所 タスク管理 再構想解の プラクティス チケットファースト、No Ticket, No Commit! チケットファースト、 棚卸し 根本原因 ・タスクが見える化されていない ・タスクが優先順位付けされてない 挿話証拠 「タスクがどんどん溜まっていくね」 症状と結果 チケットが最新化されない 再構想による解 決 ・チケットと成果物を紐づける ・定期的に棚卸しする 変種 ・乱発されたチケット ・放置されたチケット (copyright2010 akipii@XPJUG関西) 31
    • 【パターン2】イテレーションを運用できてない 名前 イテレーションを運用できてない 頻出場所 リリース計画 再構想解の プラクティス 小規模リリース 根本原因 チケットの納期が意識されてないからリリースが1回だけ 挿話証拠 「残業や休日出勤が多いね」 症状と結果 ・数えられないぐらいチケットが溜まっている ・開発のリズムが無い 再構想による解 決 ・イテレーションをリリース予定バージョンに紐づける ・リリース計画を立てて頻繁に改良する 変種 ・空っぽのロードマップ ・リリースは1回だけ (copyright2010 akipii@XPJUG関西) 32
    • 【パターン3】並行開発できてない 名前 並行開発できていない 頻出場所 構成管理 再構想解の プラクティス ・メインラインモデル ・タスクブランチ ・トピックブランチ 根本原因 並行開発の構成管理が不十分 挿話証拠 「リリース作業が大変だね」 症状と結果 ・マージ作業が大変 ・リリース作業が長引く 再構想による解 決 メインラインモデルのタスク管理をチケットで行う 変種 ・trunkしかないソース管理 しかないソース管理 ・野放図にたくさんあるブランチ (copyright2010 akipii@XPJUG関西) 33
    • まとめ ツールがサポートすれば、 ツールがサポートすれば、 行動が変わっていく。 行動が変わっていく。 行動が変われば が変われば、 行動が変われば、 考え方も変わっていく も変わっていく。 考え方も変わっていく。 考え方が変われば 考え方が変われば チームも変わっていく。 人もチームも変わっていく。 チケット駆動開発でアジャイル開発を実践してみよう BTSがあれば誰でも運用できる 「No Ticket, No Commit !」から始めよう (copyright2010 akipii@XPJUG関西) 34