アジャイル開発から継続的デリバリーへ TFSUG#5

アジャイル開発から
継続的デリバリーへ
株式会社 NTTデータ
柴山洋徳
2012/4/13

Copyright © 2012 NTT DATA CORPORATION

自己紹介
 柴山洋徳（Twitter:shibao800）
 株式会社NTTデータ認定プロジェクトマネージャ
 仕事
 CCPM/TOC コンサルティング
 組織変革コンサルティング
 社内システム開発のスクラムマスター
 社内システム開発のプロダクトオーナー
 社内アジャイルコーチ

プロローグ：
アジャイルとの出会い
http://www.flickr.com/photos/conchur/3358169824/

悪夢の始まり
 社内システム開発のユーザ部門責任者
 開発は別組織の別部隊
 インドは素晴らしい（らしい）
 アジャイルっておいしいの？


流れないウォーターフォール
 インド人にとって慣れないウォーターフォール
 大幅な遅延，眠らない開発
 モチベーションダウン

http://www.flickr.com/photos/denise_mayumi/2269480944/

ピボットポイント
 「お前プロジェクトマネージャやれ」
 でも，「当初の予定通りに開発してね」
 残された時間は4ヶ月


アジャイルとの邂逅
 Scrumをベースにプロセスを徹底的に整備
 インド開発拠点の自治化
 プロダクトオーナー＆スクラムマスター

http://www.flickr.com/photos/yto/5101830991/

山場を越えて
 当初の計画通りに開発を完了
 スモールスタート・スモールサクセス
 開発メンバのやる気と自信
 アジャイルっておいしい

http://www.flickr.com/photos/alvarolopez/2257656186/

みんな幸せ
Happy End


まだだ、まだ終わらんよ！

To Be Continued

第一章：
過渡期のアジャイルの限界
http://www.flickr.com/photos/alexandernilssen/3103869801/

終わらない開発
 新規開発からエンハンス開発へ移行
 特定顧客向けの派生開発の立ち上げ
 チームの拡大
 アジャイルっておいしいままなの？

http://www.flickr.com/photos/runfreefall/903725838/

自動化されていないテスト

http://www.flickr.com/photos/lawley/4918643/

統一されていない環境

http://www.flickr.com/photos/horiavarlan/4273913228/

お約束のあれ


新たな試練

To Be Continued

第二章：
アジャイルの再構築
http://www.flickr.com/photos/qmnonic /4794257439/

アジャイル導入において重要なこと
 ゴールの共有
 対立構図の解消
 スモールスタート・スモールサクセス
 制約と非制約の混合アプローチ


ゴールの共有


 どんな世界を目指すのか？
 自己組織化を促す
 わくわく感を持つ http://www.flickr.com/photos/alistairmcmillan/171605775/

定期ワークショップの開催
 Continuous Deliveryの勉強会
 Visual Studio ALMのデモ動画試聴会
 毎週半日をワークショップの時間に


対立構図の解消
http://www.flickr.com/photos/xtrah/5670936962/


 導入したい人・もの vs チームから
 コンテキスト・問題 vs チームへ
 自律的カイゼンを促す

Agile Buffet

構成管理

http://www.flickr.com/photos/mako_side_b/2337300578/

スモールスタート
スモールサクセス

http://www.flickr.com/photos/sneakerdog/319088191/

モチベーションのハイプカーブ
動機

時間
未来への現実成功好循環
期待問題体験

ステップ戦略
 開発環境 ⇒ テスト環境 ⇒ Scrum環境
 まずは，日本で．上手くいったらインドへ
 各スプリントで何か一つを取り入れる

http://www.flickr.com/photos/foilman/

開発環境
 構成管理，CIをTFSへ一番最初に移行
 TFSサーバはインドに配置．専用線で日本から
 開発者環境はVMイメージを作成して配布

TFS: Team Foundation Server. Microsoft社のApplication Lifecycle Management環境を実現するプロダクト．

構成管理
The two DEV India Team
branches are
created as
sequential tasks,
Japan Team
but as one unit of

Branch

Branch
work.

FI

FI

RI

RI
Development
3.0DEV

V3.0 (start)

flow of merges (changes)
V2.4 (start)

2.4DEV

CI / Nightly Builds
Branch

Branch

RI
(Early validation)

FI
FI
V2.3 Hotfix1

MAIN

V2.3 V2.4

flow of merges (changes)
Branch

Production Nightly Build
RI

(Early Validation)
Production /
Release
HOT FIX
Branch

Branch
RI

RI
The two Production
branches are
created as
RELEASE
sequential tasks,
but as one unit of
Release 2.3.1.0 Release 2.3.1.1 Release 2.4.0.0 Release 2.4.0.1
work.

テスト環境
 Test Manager & TFS
 受け入れテストから自動化
 出力データ，DBの状態，UI画像の正解比較
 受け入れテスト実行環境はHype-Vで管理


テスト自動化
クライアント側サーバ側
結果データ出力
（XML/SQL/IMG） 5

4
正解データと
ブラウザ出力結果を比較
（XML/SQL/IMG）

1 2

自動化
自動化コード実行事前処理実行
3
パラメータ一覧 PsExec
6 事後処理実行

Visual Studio
2010

制約と非制約の混合アプローチ
http://www.flickr.com/photos/perspective/67620969/


 どっちをとるか？のジレンマ
 常に正解は一つではない TOC的アプローチ

テスト戦略
 単体テストの自動化 vs 受け入れテストの自動化
 ビジネス価値最大化の制約は何か？
 エンハンス開発なら「受け入れテスト」が制約
 既存の受け入れテストをパワーをかけて自動化
 単体は開発対象となったスプリントで自動化


リスクベースドテスト
 各フィーチャをビジネス価値付け
 ビジネス価値低下のリスクを算出
 リスクの高いものからテスト自動化
 スプリント毎にインドと日本で分担
 テストプランニングミーティング


リスクベースドテスト


アジャイルの安定運用へ

To Be Continued

第三章：
安定期のアジャイル模様
http://www.flickr.com/photos/58782395@N03/5518988345/

ツール vs アナログ

http://www.flickr.com/photos/finklez/5561579362/

ツール vs アナログ

 対立ではなく，組み合わせ
 チームの成熟度にもよる
 立ち上げ初期はアナログを推奨

http://www.flickr.com/photos/finklez/5561579362/

ツールの高度な透明性
http://www.flickr.com/photos/dany13/6306491150/


 アナログでは見えない事もある
 気付かない事に気づくきっかけ
 本来やるべきことに集中できる

アナログの直感的な透明性
http://www.flickr.com/photos/williamhook/4742869256/


 毎日いつでも誰でもすぐに見える
 チームの外からも見える
 人間の感覚に訴える

ユーザーストーリーマッピング


プロダクトバックログ


プランニングポーカー


スプリントバックログ


スプリント中のモニタリング


バーンダウンチャート


デモレビュー


振り返り


さらなる継続的改善

To Be Continued

第四章：
Continuous Deliveryへ
http://www.flickr.com/photos/nicmcphee/250890495/

アジャイルにおける開発期間

4週間

3週間

2週間

1週間以下

0% 20% 40% 60%

出典： Scott W. Ambler www.ambysoft.com/surveys/

アジャイルにおけるリリース期間

1ヶ月over
4週間
3週間
2週間
1週間
1日以下
0% 10% 20% 30% 40%

出典： Scott W. Ambler www.ambysoft.com/surveys/

Agilityの欠如

http://www.flickr.com/photos/wwarby/4782861914

Water-Scrum-Fall
 よく見かける現実解
 プロダクト制約，会社ルール，コンプライアンス

Requirements Release
and planning Sprints

http://www.flickr.com/photos/wimox/5208779639/

リリースの悪夢
 レガシーシステム
 リリーストレインアプローチ
 リリースオーバーヘッド
 組織文化の変化への抵抗 http://www.flickr.com/photos/wimox/5208779639/

Sprints Release

技術的負債
Cost of Change (CoC) Delivery Speed 
Responsiveness  Actual
CoC

Product Technical Debt
Release
Optimal CoC

1 2 3 4 5 6 7 8
Years

Continuous Delivery

http://www.flickr.com/photos/evelynishere/3451469791

ビジネスニーズ駆動のリリース

http://www.flickr.com/photos/teegardin/5912231439

 開発の制約ではなく，ビジネスニーズと連動
 常にソフトウェアはリリース可能な状態

ユーザと開発の強いフィードバックループ

http://www.flickr.com/photos/usnationalarchives/6124109059

 新しいアイディアをすぐに実現できるようにする
 ユーザからの早期のフィードバックを得る
 ユーザをソフトウェアライフサイクルに巻き込む

リスクの低減

http://www.flickr.com/photos/epsos/4376727123

 ムダなソフトウェアを作るリスクの低減
 ビックバンリリースのリスクの低減
 リリースプロセス自体のリスクの低減

Continuous Deliveryの全体像
Release

Deploy

User Acceptance Test
Deploy

Commit Acceptance Test
Unit Test

開発者ユーザ
Feedback CI Env.
Integration Test ATT Env.
Canary Env.
Feedback

Feedback

Feedback

デリバリープロセスを全て自動化する

http://www.flickr.com/photos/fagorautomation/6482019321

 ビルド/テストを自動化する
 環境構築/設定、デプロイを自動化する
 何か問題があれば、以前の状態に自動的に戻す

すべてを構成管理下に置く
 ソースコード
 テストコード/テストケース/テストデータ
 ミドル/アプリケーション設定ファイル
 デプロイスクリプト
 データベーススクリプト
 テスト/開発環境のスナップショットイメージ


すべてをクラウドに置く
 開発者は開発環境クラウドに接続することで、全員が同じ環
境を使う
 Acceptance Test環境もクラウド上にホストし、並列でテス
トを自動実行する
 すべての環境は必ずデプロイ自動化の仕組みによってデプロイ
する
 スナップショットイメージよるバックアップとロールバック


クライアントAPのデプロイ自動化
 クライアントAPがデプロイ自動化の大きな壁
 一般的には、自動アップデートで対応
 TS(Terminal Service)Remote APPの仕組みを利用


カナリヤリリースとリーン

http://www.flickr.com/photos/revdancatt/400814032

顧客はクラウドの中

http://www.flickr.com/photos/dannykboyd/4746718211

 不特定多数の顧客や潜在的な顧客
 顧客自身も“本当に欲しい物”に気付いていない
 誰からも使われない機能の“ムダ”

イノベーター理論とフィードバック
 イノベーターとアーリーアダプター
 両ユーザに対して先行リリースしてFBを得る

アレ
アーイ
ーリ
イト
リー
ノマラ
ーマ
ベジガ
アジ
ーョー
ダョ
タリド
プリ
ーテ
タティ
ーィー
ー

2.5% 13.5% 34% 34% 16%

MVP(Minimum Viable Product)

http://www.flickr.com/photos/kmk7702/5917424548/

 必要最小限のプロダクト/フィーチャー
 ユーザからのフィードバックを受けるための最小単位

カナリヤリリース
通常エンハンス
Release

Deploy 一般
ユーザユーザ
ストーリー CI Env. ATT Env. Production Env.

新フィーチャー
Release

Deplo
y
Deploy コア一般
ユーザユーザユーザ
ストーリー CI Env. ATT Env. Canary Env. Production Env.
（MVP）
Feedback


顧客へ
迅速に
価値の高いソフトウェアを
デリバリーするために！

一緒に議論していきましょう！

Fin.
TFS , Team Foundation ServerおよびVisual Studio は、米国 Microsoft CORPORATIONの米国およびその他の国における登録商標または商標です。
その他、記載されている会社名、商品名、サービス名等は、各社の商標または登録商標です。

アジャイル開発から継続的デリバリーへ TFSUG#5

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (18)

En vedette

En vedette (20)

Similaire à アジャイル開発から継続的デリバリーへ TFSUG#5

Similaire à アジャイル開発から継続的デリバリーへ TFSUG#5 (20)

Dernier

Dernier (9)

アジャイル開発から継続的デリバリーへ TFSUG#5