Developers Summit 2010 〜世界は変わった。開発の現場はどうか？〜 1日目
目黒雅叙園にて開催されたDevelopers Summit 2010 〜世界は変わった。開発の現場はどうか？〜に行ってきました。
客層はSIerの担当からリーダークラスが中心といった印象で、20〜40代前半が多数でした。
スーツと私服の割合は半々で、自分はスーツで参加しています。
ワークショップ【18-C-1】
ソースコード・リーディング・ワークショップ in デブサミ2010
協力：日本IBM株式会社
森崎修司 氏/保田祐一郎 氏
概要ver1.0のJavaAppletのコードを読んで、それに対する機能追加差分(ver2.0)のコードを読んで組み込んでも問題ないかを判断する課題で、最後に周囲の参加者とディスカッションするものです。
以下自分及び周囲の意見です。
- ソースのレベルが低すぎる
と文句を言いつつも、時間がかかった変更のレビューをグループで決めて提出した
最後に講師の方から、今までの研究で得た結果が説明され、私たちのグループは見当違いの箇所に時間かけたり、難易度が高いと感じたりしていた
研究データにノイズ入れて、すいませんorz
以下セッションメモ
- ソースコードメトリクスと読解時間の関係
開発プロセス【18-C-3】
アジャイルテスト−高品質を追求するアジャイルチームにおけるテストの視点−
増田聡 氏
概要講演者が翻訳に携わった『実践アジャイルテスト テスターとアジャイルチームのための実践ガイド』の原書の内容を掻い摘んでプレゼンするものです。
- 『実践アジャイルテスト テスターとアジャイルチームのための実践ガイド』の原書の『Agile Testing』の内容は実践的
- 5.2.3 指標でやってはならないこと
- 7.2.3 テストを考慮した設計
- 等、日々考えていることのヒントが書かれていた
- アジャイルテスト＝アジャイルチームのテスト
- 従来型テストの視点
- V字モデル
- 標準(IEEE等)
- テストケース作成
- 等
- メソドロジ
- プロセス記述(WBS)
- ガイド
- 作成物サンプル
- 等
- アジャイルテストの4象限
自動と手動 ビジネス面 手動
┌─────────────┬─────────────┐
│ │ 探索的テスト │
│ 機能テスト │ シナリオ │
│ ストーリーテスト │ ユーザビリティテスト │
│ プロトタイプ │ UAT(受入テスト) │
│ シミュレーション │ アルファ/ベータ │
チームを│ Q2│Q3 │製品を
支援する├─────────────┼─────────────┤批評する
│ Q1│Q4 │
│ 単体テスト │パフォーマンス/負荷テスト │
│ コンポーネントテスト │セキュリティテスト │
│ │ 「〜性」テスト │
│ │ │
│ │ │
└─────────────┴─────────────┘
自動 技術面 ツール
- 高品質を目指すチームのプラクティス
- チーム全体のアプローチを取る
- プログラマと一緒に会議に参加して、一緒にチーム全体の問題としてとらえる
- アジャイルテストの考えを採用する
- 継続的により良い方法を探し、良い本やブログ等を読み、新しいアイデアやスキルを身につける
- 自動リグレッションテストを適用する
- フィードバックを与え、受ける
- コアプラクティスの基礎を築く
- 継続的インテグレーションをする
- テスト環境を管理する
- 技術的な負債(未解決の技術的課題の累積)を管理する
- 段階的に作る
- コーディングとテストは一つのプロセスとする
- 各プラクティスの相乗効果を図る
- 顧客と共同作業する
- テスターはまとめ役になる
- 広い視野を持つ
- 現在のストーリーがビジネスの重要なスキームに合うか評価できるようにする
- チーム全体のアプローチを取る
- アジャイルテストへの移行
- 文化的なチャレンジ
- 組織の文化→味方を増やす
- 適応のする為の阻害要因→継続する
- 変革の導入→小さな成功を収める
- 管理職の期待 → 管理職の世界観の共有
- 変化は簡単ではない→体験させる
- チームの運営
- チームの構成→役割分担は必要
- 物の準備→作業環境、ツールも必要
- 人材→どのような人物がふさわしいか
- チームの立ち上げ→情報共有、目的共有
- プロセス移行
- 軽量プロセスを探す→出来ることから
- 指標を設定する→プラス思考になれる指標を設定
- 欠陥の追跡をする→ナレッジベースとして使う
- テスト計画書を作成する→先のことを考えるとリスクが浮かぶ
- 既存のプロセスとモデル→従うべきプロセスもある
- 文化的なチャレンジ
- 最後に、アジャイルプロセスサポートツール「Rational Team Concert」の紹介
雑感
- 増田氏は萩本氏と似た様なことを仰っていた
- 平鍋氏は居られなかったので、誰も突っ込んでいなかった
- Ask the Speakerで聞こうかとも思ったけど、次のセッションもとても人気があり、席を立つことが出来なかったので諦め
- 内容は良かったので、『実践アジャイルテスト テスターとアジャイルチームのための実践ガイド』がdevsumi価格で10%OFFだったので、購入
- http://togetter.com/li/5878 左記URLでも語られていたけど、TDDっていうのはチームの開発を支援するものであって、品質を保証するものではないということをあらためて実感
開発プロセス【18-C-4】
ドッグフーディングとアジャイル開発
大澤俊介 氏
概要日本人なのに、Seanというイカス名前を名乗っている方によるアトラシアン製品説明とデモを行うセッションです。
- アトラシアンの概要
- アトラシアンのミッション(a different kind of software company)
- アトラシアンのソフトウェア開発
- ショートリリース
- 市場動向をつかみやすい
- アジャイルを強要
- リリース予想
- チームにとってのメリット
- チームの士気向上
- 適度な緊張
- バグ修正に時間を使う
- 無理をしなくて済む
- ドッグフーディング
- FAIL FAST!
- 早く失敗すれば早く回復できる
- 社内ユーザーからのフィードバック
- 社員全員がテストユーザーな様なもの
- 素早いフィードバックが重要
- FAIL FAST!
- Good から Great へ「クォーターごとのリリース」を目指す
- コードレビュー
- 同僚にコードを見てもらうと、2つのうちのどちらかが起こる
- 説明しているうちに自分で気づく
- 同僚が気づく
- FORMALITYによる区分(上から順番にFormal)
- Inspection
- Team Review
- Walkthrough
- Peer Deskcheck, Passaround
- Ad Hoc Review
- 同僚にコードを見てもらうと、2つのうちのどちらかが起こる
- ベネフィット
- 顧客により発見された欠陥修正コスト$2,900
- インスペクションで発見した$146
- ある大企業では年間$2.5M削減
- 教育の効果
- ピアレビューの障壁
- エゴ
- 熟練デベロッパーによる支配
- レビューではなくプレゼンに
- 問題発見ではなく、問題解決ディスカッションに
- コードレビューの障壁
- スケジュールや場所の確保
- 地理的に分散したチーム
- プロセスにかかる経費
- コードレビューツール利用のメリット
- ミーティングの調整、記録など管理者の負荷を最小限にできる
- 入力する時間があり、記録に残るので、非建設的なコメントがされにくい
- 非同期で実施できる
- 透明性がある
- 結論: 良いツールはレビューの量と質の両方を増加させる
- ピアレビューの障壁
- アトラシアンではオンラインコードレビューを活用
- Five Tips For Agile Code Reviewers
- レビューするコードに関連する課題を読む
- コード変更の構成を見る
- 機能が動作しているか確認する
- 変更を自身で行うことを考えてみる
- レビュー終了時、提案リストをまとめ優先順位を付ける
- Tips By Wojtek
- 頻度：できるだけ頻繁に。“継続的コードレビュー”
- スケジュール：1日の最初、最後あるいはお昼
- 誰が？：同僚が一番。次に Tech Lead(技術リーダー?)
- 何人ぐらい？：2〜4 人で十分。時には1人でも
- ワークフロー：できるだけシンプルに
- 測定方法：それほど気にしない。少なくとも最初は
- Five Tips For Agile Code Reviewers
- PEOPLE
- ダニエル・ピンク「やる気に関する驚きの科学」より
- 20世紀的な報酬─狭い範囲でしか機能しない
- If then式の報酬─クリエイティビティを損なうことも
- 高いパフォーマンスの秘訣─内的な意欲
- ダニエル・ピンク「やる気に関する驚きの科学」より
- 人材への投資
- 社員が誇れる会社
- スターライセンスという10ユーザまで使えるライセンスを1000円で販売しており、そのライセンスの販売で得た全ての御金を寄付している
- 別の方からデモ
雑感
- 会社の説明が気持ち長かった、もうちょっと時間配分を考えてもらえると良かったかも
- デモは全般的に巧くない
- でも、“製品自体が営業マン、口コミ”と自負するだけあって、製品は素晴らしいものだったと思う
- 使いたいので、今度機会があったら、提案したい
Special【18-E-7】
デブサミオフィシャルコミュニティから選出のLT大会
すくすくスクラム/DevLOVE/日本XPユーザグループ/日本OpenSolarisユーザーグループ/日本Javaユーザグループ/日本PostgreSQLユーザ会/日本Rubyの会/Visual Studio ユーザーグループ/Firebird日本ユーザー会/わんくま同盟/司会 よしおかひろたか 氏/ドラ娘 永田祐子氏
概要デブサミに賛同いただいているコミュニティによる、ライトニングトークセッション。
- すくすくスクラムさん
- お子さんの写真で会場に笑いの渦を発生させていた
- 興味あったので、参加申請
- お子さんの写真で会場に笑いの渦を発生させていた
- DevLove
- 手書きのMindMapには「面白い！」「スゲー面白い！！」「よし、参加申請だ！」とだけ書いてあって、爆笑していたことしか覚えていない
- 日本Rubyの会
- 明日(2/19)は併設されているPMカンファレンスでお話をしまーすとびしっとスーツを着用した写真で会場を爆笑の渦に*1
- Visual Studio ユーザーグループ
- 難しい話は良く分かりません＞＜
- devsumi事務局の岩切氏
- スライドはなかったけど「世の中を良くするのはエンジニアなんです。そのためにソフトウェアを作ってください！」」という言葉に感動した
- 日本XPユーザグループ
- XPに携わって、-20Kgにお茶吹く位笑った(実際には飲んでない)
- 「面白い！」「スゲー面白い！！」「よし、参加申請だ！」という流れで参加申請
- ってか昔入ろうと思って、エラーで弾かれたことを思い出したら、ページなくなっているとのこと
- ちっちがうんだ、自分はアジャイルソフトウェア開発に元々興味があったってちょ、やめくぁwせｄｒｆｔｇｙふじこｌｐ；＠：「」
- 日本Javaユーザグループ
- 赤い人(Oracxx)の影響強くなったSunのお話で会場を爆笑に。
- 日本PostgreSQLユーザ会
- PostgreSQLはこんなにすごいんだよーって話
- 日本OpenSolarisユーザーグループ
- 海外でこんなことしてきたよーって話
- Firebird日本ユーザー会
- 流れる様なトーク
- Firefox、Thunderbirdと来て最後のJALにお茶吹く位笑った
- 多分、このLTが会場一番爆笑していたと思う
- そして、LTに加えて、本のプレゼントの為にじゃんけんもしたのに、5分以内だった、すごい！
- 本をもらったので、自分はこれを読まなければならないのである、まる
- 流れる様なトーク
- Goの人
- ハイリスクハイリターンな可能性を秘めたGoのお話
- わんくま同盟
- フッター以外は去年の使いまわしです、えへっで会場の笑いの渦に
雑感
- 元々社内イベントで、LTすることになったので、その参考になればいいなぁと思って参加しましたが、甘かった
- LT初めてと仰る倉貫氏(日本XPユーザグループのLT)も会場を爆笑の渦に叩き込んでいた、きっぱりはっきり言ってレベル高過ぎ
- きっとLTする人は全員他の発表で経験値を稼いでいるんだね、これは
- つまり、私のLTが失敗することがほぼ決まったというわけだ、えぇ
- まっ、失敗から何か学べばいいんだよ、ねっ？
*1:カジュアルな格好でLTしていた
