【12-A-4】　Eclipse-Way ：分散アジャイル開発のためのプラクティスとその事例

藤井　智弘日本アイ・ビー・エム株式会社ソフトウェア事業Rational テクニカルセールス＆サービス

12-A-4

Eclipse-way

分散アジャイル開発のためのプラクティスとその実践例

2009年2月13日金曜日

今日の主題アジャイル開発の有効性は認知されつつも、規模の拡大とオフショア等の分散体制の壁にぶつかっています。

Eclipse-WayはEclipse自体の開発から生まれたアジャイルプラクティス集であり、Rational TeamConcertの開発で、100人×3年以上にわたって適用され、またその過程はインターネット上に公開されています。

本セッションでは、RTCの開発をひとつの例に、アジャイルプラクティスのスケールアップのポイントを探ります。


http://www.jazz.net/オープンソースの開発モデルの成功体験を、有償製品の開発モデルに転用

The Jazz Project


今日の演目

Eclipse-Way 概要実践例としての

Rational Team Concert開発体制イテレーションの詳細


the Eclipse Way

new & noteworthy

drive with open eyes

validate

reduce stress

learn

enable

attract to latest

transparency

validateupdate

show progress

enable

explore

validate

feedback

サインオフ

コンポーネント中心

ダイナミックなチーム

APIファースト

アダプティブプランニングレトロスペクティブ

マイルストーンファーストいつも

クライアントと共に

ライブベータ

エンドゲーム

アウトプットを自身でも使う

コミュニティを巻き込む

継続した統合

継続したテスト


the Eclipse Way

new & noteworthy


validate

reduce stress

learn

enable

attract to latest

transparency

validateupdate

show progress

enable

explore

validate

feedback

サインオフ

アジャイルで共通のプラクティス



APIファースト




ライブベータ

エンドゲーム



継続した統合



the Eclipse Way

new & noteworthy


validate

reduce stress

learn

enable

attract to latest

transparency

validateupdate

show progress

enable

explore

validate

feedback

サインオフ

アジャイルで共通のプラクティスオープンソースで共通のプラクティス



APIファースト




ライブベータ

エンドゲーム



継続した統合



the Eclipse Way

new & noteworthy


validate

reduce stress

learn

enable

attract to latest

transparency

validateupdate

show progress

enable

explore

validate

feedback

サインオフ

アジャイルで共通のプラクティスオープンソースで共通のプラクティススケールアップのためのプラクティス



APIファースト




ライブベータ

エンドゲーム



継続した統合



Team First

Members

Build

Release/Iteration Plan

Categories

Streams（作業領域）

Queries（状況の照会）

Events（イベント）

has

produces

definesgenerates

worksin

is responsible

shares

Process（プロセス）

Team

followsowns

“ツール”はチームを“知っている“

チームはそれぞれ“異なる“


成果物の追跡

Work Item

IterationPlan

Build

Release

Change SetSnapshotUser

StreamArtifacts

subscribesapprovesreviews related

implements

promoted

built from

found in

plannedfor

included

reportedagainst

included

included

Workspace

change flow

Work items で作業や課題を追跡する


“パーソナル”


“チーム”


“チームから成るチーム“


トレンド


実践例としてのRational TeamConcert開発


分散開発体制

ZurichBeaverton

Ottawa Saint Nazaire

Raleigh

Toronto

Winnipeg Lexington


タイムライン

エンドゲーム

リリースM1a

pla

n

dev

elo

p

stab

ilize

4 weeks

ウォームアップ

retr

osp

ecti

ve

init

ial r

elea

se p

lan

dec

om

pre

ssio

n

M1

pla

n

dev

elo

p

stab

ilize

…

pla

n

dev

elo

p

stab

ilize

サインオフ

サインオフサインオフ

4 weeks 4 weeks

fix

- s

pit

& p

olis

h

test fix

test

イテレーション終了時デモ、レトロスペクティブ、New & Noteworthy


環境


メンバーの役割モデルプロジェクト・マネージメント・コミッティ(PMC)

リリースプランに責任テーマ設定ファシリテイター、コーディネータ

全員参加型の意思決定を推進 e.g. “アーキテクチャ上の課題トップ 5 “

コンポーネント・リードイテレーションプラン、テストプランに責任

コントリビュータコード、テスト、デザインに責任多くの役割を果たす

開発者、テスター、アーキテクトカスタマーサポート、リリースエンジニアリング

PMC

ComponentLead

ComponentLead …

Contributor Contributor …


コンポーネントベース開発 “コンポーネント・ベースド” チームは、１拠点に存在し、ひとつあるいはそれ以上のコンポーネントに責任を持つ

コンポーネント群は分散して存在する

“architecture follows organization” Team Concert はコンポーネント・ベースド開発をサポートするチームは自身の“ストリーム”を持つチームは、そのストリーム内で、リソースの変更を共有するチームは自身が責任を有すコンポーネントがあるストリームはコンポーネントを参照する


Teams of Teams

Dynamic team Maintenance Development line

Main development line

Agile Planning Source Control

Jazz Development


プロセス：追跡するアイテム障害（Defects）, タスク（Tasks）, 機能拡張（Enhancements）

ビルド･ステータス（Build status）

レトロスペクティブ（Retrospectives）計画項目（Plan Items）, ストーリ（Stories）


プロセスルールを、イテレーションフェーズに合わせて定義

開発期コード変更の登録にはコメントをつけること

安定化期コード変更の登録には、ワークアイテムとの関連付けておくこと

コンポーネントリードによる承認が必須チームメンバーによるレビューをうけること


プロセスをツールで制御


計画期

エンドゲーム

リリースM1a

pla

n

dev

elo

p

stab

ilize

4 weeks


retr

osp

ecti

ve

init

ial r

elea

se p

lan

dec

om

pre

ssio

n

M1

pla

n

dev

elo

p

stab

ilize

…

pla

n

dev

elo

p

stab

ilize

サインオフ


4 weeks 4 weeks

fix

- s

pit

& p

olis

h

test fix

test


ワークアイテムの計画 Plan Item (フィーチャー)

提案（Proposed）, コミット（Committed）, 延期（Deferred）

ストーリー（Story）タスク（Task）


”アジャイル化”にむけてへの不安要求やら仕様やら･･･

「“全体のプラン”ってどうする？」- 抜け、漏れ

「“好き勝手放題”をどう収束（あるいは抑える）させるの？」


Jazz.netでの例巨視的視点：リリースプラン

https://jazz.net/development/DevelopmentItem.jsp?href=content/project/plans/rtc-plan-2.0.html

Components and product configurations Release deliverables Release milestones Operating environments Compatibility and Evolution Themes and Priorities Plan items UIs




Jazz.netでの要求等の構造テーマ

Plan Item(フィーチャー)

ストーリー

より詳細、具体的


“Enterprise Scalability and Security”“Jazz Product Family”“Web Access”“Easy to Set up and Maintain”....

タスク

実現する


Jazz.netでの要求等の構造テーマ




“Project level read access control”“Server performance and scaling data”“Provide REST API or work items”“Support Visual Studio IDE”ストーリー

タスク

実現する


Jazz.netでの要求等の構造


Jazz.netでの要求等の構造リリース

マイルストーン

テーマ


イテレーション



～成る

～成る

ストーリー

タスク

実現する

提供される

実装される

割当てられる


イテレーションプランストーリーの定義タスクへの詳細化

工数見積もり

作業負荷のバランス


フィードバックのフォーカスと収束

全体から見て、”今”どうなっているか？今“何を”議論すべきか？


開発

エンドゲーム

リリースM1a

pla

n

dev

elo

p

stab

ilize

4 weeks


retr

osp

ecti

ve

init

ial r

elea

se p

lan

dec

om

pre

ssio

n

M1

pla

n

dev

elo

p

stab

ilize

…

pla

n

dev

elo

p

stab

ilize

サインオフ


4 weeks 4 weeks

fix

- s

pit

& p

olis

h

test fix

test


進捗の追跡イテレーションプランでの進捗が見られるダッシュボードで時系列の進捗を把握

イテレーション単位トレンド


”アジャイル化”にむけてへの不安”結局、人の仕事のすべては管理できない”



同じチーム→目が届く→リカバリできる



同じチーム→目が届く→リカバリできる他のチーム→（自チームほどには）目が届かない　　　　　→ちょっと怖い。でも、そばに　　　　　　いれば何とかなる



同じチーム→目が届く→リカバリできる他のチーム→（自チームほどには）目が届かない　　　　　→ちょっと怖い。でも、そばに　　　　　　いれば何とかなる

離れたチーム→何をしてるかわからない。　　　　　　→怖すぎる


Team First：”チーム”がチームとして機能するために

Members

Build

Release/Iteration Plan

Categories

Streams（作業領域）

Queries（状況の照会）

Events（イベント）

has

produces

definesgenerates

worksin

is responsible

shares

Process（プロセス）

Team

followsowns

チームの役割に応じたルール/ワークフローの活用他の悪影響を排除できる”独立した”作業空間の確保”Whole team”→”Dynamic Team”と独立性のバランス

- リソース管理とビルド環境


リソース＆ビルド管理

Eclipse workspace

クライアントＡ

Eclipse workspace

クライアントB



Eclipse workspace


Eclipse workspace

クライアントB

ストリームリポジトリワークスペース

リポジトリワークスペース

auto-check in

auto-check in

deliver



Eclipse workspace


Eclipse workspace

クライアントB



auto-check in

auto-check in

deliver



Eclipse workspace


Eclipse workspace

クライアントB



auto-check in

auto-check in

deliver

一時待避エリア

Suspend/Resume



Eclipse workspace


Eclipse workspace

クライアントB



auto-check in

auto-check in

deliver


Suspend/Resume

スナップショット



Eclipse workspace


Eclipse workspace

クライアントB



auto-check in

auto-check in

deliver


Suspend/Resume

スナップショット

ビルドエンジン

参照


リソースの共有ストリームでチームの作業領域の独立性を確保

Maintenance Stream

IntegrationStream

Developer workspaces

Build workspace


独立性のレベルRTCでの”領域”に関する概念独立性のレベル

リポジトリ・ワークスペース (Repository workspaces)

個人レベル

ストリーム (Streams)

チームレベル

サスペンド＆レジューム(Suspend and Resume)

個人の個々の作業単位

チームエリア (Team areas)

プロセス


ビルドサポート開発者単位

“パーソナルビルド”

チーム単位 “チームの継続したビルド”

複合チーム単位ウィークリーの統合ビルド

安定化を目的継続統合ストリーム

変更分の共有、不安定


“リズム“Rhythm for Green

リポジトリワークスペース(Personal Builds)‏

good buildfailed build

週次統合ストリーム (Team of team )‏

deliver/accept

RC2

RC2 Stabilization ストリーム

チームストリーム(Team Builds)‏

変更セットの公開と受け入れ

C-I ストリーム (Team of team Builds)‏

ベースラインの公開と受け入れ

suspend/resume

suspend/resume


ビルド状況のトラッキング


Test Health


何が起きているか？

Team EventsSection

Jazz EventsSection

FeedsViewlet

チーム間はフィードでつなぐ:

マイ・イベントチーム・イベント


Team of Teams Dashboard


安定化期

エンドゲーム

リリースM1a

pla

n

dev

elo

p

stab

ilize

4 weeks


retr

osp

ecti

ve

init

ial r

elea

se p

lan

dec

om

pre

ssio

n

M1

pla

n

dev

elo

p

stab

ilize

…

pla

n

dev

elo

p

stab

ilize

サインオフ


4 weeks 4 weeks

fix

- s

pit

& p

olis

h

test fix

test


安定化したビルドをマイルストーンとして格上げ Work item で承認状況を追跡


レトロスペクティブ

ワークアイテムの一種何ができて何ができないか？

プロセスをどう調整するか？

PMC がサマライズする


エンドゲーム

エンドゲーム

リリースM1a

pla

n

dev

elo

p

stab

ilize

4 weeks


retr

osp

ecti

ve

init

ial r

elea

se p

lan

dec

om

pre

ssio

n

M1

pla

n

dev

elo

p

stab

ilize

…

pla

n

dev

elo

p

stab

ilize

サインオフ


4 weeks 4 weeks

fix

- s

pit

& p

olis

h

test fix

test


エンドゲームでのトラッキング






PMCによる承認


RTCの外部で行われるアクション

コンポーネントリードと２フェーズプランニングコール安定化週では毎日

イテレーション終了時にデモコンポーネントチーム内では、毎日スタンダップミーティングを実施

リリースサイクルの最初ではF2Fミーティング

新しいコンポーネント開発企画時はF2F


ポイント ”チーム”の独立化 ”無駄を排する”→＋”ロスを最小化する”

スキルのばらつきは不可避→”WBSの集合としてのプロセス”から”完了基準の集合体”へ



Documents

【12-A-4】 Eclipse-Way ：分散アジャイル開発のためのプラクティスとその事例

【12-A-4】　Eclipse-Way ：分散アジャイル開発のためのプラクティスとその事例