Embed Size (px)
DESCRIPTION
【13-E-2】アート・オブ・アジャイル デベロップメント 〜テストが駆動するビジネス価値〜
Citation preview
アート・オブ・
アジャイルデベロップメント～テストが駆動するビジネス価値～
木下 史彦(株)永和システムマネジメント
目黒雅叙園; 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】
