読者です 読者をやめる 読者になる 読者になる

[http://www.seshop.com/event/dev/2009/timetable/Default.asp?mode=detail&eid=124&sid=788&tr=10_Development+Style(Test)#788:title=パネルディスカッション:テストを行うこと、テストを続けること]

最初に撮影禁止と言われたので写真撮ってません。
途中でPCのバッテリが切れたのでメモも取れず… orz

飄々と受け答えしている関さんが素敵でした。
顔と名前から id がすらすらと出てくる角谷さんスゲー。

以下メモ。嘘書いてるかもしれません。

副題: Developer [Test] Summit 2009

去年のテストサミットのふりかえり

  • ゲスト: ひがやすを氏
  • Programming First Development
    • テストはコスト
    • だから後から作る
    • なぜならバグは偏在するから

このセッションで持ち帰ってほしいこと

  • 開発の一部としてごく普通にテストをする文化のチームはどういうものか
  • テストは全体の一部だということ 思考停止しないということ

関さんのデブサミ2008のサマリ

  • XPだったもの
  • Stories(Planning Game)
  • テスト担当者 = 開発者
  • テストの合間にプログラミング
  • 工程はバージョン
  • 昨日から今日へのバージョンへ
  • 次の工程に不良を残さない
  • おかしなところはすぐ直す
  • 二つの成果物
    • ソフトウェア
    • プロセス=チーム もう一つの成果物

Agenda 関さんと議論したい...

  • チームについて
  • テストについて
  • バグ管理について

チームについて

  • 同一チームでやることの良さと難しさ
  • Q. 新しいメンバーは入りづらい?
  • A.
  • ないんじゃないかな。むしろ抜けにくいかも。
    • ペアテスト。学習しやすい。
  • Q. どういう試験?
  • A.
    • 二人で製品の前に座って、ストーリーカードに試験が書いてあるので、それを見ながら製品を触っていく
    • 一人にしてあげないから、一人が好きな人はつらいかも。
  • Q. メンバーの入れ替わりはあるのか?
  • A.
    • 色んな事情で入れ替わりはある。
    • もうやめたいって人はいない。
    • よそにいっても仕事にならないんじゃないか。
    • いわゆるXPのハイになるとかには興味はない。
    • そうしないと製品がでないからやってる。
    • 楽しさには興味はない。
    • はたからみると楽しいかもね。
  • Q. 関さんの役割は?
  • A.
    • 無職
    • どのストーリーにも割り当てられない。
    • 誰が何が得意とか、観察する係。
    • 触媒。みんな「何してるかしらない」といってる。
  • Q. チームを立ち上げたばかりのころの話
  • A.
    • 最初はレガシーコードに向き合うところから。
    • 直したいけど壊しそうで直せない。
    • 計画ゲームをして優先度つけながら何をやるか決める。
    • レガシーコードに対するテスト 人間がやる試験を整備
    • 「僕が試験するから、みんなコード書いていい」
    • ペアプロテストファースト、TDD とかは後回し。
  • Q. 関さんは既存のチームにやってきた?
  • A.
    • ずっと一緒のチームだった。
    • 雰囲気ヤバくなってきた。製品が出るのが遅くなってきたり。
    • 違う作戦にしてみたかった。
    • ビジネス的な立場の人とプログラミングする人が優先度を考えた
    • 危機をみんなで感じていた
    • 最初からビジネス的な人も混じってた
    • 土壌が揃ってた。やりやすかった。
  • Q. 実際書籍の知識だけでアジャイルを始められるのか
    • 実際関さんはどうしていたか
  • A.
    • 成果物と言われている設計書の意味のなさを感じていた。
    • 世間でこんなこと言っている人がいる→真似してみた。
    • 本読んでコードかける人はいない。アジャイルも同じ。
  • Q. 「そんなのうちではできないよ」というひとへ
      • 文化の伝搬
  • A.
    • 他のチームもやってる
    • 1つは始まりは今のチームのコピー。結果的に違う進化。
    • 1つは全然関わらなくて、真似して自分たちで始めたチーム。
    • できない人もいるかもしれないけどできる人もいる。

太田さん
「ダイキボ」開発での話

  • オフショアの世界では
    • 予測可能性が大事
    • 「(もろもろ)低め安定」がオフショアの極意
  • Q. ブレの無い見積りができる?
  • A.
    • 彼らは予測可能性が重要。
    • 仕様書を読まずに厚みで計算している。

関さん

  • 予測可能は重要
  • 問題を分割すると同じサイズになっている。
  • だから予測可能。
  • ストーリー何個だからどれくらいという予想がつく。
  • 見積りは全員でやる。
  • 長くやってるからかも。

太田さん

  • 工程で人がわかれると見積りが外れる。

和田さん

  • チームのメンバーがある程度固定化されてるのがいい。
  • 人数編成で考える品質マネジメント?
    • 10人以下: 多能工
    • 100人以上: 低め安定が前提に?
  • 良いチームは金がかからない
    • 教育コスト、採用コストがかからない

関さんのチームは 20〜30人
製品全体では 100人超える

テストについて

  • そもそもなぜテストをするのか
    • 疑っているか?
    • 全体でソフトウェア開発なのだけど、専門家の領域を壊そうとしていない
      • 殻から出てこないのか、殻を疑っているのか
  • テスト技法について
  • A.
    • バグがないことを証明することは不可能
    • バグは無限
    • バグがない状態というのはない
    • 品質をあげているわけではない。
    • テストをいくらやっても品質はあがらない。超重要
    • 品質をあげるきっかけを見つける行為。
    • 理想の状態とギャップを知るため。

この辺でバッテリ切れ。

質問の時間に自分も質問してみました。

  • Q. 製品として出荷判定時の品質基準のようなものがあるか?
  • A.
    • QA部隊が別にいるので、そこがやっている。
    • そこに回すかどうかの判断は自分たちで行なっているので、自分たちで決めているといえるかも。

終了後もアスクスピーカーコーナーで色々話を聞かせていただきました。楽しかったです。