19-B-3 三周遅れのXP -僕とドワンゴのXP-／庄司嘉織

素晴らしいプレゼンでした。見た目としゃべりとのギャップがいい感じです。
角谷さんのもそうですけど、良いプレゼンは文章や資料では再現できないので、来れなかった人のためにせめて動画が見れればいいんですが、デブサミは撮影禁止なのが残念なところです。
ドワンゴはちゃんとしっかりアジャイルしているのが凄いです。

以下適当なメモ。嘘かいてあるかもしれません。

http://yoshiori.org

タイトルの説明

3周遅れ
ネガティブじゃない
1周目ケントベック
2周目角谷さん
3周目
1.方向を示し
2.道を通す人
３周目→実は２周遅れ。間違いでした

車輪の再発明をしない

開発プロセスについても車輪の再発明をしない
さらに先に進める
原点にあたらないとダメ→そんな奴は老害
やらないといけないことは高速道路の設置
うちらの業界はブログ書いたりtwitterで発言してる→高速道路を設置してる

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
- 1. Tracから日報
- 2. Tracのマイルストーン一括移動
- 3. IRCの「all:」の発言を毎日メール
- 4. IRCにチケット番号書くと概要表示
- 5. etc...
Ruby, Python, PHP, VB... いろんな言語でかかれている
個人のローカルで動いてるプログラムも多数