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

6,867 views
6,686 views

Published on

【公開】XP祭り関西2009講演資料「チケットファーストでアジャイル開発!~チケットに分割して統治せよ」: プログラマの思索 http://forza.cocolog-nifty.com/blog/2009/02/xp2009-746a.html
(2009/1/24)

祭り09詳細 - XPJUG関西wiki
http://www.xpjug.jp/cgi-bin/main_wiki/wiki.cgi?page=%BA%D7%A4%EA%A3%B0%A3%B9%BE%DC%BA%D9

Published in: Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,867
On SlideShare
0
From Embeds
0
Number of Embeds
764
Actions
Shares
0
Downloads
84
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

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

  1. 1. XPJUG関西(Copyright Akipii)1 チケットファーストでチケットファーストでチケットファーストでチケットファーストで アジャイル開発!アジャイル開発!アジャイル開発!アジャイル開発! 2009/01/24 あきぴー チケットに分割して統治せよチケットに分割して統治せよチケットに分割して統治せよチケットに分割して統治せよ
  2. 2. XPJUG関西(Copyright Akipii)2 自己紹介 HN:あきぴー 主な職歴 業務系Webシステムの開発部隊に所属 プログラミングからプロジェクト管理まで何でも 興味 XP、Scrumなどのアジャイル開発
  3. 3. XPJUG関西(Copyright Akipii)3 第第第第1部部部部 チケット駆動開発の発端チケット駆動開発の発端チケット駆動開発の発端チケット駆動開発の発端 チケットはチケットはチケットはチケットは XPのタスクカードのタスクカードのタスクカードのタスクカード
  4. 4. XPJUG関西(Copyright Akipii)4 アジャイル開発の利点 要望から実装・リリースまでの期間が短い イテレーション単位に小さく作ってリリースする繰り返し開発 早めにリリースするから重大な問題を早く検知できる リリース後も継続的な修正を受け入れる 次のイテレーションで改善要望を機能追加できる 小さく作るからリリースのリスクが小さい SW構成管理(SCM)の重要性を再認識させた ソース共同所有でいつでも誰でもソースを修正可能 テスト駆動開発(TDD)で単体テスト品質を保証 継続的インテグレーション(CI)で常時リリース可能
  5. 5. XPJUG関西(Copyright Akipii)5 アジャイル開発の運用の課題 進化的保守 イテレーション計画は流動的な為、細かなタスク 変更が多く、リアルタイムな進捗管理が難しい 並行開発 継続的な機能追加によってソースの修正が多い 本番・開発中各々のソース管理に手間がかかる 変更管理 リファクタリング、バグ修正、機能追加等の色々 な変更が混在する為、品質を制御しにくい
  6. 6. XPJUG関西(Copyright Akipii)6 チケット駆動開発の発端 ルーツはバグ管理システム(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」だと「テスト駆動開発」と間違えそう
  7. 7. XPJUG関西(Copyright Akipii)7 チケット駆動開発とは(1) BTSのチケットをXPのタスクカードのように使う XPのタスクカードをデジタル化する ( 阪井さん@SRA先端技術研究所から ) 障害も要望もチケットで扱う(Issue Tracking) 作業状態、進捗情報はチケットで一元管理 ガントチャート、バーンダウンチャートで進捗管理 バグ修正や機能追加等をワークフロー管理 チケット集計結果からバグ収束曲線等で品質管理
  8. 8. XPJUG関西(Copyright Akipii)8 チケットの概念モデル(Redmine)
  9. 9. XPJUG関西(Copyright Akipii)9 チケット駆動開発とは(2) ソースの変更はチケットと関連付ける チケットからソースの修正理由を追跡できる 例:ソースAの修正で影響を受けるソースは? ソースソースソースソースAのコミット履歴のコミット履歴のコミット履歴のコミット履歴 からチケットを探すからチケットを探すからチケットを探すからチケットを探す
  10. 10. XPJUG関西(Copyright Akipii)10 チケット駆動開発とは(3) 並行開発をチケットで管理する 新規開発(trunk)とその分岐である本番運用(branch) でチケットを使い分ける コードライン単位で異なる目的の作業をチケット管理で きる
  11. 11. XPJUG関西(Copyright Akipii)11 TiDDの運用サイクル(Redmine) Redmine PL ユーザ PG 開発チーム バージョン登録 チケット更新 集計表示 問合せ バージョンClose 次バージョンへ
  12. 12. XPJUG関西(Copyright Akipii)12 チケット駆動開発のプラクティス キャッチフレーズは「チケットに分割して統治せよチケットに分割して統治せよチケットに分割して統治せよチケットに分割して統治せよ」 1. チケット・ファースト(Ticket First) プロジェクトの作業はチケットを受け取ってから始める チケット無しで成果物の更新不可 2. チケットで分割統治(Divide and Conquer) チケットの粒度は追跡可能なタスクまで細分化する バージョン毎にチケットをグループ化してまとめる 3. 小規模リリース(Small Releases) バージョン毎に小さく作って小刻みにリリースする リリース結果は終了チケットの履歴として残る 4. ふりかえり(Retrospect) チケット集計結果から次バージョンへ向けて改善しよう
  13. 13. XPJUG関西(Copyright Akipii)13 第第第第2部部部部 チケット駆動開発の実践チケット駆動開発の実践チケット駆動開発の実践チケット駆動開発の実践 Redmineの運用例の運用例の運用例の運用例
  14. 14. XPJUG関西(Copyright Akipii)14 チケット駆動開発の機能構成図(例) バージョン管理バージョン管理バージョン管理バージョン管理ビルド管理 変更管理変更管理変更管理変更管理マネジメントマネジメントマネジメントマネジメント 継続的インテグレーション継続的インテグレーション継続的インテグレーション継続的インテグレーション テスト駆動開発テスト駆動開発テスト駆動開発テスト駆動開発 ソース共同所有ソース共同所有ソース共同所有ソース共同所有 メインラインモデルメインラインモデルメインラインモデルメインラインモデル チケット駆動開発チケット駆動開発チケット駆動開発チケット駆動開発
  15. 15. XPJUG関西(Copyright Akipii)15 (1-1)ワークフロー管理 ロール、トラッカー、ステータスロール、トラッカー、ステータスロール、トラッカー、ステータスロール、トラッカー、ステータス でワークフローを切り替え可能でワークフローを切り替え可能でワークフローを切り替え可能でワークフローを切り替え可能 ↓ 1.ロール:管理者、開発者ロール:管理者、開発者ロール:管理者、開発者ロール:管理者、開発者etc 2.トラッカー:バグ、新規開発トラッカー:バグ、新規開発トラッカー:バグ、新規開発トラッカー:バグ、新規開発etc 3.ステータスは先行と移行先のステータスは先行と移行先のステータスは先行と移行先のステータスは先行と移行先の マトリックスで一覧表示マトリックスで一覧表示マトリックスで一覧表示マトリックスで一覧表示
  16. 16. XPJUG関西(Copyright Akipii)16 (1-2)チケットの状態遷移図(Redmine)
  17. 17. XPJUG関西(Copyright Akipii)17 (1-3)運用フロー(Redmine)
  18. 18. XPJUG関西(Copyright Akipii)18 (2)ロードマップ作成 Redmineのバージョンがイテレーションに相当する。のバージョンがイテレーションに相当する。のバージョンがイテレーションに相当する。のバージョンがイテレーションに相当する。 バージョン単位で進捗率、関連チケットを表示する。バージョン単位で進捗率、関連チケットを表示する。バージョン単位で進捗率、関連チケットを表示する。バージョン単位で進捗率、関連チケットを表示する。 →プロジェクトの進捗はイテレーションで管理する。プロジェクトの進捗はイテレーションで管理する。プロジェクトの進捗はイテレーションで管理する。プロジェクトの進捗はイテレーションで管理する。
  19. 19. XPJUG関西(Copyright Akipii)19 (3) チケット登録 1.トラッカー:チケットの種類トラッカー:チケットの種類トラッカー:チケットの種類トラッカー:チケットの種類 2.ステータス:チケットの作業状態ステータス:チケットの作業状態ステータス:チケットの作業状態ステータス:チケットの作業状態 3.TargetVersion::::マイルストーンマイルストーンマイルストーンマイルストーン 4.開始日、終了日:作業期間開始日、終了日:作業期間開始日、終了日:作業期間開始日、終了日:作業期間 5.カテゴリ:機能の単位。カテゴリ:機能の単位。カテゴリ:機能の単位。カテゴリ:機能の単位。
  20. 20. XPJUG関西(Copyright Akipii)20 (4)ガントチャート チケットに開始日、終了日を記入すれば、チケットに開始日、終了日を記入すれば、チケットに開始日、終了日を記入すれば、チケットに開始日、終了日を記入すれば、 ガントチャートを自動生成してくれる。ガントチャートを自動生成してくれる。ガントチャートを自動生成してくれる。ガントチャートを自動生成してくれる。
  21. 21. XPJUG関西(Copyright Akipii)21 (5-1)バージョン管理と連携 SVNリポジトリを一覧表示。リポジトリを一覧表示。リポジトリを一覧表示。リポジトリを一覧表示。 プロジェクトとソースリポジトリがプロジェクトとソースリポジトリがプロジェクトとソースリポジトリがプロジェクトとソースリポジトリが1対対対対1対応。対応。対応。対応。
  22. 22. XPJUG関西(Copyright Akipii)22 (5-2)コミット時にチケットと連携 SVNコミットログに下記のキーワードをコミットログに下記のキーワードをコミットログに下記のキーワードをコミットログに下記のキーワードを 書くとチケットと連携できる。書くとチケットと連携できる。書くとチケットと連携できる。書くとチケットと連携できる。 例例例例1:::: refs 11 例例例例2:::: fixes 11 (11はチケットはチケットはチケットはチケットNo)
  23. 23. XPJUG関西(Copyright Akipii)23 (5-3)チケットにリビジョン表示 チケットにチケットにチケットにチケットにSVNリビジョンを表示リビジョンを表示リビジョンを表示リビジョンを表示 ↓ ソースから変更理由を追跡できるソースから変更理由を追跡できるソースから変更理由を追跡できるソースから変更理由を追跡できる
  24. 24. XPJUG関西(Copyright Akipii)24 (6) リリース後にニュースで告知
  25. 25. XPJUG関西(Copyright Akipii)25 (7-1)サマリ(チケット集計結果) トラッカーやバージョン毎に、残チケットの作業状態を表示。トラッカーやバージョン毎に、残チケットの作業状態を表示。トラッカーやバージョン毎に、残チケットの作業状態を表示。トラッカーやバージョン毎に、残チケットの作業状態を表示。 開発チームの成績表に相当する。開発チームの成績表に相当する。開発チームの成績表に相当する。開発チームの成績表に相当する。
  26. 26. XPJUG関西(Copyright Akipii)26 (7-2)リポジトリ統計 SVNリポジトリの月別リビジョン回数、コミット回数を表示。リポジトリの月別リビジョン回数、コミット回数を表示。リポジトリの月別リビジョン回数、コミット回数を表示。リポジトリの月別リビジョン回数、コミット回数を表示。 開発チームの活発度合いが分かる。開発チームの活発度合いが分かる。開発チームの活発度合いが分かる。開発チームの活発度合いが分かる。
  27. 27. XPJUG関西(Copyright Akipii)27 TiDDをRedmineで運用後 プロジェクトの問題や進捗を見える化できた 残タスク、進捗率がリアルタイムに一目瞭然 遅延タスクが明確なので進捗管理しやすくなった アジャイル開発をようやく理解できた RedmineロードマップがXPのイテレーション計画に相当する プロジェクトの進捗はイテレーションで制御する発想 チケットの取捨選択が重要(本来のマネジメント) 開発者の受けもいい 変更理由はチケットに書くのでソースが綺麗 バグを見つけたら自発的にチケット登録してくれる チケット管理の課題が見えてきた チケットをリアルタイムに保守しなければ、BTSは無意味 プロジェクト管理をチケット管理に置き換える発想
  28. 28. XPJUG関西(Copyright Akipii)28 チケット駆動開発の特徴 タスクをToDo(課題)として管理する 顧客の要望と開発者の工数見積のバランスで優先順位付け チケットの取捨選択でイテレーション計画は頻繁に変わる ソースから作業理由・要件を追跡しやすい 例えば過去のパッチの意図を検索できる 要件→仕様→【チケット】←ソースのトレーサビリティが可能 自然に強力なSW構成管理のインフラになる 変更管理、構成管理、メトリクス収集が自動化される 開発者はチケットだけ意識すればいい メインラインモデルとチケット駆動開発は相性が良い バグ修正と機能追加はチケットの種類を変える
  29. 29. XPJUG関西(Copyright Akipii)29 チケット駆動開発の運用の注意点 チケットを乱発・放置しない運用は何か? リリース時期が不明なチケットは内部課題で一旦保留 遅延したチケットは更にチケットを分割する SW開発の全業務をカバーできるか? インシデント管理はバグと異なる別種類のチケットにする 基本は成果物を作る作業をチケットに対応付ける 大規模チームで運用できるか? チケット管理だけの専門担当者を置く 構成管理会議(CCB)でチケット解決の方針を決定する チケット集計結果から得られたメトリクスを過信しない メトリクスの意味を正しく理解して、意思決定に使いましょう
  30. 30. XPJUG関西(Copyright Akipii)30 まとめ・謝辞 アジャイル開発はチケット・ファーストから始めよう タスクはチケットに分割して統治せよ アジャイル開発は高度なSW構成管理ツールを必要とする チケット駆動開発は、Ajaxみたい 中身(BTS)は古いが新しい衣(TiDD)を被ったアジャイル開発 謝辞 チケット駆動開発の提唱者まちゅさん 勉強会で一緒に議論してくれた仲間へ えと~さん、東さん、よしうみさん、たけぷ~さん、うえださん、Tanigon さん、せりまささん、判谷さん、猪原さん、阪井さん 講演の場を提供してくれたXPJUG関西へ

×