読者です 読者をやめる 読者になる 読者になる

ひつじのにっき

mhidakaのにっきです。たまに長文、気が向いたとき更新。

【13-E-2】アート・オブ・アジャイル デベロップメント 〜テストが駆動するビジネス価値〜

アジャイル開発、特にXPでのテストについて。
テスト手法の紹介とテスト駆動開発でのテスト方法など開発現場に近い視点で解説
アジャイル開発は石橋をたたいて渡るという表現が印象的。


実際のところ、より簡潔なウォーターフォール開発すらうまく回ってない開発で
プラクティス(37個)をすべて守るのは生半可ではないはず。
アジャイルを通して開発プロセスだけではなく組織を変えていければとても素晴らしい。


特に話を聞いた後で、今後、考えていきたいと思ったのは
ウォーターフォールからアジャイルへの開発転換という途中切り替えの場合。
その際

  • 未テスト状態の怖くて変更できないレガシーコードの扱い、
  • プラクティス運用ルール

などが課題かな。勉強を継続したいです。

13-E-2 アート・オブ・アジャイル デベロップメント 〜テストが駆動するビジネス価値〜 木下 史彦

◆自己紹介
 アジャイルデベロップメント
 平鍋さんと一緒に翻訳しました
 33歳。業界は11年、アジャイル開発は4年弱

◆テストの話
 ・DevelopmentStyle Testトラック
 ・テストと自動化について

◆アジャイル開発
 協調性を重んじる環境でフィードバック…(以下略

 イテレーションの繰り返しを行う
  ストーリー → 開発 → 顧客テスト → イテレーションデモ → ふりかえり → (最初に戻る)
 
◆テスト駆動開発(TDD)
 目標:動作するきれいなコード
 TDDのサイクル 
  Think → RedBar → GreenBar → Refactaring 
  ~~~~がふえた         ↑___________|
  
 RedBar  :コードが整理されていない汚い状態
 GreenBar:きれいなコードを維持

 Think、考える=設計行為
  そのコードでやりたい動作は何か?
  コードの長さは5行以下と制限する★

 ペアプログラミング
  ドライバとナビゲータに分かれてプログラミング、主にナビゲータが考える。
  生産性が落ちる?
   →それはナビゲータが寝てるから(会場笑い)

 ピンポンペアリング - ペアプロの派生
  → テストを書いた段階でペア交代 RedBarからGreenBarの状態に移るあたりで。
  だいたい2時間ぐらいで交代する。

◆テスト駆動開発の事例
 1カ月のプロジェクト
  プロダクトコード: 10Kstep
  テストコード    : 20Kstep
                    カバレッジは97%★

◆開発者テストの分類
  ユニットテスト
   単体テスト。シンプルな設計を行う、スピードを優先
   ⇒ 10分ビルド:コミットして10分以内のビルドを。

 インテグレーションテスト
  外部I/Fをテスト

 エンドツーエンドテスト
  ユニットテストとインテグレーションテストがかみ合っていることを確認
  時間がかかる。仕様変更のときにテスト内容も大きく変わる可能性があり、
  手戻りが多くなる恐れ

 基本的には小さく、早く回すことが重要★

◆顧客テスト
 説明 → サンプル(この段階で自動化) → 開発 → テストする(完了基準)
 顧客がテストの意義:コミュニケーションのために実施★

 ユビキタス言語によるテストで顧客と開発者で共通言語を持つ
 
 完了に対する共同認識を持つ
 ⇒ 顧客との関係を変えること

◆QAテスト
 XP、TDDには存在しない

 それはバグなしプラクティスがあるから。
  バグを書かない  :すべてのXPプラクティスをやること。←難しい。
  リファクタリング:バグをすぐに修正することで連鎖を防ぐ
  探索的テスト

 注意
  ほぼすべてのXPプラクティスをやるということはすごく厳しい基準
  ⇒ できてない場合はやはりQAテストが必要

  探索的テスト
   自動テストを補完する。品質保証ではない。
   目的は抜け穴を探し、見つけたバグではソフトウェアやプロセスへのフィードバックを期待

 事例:ペアテスト
  時間区切って2時間ぐらい動かしながら
  手動テストでバグが見つかれば自動テストに組み込む

◆アジャイル開発におけるテスト
 小さく速く回す
 いつでもリリース(技術的に)できるようにしとく
 
 顧客との関係を変える、プロセス改善のポイント
 ⇒石橋をたたいて渡る。
   アジャイルは好き勝手をしているプロジェクト開発ではない

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

 ビジネス要件 ⇒ 開発 ⇒ ビジネス価値の創出 
 
 上記の流れがプロジェクト単位ではなく、要件ごとに繰り返される。
 ⇒ 価値から要件にフィードバックすることが重要★

 作り方は反復的かつ、インクリメンタルであること。
  細かく反復することで可視性、リスク等を防ぐ★

◆従来型開発との比較
 従来型はリスクは最後のテストまで残る
  コードもどんどん汚くなっていくため、技術的負債が大きい。

 アジャイルでは
  テストのフェーズを開発の中に組み込むため
  技術的負債が小さい

★既存のコードにテストがない場合
 レガシーコード:怖くて変更できないコードのこと
 ⇒ エンドツーエンド スモークテストで解決
    足場をまず組んで外部I/Fからテストを実施、
    そのあとでUnitTestなど内側のテストを実施するべき★
 
◆組織を成功に導く
 エクスストリームプログラミング

 ・導入には3つの障害がある★
   組織的障壁
   心理的障壁
   技術的障壁

 組織的障壁
  上司が認めてくれない
  契約の壁
   ⇒ 提案・営業から開発までエンドツーエンドで行う
     全員の理解を得る必要がある

 心理的障壁
  進捗や納期の心配
  ⇒ もっとも適当なプログラマと顧客の比率は3対2 では?
    プログラマが多すぎるのでは?確認の前に進みすぎてしまう。
    こまめにデモ等で確認、技術的負債を溜めないこと。 

 技術的課題
  開発手法の習得には数カ月かかる
  アジャイルは難しい ⇒ 基本、頑張れ(ここが精神論なのが惜しいw)
                        技術者には技術的探求が必要だ、やれ!

◆まとめ
 XPを取り上げた理由
  ・私が知っているアジャイル手法のうち、調和とバランスがとれている
  ・アジャイルの5つの原則を含み、プラクティスが豊富

 ⇒ アジャイルを開発者だけのものにしないで
   自分たちがやっていることがビジネスにつながる実感が必要★