撮影禁止を知らずに写真撮ってたらおこられました。ごめんなさい。
このセッションだけ特別かと思ったのですけど、あとでパンフ見てみたらデブサミ全体として撮影禁止だったようです。
この手のイベントで一律撮影禁止なのはいまいちだと思います。
以下メモ。嘘書いてるかもしれません。
- 「木下さん」でググると3番めに出てくる。
- ちょうど誕生日。会場拍手。
- アジャイルデベロップメントとは?
- 「ちゃんとしたソフトウェアを作る」 by id:kakutani
- 開発がアジャイルであるということは、協調性を重んじる環境でフィードバックに基づいた調整をおこないつづけること
Developer Testing
- テスト駆動開発
- 小さく速く回す
- Think→Red bar→Green bar→Refactor
- 考える
- コードでやりたい動作が何であるかを想像する
- テストを考え出す
- 設計行為
- 誰が考える?
- ピンポンペアプロ
- Red bar と Green bar の間でテストコード書いた後に交代
Customer Testing
- 顧客テスト
- 説明→サンプル<自動化>→(開発)→テスト<完了基準>
- コミュニケーションのため
- 顧客に決断してもらう
- Agile2008 Executable User Stories R Spec Bdd
- ユビキタス言語
- 「完了」に対する共通の認識
- 顧客との関係を変える
QA Testing
- 存在しない
- XPチームには独立したQA部門は存在しない
- XPチームの目標はバグをかかないこと
- バグなし
- 結果を出すためには、ほぼすべてのXPプラクティスを実践する必要がある
- 37個のうち33個
探索的テスト
- 自動テストを補完する
- 品質保証ではない
- チームの品質保証に対するやり方に関するフィードバック
- ソフトウェア
- チームのプロセス
前半まとめ
- アジャイル開発におけるテスト
- 小さく速く回す
- いつでも(技術的には)リリースできる状態にしておく
- 顧客との関係を変える
- プロセスを改善していく
- 石橋を叩いて渡る
- やんちゃではない。慎重なやりかた
テストが駆動するビジネス価値
- テスト→ビジネス価値→組織的な成功
- ビジネス要件→開発→ビジネス価値
- 実際にはこまぎれ。
- ビジネス価値→ビジネス要件 のフィードバックもある。
イテレーティブかつインクリメンタルな開発
- バスタブモデル
- 従来
- 要件定義はこまかく打ち合わせ。
- 設計・実装はそれなり
- テストは打ち合わせなし
- リスクは高いまま
- 技術的負債はあがりつづける
FAQ
- 既存のコードにテストがなかったら…
- レガシーコード
- テストのないコード
- 怖くて変更できないコード
- 木下さんの案件数
- 新規開発41%, 既存開発27%, コンサル32%
- 既存の中で→レガシー83%, テストコードあり17%
- エンドツーエンドスモークテスト
- 大きな間違いをしたときに警告してくれる
「組織を成功に導くエクストリームプログラミング」の道
- 「の道」を入れたかったけど長すぎて却下された。
導入の障壁
- 組織的障壁
- Q.
- 上司や同僚が認めてくれない 契約とか…
- A.
- 提案・営業から開発までエンドツーエンドでやる
- 腹をくくった
- よい習慣を広める
- みんなが助けてくれる
- 契約はあまり気にしない
- 目の前の困っている人を助けたい
- 心理的障壁
- Q.
- 進捗が落ちる
- 納期に間に合わなくなるのではないか
- A.
- 技術的障壁
- Q.
- 習得が難しい
- 1〜2ヶは生産性が落ちる
- A.
- アジャイルは難しい
- 素振り重要
- 歯をくいしばってやる
- 親身になって教える
- みんな好きでやってる
原則
- プロセス
- 人を信頼する
- ムダを排除する
- 価値を届ける
- 技術的卓越を追求する
自己鍛錬
- XPが最も調和とバランスが取れている
- プラクティス37個の中に対象が顧客のものがある
- XP(アジャイル)を開発者だけのものにするのはもう終わりにしたい