Agile at salesforce
-
Upload
ryoji-osawa -
Category
Documents
-
view
616 -
download
2
Transcript of Agile at salesforce
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 、バックエンド関連のチームを主流に見られる傾向