SlideShare ist ein Scribd-Unternehmen logo
1 von 71
Agile Development at Salesforce.com


大沢 良樹
Salesforce.com Inc.
July 2012
Safe Harbor
Safe harbor statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forward-
looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the
assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or
implied by the forward-looking statements we make. All statements other than statements of historical fact could be
deemed forward-looking, including any projections of subscriber growth, earnings, revenues, or other financial items and
any statements regarding strategies or plans of management for future operations, statements of belief, any statements
concerning new, planned, or upgraded services or technology developments and customer contracts or use of our
services.

The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and
delivering new functionality for our service, our new business model, our past operating losses, possible fluctuations in
our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the
outcome of intellectual property and other litigation, risks associated with possible mergers and acquisitions, the
immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate
our employees and manage our growth, new releases of our service and successful customer deployment, our limited
history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further
information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual
report on Form 10-K for the most recent fiscal year ended January 31, 2010. This documents and others are available
on the SEC Filings section of the Investor Information section of our Web site.

Any unreleased services or features referenced in this or other press releases or public statements are not currently
available and may not be delivered on time or at all. Customers who purchase our services should make the purchase
decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not
intend to update these forward-looking statements.
AGENDA

1. About me
2. About Salesforce.com
3. Adaptive Development Methodology
4. 継続的インテグレーション
5. 自動化テスト
6. リリースマネージメント
Adaptive Development Methodology
             (ADM)
Background


       2002年 1年に4回のバージョンアップ




       2006年 1年に1回のバージョンアップ
Waterfall Model
計画どうり進まない、
予測できないプロジェクト
可視性の欠如
常に変化する
  プライオリティ
ユーザフィードバック
        の欠如
メジャーリリースに掛かった日数




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




2000     2001   2002   2003   2004   2005   2006
What is ADM?

   ADM (Adaptive Delivery Methodology) は
salesforce.comに特化した大規模アジャイル開発手法


                  SCRUM
           XP開発プラクティス
                LEANの理念
What is ADM?
  Consistent Rhythm
                            Self-organizing        Continuous integration

Lean                                                            Self-correcting
                                   Time-boxed

         Ftest - Selenium                               Refactoring

                            Continuous learning
  Transparent
                                                                Early Feedback
                                 Iterative
       Code Reviews                                        Just-in-time
                   Collective code ownership
                                                                      Debt free
Continuous
  improvement                 Continuously releasable
What is ADM?




       Simple
ADM 5つの基本理念
ムダの排除
クオリティ・ファースト
「人」主導
ジャストインタイム
      の意思決定
迅速なデリバリー
開発は30日の
 タイムボックス内で作業
チームが主役
密度の高い
日常のコミュニケーション
Salesforce Release Cycle

           Release                                     Release
                      Product Development Sprints                      Release
           Planning                                     Sprint


   December January         February     March       April       May         June




                                                         Release                                          Release
 de Line                                                               Product Development Sprints                    Release
                                                         Planning                                          Sprint
Opens

                                                     April       May         June        July        August   September October




                                                 Code Line
                                                  Opens
SFDC Release CycleとADMの開発リズム

Release                  Release                  Release                Release




   2月     3月   4月   5月      6月     7月   8月   9月      10月    11月   12月   1月




                                   毎月の一定なリズム
SCRUM
What is SCRUM?




   アジャイル開発の代表的なプロジェクトマネージメント手法
   作業期間(スプリント)を繰り返しソフトウェアを構築
   チーム自身が作業する仕事を決める
   スプリント終了後、リリース可能な成果物を生成
PRODUCT BACKLOG
3   デイリー・スタンドアップ
Scrum Life-cycle




                                                 4   スプリント・レビュー



            2   スプリントプランニング
                                  30日間
                                  スプリント
                                                     リリース可能な成果物


1   プロダクト・バックログ

      1 1
                                                 5    レトロスペクティブ
      2 2
      3 3         コミットメント
      4 4
      5
      5
      6
      6
      7
      7
      8
      8
      9
      9
      10
      10
      11
      11
      12
      12
      13
      13
Sprint Planning


 プロダクト・バックログから優先度の
  高い項目を選択
 チームが作業量を決める
 タスクの細分化、見積もり
 タスクの割り当てはしない
進捗状況の管理
Salesforceを使ってScrumタスクを管理

バックログの管理、優先度付け
 スタンドアップ・ミーティング(15分)で進捗の報告
 毎日、同じ時間&同じ場所で行う
 簡潔な報告
 残り作業量と残り期日のみトラッキング
明確な
  「完了」の定義




    明確な
    「完了」の定
    義
Doneness Checklist
                                                         <機能 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                        
「完了」できなかった場合はどうなる?
未完了の機能は無効化させ
次のリリースで完了させる
Scrum Team @ Salesforce

                  Cross Functional Team
                  150以上のScrum Teams
                  各チームが特定の製品、機能を担当
                  6-10人のメンバーで構成
Salesforce Office in SF
Scrum at Scale

                                                Scrum of
                                                Scrum of                            Technical Operations
                                                Scrums




                  Platform Division      Applications Division   Infrastructure Division

                          Scrum of              Scrum of               Scrum of
                          Scrums                Scrums                 Scrums

                                                                                            Shared Resources



 Scrum Teams                                                                               UI Design     Doc
(with dedicated
  Dev & QA)

                                                                                            System
                                                                                                       Usability
                                                                                             Test


                  Work
                  group               Work
                                      group
Scrum of Scrums
Chatter @ Salesforce R&D

 1400以上のChatter Group
 チーム、部門をまたがる情報共有、コラボレーション
 R&D組織全体に関わることを日々活発に議論
 仕事以外の雑談もChatterで!
   – Airing of Grievances
   – Sign your praises on high
   – Opportunity Open Market
Chatter Groupを活用して
チーム/部門をまたいだコラボレーション
Salesforce R&D 開発環境
“Don’t just clean it.
             Keep it clean.”
継続的インテグレーション
 Continuous Integration
継続的インテグレーション


               SYNC
                                    •   XPの開発手法のひとつ
                                    •   小規模な変更を頻繁にレポジトリ
                                        にコミットを繰り返しながらソフ
                           MAKE
TEST                                    トウェアを構築していく
                          CHANGES
                                    •   開発ビルド作業の自動化
                                    •   最低1日1回のコミット




       BUILD          COMMIT
継続的インテグレーションの利点


• インテグレーションに伴うリスクの軽減 (Small = Better)
• ビルド自動化によるインテグレーション作業の軽減
• 自動化テストと併用し、問題や不具合の早期発見と常時モニ
  タリング
• ソフトウェアの品質向上
Autobuild
Continuous Integration Build System @ SFDC
Autobuild

•   完全自動化されたビルドプロセス
                                           SYNC
•   全てのコードライン、変更にビルド+自動化テスト
•   ビルド問題発生時すぐにコミッターに通知
                                                       MAKE
                                TEST
•   自動化テストと併用、常時コードラインのモニタリング                         CHANGES


•   テスト分散による実行時間の短縮
•   クリティカルなテスト実行完了 45分以内
                                   BUILD          COMMIT
ビルドは絶対に壊さない!


壊れたビルドの修正 = 最優先事項
テストの自動化
Why do we automate tests, anyway?
自動化テストへの投資
どうしてテストを自動化するのか?


 時間とコストの節約
   24時間/365日継続して実行可能
   リグレッションテスト
   バグの早期発見、フィードバック
コードラインは常にクリーンを維持


   自動化テスト結果(成功率)は重要な指標
   自動化テスト結果の目標値をR&D全体に設定
   毎月の目標値を満たしながら開発作業を進める
Lock-the-Line Policy
テスト成功率が基準値以下(99.x%)なら
Lock-the-Line by Team
   各チームにも目標値が設定
リリースマネージメント
  Continuous Deployment
リリース・デプロイメント @ SFDC


 デプロイメントの完全自動化
 デプロイ完了後に自動的にリグレッションテスト実行
 問題が発生した場合、すぐにロールバック
 2011年 250以上のデプロイ実施
Dogfooding – まずは自分達で使う

 本番環境リリースの2ヶ月前に
  GUSのアップグレード
 自分達で使いながらバグの洗い
  出しと修正を繰り返す
段階的なリリース



    GUS     Sandbox   Production




 段階的リリースによるバグの洗い出しと修正を繰り返す
     カスタマーへのインパクトを最小限に
継続的モニタリング
おさらい

1.   ADMの概要

2.   5つのADM基本概念

3.   30日のタイムボックスで作業

4.   Scrumプロセス

5.   継続的インテグレーション

6.   自動化テストの役割

7.   デプロイメント完全自動化

8.   Dogfooding、段階的なリリース
Agile Development at Salesforce

Weitere ähnliche Inhalte

Was ist angesagt?

ウォーターフォールとアジャイル開発の比較 
ウォーターフォールとアジャイル開発の比較 ウォーターフォールとアジャイル開発の比較 
ウォーターフォールとアジャイル開発の比較 
Unicast Inc.
 
定量的プロジェクト管理ツール概要 Lt 20110730
定量的プロジェクト管理ツール概要 Lt 20110730定量的プロジェクト管理ツール概要 Lt 20110730
定量的プロジェクト管理ツール概要 Lt 20110730
hiroetoh
 

Was ist angesagt? (20)

とあるメーカーのRedmine活用事例
とあるメーカーのRedmine活用事例とあるメーカーのRedmine活用事例
とあるメーカーのRedmine活用事例
 
リーン開発の本質 公開用
リーン開発の本質 公開用リーン開発の本質 公開用
リーン開発の本質 公開用
 
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違いなぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
 
ソフトウェア調達におけるアジャイル開発の要点と現状 Slideshare
ソフトウェア調達におけるアジャイル開発の要点と現状 Slideshareソフトウェア調達におけるアジャイル開発の要点と現状 Slideshare
ソフトウェア調達におけるアジャイル開発の要点と現状 Slideshare
 
ソフトウェア構成管理入門
ソフトウェア構成管理入門ソフトウェア構成管理入門
ソフトウェア構成管理入門
 
RAD Studioで実践する継続的インテグレーション アプリとデベロッパーの価値を拡張するエッセンス #dcamp_jp
RAD Studioで実践する継続的インテグレーション アプリとデベロッパーの価値を拡張するエッセンス #dcamp_jpRAD Studioで実践する継続的インテグレーション アプリとデベロッパーの価値を拡張するエッセンス #dcamp_jp
RAD Studioで実践する継続的インテグレーション アプリとデベロッパーの価値を拡張するエッセンス #dcamp_jp
 
ソフトウェア開発を加速させるリーン開発の原則 公開用
ソフトウェア開発を加速させるリーン開発の原則 公開用ソフトウェア開発を加速させるリーン開発の原則 公開用
ソフトウェア開発を加速させるリーン開発の原則 公開用
 
ヒーロー島 Visual Studio 2012
ヒーロー島 Visual Studio 2012ヒーロー島 Visual Studio 2012
ヒーロー島 Visual Studio 2012
 
Devlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのかDevlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのか
 
タイムボックス制約付きインクリメンタル開発
タイムボックス制約付きインクリメンタル開発タイムボックス制約付きインクリメンタル開発
タイムボックス制約付きインクリメンタル開発
 
ウォーターフォールとアジャイル開発の比較 
ウォーターフォールとアジャイル開発の比較 ウォーターフォールとアジャイル開発の比較 
ウォーターフォールとアジャイル開発の比較 
 
継続的デリバリー読書会 14章
継続的デリバリー読書会 14章継続的デリバリー読書会 14章
継続的デリバリー読書会 14章
 
アジャイル開発の始め方
アジャイル開発の始め方アジャイル開発の始め方
アジャイル開発の始め方
 
アジャイル開発の進め方
アジャイル開発の進め方アジャイル開発の進め方
アジャイル開発の進め方
 
定量的プロジェクト管理ツール概要 Lt 20110730
定量的プロジェクト管理ツール概要 Lt 20110730定量的プロジェクト管理ツール概要 Lt 20110730
定量的プロジェクト管理ツール概要 Lt 20110730
 
これからのソフトウェア開発での
プロジェクト管理の展望【リックソフトセミナー】
これからのソフトウェア開発での
プロジェクト管理の展望【リックソフトセミナー】これからのソフトウェア開発での
プロジェクト管理の展望【リックソフトセミナー】
これからのソフトウェア開発での
プロジェクト管理の展望【リックソフトセミナー】
 
継続的デリバリー読書会資料 #1
継続的デリバリー読書会資料 #1継続的デリバリー読書会資料 #1
継続的デリバリー読書会資料 #1
 
チーム×ツール Team Foundation Server & Service 共感しActionできる開発基盤 アルティメイタム【デブサミ 2013 ...
チーム×ツール Team Foundation Server & Service 共感しActionできる開発基盤 アルティメイタム【デブサミ 2013 ...チーム×ツール Team Foundation Server & Service 共感しActionできる開発基盤 アルティメイタム【デブサミ 2013 ...
チーム×ツール Team Foundation Server & Service 共感しActionできる開発基盤 アルティメイタム【デブサミ 2013 ...
 
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
 
現場の見える化で、チーム力を向上させる
現場の見える化で、チーム力を向上させる現場の見える化で、チーム力を向上させる
現場の見える化で、チーム力を向上させる
 

Andere mochten auch

Innovation@salesforce
Innovation@salesforceInnovation@salesforce
Innovation@salesforce
cfry
 
Force Certification
Force CertificationForce Certification
Force Certification
josephamalan
 
Salesforce.com strategic analysis
Salesforce.com strategic analysisSalesforce.com strategic analysis
Salesforce.com strategic analysis
Sophie Michelot
 
Salesforce Traning Adm 201
Salesforce Traning   Adm 201Salesforce Traning   Adm 201
Salesforce Traning Adm 201
plug2learn
 
Ch5: Organising and Staffing the Salesforce
Ch5: Organising and Staffing the SalesforceCh5: Organising and Staffing the Salesforce
Ch5: Organising and Staffing the Salesforce
itsvineeth209
 
Stanford Case Study - Salesforce.com Transformation
Stanford Case Study - Salesforce.com TransformationStanford Case Study - Salesforce.com Transformation
Stanford Case Study - Salesforce.com Transformation
Steve Greene
 

Andere mochten auch (17)

Innovation@salesforce
Innovation@salesforceInnovation@salesforce
Innovation@salesforce
 
Force Certification
Force CertificationForce Certification
Force Certification
 
Salesforce Innovates Faster with Agile - You Can Too
Salesforce Innovates Faster with Agile - You Can TooSalesforce Innovates Faster with Agile - You Can Too
Salesforce Innovates Faster with Agile - You Can Too
 
ADM Overview - Customers
ADM Overview - CustomersADM Overview - Customers
ADM Overview - Customers
 
How To Staff for Salesforce Innovation
How To Staff for Salesforce InnovationHow To Staff for Salesforce Innovation
How To Staff for Salesforce Innovation
 
Salesforce.com strategic analysis
Salesforce.com strategic analysisSalesforce.com strategic analysis
Salesforce.com strategic analysis
 
Agile 2010 conference - a holistic approach to scaling agile at salesforce
Agile 2010 conference - a holistic approach to scaling agile at salesforceAgile 2010 conference - a holistic approach to scaling agile at salesforce
Agile 2010 conference - a holistic approach to scaling agile at salesforce
 
Salesforce Traning Adm 201
Salesforce Traning   Adm 201Salesforce Traning   Adm 201
Salesforce Traning Adm 201
 
Scrum Gathering 2008 Stockholm - Salesforce.com
Scrum Gathering 2008 Stockholm - Salesforce.comScrum Gathering 2008 Stockholm - Salesforce.com
Scrum Gathering 2008 Stockholm - Salesforce.com
 
Adaptive Development Methodology
Adaptive Development MethodologyAdaptive Development Methodology
Adaptive Development Methodology
 
Ch5: Organising and Staffing the Salesforce
Ch5: Organising and Staffing the SalesforceCh5: Organising and Staffing the Salesforce
Ch5: Organising and Staffing the Salesforce
 
The Salesforce Playbook- 6 Steps to Better Deployments
The Salesforce Playbook- 6 Steps to Better DeploymentsThe Salesforce Playbook- 6 Steps to Better Deployments
The Salesforce Playbook- 6 Steps to Better Deployments
 
The Ideal Salesforce Development Lifecycle
The Ideal Salesforce Development LifecycleThe Ideal Salesforce Development Lifecycle
The Ideal Salesforce Development Lifecycle
 
Stanford Case Study - Salesforce.com Transformation
Stanford Case Study - Salesforce.com TransformationStanford Case Study - Salesforce.com Transformation
Stanford Case Study - Salesforce.com Transformation
 
Salesforce Presentation
Salesforce PresentationSalesforce Presentation
Salesforce Presentation
 
Salesforce.com Agile Transformation - Agile 2007 Conference
Salesforce.com Agile Transformation - Agile 2007 ConferenceSalesforce.com Agile Transformation - Agile 2007 Conference
Salesforce.com Agile Transformation - Agile 2007 Conference
 
Salesforce Development Best Practices
Salesforce Development Best PracticesSalesforce Development Best Practices
Salesforce Development Best Practices
 

Ähnlich wie Agile Development at Salesforce

Agile japan2010 rakuten様プレゼン資料
Agile japan2010 rakuten様プレゼン資料Agile japan2010 rakuten様プレゼン資料
Agile japan2010 rakuten様プレゼン資料
Akiko Kosaka
 
イノベーションスプリント2011 infragisticsにおける世界分散アジャイル開発事例~ communication matters ~
イノベーションスプリント2011 infragisticsにおける世界分散アジャイル開発事例~ communication matters ~イノベーションスプリント2011 infragisticsにおける世界分散アジャイル開発事例~ communication matters ~
イノベーションスプリント2011 infragisticsにおける世界分散アジャイル開発事例~ communication matters ~
InnovationSprint2011
 
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills neede...
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten,  core skills  neede...楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten,  core skills  neede...
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills neede...
Rakuten Group, Inc.
 
X dev 20121106
X dev 20121106X dev 20121106
X dev 20121106
Ken Azuma
 
クラウドが実現するソフト開発・運用の変革と自動化
クラウドが実現するソフト開発・運用の変革と自動化クラウドが実現するソフト開発・運用の変革と自動化
クラウドが実現するソフト開発・運用の変革と自動化
Etsuji Nakai
 
Agile at salesforce
Agile at salesforceAgile at salesforce
Agile at salesforce
Ryoji Osawa
 

Ähnlich wie Agile Development at Salesforce (20)

Agile japan2010 rakuten様プレゼン資料
Agile japan2010 rakuten様プレゼン資料Agile japan2010 rakuten様プレゼン資料
Agile japan2010 rakuten様プレゼン資料
 
【XDev】A-2 アジリティ向上のためのツール活用
【XDev】A-2 アジリティ向上のためのツール活用【XDev】A-2 アジリティ向上のためのツール活用
【XDev】A-2 アジリティ向上のためのツール活用
 
DOO-004_楽天での DevOps 実践事例と Azure ベスト プラクティス
DOO-004_楽天での DevOps 実践事例と Azure ベスト プラクティスDOO-004_楽天での DevOps 実践事例と Azure ベスト プラクティス
DOO-004_楽天での DevOps 実践事例と Azure ベスト プラクティス
 
A 1-1 tfs on azure で始めるイマドキのソフトウェア開発
A 1-1 tfs on azure で始めるイマドキのソフトウェア開発A 1-1 tfs on azure で始めるイマドキのソフトウェア開発
A 1-1 tfs on azure で始めるイマドキのソフトウェア開発
 
Go azure tfs_service
Go azure tfs_serviceGo azure tfs_service
Go azure tfs_service
 
2011年マイクロソフト テクノロジー振り返り~開発編~
2011年マイクロソフト テクノロジー振り返り~開発編~2011年マイクロソフト テクノロジー振り返り~開発編~
2011年マイクロソフト テクノロジー振り返り~開発編~
 
Net advantage 2012 volume2 最新情報 xaml プラットフォーム編
Net advantage 2012 volume2 最新情報 xaml プラットフォーム編Net advantage 2012 volume2 最新情報 xaml プラットフォーム編
Net advantage 2012 volume2 最新情報 xaml プラットフォーム編
 
イノベーションスプリント2011 infragisticsにおける世界分散アジャイル開発事例~ communication matters ~
イノベーションスプリント2011 infragisticsにおける世界分散アジャイル開発事例~ communication matters ~イノベーションスプリント2011 infragisticsにおける世界分散アジャイル開発事例~ communication matters ~
イノベーションスプリント2011 infragisticsにおける世界分散アジャイル開発事例~ communication matters ~
 
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills neede...
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten,  core skills  neede...楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten,  core skills  neede...
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills neede...
 
【Agile Conference tokyo 2011】 継続的フィードバック
【Agile Conference tokyo 2011】 継続的フィードバック【Agile Conference tokyo 2011】 継続的フィードバック
【Agile Conference tokyo 2011】 継続的フィードバック
 
学生が行うプロジェクト活動への アジャイル開発手法 「Scrum」の導入 | 仙台高専教育研究交流会
学生が行うプロジェクト活動へのアジャイル開発手法「Scrum」の導入 | 仙台高専教育研究交流会学生が行うプロジェクト活動へのアジャイル開発手法「Scrum」の導入 | 仙台高専教育研究交流会
学生が行うプロジェクト活動への アジャイル開発手法 「Scrum」の導入 | 仙台高専教育研究交流会
 
Force.com開発基礎
Force.com開発基礎Force.com開発基礎
Force.com開発基礎
 
幅広い技術力が身につくSalesforceエンジニアのススメ〜入門編〜
幅広い技術力が身につくSalesforceエンジニアのススメ〜入門編〜幅広い技術力が身につくSalesforceエンジニアのススメ〜入門編〜
幅広い技術力が身につくSalesforceエンジニアのススメ〜入門編〜
 
X dev 20121106
X dev 20121106X dev 20121106
X dev 20121106
 
クラウドが実現するソフト開発・運用の変革と自動化
クラウドが実現するソフト開発・運用の変革と自動化クラウドが実現するソフト開発・運用の変革と自動化
クラウドが実現するソフト開発・運用の変革と自動化
 
Scrum"再"入門
Scrum"再"入門Scrum"再"入門
Scrum"再"入門
 
Agile at salesforce
Agile at salesforceAgile at salesforce
Agile at salesforce
 
アジャイル開発&TFS導入
アジャイル開発&TFS導入アジャイル開発&TFS導入
アジャイル開発&TFS導入
 
ITS fidel
ITS fidelITS fidel
ITS fidel
 
でぶさみ夏2013 キーノート オレンジレンジャーの資料
でぶさみ夏2013 キーノート オレンジレンジャーの資料でぶさみ夏2013 キーノート オレンジレンジャーの資料
でぶさみ夏2013 キーノート オレンジレンジャーの資料
 

Agile Development at Salesforce

Hinweis der Redaktion

  1. コードラインを常にクリーンな状態に維持するために重要な役割を果たすのが必要なものが継続的インテグレーションです.