アート・オブ・アジャイル デベロップメント...

アート・オブ・

アジャイルデベロップメント～テストが駆動するビジネス価値～

木下 史彦(株)永和システムマネジメント

f-kinoshita@esm.co.jp

目黒雅叙園; 2009-02-13(金)

つなぐ、つながる、そして未来へDevelopers Summit 2009

【13-E-2】

私たちはあなたがアジャイル開発の「道」を極める手助けをしたい。

We want to help you master the art of agile development.

自己紹介✓木下史彦✓(株)永和システムマネジメント✓オブジェクト倶楽部✓日本XPユーザグループスタッフ✓http://fkino.net

好評発売中

デブサミ会場内にて

先行発売

サイン会をやってます2/12 12:20～12:502/12 16:15～16:352/13 12:20～12:50@オブジェクト倶楽部ブース

私事ですが

Birthday

「木下さん」で検索してください。

謝辞✓岩切晃子さん✓和田卓人さん✓角谷信太郎さん✓平鍋健児さん✓日本のアジャイルコミュニティのみなさん✓永和システムマネジメントのみなさん

2009年2月13日

デブサミ2日目

DevelopmentStyle(Test)

テストにまつわる話

デブサミといえば

翔泳社

2007年4月

ツール✓テスト✓JUnit✓jMock✓jWebTest

✓自動化✓Maven2✓Continuum

テストの戦略

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

本日のお品書き✓アジャイル デベロップメント✓アート・オブ・アジャイル テスティング✓テストが駆動するビジネス価値✓組織を成功に導くエクストリームプログラミングの道

アジャイルデベロップメント

開発がアジャイルであるということは、協調性を重んじる環境で、フィードバックに基づいた調整を行い続けることである。

出典:『アジャイルプラクティス』

Copyright (c) 2009 Eiwa System Management, Inc.

イテレーション (1週間) の流れ要求

リリース可能なソフトウェア Ship It!

次のイテレーションへ

内部リリース

ふりかえりKPTベロシティ

バックログ

タスクプログラミング

機能バグデータ移行ドキュメント環境構築性能ジョーカー 受入テストを

書く 受入テストをする

完了基準

TDDCI

仕様の確認見積りスパイク

ふりかえりやバックログの優先度付けなどはお客さまにご協力いただきながら進めていきます。

イテレーションの流れストーリー

開発する

顧客テスト

イテレーションデモ

ふりかえり

完了基準

アート・オブ・アジャイルテスティング

テストの分類✓Developer Testing✓Customer Testing✓QA Testing

http://www.slideshare.net/t_wada/devsumi-2008-developer-testing

DeveloperTesting

イテレーションの流れストーリー

開発する

顧客テスト

イテレーションデモ

ふりかえり

完了基準

テスト駆動開発Test-Driven Development

TDDの目標動作するきれいなコード

Ron Jeffries

TDDのサイクルきれい

汚い

(すぐには)動かない 動作する

Green

Refactoring

Red

TDDのサイクル

出典:『The Art of Agile Development』

TDDのサイクル

出典:『アート・オブ・アジャイル デベロップメント』

TDDのサイクル

出典:『アート・オブ・アジャイル デベロップメント』

インクリメント

インクリメント考える

レッドバー

グリーンバー

リファクタリング

インクリメント考える

レッドバー

グリーンバー

リファクタリング

何を

考える✓コードでやりたい動作が何であるかを想像する✓5行以下のコードで済む小さなインクリメントを考え出す✓テストを考え出す

設計行為

誰が

主にナビゲータ

ペアプログラミング

主にナビゲータ

ピンポンペアリング考える

レッドバー

グリーンバー

リファクタリング

ペア交代

事例: テスト駆動開発✓1ヶ月✓7人✓Ruby✓Test::Unit✓Mocha

プロダクトコード10Kステップ

プロダクトコード10Kステップ

テストコード20Kステップ

カバレッジ97%

Developer Testingの分類✓ユニットテスト✓インテグレーションテスト✓エンドツーエンドテスト

ユニットテスト✓外部とのやり取りがない✓「シンプルな設計」が不可欠✓スピード重要

テスティングツール✓JUnit✓RSpec✓Google Test

10分ビルド

ユニットテストは高速に実行できる。もし高速に実行できないなら、それはユニットテストではない。̶̶ Michael C. Feathers

インテグレーションテスト✓外部とのやり取りをする✓データベース✓ネットワーク✓ファイルシステム✓プロセス境界

エンドツーエンドテスト✓ユニットテストとインテグレーションテストが完全にかみ合っていることを確認する✓実行に時間がかかる✓準備と後始末に手間がかかる✓このテスト自体が技術的負債になる

小さく速く回す

テストの分類✓Developer Testing✓Customer Testing✓QA Testing

http://www.slideshare.net/t_wada/devsumi-2008-developer-testing

CustomerTesting

イテレーションの流れストーリー

開発する

顧客テスト

イテレーションデモ

ふりかえり

完了基準

顧客テスト説明

サンプル

開発する

テストする

自動化

完了基準

コミュニケーションのためのもの

テスティングツール✓Fit✓Selenium✓Cucumber

10顧客に決断してもらう

『アジャイルプラクティス』より

Executable User Stories R Spec Bdd

http://www.slideshare.net/deimos/aslak-hellesoy-executable-user-stories-r-spec-bdd

✓ユビキタス言語✓「完了」に対する共通の認識

顧客との関係を変える

テストの分類✓Developer Testing✓Customer Testing✓QA Testing

http://www.slideshare.net/t_wada/devsumi-2008-developer-testing

QATesting

存在しない

XPチームには独立したQA部門というものはない

XPチームの目標はそもそもバグを書かないことだ

✓バグなし✓探索的テスト

バグなしNo Bugs

バグを書かないこと

ほぼバグゼロを実現する方法✓バグをほとんど書かない✓バグの繁殖場所を撲滅する✓バグをすぐに修正する✓プロセスをテストする✓プロセスを修正する

ほぼバグゼロを実現する方法✓バグをほとんど書かない✓バグの繁殖場所を撲滅する✓バグをすぐに修正する✓プロセスをテストする✓プロセスを修正する

ほぼすべてのXPプラクティス

ほぼバグゼロを実現する方法✓バグをほとんど書かない✓バグの繁殖場所を撲滅する✓バグをすぐに修正する✓プロセスをテストする✓プロセスを修正する

ほぼすべてのXPプラクティス

リファクタリング

ほぼバグゼロを実現する方法✓バグをほとんど書かない✓バグの繁殖場所を撲滅する✓バグをすぐに修正する✓プロセスをテストする✓プロセスを修正する

ほぼすべてのXPプラクティス

リファクタリング

割れ窓

ほぼバグゼロを実現する方法✓バグをほとんど書かない✓バグの繁殖場所を撲滅する✓バグをすぐに修正する✓プロセスをテストする✓プロセスを修正する

ほぼすべてのXPプラクティス

リファクタリング

割れ窓

探索的テスト

使用上の注意✓XPのあらゆる仕組みと裏付けを拠り所にしている。✓結果を出すためには、ほぼすべてのXPプラクティスを実践する必要がある。

‣ 考えること✓ ペアプログラミング✓ 活き活きとした仕事✓ 情報満載の仕事場✓ 根本原因分析✓ ふりかえり‣ 協力すること✓ 信頼✓ 全員同席✓ 真の顧客の参加✓ ユビキタス言語✓ スタンドアップミーティング✓ コーディング標準✓ イテレーションデモ✓ 報告‣ リリースすること✓ 「完全Done」✓ バグなし✓ バージョン管理✓ 10分ビルド✓ 継続的インテグレーション✓ コードの共同所有

✓ ドキュメント‣ 計画すること✓ ビジョン✓ リリース計画✓ 計画ゲーム✓ リスク管理✓ イテレーション計画✓ ゆとり✓ ストーリー✓ 見積り‣ 開発すること✓ インクリメンタルな要件✓ 顧客テスト✓ テスト駆動開発✓ リファクタリング✓ シンプルな設計✓ インクリメンタルな設計とアーキテクチャ

✓ スパイクソリューション✓ パフォーマンスの最適化✓ 探索的テスト

‣ 考えること✓ ペアプログラミング✓ 活き活きとした仕事✓ 情報満載の仕事場✓ 根本原因分析✓ ふりかえり‣ 協力すること✓ 信頼✓ 全員同席✓ 真の顧客の参加✓ ユビキタス言語✓ スタンドアップミーティング✓ コーディング標準✓ イテレーションデモ✓ 報告‣ リリースすること✓ 「完全Done」✓ バグなし✓ バージョン管理✓ 10分ビルド✓ 継続的インテグレーション✓ コードの共同所有

✓ ドキュメント‣ 計画すること✓ ビジョン✓ リリース計画✓ 計画ゲーム✓ リスク管理✓ イテレーション計画✓ ゆとり✓ ストーリー✓ 見積り‣ 開発すること✓ インクリメンタルな要件✓ 顧客テスト✓ テスト駆動開発✓ リファクタリング✓ シンプルな設計✓ インクリメンタルな設計とアーキテクチャ

✓ スパイクソリューション✓ パフォーマンスの最適化✓ 探索的テスト

探索的テスト

探索的テストテストの設計

テストの実行

結果の解釈

探索的テスト✓自動テストを補完する✓品質保証ではない✓チームの品質保証に対するやり方に関するフィードバック✓ソフトウェア✓チームのプロセス

事例: ペアテスト✓ペアでテストを行う✓手動テスト✓タイムボックス (2時間)✓たとえばデモの前の時間を使う✓バグが見つかれば修正して、自動テストに組み込む

前半のまとめ

アジャイル開発におけるテスト✓小さく速く回す✓いつでも (技術的には) リリースできる状態にしておく✓顧客との関係を変える✓プロセスを改善していく

石橋を叩いて渡る

テストが駆動するビジネス価値

組織を成功に導くエクストリームプログラミング

テスト

ビジネス価値

テスト

組織的な成功

ビジネス価値

テスト

開発 ビジネス価値

ビジネス要件

開発 ビジネス価値

ビジネス要件

開発 ビジネス価値

ビジネス要件

開発 ビジネス価値

ビジネス要件

Copyright (c) 2009 Eiwa System Management, Inc.

イテレーティブかつインクリメンタルな開発

1週間 = 1イテレーション

可視性状況が見えない

イテレーション毎に動くものべースで確認できる

変更容易性初期に要件を確定しなければならない

変更は最後のイテレーションがはじまるまで可能

技術リクス低減最後まで動いているものを確認することができない

動くものをベースに徐々に機能を追加していく

ビジネス価値最後の最後までリリースできない

早期にリリース可能な動くソフトウェアが入手できる

アジャイル開発

従来型の開発

打ち合わせ＆

リリース

時間

ユーザと開発者の距離

バスタブモデル

Copyright (c) 2009 Eiwa System Management, Inc.

イテレーティブかつインクリメンタルな開発

1週間 = 1イテレーション

可視性状況が見えない

イテレーション毎に動くものべースで確認できる

変更容易性初期に要件を確定しなければならない

変更は最後のイテレーションがはじまるまで可能

技術リクス低減最後まで動いているものを確認することができない

動くものをベースに徐々に機能を追加していく

ビジネス価値最後の最後までリリースできない

早期にリリース可能な動くソフトウェアが入手できる

アジャイル開発

従来型の開発

打ち合わせ＆

リリース

時間

ユーザと開発者の距離

いいことずくめ

アジャイル開発

時間

ユーザと開発者の距離

打ち合わせ＆

リリース

従来型

時間

ユーザと開発者の距離

打ち合わせ デモ リリース

要件定義 設計・実装 テスト

従来型 ̶̶リスク

時間

ユーザと開発者の距離

打ち合わせ デモ リリース

要件定義 設計・実装 テスト

従来型 ̶̶技術的負債

時間

ユーザと開発者の距離

打ち合わせ デモ リリース

要件定義 設計・実装 テスト

従来型→アジャイル

時間

ユーザと開発者の距離

打ち合わせ デモ リリース

要件定義 設計・実装 テスト

✓テスト駆動開発✓インクリメンタルな設計とアーキテクチャ

従来型→アジャイル

時間

ユーザと開発者の距離

打ち合わせ デモ リリース

要件定義 設計・実装 テスト

✓テスト駆動開発✓インクリメンタルな設計とアーキテクチャ

従来型→アジャイル

時間

ユーザと開発者の距離

打ち合わせ デモ リリース

要件定義 設計・実装 テスト

✓顧客テスト✓バグなし✓探索的テスト

従来型→アジャイル

時間

ユーザと開発者の距離

打ち合わせ デモ リリース

要件定義 設計・実装

✓顧客テスト✓バグなし✓探索的テスト

従来型→アジャイル

時間

ユーザと開発者の距離

打ち合わせ デモ リリース

要件定義 設計・実装

✓顧客テスト✓バグなし✓探索的テスト

従来型→アジャイル

時間

ユーザと開発者の距離

打ち合わせ リリース

要件定義

✓顧客テスト✓バグなし✓探索的テスト

従来型→アジャイル

時間

ユーザと開発者の距離

打ち合わせ リリース

要件定義

✓ビジョン✓インクリメンタルな要件

従来型→アジャイル

時間

ユーザと開発者の距離

リリース

要件定義

✓ビジョン✓インクリメンタルな要件

打ち合わせ＆

リリース

従来型→アジャイル

時間

ユーザと開発者の距離

リリース

✓ビジョン✓インクリメンタルな要件

打ち合わせ＆

リリース

アジャイル開発

時間

ユーザと開発者の距離

打ち合わせ＆

リリース

FAQ

既存のコードにテストがなかったら……

レガシーコードテストのないコード

怖くて変更できないコード James Shore

Michael C. Feathers

案件数

コンサル32%

既存開発27%

新規開発41%

2008年8月以降にお引き合いをいただいた案件

レガシー/既存開発テストコードあり

17%

レガシー83%

2008年8月以降にお引き合いをいただいた案件

エンドツーエンドスモークテスト

エンドツーエンドスモークテスト

✓大きな間違いをしたときに警告してくれる✓「接合部」を見つけて、ユニットテストを導入する

テスティングツール✓Fit✓Selenium✓Cucumber

心強い

シームレスに移行する

組織を成功に導くエクストリームプログラミング

の道

導入の障壁

✓組織的障壁✓心理的障壁✓技術的障壁

組織的障壁✓上司や同僚が認めてくれない✓うちの開発は特殊だから✓ぼくらの組織では使えない✓契約がry)

✓提案・営業から開発までエンドツーエンドでやる✓腹をくくった✓よい習慣を広める✓みんなが助けてくれる

✓契約はあまり気にしていない✓目の前の困っている人を助けたい

心理的障壁✓進捗がおちる✓納期に間に合わなくなるのではないか

３対2

３対2プログラマと顧客の比率

✓こまめにデモして状況を共有する✓技術的負債を溜めないことの方が重要✓不安なことがあればメールしてほしい

技術的障壁✓習得が難しい✓1～2ヶ月は生産性が落ちる

アジャイルの衰退と凋落

アジャイルは難しい。2日間の座学で身につくようなもんじゃない。

✓素振り重要✓歯を食いしばってやる✓親身になって教える✓みんな好きでやってる

原則✓プロセスを改善する✓人を信頼する✓ムダを排除する✓価値を届ける✓技術的卓越を追求する

原則✓プロセスを改善する✓人を信頼する✓ムダを排除する✓価値を届ける✓技術的卓越を追求する

自己鍛錬Self Discipline

まとめ

Of all agile methods I know, XP is the most complete.

私が知っているアジャイル手法のうち、XPが最も調和とバランスがとれている。

原則✓プロセスを改善する✓人を信頼する✓ムダを排除する✓価値を届ける✓技術的卓越を追求する

‣ 考えること✓ ペアプログラミング✓ 活き活きとした仕事✓ 情報満載の仕事場✓ 根本原因分析✓ ふりかえり‣ 協力すること✓ 信頼✓ 全員同席✓ 真の顧客の参加✓ ユビキタス言語✓ スタンドアップミーティング✓ コーディング標準✓ イテレーションデモ✓ 報告‣ リリースすること✓ 「完全Done」✓ バグなし✓ バージョン管理✓ 10分ビルド✓ 継続的インテグレーション✓ コードの共同所有

✓ ドキュメント‣ 計画すること✓ ビジョン✓ リリース計画✓ 計画ゲーム✓ リスク管理✓ イテレーション計画✓ ゆとり✓ ストーリー✓ 見積り‣ 開発すること✓ インクリメンタルな要件✓ 顧客テスト✓ テスト駆動開発✓ リファクタリング✓ シンプルな設計✓ インクリメンタルな設計とアーキテクチャ

✓ スパイクソリューション✓ パフォーマンスの最適化✓ 探索的テスト

プラクティス

プログラマはもちろん、テスター、プロジェクトマネージャ、……(省略)……、顧客などアジャイルに関心のあるすべての人におくる一冊である。

出典:『アート・オブ・アジャイル デベロップメント』裏表紙

XP (アジャイル) を開発者のだけのものにしておくのは、もう終わりにしたい

はじめは「アジャイルごっこ」だった。

でも

今は違う

自分たちのやっていることが、確実にビジネスにつながっているという実感

私たちはあなたがアジャイル開発の「道」を極める手助けをしたい。

We want to help you master the art of agile development.

ご清聴ありがとうございました

アンケートへのご協力をお願いします。

【13-E-2】