素晴らしいプレゼンでした。見た目としゃべりとのギャップがいい感じです。
角谷さんのもそうですけど、良いプレゼンは文章や資料では再現できないので、来れなかった人のためにせめて動画が見れればいいんですが、デブサミは撮影禁止なのが残念なところです。
ドワンゴはちゃんとしっかりアジャイルしているのが凄いです。
以下適当なメモ。嘘かいてあるかもしれません。
タイトルの説明
- 3周遅れ
- ネガティブじゃない
- 1周目 ケントベック
- 2周目 角谷さん
- 3周目
- 1.方向を示し
- 2.道を通す人
- ３周目→実は２周遅れ。間違いでした
車輪の再発明をしない
XP
4つの価値だけ覚えればいい
- コミュニケーション
- シンプルさ
- フィードバック
- 勇気
勇気→不安をなくすことによって行動できる
- テストケースが存在していればリファクタリングする勇気が出せる
おやつ神社
- 机の上におやつが置いてある
- プログラマが勝手にやってる
- みんなが気軽にしゃべれる場所を作る
テスト駆動
一昨年テストファーストがよく分からない！
- 角谷さん じゃあ、一緒にペアプロしてやってみようぜ
- 和田さん じゃあ勉強会やろう
- 品質管理ではない
- テストファーストにも拘らない
- TDDの目的はテストではない
- TDD=Test-driven development
- つまり開発手法 テスト手法ではない
- きれいで動作するコードにたどりつくには２つの道がある
- TDDは汚いけど動作する→きれいで動作する
- 動かなくてきれいなコードはゴールにたどりつけないんじゃ…
- 動作するコードをまず用意する
- リファクタリングして綺麗にしていく
- テストが先か後かは些細な問題
- 手や目で確認するのはめんどくさいでしょ
- なんでテスト自動化しないの
- 正しい結果を明日まで覚えてられない
- そのためにテストを書く
- 自分の解決すべき問題を小さく明白に
- スグにテストを実行
- 開発するためのテストを書く
- 品質管理ではなく自動化のため
- 品質を担保するためのテストではない
- TDDという開発手法自体が品質をアップさせる
- 実は今日は1年間続いていたプロジェクトのリリース日
- でも不安はない
- リファクタリングしやすい状況
- 小さい単位で一つのものを相手にする
- なんどもくりかえしそこで得た知見を即反映
- 小さいことを繰り返すことで大きいものをつくることができる
伝わりにくいこと
Q.UnitTestになってしまい、網羅的にテストを書いてしまう
- テストファーストに拘りすぎるとテストが肥大化するしテストを書くコストもかかる
- UnitTestではない
- 不安をテストする
Q. カバレッジが…品質が…テスト計画が…
- 開発のためのテストであって品質のためのテストではない
- 副作用として品質はアップする
社内でTDD写経会
- 入社して、ペアプロをお願いして、何もいわずにいきなりテストから書き始めた
- WEB+DB press Vol.35 テスト駆動開発を写経
- みんな慣れてきた
ペアプロ
- 一番大事なことはコードの共有
- 共有しないと、「○○さんが作ったのでわかりません」とか、勝手に直されると怒る人がいる
- 心に負荷をかけずにコードを共有するためにペアプロは良い
Q. XXXさんの書いたところだから…
- コードはチームのもの
Q. コードの指摘を人格批判と捉える
- コードの批判は人格批判ではありません
- 新人にはブログを書かせているし返信もブログでしてる
- 自分の書いたコードを晒すことに慣れる
- 批判を受けることにも慣れる
- わからないことがあったらブログに書け
- コードを共有化する私物化しない
- ペアプロが良い
CI (Continuous integration)
- テストをどんどん自動でやってくれる
- Hudsonを導入している
- 入社した時に Hudson があった。
- でも1日に1回しか実行されていない
- 5分に1回にした
- テストが落ちたらメールで教えてくれる
- Hudsonを使えば簡単
- 5分に1回にしたら SLOW TEST 問題発生
- テストが増える→テストにかかる時間が増える→TDDができなくなる 負の連鎖
- 自分のローカルでテストを走らせる時は、h2dbでオンメモリでテストを通すようにした。Oracleより早い
- データを消さないようにしたり
- モック化すべきだったかも
- でもモックは難しかった
- HudsonではOracleを使う
- 1回通すのに3時間くらいかかる
見積りと計画
- 苦手。偉い奴がやればいい…と思ってた
- リーダーやれと言われた。「お前のは苦手なんじゃなくてやってないだけだ」
- 社内読書会：「アジャイルな見積りと計画づくり」
- 見積りの仕方をロジカルに教えてくれる
- 一年後のリリース→答えられない
- ユーザーストーリーに分割
- プランニングポーカー 1 2 3 5 8 ? ∞
- 平均的に時間がかかるものを一つあげる → 5sp
- 同時に出すのが大事 前の人の話に影響されない
- 違いがあったら話し合う
- そろうまでやる
- 1ヶ月単位でリリース 二週間で１イテ
- 自分たちのチームがストーリーポイントをいくつ消化できるかがわかる
- 1月でどれくらい消化すればわかれば1年でどれくらい消化できるかわかる
- 月の初めにタスクを切り出す
- タスクは理想時間で。
- 大きな者は把握できるように小さく分ける
- 誰が何をやってるか？ がわかる
- 目に見えるところにおいておく
- Trac にも登録してるけど付箋もはってる
- 進捗はバーンダウンチャート
- 正直に書く
- 上司に怒られるかもしれないけど
- チームがどの程度すすんでいるかを把握するため
- ユーザーストーリーではなく機能ベースでやってる
- いろんな事情により。
- 現実がXPなどのプラクティスを採用するのが困難だったらそれにもアジャイルに対応する！
- 入力項目の仕様をExcelで提出しなくてはいけない
- →プログラムでその Excel を読み込んでバリデーション
- XPっぽくないことを言われたとしても自分たちで対処すればいい
- DB→Excel, Excel→DB
- DRY
- Ruby, Python, PHP, VB... いろんな言語でかかれている
- 個人のローカルで動いてるプログラムも多数
まとめ
- 大きなものは把握できるよう小さく分ける
- 小さい単位で一つのものを相手する
- 何度もくりかえしそこでえた知見を即反映
XP, TDD導入できないんだったら、まず個人で導入すればいい
- 個人→チームに派生する
- →会社→社会にも派生する
Kent Beck「XP is about social change.」
- 社会を変えられるかもしれない
- でも結果を求めてはいけない
- 大切なのは「真実に向かおうとする意志」
デブサミのアンケートに書かれたことを全部ブログで返信した
- 今年もやるのでぜひアンケートを書いて
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
- 作者: Mike Cohn,マイクコーン,安井力,角谷信太郎
- 出版社/メーカー: 毎日コミュニケーションズ
- 発売日: 2009/01/29
- メディア: 単行本（ソフトカバー）
- 購入: 69人 クリック: 698回
- この商品を含むブログ (217件) を見る
