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

デブサミ関西聞いてきたログその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

 IRC

 

Build bot  

いろんなプラットフォームで自動でビルドされる

Build botはテストもする

 

try server 

 テスト担当者がいる

 タッチをサブミットする。

 エッジケース含めてテスト書いて初めてチェンジできる

 他の人の変更が自分のつくった部分を壊すかもしれないので、それを見つけれるテストを書く

 かなりテストかいってるっぽ

 テストは自動化されている

 

結論

自動化+優良な市民