Developers Summit 2009 に行ってきたメモ。

行ってきた。つなぐ、つながる、そして未来へ　Developers Summit 2009。

初めての雅叙園だった。
凄い。綺麗。通路が広い。レストランが高い。

見積もりの２０年史

電研の中の人(!)の講演だった。昔の話は面白かった。○○の変遷とか興味深かった、日本は欧米から５年遅れだけどウチの職場はさらにウン年遅れだな、とか。FP法の話は知ってる内容なのに長かったので暇だった。最後が駆け足で残念だった。

• 電気の支払いの 0.2% ほど電力研究所にいくらしい。350億円/年。
• 90%=50%の法則
  • 担当者の意識と実際の進捗
  • 開発対象の不確定性
  • 生産力の不確定性
  • ソフトウェアの不可視性
• 見積もりの肝は規模把握にあり
  • 規模の過小評価
  • 仕様変更
  • 「当たり前品質」「隠れた要求仕様」
• ソフトウェアプロジェクトの混乱
  • リソース見積もりを誤ると、ほぼ確実に混乱する
    • エンジニアの生産性は、ほぼ一定。1日24時間。
    • ツールや新技術は、立ち上がりに時間が掛かる
    • 戦力の逐次投入は、愚の骨頂
  • 早く気づこう！大騒ぎしよう！！
• 見積もり方法の変遷
  • エイヤッ！
  • 熟練エンジニアのKKDD（経験、感、度胸、妥協）、COCOMO
  • ファンクションポイント法、WBS
  • スコープマネジメント、非機能要件、プロジェクトベンチマーキング
• 見積もりのトレンドの変遷
  • 工数見積もり重視（〜1980年代）
  • 規模見積もり重視（1990年代〜）
  • スコープマネジメント（最近〜今後）
• 規模見積もりの変遷
  • 開発者の作業対象量→ユーザの要求量
    • プログラム本数、行数（作業量）
    • 画面数、帳票数（物理的要求）
    • ファンクションポイント（論理的要求）
  • 規模に比例→様々な変動要因の加味。補正係数の利用→類似事例の参照
    • 単純積算：工数＝行数（本数）×生産性
    • 類似事例の生産性をベンチマーキング
    • COCOMO：工数＝生産性×規模^b×変動係数
• ファンクションポイント法
  • ソフトウェア要件
    • 機能要件　←　FP法の範囲内
    • 非機能要件　←　FP法の範囲外
      • 品質要件
      • 技術要件
  • メリット
    • 計測の過程で不明点が明確化
    • 計測者によって差があまり出ない
    • 利用者に理解しやすい
  • 諸刃の件
    • 開発条件に依存しない
  • No!!
    • FP法は工数見積もり手法ではない。規模を測る手法。
    • 工数見積もりに使えないわけではない。規模を計測することは見積もりの第一歩。
  • 留意点
    • FPと工数の相関度合いは、行程によって異なる
    • マクロの見積もりは出来るが、ミクロの見積もりはできない
• コスト変動要因（COCOMO)
• 計測量と目的量の相関を高めよう
• おわりに
  • あやふやなモノだからこそ、定量化して可視化
    • 要求があやふや
    • 生産性があやふや
  • せっかく測った定量データを大事に使おう
    • 実績の蓄積が、次を見積もる大切なノウハウになる
  • 洗濯機のアナロジー

Coverityの提供する「Coverity Inegrity Suite」によるソフトウェアテストプロセス/ソフトウェア開発ライフサイクル改善と品質の向上

もっと製品デモがあれば…。。

• ソースコードの静的解析ツール

パネルディスカッション：テストを行うこと、テストを続けること

途中までは興味深かったんだけど、、、リリース判定会議のような事は自分達でやらないくて良いのね（QA部隊がチェックしてくれる！）、うらやましい。。。

• Developer [TEST] Summit 2008 は PFD (Programming First Development)
  • テストはコスト
  • だから後から作る
  • なぜならバグは偏在するから
• このセッションで持ち帰ってほしいこと
  • 開発の一部としてごく普通にテストをする文化のチームはどういうものか
  • テストは全体の一部だと言うこと。思考停止しないということ
• ２つの成果物
  • ソフトウェア
  • プロセス = チーム
• アジェンダ
  • チームについて
  • テストについて
  • バグ管理について
• チームについて
  • XP が普通だと、チームから抜けた後にちゃんとやっていけているのか、不安だね。
  • 計画ゲーム：ビジネスの人と、プログラミングの人とが、一緒に優先順位を考えるよ。
  • 本読んだだけでコードなんて書けるようにならないでしょ？
  • ダイキボでは予測可能性が大事。
    • オフショアは「低め安定」
    • スゲー凄い人もいないけどスゲー駄目な人もいないので、予測できる
  • 工程が人が分かれると見積もりが外れる
• テストについて
  • テストをやっても品質はあがらない！
    • 品質をあげるのは、プログラミング
    • 駄目なところを見つけるのがテスト
    • 理想と自分達とのギャップを知る
  • 一部の人たちは「自分たちの領域」みたいなのを持ってる気がする
    • 「無責任領域」を決めているだけなんじゃないか？愚痴なの？言ってよ、直すからwww
  • やりかた
    • ストーリー単位にシナリオテスト
    • これをベースにアレンジしながらテストし続ける
    • 開発日記もつけてるよ。ストーリーにひっついて、開発メモが延々とついている。これを見てバグを探索する。
  • リスクベース
    • ストーリーごとにテストがある
      • 万単位である！
    • 全部はできないので、テストしないものを決める
      • 臭いとビジネス的に重要なものをテストする
  • 信頼度成長曲線
    • まず名前が良くない
      • 信頼度は成長してないよ
      • 「成長曲線」がバグ発見とかの統計に似ていたので「信頼度成長曲線」って名前になっただけ
    • これ意味あんの？
  • バグ管理について
    • RWiki
    • ストーリーとバグを等価に扱う
    • 欲しいものと今あるものが違うのであれば、それは同じもの
    • リリースまでにどれだけ理想に近づけるかの挑戦だから
    • ToBeとAsIsのギャップが新規ストーリー。
    • 計画があってバグを管理、ではなくて、ストーリーが計画。そこを見ることで仕事が進む。
    • いまやること、次にやること、だけ出す。
    • リスクが高い、すぐ欲しい、直さないとやばい（ビジネス的に）、だけ手前に出す

ついでに「モダンPerl入門」を買っておいた。10%オフだったし。サインは貰わなかった。

以上。