SlideShare a Scribd company logo
Agile開発のスケールアップ
Agile2.0を支えるチケット駆動開発

2011/1/29
あきぴー@XPJUG関西
(copyright2011 akipii@XPJUG関西)

1
自己紹介
HN:あきぴー
チケット駆動開発の本を書
きました

現在 絶賛販売中

(copyright2011 akipii@XPJUG関西)

2
Agenda
初期Agileの特徴と課題
Agile復活の流れ
スケールアップの戦略

【注意】
試行錯誤中のアイデアも
含んでいます。

【1】チケット駆動開発
【2】組織体制・権限
【3】イテレーション管理
【4】構成管理

大規模プロジェクトで運用する注意点
まとめ・謝辞

(copyright2011 akipii@XPJUG関西)

3
初期Agileの特徴
定期的なリリースによって、小刻みにシステムを
VerUpしていく(小規模リリース)
コスト・スコープ・納期の三角形でマネジメント
顧客などのステークホルダーを全員巻き込んで開発
要件漏れやビルド漏れ等のリスクを早期に検知可能
SW開発を自動化する技術を重視

しかし、Agile開発をスケールアップするのは難しい
開発をスケールアップするのは難しい
しかし、
と従来から言われ続けてきた
(copyright2011 akipii@XPJUG関西)

4
初期Agileの課題(1)
チーム間をまたがる課
題管理や顧客調整が
難しい
他チームにライブラリ作
成を依頼する課題
分散したチーム間のコ
ミュニケーション
オンサイト顧客の実現
は到底無理

かんばん

かんばん、コミュニケーションだけでは解決できない
組織構造を全体最適化する必要がある
(copyright2010 akipii@XPJUG関西)

5
初期Agileの課題(2)
チーム間のイテレーションの同期が難しい
開発チームごとに開発速度が違うため、ばらつきが出る
システム統合の場面がどうしても出てくる
複数の開発チームの成果物を結合して初めて動く

タイムラグ
が発生

システム統合
が発生

イテレーション
チームA
チームB

(copyright2011 akipii@XPJUG関西)

6
初期Agileの課題(3)
大規模プロジェクト特有の構成管理が難しい
過去の資産を流用・移植する手法が多い(派生開発)
過去の資産の共通部品化は高度な設計力を必要とする
共通部品をコア資産として保守するのは大変
2009

2010

2011

製品A
フィードバック

移植

派生・移植
製品B
派生・移植
製品C
(copyright2011 akipii@XPJUG関西)

7
Agile復活の流れ
2005年頃から「2週目のAgile 
(Agile2.0)」と呼ばれる流れが起
きた
Scrum
プロジェクトファシリテーション(PF)
高機能化したBTS/ITS
IBM、MSなどのベンダーのサポート

大規模プロジェクトへAgile開発を
適用したい動機がある
(copyright2011 akipii@XPJUG関西)

8
スケールアップの戦略
TiDDの運用と「Agile開発の本質とスケールアップ」本のノウハウを組合せる
の運用と
の運用
開発の本質とスケールアップ」本のノウハウを組合せる
TiDDは作業の見える化とナレッジ収集をサポート
「スケールアップ」本のノウハウで組織体制や運用手順をサポート
Agileなチームを
な
支える構造

運用手順
(【3】イテレーション
【 】
 管理,
 管理
【4】構成管理 etc.)
】

Agile開発チーム
(PM, PG)

PMIS

ナレッジ
(データ)

【2】組織体制・権限
】
(copyright2011 akipii@XPJUG関西)

Agile2.0がカバーす
がカバーす
る範囲

【1】TiDDがカバーす
】
る範囲
(チケット管理,
ワークフロー管理,
トレーサビリティ,
データマイニング)
9
【1】チケット駆動開発
Agile開発チーム
(PM, PG)

運用手順
(【3】イテレーション
【 】
 管理,
 管理
【4】構成管理 etc.)
】

PMIS

ナレッジ
(データ)

【2】組織体制・権限
】
(copyright2011 akipii@XPJUG関西)

10
チケット駆動開発の発端
チケット駆動開発は
チケット駆動開発はTracのチケット管理から生まれた(まちゅさん)
のチケット管理から生まれた
http://www.machu.jp/diary/20070907.html#p01

正式名称:Ticket Driven Development (まちゅさん)
BTS/ITSを障害管理だけでなくタスク管理に使う(まちゅさん)

Redmineでアジャイル開発を初めて実践できた(あきぴー)
でアジャイル開発を初めて実践できた
チケット駆動開発はAjaxみたい (上田さん)
中身(BTS)は古いが新しい衣(TiDD)を被ったアジャイル開発

(copyright2011 akipii@XPJUG関西)

11
チケット駆動開発とは
障害も要望もチケットで扱う(Issue Tracking)
作業状態、進捗情報はチケットで一元管理

チケット駆動開発の運用ルールは二つだけ
BTSチケットはXPのタスクカードのように扱う(阪井さん)
チケットはSW開発の作業指示書 (Ticket First)

BTSチケットに構成管理情報を付与する
チケット無しのソースコミット不可 (No Ticket, No Commit !)
入力

チケット

(まちゅさん)

出力

 作業

ソース・設計書

担当

開発者
(copyright2011 akipii@XPJUG関西)

12
強力なチケット集計機能
BTSチケット集計結果をかんばんのように扱う(阪井さん)
XPのタスクボードは最新化・集計が面倒
色んな観点でチケット集計したメトリクスを出力可能

かんばん
(copyright2011 akipii@XPJUG関西)

13
SCM連携でトレーサビリティ

(copyright2011 akipii@XPJUG関西)

14
SCM連携でトレーサビリティ
No Ticket, No Commit!
チケット無しのソースコミット不可!
チケット無しのソースコミット不可!
→チケットにソース修正履歴が残る

(copyright2011 akipii@XPJUG関西)

14
ワークフローで変更管理
SW開発のワークフローはBTSのワークフロー機能で制御
できる

ユーザ権限と
チケット種類の単位で
ステータスの現在・移行先を
指定する
ステータスの移行先

現
在
の
ス
テ
ー
タ
ス

(copyright2011 akipii@XPJUG関西)

15
小規模リリース
2~4週間の間隔で、小刻みに機
能拡張しながらリリースする
リリース予定バージョンがイテレー
ションに相当する
長期のリリース計画はロードマッ
プ
短期のリリース計画はイテレー
ション計画
終了チケットは変更履歴に残る

「いつリリースするか」と
「どのバージョンに設定するか」
は同じ!
(copyright2011 akipii@XPJUG関西)

16
TiDDがAgileになる理由

ロードマップをリリース計画のように扱い、小規模リリー
スを運用する開発プロセス
Redmineによるチケット駆動開発は、XPの開発ライフサイク
ルに似たアジャイル開発
(copyright2011 akipii@XPJUG関西)

17
TiDDはPMISを目指す

(copyright2011 akipii@XPJUG関西)

18
TiDDはPMISを目指す

(copyright2011 akipii@XPJUG関西)

18
TiDDはプロセス資産になる

TiDDで一元管理
で
されたデータは、
ナレッジDBになる
ナレッジ になる

(copyright2011 akipii@XPJUG関西)

19
【2】組織体制・権限
Agile開発チーム
(PM, PG)

運用手順
(【3】イテレーション
【 】
 管理,
 管理
【4】構成管理 etc.)
】

PMIS

ナレッジ
(データ)

【2】組織体制・権限
】
(copyright2011 akipii@XPJUG関西)

20
顧客プロキシ(倉貫さん)
設計チームが開発チームと顧客の橋渡しの役割を担う
設計チームが開発の前に先行して要件を引き出す
ブリッジSEのチームと同義

開発フェーズで設計メンバーは開発チームの顧客役(オンサイト顧客)
になる

開発チームA

設計チーム

顧客
システム提案
要件定義

仕様を伝達
課題管理

開発チームB

顧客プロキシ
(オンサイト顧客
オンサイト顧客
の代理人)
の代理人

(copyright2011 akipii@XPJUG関西)

21
Scrum of Scrum

週次追跡

(スケールアップ
スケールアップ)
スケールアップ

チーム間の課題の棚卸し会議
Scrumマスター(リーダー)同士で調整する

ステアリング
コミッティー

スクラムオブスクラム
Scrumマスターが集合
マスターが集合
した課題管理会議
日次追跡

Scrumマスター
マスター
日次追跡

日次追跡
日次追跡

ScrumチームA

ScrumチームB

ScrumチームC

アジャイルコンポーネントチーム
(copyright2011 akipii@XPJUG関西)

22
エスカレーションと委譲
PM

自チーム

別PM

エスカレーション

権限委譲
承認

エスカレーション
フィードバック

PG

ペア作業
テスター

大規模プロジェクトほどエスカレーションと委譲が多くなる
他チームに依頼する作業はエスカレーションする
メンバーに権限委譲して、自己組織化した方が効率的
(copyright2011 akipii@XPJUG関西)

23
Ver1.0
リファクタリング

柔軟なチケット管理
Ver1.0
バグ修正

ワークフロー変更
Ver1.0
機能Aの修正、
機能Bの修正
チケットを チケット
起票

更にチケットを分割
Ver1.1
バグ修正

別チームへ
エスカレーション

バージョン変更
チケットをコピー
(copyright2011 akipii@XPJUG関西)

24
【3】イテレーション管理
Agile開発チーム
(PM, PG)

運用手順
(【3】イテレーション
【 】
 管理,
 管理
【4】構成管理 etc.)
】

PMIS

ナレッジ
(データ)

【2】組織体制・権限
】
(copyright2011 akipii@XPJUG関西)

25
アジャイルリリーストレイン
イテレーション1
イテレーション

イテレーション2
イテレーション

イテレーション3
イテレーション

(スケールアップ
スケールアップ)
スケールアップ

イテレーション4
イテレーション

開発チームA
開発チーム

アジャイルリリー
ストレインとは、
電車が時刻表に
従って、発車・到
着するイメージを
比喩した概念

開発チームB
開発チーム

開発チームC
開発チーム

全チームのイテレーションは同期しているので、
リリースのタイミングも同じ。
(copyright2011 akipii@XPJUG関西)

26
イテレーションの継承

親プロジェクトのイテレーションを
子プロジェクトへ強制できる

(1)イテレーション
イテレーション1
イテレーション
 を作成
開発チームA
開発チーム
プロジェクト全体
(リリースモジュール
リリースモジュール)
リリースモジュール

(2)イテレーション
イテレーション1
イテレーション
 を継承
開発チームB
開発チーム
(copyright2011 akipii@XPJUG関西)

27
イテレーションの階層化(細谷さん)
イテレーション1

イテレーション2

プロジェクト
全体
早めに内部リリースして
動作確認

正式リリースで
動作確認

組込製品や
パッケージ
製品開発で
よく使われ
ている

開発チームA
開発チーム
(or 開発チーム
開発チームB)

イテレーション1/4
イテレーション3/4
イテレーション2/4
イテレーション4/4
(copyright2011 akipii@XPJUG関西)

28
反復型開発(細谷さん)
前半のイテレーションは
Agileな開発

後半のイテレーションは
過去のコンポーネント統合

システム
開発

過去のコンポーネントを統合

システム全体で統合/テストしたりするイテレーションを別途設
ける
複数チームの成果物を統合して検証する
HWとSWを結合してテストする
受入テストの観点でシステム全体を動作確認する
(copyright2011 akipii@XPJUG関西)

29
(スケールアップ
スケールアップ)
スケールアップ

アーキテクチャ助走路
前半のイテレーションは
共通部品の作り込み

後半のイテレーションは
各コンポーネントをAgileに開発

アーキテクチャ
設計
開発チームA

アーキテクチャ
助走路

開発チームB

全体アーキテクチャ設計とコンポーネント開発のイテレーションを分ける
前半のイテレーションで全体アーキテクチャを作り込む
フレームワークや共通部品を作った後に、Agileに開発していく
(copyright2011 akipii@XPJUG関西)

30
【4】構成管理
Agile開発チーム
(PM, PG)

運用手順
(【3】イテレーション
【 】
 管理,
 管理
【4】構成管理 etc.)
】

PMIS

ナレッジ
(データ)

【2】組織体制・権限
】
(copyright2011 akipii@XPJUG関西)

31
SWプロダクトライン
大規模プロジェクト開発へSWプロダクトラインの考え方を取り入れる
プロダクトラインの考え方を取り入れる
大規模プロジェクト開発へ
製品ファミリー開発の一手法で、派生開発や移植作業に強い
フレームワークや共通部品はコア資産化
コア資産から分岐した各アプリケーションは製品群として派生開発する
前半のイテレーションは
共通部品の作り込み

後半のイテレーションは
製品系列をAgileに開発

プロダクトライン
の開発
フィードバック
抽出

製品A開発
コア資産

製品B開発
(copyright2011 akipii@XPJUG関西)

32
移植作業とベンダブランチ
派生元から派生先への移植作業を構成管理する
ベンダブランチは、派生元のVerUpを派生先に取り込むSCMパターン

(copyright2011 akipii@XPJUG関西)

33
大規模プロジェクト運用の注意点
顧客プロキシの運用は難しい
設計チームの負荷が高い
分散開発の場合、開発チームとのコミュニケーションロスが大きい

Scrum of Scrumは定期的に開催する
他チームへ依頼して放置されたチケットは定期的に棚卸し
無駄な会議にならないような工夫(例:PF)が必要

イテレーションのバリエーションが多いほどスケールアップし
やすい
状況に応じて、イテレーションの目的を柔軟に変える

SWプロダクトラインの開発は難しい
共通部品化するのにコストがかかる
派生先の開発は派生元の開発スケジュールに依存する

(copyright2011 akipii@XPJUG関西)

34
まとめ・謝辞
Agile開発を大規模プロジェクトに適用できる時代になってい
る
Agile開発のエッセンスに各種技法を混ぜる
チケット駆動開発がAgile開発のインフラになる

スケールアップのノウハウはもっと必要
分散開発のコミュニケーションをPFがサポートできないか?
チケット駆動開発でサポートできる作業は無いか?

謝辞
講演の場を提供して頂いたXPJUG関西

(copyright2011 akipii@XPJUG関西)

35

More Related Content

PDF
デブサミ2011(17-B-3)講演資料「チケット駆動開発~タスクマネジメントからAgile開発へ」
PDF
Qlik TechFest B-6 これで解決! 今までのBIツールでは諦めていたチャートが 表現できる Qlik Sense拡張機能 Vizlib
PDF
ユニットテストの保守性を作りこむ, xpjugkansai2011
PDF
これからの「アジャイル」の話をしよう ――今を生き延びるための開発手法とスキル (関西バージョン)
PDF
その ionice、ほんとに効いてますか?
PPTX
C#/.NETがやっていること 第二版
PPTX
C#や.NET Frameworkがやっていること
PPTX
ちゃんとした C# プログラムを書けるようになる実践的な方法~ Visual Studio を使った 高品質・低コスト・保守性の高い開発
デブサミ2011(17-B-3)講演資料「チケット駆動開発~タスクマネジメントからAgile開発へ」
Qlik TechFest B-6 これで解決! 今までのBIツールでは諦めていたチャートが 表現できる Qlik Sense拡張機能 Vizlib
ユニットテストの保守性を作りこむ, xpjugkansai2011
これからの「アジャイル」の話をしよう ――今を生き延びるための開発手法とスキル (関西バージョン)
その ionice、ほんとに効いてますか?
C#/.NETがやっていること 第二版
C#や.NET Frameworkがやっていること
ちゃんとした C# プログラムを書けるようになる実践的な方法~ Visual Studio を使った 高品質・低コスト・保守性の高い開発

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

PDF
XP祭り関西2010発表資料「チケット駆動開発のプラクティス集」
PDF
Agile and Scrum: Theory of Knowledge Creation and A Real Story
PDF
タレントへ目指せ
PDF
Pivotal Trackerでアジャイルなプロジェクト管理
PDF
Agile Japan 2018 サテライト<名古屋> 基調講演 補足資料
PDF
はじめてのスクラム開発
PDF
チケット駆動開発はアジャイル1次ブームの夢を見る
PDF
CIサーバを制圧せよ! - プロジェクトメトリクスと自動化技術の活用よる混乱の収拾と「最強」の組織の育成
PDF
【19-D-2】IIJ社内におけるアジャイル開発、DevOpsへの取り組み
PDF
アジャイル開発の進め方
PDF
自動化の下ごしらえ
PDF
Agile meets BABOK
PDF
Automotive agile 自動車業界を取り巻くアジャイル・スクラムの潮流
PPT
Agile Communities In Japan(J)
PPT
yokyo-unv.
PPTX
OSC Enterprise 2016 ~ 新管理ダッシュボード"Cockpit“搭載により、更に進化する高機能ジョブ管理ツール「JobScheduler」
PDF
Nonaka Scrum Creating Knowledge with Users
PPTX
【JaSST'18 Tokai】アジャイルとテスト自動化導入の勘所
PDF
GoogleAnalytics Tools クックブック
PPTX
Future Tech Night Agile勉強会 20210709
XP祭り関西2010発表資料「チケット駆動開発のプラクティス集」
Agile and Scrum: Theory of Knowledge Creation and A Real Story
タレントへ目指せ
Pivotal Trackerでアジャイルなプロジェクト管理
Agile Japan 2018 サテライト<名古屋> 基調講演 補足資料
はじめてのスクラム開発
チケット駆動開発はアジャイル1次ブームの夢を見る
CIサーバを制圧せよ! - プロジェクトメトリクスと自動化技術の活用よる混乱の収拾と「最強」の組織の育成
【19-D-2】IIJ社内におけるアジャイル開発、DevOpsへの取り組み
アジャイル開発の進め方
自動化の下ごしらえ
Agile meets BABOK
Automotive agile 自動車業界を取り巻くアジャイル・スクラムの潮流
Agile Communities In Japan(J)
yokyo-unv.
OSC Enterprise 2016 ~ 新管理ダッシュボード"Cockpit“搭載により、更に進化する高機能ジョブ管理ツール「JobScheduler」
Nonaka Scrum Creating Knowledge with Users
【JaSST'18 Tokai】アジャイルとテスト自動化導入の勘所
GoogleAnalytics Tools クックブック
Future Tech Night Agile勉強会 20210709
Ad

More from akipii Oga (20)

PDF
astahで問題地図を描いてみよう~第4回astah関西勉強会の発表資料です #astahkansai
PDF
JSTQB_テストプロセスの概念モデル改善版.pdf
PDF
平鍋さんのテスト設計モデル.pdf
PDF
統計学の攻略_統計的仮説検定の9パターン.pdf
PDF
統計学の攻略_正規分布ファミリーの全体像.pdf
PDF
統計学の攻略_推測統計学の考え方.pdf
PDF
JSTQB_テストマネジメントとレビュープロセス.pdf
PDF
JSTQB_テストプロセスの概念モデル.pdf
PDF
プロセスプログラミングとは
PDF
SECIモデルの状態遷移図
PDF
物理攻略の全体マップ
PDF
初中級プロマネのための現場で活かせ!統計情報.pdf
PDF
「ハリウッドリライティングバイブル」のマインドマップ
PDF
GTDのワークフロー
PDF
プロマネの判断プロセス
PDF
プロマネの意思決定プロセス
PDF
世界を動かすプロジェクトマネジメントの教科書の概念図
PDF
チケット駆動開発の解説~タスク管理からプロセス改善へ
PDF
チケット管理の運⽤を⽀える体制
PDF
ホールディング会社の役割とIt企画・構築プロセス
astahで問題地図を描いてみよう~第4回astah関西勉強会の発表資料です #astahkansai
JSTQB_テストプロセスの概念モデル改善版.pdf
平鍋さんのテスト設計モデル.pdf
統計学の攻略_統計的仮説検定の9パターン.pdf
統計学の攻略_正規分布ファミリーの全体像.pdf
統計学の攻略_推測統計学の考え方.pdf
JSTQB_テストマネジメントとレビュープロセス.pdf
JSTQB_テストプロセスの概念モデル.pdf
プロセスプログラミングとは
SECIモデルの状態遷移図
物理攻略の全体マップ
初中級プロマネのための現場で活かせ!統計情報.pdf
「ハリウッドリライティングバイブル」のマインドマップ
GTDのワークフロー
プロマネの判断プロセス
プロマネの意思決定プロセス
世界を動かすプロジェクトマネジメントの教科書の概念図
チケット駆動開発の解説~タスク管理からプロセス改善へ
チケット管理の運⽤を⽀える体制
ホールディング会社の役割とIt企画・構築プロセス
Ad

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