Salesforce.com Agile 事例

Salesforce.com

• クラウド／ SaaS サービスベンダー

• 製品• CRM （顧客管理、営業支援）、カスタマサポート、マーケティング

、プラットフォーム、…

• R&D

• 拠点 サンフランシスコ• 世界 15 か所に分散

• 1500+ 以上のエンジニア

• シングルコードベースで開発作業

Agile 移行前

• 2006 年に Agile へ移行

• Agile 移行前はウォーターウォール型を繰り返す方式

• チーム構成• PM, Dev, QA, Doc, UX/UI

Agile へ移行した背景

• スケールしなくなった

• 機能数の増加、多様化

• エンジニア、チーム数の増加

• コードベースの増大、依存管理の複雑化

• テスト期間の長期化

• リリースサイクルの長期化

• 計画どうり進まない不安定なリリース

• 機能の詰め込み

顧客満足度、サービスに対する信頼の低下

2000 2001 2002 2003 2004 2005 2006

1 チーム当たりのリリースした機能数

メジャーリリースに掛かった日数

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

Release

Release

Agile 移行に成功した要因

• トップマネージメントのコミットメント

• 徹底した教育（特にマネージャー）

• 柔軟性は維持

• 素早いフィードバックループ体制の構築

• 継続的インテグレーション

• 自動化

• ビルド

• 自動化テスト

• デプロイメント

• バグ管理

自動化テストへの投資

品質にどのような効果があったか？

• 品質向上に大きく貢献• スケジュール通りの安定したリリースを 2007 年から継続

• 「品質」に対する考え方の変化• 「バグを探す」から「バグを出さない」仕組み、環境作りへ

• 品質を実装行程の中で作り込む

• 品質はチーム全体が負う

• 明確な「完了」リストの定義と徹底

• バイナリな意思決定

完了リスト< 機能 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

品質の常時モニタリング

• 最重要な品質指標を見える化

• 開発行程中 常時モニタリング

• “Don’t just clean it. Keep it clean”

• 品質基準を満たさないチームは前に進ませない

Lock-the-Line ポリシー

• 品質基準を満たさない場合、ソースコードをロック

• ロックされたチームは開発作業に関する Check-in 不可

• 重要な品質指標• 自動化テスト成功率 > 97-99%

• テストバグの数

• 品質基準を満たせば自動的にロック解除

• ルールa) クリティカルなテストバグが 1 以上 3 日間 OPEN の状態

b) チームにアサインされたテストバグの総数が 10 を超えた場合

c) クリティカルでないテストバグが 5 日間以上放置された 1 つでもある場合

d) チームにアサインされた全てのテストバグが 100 を超えた場合

Agile と品質エンジニア

• 品質エンジニアの役割、求められるスキルに変化

• より幅広いスキル、知識• テクニカル、プログラミングスキル

• プロダクトデザイン

• プロジェクト管理（スクラムマスター）

品質エンジニアの開発工程への統合

• デザイン、開発の初期工程から参加

• 問題の早期発見と修正• 仕様、テクニカルデザイン、ユーザビリティ

• マニュアルテストから自動化テストへ• Agile 以前は、リリース前後に自動化テスト作成

• Agile 移行後は、実装前、または実装と同時にテスト作成

• アーキテクチャ、実装詳細、開発環境の理解度が大幅に UP

品質エンジニアの役割の変化

• バグを出さない仕組み、環境を築くことに

• 常にテストを意識したコードへ• テスタビリティ向上のための開発プラクティス、デザインパターン

の実施

• リファクタリング

• API駆動型のデザイン、実装

• テスト駆動型（ TDD ）の開発

• 徹底した自動化• より深く、幅広いカバレッジ

• 効率の高いテストコード

品質エンジニア => エンジニア

• 開発者と品質エンジニアの役割の希薄化• 品質はチームが負う

• 標準化された開発プラクティスの実施、徹底

• 品質エンジニアの技術力、スキル向上

• 開発者向けの品質トレーニング、教育

• “エンジニア”で構成されたスクラムチームへ• API 、バックエンド関連のチームを主流に見られる傾向