デブサミ関西聞いてきたログその１ (Chromeのプロジェクトに学ぶAgileでScaleするソフトウェア開発手法)
http://codezine.jp/devsumi/2012/kansai/
【S-1】Chromeのプロジェクトに学ぶAgileでScaleするソフトウェア開発手法
のログ
Ajailでスケールする開発手法
クラウド時代のソフトウェア開発
chromeを例にして
昔の開発
みどりの窓口などのシステム（人員が多い)
Water fall
人員が多いので以下に人員管理するかがきもになる
工程管理が必要。
がんとちゃーとが嫌い
＝＞Chromeのやつだった
Water fall の中のものでも使われてる
行程でやることを決めておく
各フェーズが決まっていても 何をもって終了 とするか決めなければならない
いろんなメンバーが何を持って終わらせるか決めておく
サインオフ
満たしたことを確認して次にいく
現在の大規模アプリケーションを全部を一つとしてやるには大きすぎる
＝＞小さい単位（コンポーネントとか）
最小単位は小さく（コミニケーションコスト、ドキュメントコストを下げるため）
テーマを全員に共有することが大事
ワードプロセッサを例に
何を作ろうとしているかを明示かすることが大事
単純で誰でもわかるものにする
森先生は３行で書いた
大規模開発でソースコード
どの段階でビルドするかが難しい
少人数の場合はメインブランチのみで大丈夫
チームが多い場合複数のブランチをわけチーム毎にビルドする
メインブランチに戻すタイミングをきめる（インテグレーション）
５時までにチェックあうとしとく
テスト
テスト書くけど、テスト期間を置くことがおおい （find it とよんでる）
バグであっても勝手に直させない。
・よかれと思ってなおしても他に影響がある場合がおおいので
・プライバシーの問題とかクラッシュするとかじゃないと直さない
リリース
昔：リコールはしてはいけない
クラウド：クラウド側で修正がすむ。
バグよりもサービスを出した後にダウンしないことが大事
開発の行程はWater fallと一緒
何が違うか？
Launch & Iterate
小さくて早いものをつくる
ユーザーが何を期待しているかわからない
小さくつくってフィードバックをとる
○習慣〜３ヶ月
Versionはもう関係ない
昔：階段上
今：進化が小さい（バージョンがないように感じる）
オープンソース開発の注意点
テーマを共有する
役割を決める
chromeのテーマー(simple speed security stabilish)
コミッター
定義
権限
資格
自分のやりたいことだけやる人はお断り。プロジェクトに貢献するというのが大事。
Reviewerが必ず必要。
誰がどのコンポーネントをレビューできるか明示するようになった。
ML
Build bot
いろんなプラットフォームで自動でビルドされる
Build botはテストもする
try server
テスト担当者がいる
タッチをサブミットする。
エッジケース含めてテスト書いて初めてチェンジできる
他の人の変更が自分のつくった部分を壊すかもしれないので、それを見つけれるテストを書く
かなりテストかいってるっぽ
テストは自動化されている
結論
自動化＋優良な市民
