狠狠撸

狠狠撸Share a Scribd company logo
Salesforce.com Agile事例
Agile at salesforce
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 ReleaseRelease
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 at salesforce
Agileと品質エンジニア
? 品質エンジニアの役割、求められるスキルに変化
? より幅広いスキル、知識
? テクニカル、プログラミングスキル
? プロダクトデザイン
? プロジェクト管理(スクラムマスター)
品質エンジニアの開発工程への統合
? デザイン、開発の初期工程から参加
? 問題の早期発見と修正
? 仕様、テクニカルデザイン、ユーザビリティ
? マニュアルテストから自動化テストへ
? Agile以前は、リリース前後に自動化テスト作成
? Agile移行後は、実装前、または実装と同時にテスト作成
? アーキテクチャ、実装詳細、開発環境の理解度が大幅にUP
品質エンジニアの役割の変化
? バグを出さない仕組み、環境を築くことに
? 常にテストを意識したコードへ
? テスタビリティ向上のための開発プラクティス、デザインパターンの
実施
? リファクタリング
? API駆動型のデザイン、実装
? テスト駆動型(TDD)の開発
? 徹底した自動化
? より深く、幅広いカバレッジ
? 効率の高いテストコード
品質エンジニア =>エンジニア
? 開発者と品質エンジニアの役割の希薄化
? 品質はチームが負う
? 標準化された開発プラクティスの実施、徹底
? 品質エンジニアの技術力、スキル向上
? 開発者向けの品質トレーニング、教育
? “エンジニア”で構成されたスクラムチームへ
? API、バックエンド関連のチームを主流に見られる傾向
開発者
品質エンジ
ニア
エンジニア
Agile at salesforce

More Related Content

Agile at salesforce