2009-02-13 :-)
_ 朝ッ
0730 起床
_ [デブサミ2009][devsumi2009]Developers Summit 2009 2 日目
【13-E-2】アート・オブ・アジャイル デベロップメント ～テストが駆動するビジネス価値～ (永和システムマネジメント 木下史彦)
「顧客と一緒にアート・オブ・アジャイル デベロップメントを読んで、そしてアジャイルやろうぜ」
- テストの話題
- ペアプログラミング
- ナビゲーターとドライバー
- 生産性が落ちるのはナビゲーターがサボっているから
- ナビゲーターが考えないのでいちいち路肩に止まる
- テスト事例
- 1 ヶ月
- 7 人
- Test::Unit
- Mocha
- プロダクトコード 10k
- テストコード 20k
- テストの分類
- ユニットテスト
- 完全に内部のみ
- インテグレーションテスト
- 外部とやりとり
- ファイルシステム
- ネットワーク
- プロセス間
- エンドツーエンドテスト
- ユニットテストとインテグレーションテストがかみ合っていること
- ユニットテスト
- 顧客テスト
- 毎週 客先で打ち合わせ
- 実物を提示できる
- バグなし
- QA テストを無くせるぜ
- XP をほぼ全部おこなう
- アート・オブ・アジャイル デベロップメントの 37 個のうち 33 個をおこえばいいよ
- fkino の道
- 営業→開発→納品までエンドツーエンドでやる
- 契約形態はなんでもいい
- 派遣でもなんでも
- 「アジャイルごっこ」
- アジャイルは難しい
- 習得に 1, 2 ヶ月かかる
- 一朝一夕の座学では身に付かない
「営業→開発→納品までエンドツーエンドでやる」というのは重要で( 私は営業やったことないんだけど )最初から最後まで一貫して作業する、というのはアジャイル的だけでなく仕事として考えても全体を経験できるのは良い。
補足：サインを貰ってるときに「管理ごっこ」を引き合いに出したのだけど、「管理ごっこ」とは「計画を管理する、PERT図を管理する、というようにたんに道具を管理しているだけでは管理しているとは呼べない、それはただの『管理ごっこ』である」という話題を思い出したためでる。淡々 XP のプラクティスを実践しているだけでは「アジャイルごっこ」に過ぎない。
4873113954
【13-E-4】「レガシーコード」とはいったい!? ～あなたも書いてるかもしれないレガシーコード～
- 情報工房 川西俊之
- サイボウズ・ラボ 中谷秀洋
- エルテックス 大中浩行
- ディノ 高橋邦彦
苦労話をするだけの簡単なお仕事なら誰でも出来るので前に進もうぜという話題。
- レガシーコードとは
- テストがないコード
- Edit & Pray
- 書いて、祈る
- 「頼むから動いてくれ」
- Cover & Modify
- カバーして、変換する
- 変更の正しさを確かめるテスト
- 実践レガシーコード
- PassNull
- 静的 Setter
- 「フィクションの経験によると」フイタ
- WEwLC
- 近日和訳される
- レガシーコードにテストを追加するためのカタログ集
- 「リファクタリング」という言葉は使われていない
- テストが無いリファクタリングは有り得ないから
- 医者は一人では手術しない
0131177052
【13-E-5】見積もりの２０年史(電力中央研究所 高橋光裕)
- 90% = 50% の法則
- 「90% 出来ました」は 50% しかできてない
- 何を作ればいいのか分かってない
- プロジェクトの失敗原因
- 規模を過小評価
- 人
- 物
- 金
- 時間
- 仕様変更
- 当たり前品質
- 客は期待する品質を暗黙知として持っているがそれが伝えられてない
- 初めての客は要注意
- 規模を過小評価
- プロジェクトの混乱
- 混乱したプロジェクトに戦力を投入するとさらに混乱する
- →「ブルックスの法則だよ」と ばっちゃが言ってた
- 見積りの変遷
- 1970 年
- 黎明期
- エイヤッ
- 1980 年
- ホスト全盛
- COCOMO
- 熟練者による KKDD
- 経験、勘、度胸、妥協
- 1990 年
- マルチベンダ
- クライアント/サーバー
- ファンクションポイント法
- WBS
- 最近
- スコープマネジメント
- 非機能要件
- プロジェクトベンチマーキング
- 1970 年
- 完璧な見積り技法など無い
- 完璧な見積り技法が登場するまで見積りしないというのは間違い
- どの技法を使ってもいいからとにかく計測する
【13-E-7】パネルディスカッション：テストを行うこと、テストを続けること
- タワーズ・クエスト 和田卓人
- 日本IBM 太田健一郎
- 東芝医用システムエンジニアリング 関将俊
- 永和システムマネジメント 角谷信太郎(友情出演)
角谷さんがロガーやってたのでログがどこかに公開されるはず。
デブサミ2009:パネルディスカッション：テストを行うこと、テストを続けること - 角谷HTML化計画 (2009-02-13)
捺印ナビリティの関係でログは非公開です。参加者しなかった皆さん、残念でした――と思ったけど、純粋な咳さんの発言ぐらいは抜粋してもよいのかしら？
おっと。
- 開発の一部としてふつうにテストをする文化のチームとはどういうものか
- テストは全体の一部
- 思考停止しないということ
- テストの目的
- 理想と自分たちとのギャップを知る
- 品質を高めるためではない
- テストでは品質は上がらない
- コードが品質を上げる
- 品質を上げるきっかけを作る
- テストのゴール
- 森を歩くために切り開く
- そこだけやる。余計なことはやらない
- ユーザーにとって役に立つことをやる
- ストーリー
- 1 万個くらいある
- バックログ
- ストーリーごとにテストを書く
- 全部をまわすのは不可能
- 優先度をつける
- リスク
- ビジネス価値
- バグ管理
- チーム内 RWiki に全部書いてある
- RWiki とストーリー
- ストーリーが計画
- ストーリーとバグを一緒に扱う
- →課題管理( issue tracking )だよね
- あとどれだけやることが残っているのか
- いま注目すべきことが分かるようにしている
- 全部は表示しない、大きすぎて嫌になるので
- テスト
- xUnit のような物は使っている
- 手触りはやってみないと分からない
- 自動化はしていない
- →ここで言っていたテストは xUnit のような単体テストだけでなくて実機でのテストも含めている。
当たり前のことを当たり前にやっているふつうの開発 であった。
サイン会
オブジェクト倶楽部ブースに行ってサインを貰ってきた。
[ツッコミを入れる]
