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

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

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

1

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

現在　絶賛販売中


2

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

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

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

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


3

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

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

4

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

かんばん

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

5

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

タイムラグ
が発生

システム統合
が発生

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


6

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

2010

2011

製品A
フィードバック

移植

派生・移植
製品B
派生・移植
製品C

7

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

大規模プロジェクトへAgile開発を
適用したい動機がある

8

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

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

Agile開発チーム
(PM, PG)

PMIS

ナレッジ
(データ)

】

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

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

【1】チケット駆動開発
(PM, PG)

運用手順
【】
　管理,
　管理
】

PMIS

ナレッジ
(データ)

】

10

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

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

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


11

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

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

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

チケット

(まちゅさん)

出力

　作業

ソース・設計書

担当

開発者

12

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

かんばん

13

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


14

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


14

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

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

現
在
の
ス
テ
ー
タ
ス


15

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

「いつリリースするか」と
「どのバージョンに設定するか」
は同じ！

16

TiDDがAgileになる理由

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

17

TiDDはPMISを目指す


18

TiDDはプロセス資産になる

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


19

(PM, PG)

運用手順
【】
　管理,
　管理
】

PMIS

ナレッジ
(データ)

】

20

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

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

開発チームA

設計チーム

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

仕様を伝達
課題管理

開発チームB

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


21

Scrum of Scrum

週次追跡

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

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

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

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

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

日次追跡
日次追跡

ScrumチームA

ScrumチームB

ScrumチームC

アジャイルコンポーネントチーム

22

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

自チーム

別PM

エスカレーション

権限委譲
承認


PG

ペア作業
テスター

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

23

Ver1.0
リファクタリング

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

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

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

別チームへ

バージョン変更
チケットをコピー

24

【3】イテレーション管理
(PM, PG)

運用手順
【】
　管理,
　管理
】

PMIS

ナレッジ
(データ)

】

25

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





開発チームA
開発チーム

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

開発チームB
開発チーム

開発チームC
開発チーム

全チームのイテレーションは同期しているので、
リリースのタイミングも同じ。

26

イテレーションの継承

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

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

(2)イテレーション
　を継承
開発チームB
開発チーム

27

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


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

正式リリースで
動作確認

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

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

イテレーション1/4

28

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

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

システム
開発

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

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

29


アーキテクチャ助走路
共通部品の作り込み

各コンポーネントをAgileに開発

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

アーキテクチャ
助走路

開発チームB

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

30

【4】構成管理
(PM, PG)

運用手順
【】
　管理,
　管理
】

PMIS

ナレッジ
(データ)

】

31

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

製品系列をAgileに開発

プロダクトライン
の開発
抽出

製品A開発
コア資産

製品B開発

32

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


33

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

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

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

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


34

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

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

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


35

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

Recommandé

Recommandé

Contenu connexe

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

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

Plus de akipii Oga

Plus de akipii Oga (20)

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