View
1.625
Download
0
Category
Tags:
Preview:
DESCRIPTION
Citation preview
藤井 智弘日本アイ・ビー・エム株式会社ソフトウェア事業Rational テクニカルセールス＆サービス
12-A-4
Eclipse-way
分散アジャイル開発のためのプラクティスとその実践例
2009年2月13日金曜日
今日の主題 アジャイル開発の有効性は認知されつつも、規模の拡大とオフショア等の分散体制の壁にぶつかっています。
Eclipse-WayはEclipse自体の開発から生まれたアジャイルプラクティス集であり、Rational TeamConcertの開発で、100人×3年以上にわたって適用され、またその過程はインターネット上に公開されています。
本セッションでは、RTCの開発をひとつの例に、アジャイルプラクティスのスケールアップのポイントを 探ります。
2009年2月13日金曜日
http://www.jazz.net/オープンソースの開発モデルの成功体験を、有償製品の開発モデルに転用
The Jazz Project
2009年2月13日金曜日
今日の演目
Eclipse-Way 概要 実践例としての
Rational Team Concert開発 体制 イテレーションの詳細
2009年2月13日金曜日
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ファースト
アダプティブプランニング レトロスペクティブ
マイルストーンファーストいつも
クライアントと共に
ライブベータ
エンドゲーム
アウトプットを自身でも使う
コミュニティを巻き込む
継続した統合
継続したテスト
2009年2月13日金曜日
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ファースト
アダプティブプランニング レトロスペクティブ
マイルストーンファーストいつも
クライアントと共に
ライブベータ
エンドゲーム
アウトプットを自身でも使う
コミュニティを巻き込む
継続した統合
継続したテスト
2009年2月13日金曜日
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ファースト
アダプティブプランニング レトロスペクティブ
マイルストーンファーストいつも
クライアントと共に
ライブベータ
エンドゲーム
アウトプットを自身でも使う
コミュニティを巻き込む
継続した統合
継続したテスト
2009年2月13日金曜日
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ファースト
アダプティブプランニング レトロスペクティブ
マイルストーンファーストいつも
クライアントと共に
ライブベータ
エンドゲーム
アウトプットを自身でも使う
コミュニティを巻き込む
継続した統合
継続したテスト
2009年2月13日金曜日
Team First
Members
Build
Release/Iteration Plan
Categories
Streams（作業領域）
Queries（状況の照会）
Events（イベント）
has
produces
definesgenerates
worksin
is responsible
shares
Process（プロセス）
Team
followsowns
“ツール”はチームを“知っている“
チームはそれぞれ“異なる“
2009年2月13日金曜日
成果物の追跡
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 で作業や課題を追跡する
2009年2月13日金曜日
“パーソナル”
2009年2月13日金曜日
“チーム”
2009年2月13日金曜日
“チームから成るチーム“
2009年2月13日金曜日
トレンド
2009年2月13日金曜日
実践例としてのRational TeamConcert開発
2009年2月13日金曜日
分散開発体制
ZurichBeaverton
Ottawa Saint Nazaire
Raleigh
Toronto
Winnipeg Lexington
2009年2月13日金曜日
タイムライン
エンドゲーム
リリース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
2009年2月13日金曜日
環境
2009年2月13日金曜日
メンバーの役割モデル プロジェクト・マネージメント・コミッティ(PMC)
リリースプランに責任テーマ設定ファシリテイター、コーディネータ
全員参加型の意思決定を推進 e.g. “アーキテクチャ上の課題トップ 5 “
コンポーネント・リード イテレーションプラン、テストプランに責任
コントリビュータ コード、テスト、デザインに責任 多くの役割を果たす
開発者、テスター、アーキテクト カスタマーサポート、リリースエンジニアリング
PMC
ComponentLead
ComponentLead …
Contributor Contributor …
2009年2月13日金曜日
コンポーネントベース開発 “コンポーネント・ベースド” チームは、１拠点に存在し、ひとつあるいはそれ以上のコンポーネントに責任を持つ
コンポーネント群は分散して存在する
“architecture follows organization” Team Concert はコンポーネント・ベースド開発をサポートする チームは自身の“ストリーム”を持つ チームは、そのストリーム内で、リソースの変更を共有する チームは自身が責任を有すコンポーネントがある ストリームはコンポーネントを参照する
2009年2月13日金曜日
Teams of Teams
Dynamic team Maintenance Development line
Main development line
Agile Planning Source Control
Jazz Development
2009年2月13日金曜日
プロセス：追跡するアイテム 障害（Defects）, タスク（Tasks）, 機能拡張（Enhancements）
ビルド･ステータス（Build status）
レトロスペクティブ（Retrospectives） 計画項目（Plan Items）, ストーリ（Stories）
2009年2月13日金曜日
プロセスルールを、イテレーションフェーズに合わせて定義
開発期 コード変更の登録にはコメントをつけること
安定化期 コード変更の登録には、ワークアイテムとの関連付けておくこと
コンポーネントリードによる承認が必須 チームメンバーによるレビューをうけること
2009年2月13日金曜日
プロセスをツールで制御
2009年2月13日金曜日
計画期
エンドゲーム
リリース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
2009年2月13日金曜日
ワークアイテムの計画 Plan Item (フィーチャー)
提案（Proposed）, コミット（Committed）, 延期（Deferred）
ストーリー（Story） タスク（Task）
2009年2月13日金曜日
”アジャイル化”にむけてへの不安要求やら仕様やら･･･
「“全体のプラン”ってどうする？」- 抜け、漏れ
「“好き勝手放題”をどう収束（あるいは抑える）させるの？」
2009年2月13日金曜日
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
2009年2月13日金曜日
Jazz.netでの要求等の構造テーマ
Plan Item(フィーチャー)
ストーリー
より詳細、具体的
より詳細、具体的
“Enterprise Scalability and Security”“Jazz Product Family”“Web Access”“Easy to Set up and Maintain”....
タスク
実現する
2009年2月13日金曜日
Jazz.netでの要求等の構造テーマ
Plan Item(フィーチャー)
より詳細、具体的
より詳細、具体的
“Project level read access control”“Server performance and scaling data”“Provide REST API or work items”“Support Visual Studio IDE”ストーリー
タスク
実現する
2009年2月13日金曜日
Jazz.netでの要求等の構造
2009年2月13日金曜日
Jazz.netでの要求等の構造リリース
マイルストーン
テーマ
Plan Item(フィーチャー)
イテレーション
より詳細、具体的
より詳細、具体的
～成る
～成る
ストーリー
タスク
実現する
提供される
実装される
割当てられる
2009年2月13日金曜日
イテレーションプラン ストーリーの定義 タスクへの詳細化
工数見積もり
作業負荷のバランス
2009年2月13日金曜日
フィードバックのフォーカスと収束
全体から見て、”今”どうなっているか？今“何を”議論すべきか？
2009年2月13日金曜日
開発
エンドゲーム
リリース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
2009年2月13日金曜日
進捗の追跡 イテレーションプランでの進捗が見られるダッシュボードで時系列の進捗を把握
イテレーション単位 トレンド
2009年2月13日金曜日
”アジャイル化”にむけてへの不安”結局、人の仕事のすべては管理できない”
2009年2月13日金曜日
”アジャイル化”にむけてへの不安”結局、人の仕事のすべては管理できない”
同じチーム→目が届く→リカバリできる
2009年2月13日金曜日
”アジャイル化”にむけてへの不安”結局、人の仕事のすべては管理できない”
同じチーム→目が届く→リカバリできる 他のチーム→（自チームほどには）目が届かない →ちょっと怖い。でも、そばに いれば何とかなる
2009年2月13日金曜日
”アジャイル化”にむけてへの不安”結局、人の仕事のすべては管理できない”
同じチーム→目が届く→リカバリできる 他のチーム→（自チームほどには）目が届かない →ちょっと怖い。でも、そばに いれば何とかなる
離れたチーム→何をしてるかわからない。 →怖すぎる
2009年2月13日金曜日
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”と独立性のバランス
- リソース管理とビルド環境
2009年2月13日金曜日
リソース＆ビルド管理
Eclipse workspace
クライアントＡ
Eclipse workspace
クライアントB
2009年2月13日金曜日
リソース＆ビルド管理
Eclipse workspace
クライアントＡ
Eclipse workspace
クライアントB
ストリームリポジトリワークスペース
リポジトリワークスペース
auto-check in
auto-check in
deliver
2009年2月13日金曜日
リソース＆ビルド管理
Eclipse workspace
クライアントＡ
Eclipse workspace
クライアントB
ストリームリポジトリワークスペース
リポジトリワークスペース
auto-check in
auto-check in
deliver
2009年2月13日金曜日
リソース＆ビルド管理
Eclipse workspace
クライアントＡ
Eclipse workspace
クライアントB
ストリームリポジトリワークスペース
リポジトリワークスペース
auto-check in
auto-check in
deliver
一時待避エリア
Suspend/Resume
2009年2月13日金曜日
リソース＆ビルド管理
Eclipse workspace
クライアントＡ
Eclipse workspace
クライアントB
ストリームリポジトリワークスペース
リポジトリワークスペース
auto-check in
auto-check in
deliver
一時待避エリア
Suspend/Resume
スナップショット
2009年2月13日金曜日
リソース＆ビルド管理
Eclipse workspace
クライアントＡ
Eclipse workspace
クライアントB
ストリームリポジトリワークスペース
リポジトリワークスペース
auto-check in
auto-check in
deliver
一時待避エリア
Suspend/Resume
スナップショット
ビルドエンジン
参照
2009年2月13日金曜日
リソースの共有ストリームでチームの作業領域の独立性を確保
Maintenance Stream
IntegrationStream
Developer workspaces
Build workspace
2009年2月13日金曜日
独立性のレベルRTCでの”領域”に関する概念 独立性のレベル
リポジトリ・ワークスペース (Repository workspaces)
個人レベル
ストリーム (Streams)
チームレベル
サスペンド＆レジューム(Suspend and Resume)
個人の個々の作業単位
チームエリア (Team areas)
プロセス
2009年2月13日金曜日
ビルドサポート 開発者単位
“パーソナルビルド”
チーム単位 “チームの継続したビルド”
複合チーム単位 ウィークリーの統合ビルド
安定化を目的 継続統合ストリーム
変更分の共有、不安定
2009年2月13日金曜日
“リズム“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
2009年2月13日金曜日
ビルド状況のトラッキング
2009年2月13日金曜日
Test Health
2009年2月13日金曜日
何が起きているか？
Team EventsSection
Jazz EventsSection
FeedsViewlet
チーム間はフィードでつなぐ:
マイ・イベント チーム・イベント
2009年2月13日金曜日
Team of Teams Dashboard
2009年2月13日金曜日
安定化期
エンドゲーム
リリース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
2009年2月13日金曜日
安定化したビルドをマイルストーンとして格上げ Work item で承認状況を追跡
2009年2月13日金曜日
レトロスペクティブ
ワークアイテムの一種 何ができて何ができないか？
プロセスをどう調整するか？
PMC がサマライズする
2009年2月13日金曜日
エンドゲーム
エンドゲーム
リリース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
2009年2月13日金曜日
エンドゲームでのトラッキング
2009年2月13日金曜日
エンドゲームでのトラッキング
2009年2月13日金曜日
エンドゲームでのトラッキング
2009年2月13日金曜日
PMCによる承認
2009年2月13日金曜日
RTCの外部で行われるアクション
コンポーネントリードと２フェーズプランニングコール 安定化週では毎日
イテレーション終了時にデモ コンポーネントチーム内では、毎日スタンダップミーティングを実施
リリースサイクルの最初ではF2Fミーティング
新しいコンポーネント開発企画時はF2F
2009年2月13日金曜日
ポイント ”チーム”の独立化 ”無駄を排する”→＋”ロスを最小化する”
スキルのばらつきは不可避→”WBSの集合としてのプロセス”から”完了基準の集合体”へ
2009年2月13日金曜日
2009年2月13日金曜日
Recommended