Get Clean, Stay Clean

(1)

(2)

長沢智治

ながさわ

ともはる

日本マイクロソフト株式会社

デベロッパー＆プラットフォーム統括本部

エバンジェリスト / シニアプロダクトマネージャ

• E-AGILITY 協議会準備委員

• ソフトウェアテスト技術振興協会ツールワーキンググループメンバー

• 日本 XP ユーザグループスタッフ

• アジャイルイベント Agile Day 発起人

(

)

:

(

)

国内大手

情報通信企業

Rational

Software

IBM

Rational

Borland

Software

Microsoft

Software/Network

Engineer

Software

Engineering

Specialist

Brand Services

(3)

(4)

(5)

(6)

Microsoft Visual Studio の開発部門では、

大きく変わる開発チームに最高の開発プラットフォームを提供するという

価値

を継続し続けるために、幾度となく

改善活動

を行っています。

本セッションでは、

Quality

を価値と定めて、開発部門が実施したこと、

– Code Complete

から

Feature Complete

への意識の改革

– Quality Gate

– チーム開発基盤

と

テスト自動化

の整備

について、皆様と共有いたします。

アジャイルプラクティス

の積極採用と

テーラリング

、大規模開発での

透明性の確保

、

バグ負債

を10分の1に

削減

、イテレーションの

期間を

半減

させた実話をお伝えします。

(7)

(8)

あらゆる開発に適用できるフレームワークと開発支援ツールを

開発チームに提供し続ける

Integrated Development Environment

開発者の生産性の向上と

開発者同士のコラボレーション

Application Lifecycle Management

開発チームの生産性の向上と

チーム

コラボレーション

(9)

Integrated Development Environment

Application Lifecycle Management

開発者の生産性の向上と

開発者同士のコラボレーション

開発チームの生産性の向上と

チーム

コラボレーション

eclipse

Microsoft®

Test Manager

あらゆる開発に適用できるフレームワークと開発支援ツールを

開発チームに提供し続ける

(10)

メジャーリリース

サービスパック

次期メジャーリリース

サービスパック

CTP Beta

RC

Hot Fix

Feature Pack

Power Tools

CTP/Beta

リリース

(11)

(12)

(13)

(14)

(15)

(16)

(17)

開発し続けるための決断 (背景)

IDE

ALM

IDE 機能

IDE 拡張

For Architects, Developers, Testers

ALM 機能

IDE 機能

IDE 拡張

For Architecture, Development, Test

ALM 機能

2005

2008

2010

IDE 機能 & 拡張

Test Pro 機能

ALM 機能

テスト仮想化

事件の

現場

改善の

現場

(18)

開発し続けるための決断 (背景)

IDE

ALM

IDE 機能

IDE 拡張

For Architects, Developers, Testers

ALM 機能

IDE 機能

IDE 拡張

For Architecture, Development, Test

ALM 機能

2005

2008

2010

IDE 機能 & 拡張

Test Pro 機能

ALM 機能

テスト仮想化

 2 年単位でのリリース

 機能大幅増加に関わらず

 より多くのチーム開発機能

 品質基準を満たせず

 リリースを延期

(19)

(20)

IDE

ALM

IDE 機能

IDE 拡張

For Architects, Developers, Testers

ALM 機能

IDE 機能

IDE 拡張

For Architecture, Development, Test

ALM 機能

2005

2008

2010

IDE 機能 & 拡張

Test Pro 機能

ALM 機能

テスト仮想化

開発し続けるための決断 (取り組み)

(21)

開発し続けるための決断 (取り組み)

IDE

ALM

IDE 機能

IDE 拡張

For Architects, Developers, Testers

ALM 機能

IDE 機能

IDE 拡張

For Architecture, Development, Test

ALM 機能

2005

2008

2010

IDE 機能 & 拡張

Test Pro 機能

ALM 機能

テスト仮想化

価値ある機能を提供

タイムリーに提供

価値 (品質) の向上

透明性とアジリティ

(22)

開発し続けるための決断 (成果)

IDE

ALM

IDE 機能

IDE 拡張

For Architects, Developers, Testers

ALM 機能

IDE 機能

IDE 拡張

For Architecture, Development, Test

ALM 機能

2005

2008

2010

IDE 機能 & 拡張

Test Pro 機能

ALM 機能

テスト仮想化

Visual Studio 2005 beta 1

(23)

開発し続けるための決断 (成果)

IDE

ALM

IDE 機能

IDE 拡張

For Architects, Developers, Testers

ALM 機能

IDE 機能

IDE 拡張

For Architecture, Development, Test

ALM 機能

2005

2008

2010

IDE 機能 & 拡張

Test Pro 機能

ALM 機能

テスト仮想化

(24)

(25)

価値感の源泉

Remaining

W

ork

Plan

_{Task 1}

Task 2

 従来型の手法。タスクを分解し (WBS) 完了を計測

 原価計算

Value

 提供可能な “顧客価値” の増分で計算

 リーン生産と制約条件理論 (TOC)

“価値” を基準とし、高めていく:

 定義:

投資収益率、信頼関係、透明性、個人力、責任の共有、状況に応じた戦略

 やり方:

価値に基づく組織運営、意思決定

 測定法:

タスク達成率より、価値を測定

(26)

(27)

Milestone of Quality

 “負債” を理解する

 テストの自動化の促進

 製品コードバグの把握

 テストケースバグの把握

 テスト環境のバグの把握

 “負債” の共通認識

 “負債” のコスト

 “負債” の撲滅

 “品質” の測定

 迅速かつ、一貫して実施

 いつでも、どこでも

 早期からの “品質” の作りこみ

 ゆとりを取り戻す

(28)

Executive Sponsorship

• 新規の開発を 4 ヵ月間停止

– 文化の見直し

• Code Complete  Feature Complete

• Definitions of “Done” (Quality Gates)

– 徹底的な効率化

• チーム開発基盤の整備

• さらなるテスト自動化

(29)

(30)

(31)

Initiative | Feature Complete

PM* Group

Dev Group

Test Group

*Program Manager

物理的な組織体系

バーチャルなチーム

Feature

#1

Feature

#2

Feature

#3

1 人

4 人以下

XP

Scrum

Waterfall

 Feature Complete を目的としたチームとやり方の委譲

(32)

Initiative | Feature Complete

ビジョンや主要なテーマ

ユーザーにとっての投資効果

顧客価値の大きいエリア

テーマ:

ユーザーが顧客価値を高めるための製品活用法

シナリオの実現解

ユーザーストーリー

Experience から導き出されたもの

リリース計画

反復計画と実施

(33)

User Feedback

ストーリーボード

シナリオベースの

ユーザーフィードバック

の機会

(34)

Voting Sheets

Importance to your

business

Satisfaction with

_Existing

Notes

Most

important

Least important

functionality meet your

Does the existing

needs?

Pain

(mark with 'x')

Yes

No

Don't know

Once I work with something I can’t find it

again

I can’t tell what changed from build to

build, especially over time

I don’t know who is the expert of a given

area

I need another pair of eyes on my code

(35)

(36)

Initiative | チーム開発基盤

Dog Fooding:

(37)

Initiative | チーム開発基盤

Scenario

Experience

(38)

Initiative | Feature Complete

情報共有

意思決定

(39)

Initiative | Feature Complete

チームキャパシティ

 Yellow: 70 %以上

(40)

Initiative | Feature Complete

Risk Level

Green: 予定通り

Yellow: リスクを伴う

Red: 想定外

(41)

Initiative | Feature Complete

 自動単体テストも作成

 Feature のテストを作成

 シナリオテストは後でもよい

 Feature の完成に向けた作業見積り

 コードの完成で見積もらない

 段階的なコミット

 前倒しで、品質を作り込む～ Feature の完成前に実施

 脅威分析と Feature レベルのテストを必ず実施

 より多くのバグを発見し、修正

(42)

Initiative | Definitions of “Done”

 自動単体テストも作成

 Feature のテストを作成

 シナリオテストは後でもよい

 Feature の完成に向けた作業見積り

 コードの完成で見積もらない

 段階的なコミット

 前倒しで、品質を作り込む～ Feature の完成前に実施

 脅威分析と Feature レベルのテストを必ず実施

 より多くのバグを発見し、修正

(43)

Initiative | Definitions of “Done”

 自動単体テストも作成

 Feature のテストを作成

 シナリオテストは後でもよい

 Feature の完成に向けた作業見積り

 コードの完成で見積もらない

 段階的なコミット

 前倒しで、品質を作り込む～ Feature の完成前に実施

 脅威分析と Feature レベルのテストを必ず実施

 より多くのバグを発見し、修正

Task

Source

We’re done.

Feature ごとの

 期日のコミット

 品質基準の達成と進捗

I’m done.

個人レベルはチームで決定

 開発プロセス

 タスクの粒度、進捗

Test

無理なマイクロマネージメントを行わない

 チームに権限を委譲

(44)

Initiative | Definitions of “Done”

Task

各 Feature の進捗

Product Unit の進捗

ビジネスの進捗

Feature 単位での報告義務

（タスクレベルは Team の方針による）

(45)

(46)

(47)

Initiative | Definitions of “Done”

自動テストによる

コードのカバレッジ率が

70 ％

(48)

(49)

(50)

Initiative | Definitions of “Done”

Feature ブランチ

Check Point

＃1

Check Point

＃2

実施計画レビュー

どのように計画し

たのかを説明

実施内容レビュー

何を実施したのか

を説明

Feature のデモ

Check Point:

マネージャとの

レビュー/フィードバック/意思決定の機会

CP#0

コミット

見積り

CP#1

コミット

再見積り

CP#2

コミット

(51)

Initiative | Definitions of “Done”

 開発したテストの実施

 探索的テスト

 回帰テスト

 夜間テスト

Quality Gates

Build Verification Tests

 夜間テスト

 フル自動テストー Main へマージ前に実施

 統合テストと、探索的テスト

 パフォーマンスとストレステスト

 夜間テスト

(52)

公開向け資料用補足スライド

• 以下4スライドには、

– 米MSで自分たちのために開発したテストの効

率化のためのツール/方法について触れていま

す。

– これらはすでに Visual Studio 2010 の機能と

して実装されており、その動画へのリンクも記

載してあります。

クリックすることで、SlidesShare で公開

しているデモ動画にアクセスできます。

(53)

Initiative | Definitions of “Done”

 自動ビルドの仕組み

 継続的インテグレーションの進化形

 自動ビルド、テストで失敗の場合は、チェックインをさせない

 Quality Gates を自動化

ビルド/検証

開発者環境

ソース管理

継続的インテグレーション:

ゲートチェックイン:

(54)

Initiative | Definitions of “Done”

 開発者による単体テスト実行や自動ビルド時のテスト実行を記録

 ソースコード/テストコードの変更時に、検討すべきコードを自動検出

開発者環境

ソース管理

ビルド/検証

ソースとテストの関係を自動記録

開発時に検証すべきテストを一覧で通知

(55)

手動テスト

Initiative | Definitions of “Done”

 手動テスト時の結果を自動記録

 画面ショット、操作ビデオ、操作手順、システム情報

 2回目以降のテストを自動化

 自動ビルドでテスト実行

 バグの自動起票による開発者とテスターのやり取りの効率化

手動テスト

の自動化

検証に

組み込む

(56)

Initiative | Definitions of “Done”

 テスト環境を動的に構築しテスターに提供

 問題発生時に、テスト環境を開発者に瞬時に提供

開発者環境

ソース管理

ビルド/検証

仮想テスト環境

手動テスト

バグ起票と更新

C

D

B

(57)

Initiative | Definitions of “Done”

 開発したテストの実施

 探索的テスト

 回帰テスト

 夜間テスト

Quality Gates

Build Verification Tests

 夜間テスト

 フル自動テストー Main へマージ前に実施

 統合テストと、探索的テスト

 パフォーマンスとストレステスト

 夜間テスト

(58)

(59)

まとめ

 すべての “負債” の排除

 ビジョンの明確化

 フィーチャークルーと “Done” の定義

 ブランチ戦略および、テスト環境の整備

 透明性の確保と維持

 チームの自律とレポートの集中化

 各段階でのユーザーフィードバック

 反復的な計画

(60)

まとめ

• 意思決定” に効果を発揮

– 透明性と傾向分析

– 統括的なリーダーシップの意思決定

– 実測駆動な状況把握

– 自律したチームによる意思決定

– チームの自主的な報告

– 主要なメトリックスの自動追跡

(61)

Team Foundation Server

(62)

Team Foundation Server

現在の開発者数

3,839

作業項目数

839,595

ソースファイル数

826,234,724

ビルド数

2,010/月

2010 年 5 月現在

10 以上の

開発拠点

(63)

(64)

(65)

まとめ

 尊敬と結束

 透明性はすべてに役に立つ

 チームと組織のサイズ

 チームは、9 人まで

 組織は、できるだけ 160 人以内の単位

 Dunber’s Number

 Scenario を目安に組織化

 変化を作る

(66)

(67)

まとめ

Keep It Simple Stupid.

 複雑さの軽減に注力

 シンプルにスタート

 小さくスタート

 リアルなデータで価値を

示す

 一目で理解できるレポー

トを作成

 常によりよいものを

 誤りは正す

 アジャイルなプロセスを

作成すること

 K.I.S.S. を忘れないこと

 早い段階から巻き込む

 「それをやろう」と言っ

てもらう

 成功するための人員を確

(68)

© 2011 Microsoft Corporation. All rights reserved. © 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows 7, Visual Studio and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.

The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS,

IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Get Clean, Stay Clean

長沢 智治

ながさわ

ともはる

日本マイクロソフト株式会社

デベロッパー＆プラットフォーム統括本部

エバンジェリスト / シニア プロダクト マネージャ

• E-AGILITY 協議会 準備委員

• ソフトウェアテスト技術振興協会 ツール ワーキンググループ メンバー

• 日本 XP ユーザグループ スタッフ

• アジャイル イベント Agile Day 発起人

(

)

:

(

)

国内大手

情報通信企業

Rational

Software

IBM

Rational

Borland

Software

Microsoft

Software/Network

Engineer

Software

Engineering

Specialist

Brand Services

Microsoft Visual Studio の開発部門では、

大きく変わる開発チームに最高の開発プラットフォームを提供するという

価値

を継続し続けるために、幾度となく

改善活動

を行っています。

本セッションでは、

Quality

を価値と定めて、開発部門が実施したこと、

– Code Complete

から

Feature Complete

への意識の改革

– Quality Gate

– チーム開発基盤

と

テスト自動化

の整備

について、皆様と共有いたします。

アジャイル プラクティス

の積極採用と

テーラリング

、大規模開発での

透明性の確保

、

バグ負債

を10分の1に

削減

、イテレーションの

期間を

半減

させた実話をお伝えします。

あらゆる開発に適用できるフレームワークと開発支援ツールを

開発チームに提供し続ける

Integrated Development Environment

開発者の生産性の向上と

開発者同士のコラボレーション

Application Lifecycle Management

開発チームの生産性の向上と

チーム

コラボレーション

Integrated Development Environment

Application Lifecycle Management

開発者の生産性の向上と

開発者同士のコラボレーション

開発チームの生産性の向上と

チーム

コラボレーション

eclipse

長沢智治

エバンジェリスト / シニアプロダクトマネージャ

• E-AGILITY 協議会準備委員

• ソフトウェアテスト技術振興協会ツールワーキンググループメンバー

• 日本 XP ユーザグループスタッフ

• アジャイルイベント Agile Day 発起人

アジャイルプラクティス

メジャーリリース

サービスパック

次期メジャーリリース

サービスパック