Agile at salesforce

1,090 views

Published on

Agile at salesforce

  1. 1. Salesforce.com Agile事例
  2. 2. Salesforce.com • クラウド/SaaSサービスベンダー • 製品 • CRM(顧客管理、営業支援)、カスタマサポート、マーケティング 、プラットフォーム、… • R&D • 拠点サンフランシスコ • 世界 15か所に分散 • 1500+ 以上のエンジニア • シングルコードベースで開発作業
  3. 3. Agile移行前 • 2006年にAgileへ移行 • Agile移行前はウォーターウォール型を繰り返す方式 • チーム構成 • PM, Dev, QA, Doc, UX/UI プランニング & デザイン 実装 テスト リリース パッチリ リース プランニング & デザイン 実装 テスト リリース パッチリ リース
  4. 4. Agileへ移行した背景 • スケールしなくなった • 機能数の増加、多様化 • エンジニア、チーム数の増加 • コードベースの増大、依存管理の複雑化 • テスト期間の長期化 • リリースサイクルの長期化 • 計画どうり進まない不安定なリリース • 機能の詰め込み 顧客満足度、サービスに対する信頼の低下
  5. 5. 2000 2001 2002 2003 2004 2005 2006 1チーム当たりのリリースした機能数 メジャーリリースに掛かった日数
  6. 6. Agile @ Salesforce • ADM (Adaptive Development Model) • Salesforce R&Dに特化したAgile開発方式 • スクラム、XP開発プラクティス、Leanの理念 • 1年に3回のメジャーリリース • 30日間のタイムボックス • 月単位で仕事を完了 毎月の一定なリズム 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 Release Release ReleaseRelease
  7. 7. Agile移行に成功した要因 • トップマネージメントのコミットメント • 徹底した教育(特にマネージャー) • 柔軟性は維持 • 素早いフィードバックループ体制の構築 • 継続的インテグレーション • 自動化 • ビルド • 自動化テスト • デプロイメント • バグ管理
  8. 8. 自動化テストへの投資
  9. 9. 品質にどのような効果があったか? • 品質向上に大きく貢献 • スケジュール通りの安定したリリースを2007年から継続 • 「品質」に対する考え方の変化 • 「バグを探す」から「バグを出さない」仕組み、環境作りへ • 品質を実装行程の中で作り込む • 品質はチーム全体が負う • 明確な「完了」リストの定義と徹底 • バイナリな意思決定
  10. 10. 完了リスト <機能 1> <機能 2> <機能 3> Code checked in and follows department standards    No open regressions. Automated tests written and reviewed for all regressions    No open P1 & P2 bugs    Code Coverage of 70% (or as agreed with team) 70% 70%  100% of test cases logged in QAForce and executed in a QA environment, and all P1/P2 cases passing    All resolved bugs verified and closed    Performance/scalability impact ascertained and sys testing scheduled if required    UE has reviewed any new features; P1 and P2 UI bugs fixed    Usability testing completed when necessary, and feedback incorporated into backlog    Code and UI reviewed for 508 compliance; UE team notified of any non-compliant features    All UI labels ready for localization vendors    User documentation complete and checked in    Metrics to measure customer usage have been defined and a Metric Request ticket filed for new metrics    Security standards met and critical issues resolved   
  11. 11. 品質の常時モニタリング • 最重要な品質指標を見える化 • 開発行程中常時モニタリング • “Don’t just clean it. Keep it clean” • 品質基準を満たさないチームは前に進ませない
  12. 12. Lock-the-Line ポリシー • 品質基準を満たさない場合、ソースコードをロック • ロックされたチームは開発作業に関するCheck-in 不可 • 重要な品質指標 • 自動化テスト成功率> 97-99% • テストバグの数 • 品質基準を満たせば自動的にロック解除 • ルール a) クリティカルなテストバグが1以上3日間 OPENの状態 b) チームにアサインされたテストバグの総数が10を超えた場合 c) クリティカルでないテストバグが5日間以上放置された1つでもある場合 d) チームにアサインされた全てのテストバグが100を超えた場合
  13. 13. Agileと品質エンジニア • 品質エンジニアの役割、求められるスキルに変化 • より幅広いスキル、知識 • テクニカル、プログラミングスキル • プロダクトデザイン • プロジェクト管理(スクラムマスター)
  14. 14. 品質エンジニアの開発工程への統合 • デザイン、開発の初期工程から参加 • 問題の早期発見と修正 • 仕様、テクニカルデザイン、ユーザビリティ • マニュアルテストから自動化テストへ • Agile以前は、リリース前後に自動化テスト作成 • Agile移行後は、実装前、または実装と同時にテスト作成 • アーキテクチャ、実装詳細、開発環境の理解度が大幅にUP
  15. 15. 品質エンジニアの役割の変化 • バグを出さない仕組み、環境を築くことに • 常にテストを意識したコードへ • テスタビリティ向上のための開発プラクティス、デザインパターンの 実施 • リファクタリング • API駆動型のデザイン、実装 • テスト駆動型(TDD)の開発 • 徹底した自動化 • より深く、幅広いカバレッジ • 効率の高いテストコード
  16. 16. 品質エンジニア =>エンジニア • 開発者と品質エンジニアの役割の希薄化 • 品質はチームが負う • 標準化された開発プラクティスの実施、徹底 • 品質エンジニアの技術力、スキル向上 • 開発者向けの品質トレーニング、教育 • “エンジニア”で構成されたスクラムチームへ • API、バックエンド関連のチームを主流に見られる傾向 開発者 品質エンジ ニア エンジニア

×