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