XP祭り関西2011講演資料「Agile開発のスケールアップ~Agile2.0を支えるチケット駆動開発」

3,996 views

Published on

【公開】XP祭り関西2011講演資料「Agile開発のスケールアップ~Agile2.0を支えるチケット駆動開発」 #xpjugkansai: プログラマの思索 http://forza.cocolog-nifty.com/blog/2011/02/xp2011agileagil.html

XP祭り関西2011講演資料
「Agile開発のスケールアップ~Agile2.0を支えるチケット駆動開発」
XP祭り関西2011 - XPJUG関西wiki
http://www.xpjug.jp/cgi-bin/main_wiki/wiki.cgi?page=%A3%D8%A3%D0%BA%D7%A4%EA%B4%D8%C0%BE%A3%B2%A3%B0%A3%B1%A3%B1

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

No Downloads
Views
Total views
3,996
On SlideShare
0
From Embeds
0
Number of Embeds
946
Actions
Shares
0
Downloads
13
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

XP祭り関西2011講演資料「Agile開発のスケールアップ~Agile2.0を支えるチケット駆動開発」

  1. 1. Agile開発のスケールアップ Agile2.0を支えるチケット駆動開発 2011/1/29 あきぴー@XPJUG関西 (copyright2011 akipii@XPJUG関西) 1
  2. 2. 自己紹介 HN:あきぴー チケット駆動開発の本を書 きました 現在 絶賛販売中 (copyright2011 akipii@XPJUG関西) 2
  3. 3. Agenda 初期Agileの特徴と課題 Agile復活の流れ スケールアップの戦略 【注意】 試行錯誤中のアイデアも 含んでいます。 【1】チケット駆動開発 【2】組織体制・権限 【3】イテレーション管理 【4】構成管理 大規模プロジェクトで運用する注意点 まとめ・謝辞 (copyright2011 akipii@XPJUG関西) 3
  4. 4. 初期Agileの特徴 定期的なリリースによって、小刻みにシステムを VerUpしていく(小規模リリース) コスト・スコープ・納期の三角形でマネジメント 顧客などのステークホルダーを全員巻き込んで開発 要件漏れやビルド漏れ等のリスクを早期に検知可能 SW開発を自動化する技術を重視 しかし、Agile開発をスケールアップするのは難しい 開発をスケールアップするのは難しい しかし、 と従来から言われ続けてきた (copyright2011 akipii@XPJUG関西) 4
  5. 5. 初期Agileの課題(1) チーム間をまたがる課 題管理や顧客調整が 難しい 他チームにライブラリ作 成を依頼する課題 分散したチーム間のコ ミュニケーション オンサイト顧客の実現 は到底無理 かんばん かんばん、コミュニケーションだけでは解決できない 組織構造を全体最適化する必要がある (copyright2010 akipii@XPJUG関西) 5
  6. 6. 初期Agileの課題(2) チーム間のイテレーションの同期が難しい 開発チームごとに開発速度が違うため、ばらつきが出る システム統合の場面がどうしても出てくる 複数の開発チームの成果物を結合して初めて動く タイムラグ が発生 システム統合 が発生 イテレーション チームA チームB (copyright2011 akipii@XPJUG関西) 6
  7. 7. 初期Agileの課題(3) 大規模プロジェクト特有の構成管理が難しい 過去の資産を流用・移植する手法が多い(派生開発) 過去の資産の共通部品化は高度な設計力を必要とする 共通部品をコア資産として保守するのは大変 2009 2010 2011 製品A フィードバック 移植 派生・移植 製品B 派生・移植 製品C (copyright2011 akipii@XPJUG関西) 7
  8. 8. Agile復活の流れ 2005年頃から「2週目のAgile  (Agile2.0)」と呼ばれる流れが起 きた Scrum プロジェクトファシリテーション(PF) 高機能化したBTS/ITS IBM、MSなどのベンダーのサポート 大規模プロジェクトへAgile開発を 適用したい動機がある (copyright2011 akipii@XPJUG関西) 8
  9. 9. スケールアップの戦略 TiDDの運用と「Agile開発の本質とスケールアップ」本のノウハウを組合せる の運用と の運用 開発の本質とスケールアップ」本のノウハウを組合せる TiDDは作業の見える化とナレッジ収集をサポート 「スケールアップ」本のノウハウで組織体制や運用手順をサポート Agileなチームを な 支える構造 運用手順 (【3】イテレーション 【 】  管理,  管理 【4】構成管理 etc.) 】 Agile開発チーム (PM, PG) PMIS ナレッジ (データ) 【2】組織体制・権限 】 (copyright2011 akipii@XPJUG関西) Agile2.0がカバーす がカバーす る範囲 【1】TiDDがカバーす 】 る範囲 (チケット管理, ワークフロー管理, トレーサビリティ, データマイニング) 9
  10. 10. 【1】チケット駆動開発 Agile開発チーム (PM, PG) 運用手順 (【3】イテレーション 【 】  管理,  管理 【4】構成管理 etc.) 】 PMIS ナレッジ (データ) 【2】組織体制・権限 】 (copyright2011 akipii@XPJUG関西) 10
  11. 11. チケット駆動開発の発端 チケット駆動開発は チケット駆動開発はTracのチケット管理から生まれた(まちゅさん) のチケット管理から生まれた http://www.machu.jp/diary/20070907.html#p01 正式名称:Ticket Driven Development (まちゅさん) BTS/ITSを障害管理だけでなくタスク管理に使う(まちゅさん) Redmineでアジャイル開発を初めて実践できた(あきぴー) でアジャイル開発を初めて実践できた チケット駆動開発はAjaxみたい (上田さん) 中身(BTS)は古いが新しい衣(TiDD)を被ったアジャイル開発 (copyright2011 akipii@XPJUG関西) 11
  12. 12. チケット駆動開発とは 障害も要望もチケットで扱う(Issue Tracking) 作業状態、進捗情報はチケットで一元管理 チケット駆動開発の運用ルールは二つだけ BTSチケットはXPのタスクカードのように扱う(阪井さん) チケットはSW開発の作業指示書 (Ticket First) BTSチケットに構成管理情報を付与する チケット無しのソースコミット不可 (No Ticket, No Commit !) 入力 チケット (まちゅさん) 出力  作業 ソース・設計書 担当 開発者 (copyright2011 akipii@XPJUG関西) 12
  13. 13. 強力なチケット集計機能 BTSチケット集計結果をかんばんのように扱う(阪井さん) XPのタスクボードは最新化・集計が面倒 色んな観点でチケット集計したメトリクスを出力可能 かんばん (copyright2011 akipii@XPJUG関西) 13
  14. 14. SCM連携でトレーサビリティ (copyright2011 akipii@XPJUG関西) 14
  15. 15. SCM連携でトレーサビリティ No Ticket, No Commit! チケット無しのソースコミット不可! チケット無しのソースコミット不可! →チケットにソース修正履歴が残る (copyright2011 akipii@XPJUG関西) 14
  16. 16. ワークフローで変更管理 SW開発のワークフローはBTSのワークフロー機能で制御 できる ユーザ権限と チケット種類の単位で ステータスの現在・移行先を 指定する ステータスの移行先 現 在 の ス テ ー タ ス (copyright2011 akipii@XPJUG関西) 15
  17. 17. 小規模リリース 2~4週間の間隔で、小刻みに機 能拡張しながらリリースする リリース予定バージョンがイテレー ションに相当する 長期のリリース計画はロードマッ プ 短期のリリース計画はイテレー ション計画 終了チケットは変更履歴に残る 「いつリリースするか」と 「どのバージョンに設定するか」 は同じ! (copyright2011 akipii@XPJUG関西) 16
  18. 18. TiDDがAgileになる理由 ロードマップをリリース計画のように扱い、小規模リリー スを運用する開発プロセス Redmineによるチケット駆動開発は、XPの開発ライフサイク ルに似たアジャイル開発 (copyright2011 akipii@XPJUG関西) 17
  19. 19. TiDDはPMISを目指す (copyright2011 akipii@XPJUG関西) 18
  20. 20. TiDDはPMISを目指す (copyright2011 akipii@XPJUG関西) 18
  21. 21. TiDDはプロセス資産になる TiDDで一元管理 で されたデータは、 ナレッジDBになる ナレッジ になる (copyright2011 akipii@XPJUG関西) 19
  22. 22. 【2】組織体制・権限 Agile開発チーム (PM, PG) 運用手順 (【3】イテレーション 【 】  管理,  管理 【4】構成管理 etc.) 】 PMIS ナレッジ (データ) 【2】組織体制・権限 】 (copyright2011 akipii@XPJUG関西) 20
  23. 23. 顧客プロキシ(倉貫さん) 設計チームが開発チームと顧客の橋渡しの役割を担う 設計チームが開発の前に先行して要件を引き出す ブリッジSEのチームと同義 開発フェーズで設計メンバーは開発チームの顧客役(オンサイト顧客) になる 開発チームA 設計チーム 顧客 システム提案 要件定義 仕様を伝達 課題管理 開発チームB 顧客プロキシ (オンサイト顧客 オンサイト顧客 の代理人) の代理人 (copyright2011 akipii@XPJUG関西) 21
  24. 24. Scrum of Scrum 週次追跡 (スケールアップ スケールアップ) スケールアップ チーム間の課題の棚卸し会議 Scrumマスター(リーダー)同士で調整する ステアリング コミッティー スクラムオブスクラム Scrumマスターが集合 マスターが集合 した課題管理会議 日次追跡 Scrumマスター マスター 日次追跡 日次追跡 日次追跡 ScrumチームA ScrumチームB ScrumチームC アジャイルコンポーネントチーム (copyright2011 akipii@XPJUG関西) 22
  25. 25. エスカレーションと委譲 PM 自チーム 別PM エスカレーション 権限委譲 承認 エスカレーション フィードバック PG ペア作業 テスター 大規模プロジェクトほどエスカレーションと委譲が多くなる 他チームに依頼する作業はエスカレーションする メンバーに権限委譲して、自己組織化した方が効率的 (copyright2011 akipii@XPJUG関西) 23
  26. 26. Ver1.0 リファクタリング 柔軟なチケット管理 Ver1.0 バグ修正 ワークフロー変更 Ver1.0 機能Aの修正、 機能Bの修正 チケットを チケット 起票 更にチケットを分割 Ver1.1 バグ修正 別チームへ エスカレーション バージョン変更 チケットをコピー (copyright2011 akipii@XPJUG関西) 24
  27. 27. 【3】イテレーション管理 Agile開発チーム (PM, PG) 運用手順 (【3】イテレーション 【 】  管理,  管理 【4】構成管理 etc.) 】 PMIS ナレッジ (データ) 【2】組織体制・権限 】 (copyright2011 akipii@XPJUG関西) 25
  28. 28. アジャイルリリーストレイン イテレーション1 イテレーション イテレーション2 イテレーション イテレーション3 イテレーション (スケールアップ スケールアップ) スケールアップ イテレーション4 イテレーション 開発チームA 開発チーム アジャイルリリー ストレインとは、 電車が時刻表に 従って、発車・到 着するイメージを 比喩した概念 開発チームB 開発チーム 開発チームC 開発チーム 全チームのイテレーションは同期しているので、 リリースのタイミングも同じ。 (copyright2011 akipii@XPJUG関西) 26
  29. 29. イテレーションの継承 親プロジェクトのイテレーションを 子プロジェクトへ強制できる (1)イテレーション イテレーション1 イテレーション  を作成 開発チームA 開発チーム プロジェクト全体 (リリースモジュール リリースモジュール) リリースモジュール (2)イテレーション イテレーション1 イテレーション  を継承 開発チームB 開発チーム (copyright2011 akipii@XPJUG関西) 27
  30. 30. イテレーションの階層化(細谷さん) イテレーション1 イテレーション2 プロジェクト 全体 早めに内部リリースして 動作確認 正式リリースで 動作確認 組込製品や パッケージ 製品開発で よく使われ ている 開発チームA 開発チーム (or 開発チーム 開発チームB) イテレーション1/4 イテレーション3/4 イテレーション2/4 イテレーション4/4 (copyright2011 akipii@XPJUG関西) 28
  31. 31. 反復型開発(細谷さん) 前半のイテレーションは Agileな開発 後半のイテレーションは 過去のコンポーネント統合 システム 開発 過去のコンポーネントを統合 システム全体で統合/テストしたりするイテレーションを別途設 ける 複数チームの成果物を統合して検証する HWとSWを結合してテストする 受入テストの観点でシステム全体を動作確認する (copyright2011 akipii@XPJUG関西) 29
  32. 32. (スケールアップ スケールアップ) スケールアップ アーキテクチャ助走路 前半のイテレーションは 共通部品の作り込み 後半のイテレーションは 各コンポーネントをAgileに開発 アーキテクチャ 設計 開発チームA アーキテクチャ 助走路 開発チームB 全体アーキテクチャ設計とコンポーネント開発のイテレーションを分ける 前半のイテレーションで全体アーキテクチャを作り込む フレームワークや共通部品を作った後に、Agileに開発していく (copyright2011 akipii@XPJUG関西) 30
  33. 33. 【4】構成管理 Agile開発チーム (PM, PG) 運用手順 (【3】イテレーション 【 】  管理,  管理 【4】構成管理 etc.) 】 PMIS ナレッジ (データ) 【2】組織体制・権限 】 (copyright2011 akipii@XPJUG関西) 31
  34. 34. SWプロダクトライン 大規模プロジェクト開発へSWプロダクトラインの考え方を取り入れる プロダクトラインの考え方を取り入れる 大規模プロジェクト開発へ 製品ファミリー開発の一手法で、派生開発や移植作業に強い フレームワークや共通部品はコア資産化 コア資産から分岐した各アプリケーションは製品群として派生開発する 前半のイテレーションは 共通部品の作り込み 後半のイテレーションは 製品系列をAgileに開発 プロダクトライン の開発 フィードバック 抽出 製品A開発 コア資産 製品B開発 (copyright2011 akipii@XPJUG関西) 32
  35. 35. 移植作業とベンダブランチ 派生元から派生先への移植作業を構成管理する ベンダブランチは、派生元のVerUpを派生先に取り込むSCMパターン (copyright2011 akipii@XPJUG関西) 33
  36. 36. 大規模プロジェクト運用の注意点 顧客プロキシの運用は難しい 設計チームの負荷が高い 分散開発の場合、開発チームとのコミュニケーションロスが大きい Scrum of Scrumは定期的に開催する 他チームへ依頼して放置されたチケットは定期的に棚卸し 無駄な会議にならないような工夫(例:PF)が必要 イテレーションのバリエーションが多いほどスケールアップし やすい 状況に応じて、イテレーションの目的を柔軟に変える SWプロダクトラインの開発は難しい 共通部品化するのにコストがかかる 派生先の開発は派生元の開発スケジュールに依存する (copyright2011 akipii@XPJUG関西) 34
  37. 37. まとめ・謝辞 Agile開発を大規模プロジェクトに適用できる時代になってい る Agile開発のエッセンスに各種技法を混ぜる チケット駆動開発がAgile開発のインフラになる スケールアップのノウハウはもっと必要 分散開発のコミュニケーションをPFがサポートできないか? チケット駆動開発でサポートできる作業は無いか? 謝辞 講演の場を提供して頂いたXPJUG関西 (copyright2011 akipii@XPJUG関西) 35

×