Created
February 21, 2011 02:57
-
-
Save tmitz/836609 to your computer and use it in GitHub Desktop.
2011/02/18 15:25～16:15
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| * リリースマネージメントについての話で依頼 | |
| * Googleの話だけではなくで、今までの経験 | |
| * 大規模向けの話 | |
| * 大規模ソフトウェア開発の一般的な話 | |
| * 「大規模」の前提 ＝ 失敗が許されないもの | |
| * なので、非常に堅いプロセスを選ぶ | |
| * 人月が大きい案件はコントロールが効かない・わからなくなりやすい | |
| * それをmanaged・controlすることが重要 | |
| * Windows2000の開発の話 | |
| * NDAあるからあんまりしゃべれない | |
| * 98〜99年に開発が滞ってた | |
| * ブライアン・バレンタイン、イアン・マクドナルドつれてきた | |
| * リリースマネージャ | |
| * 開発プロセスのリズムを作った | |
| * 「この日までに何をしろ」 | |
| * いらないモノはどんどん削っていく | |
| * ゴール間に合わない、品質基準を満たさない | |
| * 必要なものは期日を決めて品質向上に努める | |
| * ガントチャートは嫌いだけど、タスクを認知するのには有効 | |
| * 開発サイクルごとに要件があり、Exitミーティングを経てサインオフしたら次のフェーズに進める | |
| * 数百人の開発になると上記のようなサイクルが取れない（できない） | |
| * 1つの巨大なモジュールをいくつかのコンポーネントに分割してチームで分担 | |
| * 各チームごとに独立して開発プロセスを回す | |
| * テーマ | |
| * バラバラに動くとモジュールのコンセプトがずれてしまう | |
| * 長期間の開発することでテーマが無いと何を作っているのかぼやけてしまう | |
| * コアのテーマを共有して独立性を保つ | |
| * Google Chrome開発のテーマ | |
| * 3大原則：3S「シンプル」「スピード」「セキュリティ」 | |
| * テーマはわかりやすくするのが重要 | |
| * 複数のテーマで全部実現できない場合、将来性を見越せたモノになっているか | |
| * ブランチ | |
| * メインブランチと各コンポーネントごとのブランチ | |
| * 定期的にブランチ間でインテグレーション | |
| * 厳密なチェックインで定刻に始まるビルド | |
| * テスト | |
| * 一定のテスト期間を確保 | |
| * テストは全員のミッションであり全員参加型でやる必要がある | |
| * バグのインとアウト | |
| * グラフでモニタリングして減少しているかチェック | |
| * リリース | |
| * 「失敗が許されない」 | |
| * デプロイコスト／更新コストが高いため神経すり減らす | |
| * パッケージの場合インストール後だと更新パッチ | |
| * クラウドコンピューティング（Googleでの話） | |
| * クラウド | |
| * 「いつでもどこでも」 | |
| * デプロイコスト／更新コストが低い | |
| * 各ユーザへの修正適用が一律 | |
| * 品質基準（Quality） | |
| * 避けるべきはサービスダウン | |
| * ユーザがいらつかないレイテンシをださないこと | |
| * 機能不足やtypoなんかよりも大事 | |
| * リコール／回収を避けるべき | |
| * リリースしてからが本番 | |
| * Windowsはリリースするまでが本番 | |
| * 迅速さ（Agility） | |
| * 1プロジェクトは数ヶ月で終わる | |
| * 長いこと社内に抱えずにとりあえず外に出そう、という考え方を叩きこまれる | |
| * 社内で徹底的に議論して外にだす。答えがないから。 | |
| * マーケットリサーチもするけど力いれてない | |
| * 時間をかけても本心を得られない | |
| * 市場にない製品でリサーチする意味がない | |
| * Webサービスはスプリットテストが生かしやすい環境 | |
| * 製品の進化（Evolution) | |
| * 絶え間なく進化してるからバージョンつけるのは意味ない | |
| * バージョンレスでリニアに進化 | |
| * スケール（Scale） | |
| * ビルド数が右肩上がり | |
| * スケールする開発インフラ | |
| * 既存のウォーターフォールは人による制御 | |
| * クラウドではオートメーションでスケールするインフラに | |
| * Google Chrome・日本語入力 | |
| * バージョン番号を気にする必要はない | |
| * 常に最新版を提供するから | |
| * クライアントソフトでもクラウドの考えを最大限利用 | |
| * リリースサイクル | |
| * 13週ごと→6週ごとになった経緯 | |
| * devとstableでの確認フローをずらした | |
| * 最初にオフィシャルアナウンスして社内で6週で動くように | |
| * オープン性 | |
| * 世界中から貢献してもらえるから | |
| * コードレビュー | |
| * Googleのエンジニアとは限らない（Chromium, webkit） | |
| * 1度に大量のパッチを送らない | |
| * IRC | |
| * Google日本語IMEのテーマ | |
| * 「空気のような存在になりたい」 | |
| * いろいろ機能盛り込んでたけど最小限にした | |
| * テーマ決め・タスク分割するのにホワイトボード | |
| * そのあとオンラインに上げて共有 | |
| * ビルドオーブがアルパカ | |
| * 修羅場だといらいらするので、かわいい方がいいｗ | |
| * まとめ | |
| * 短いリリースサイクル | |
| * スケール | |
| * 可視化 | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment