Your SlideShare is downloading. ×
0
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Agile Development at Salesforce
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile Development at Salesforce

756

Published on

Published in: Technology, Business
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
756
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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

    • 1. Agile Development at Salesforce.com大沢 良樹Salesforce.com Inc.July 2012
    • 2. Safe HarborSafe 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 theassumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed orimplied by the forward-looking statements we make. All statements other than statements of historical fact could bedeemed forward-looking, including any projections of subscriber growth, earnings, revenues, or other financial items andany statements regarding strategies or plans of management for future operations, statements of belief, any statementsconcerning new, planned, or upgraded services or technology developments and customer contracts or use of ourservices.The risks and uncertainties referred to above include – but are not limited to – risks associated with developing anddelivering new functionality for our service, our new business model, our past operating losses, possible fluctuations inour operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, theoutcome of intellectual property and other litigation, risks associated with possible mergers and acquisitions, theimmature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivateour employees and manage our growth, new releases of our service and successful customer deployment, our limitedhistory reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Furtherinformation on potential factors that could affect the financial results of salesforce.com, inc. is included in our annualreport on Form 10-K for the most recent fiscal year ended January 31, 2010. This documents and others are availableon 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 currentlyavailable and may not be delivered on time or at all. Customers who purchase our services should make the purchasedecisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does notintend to update these forward-looking statements.
    • 3. AGENDA1. About me2. About Salesforce.com3. Adaptive Development Methodology4. 継続的インテグレーション5. 自動化テスト6. リリースマネージメント
    • 4. Adaptive Development Methodology (ADM)
    • 5. Background 2002年 1年に4回のバージョンアップ 2006年 1年に1回のバージョンアップ
    • 6. Waterfall Model
    • 7. 計画どうり進まない、予測できないプロジェクト
    • 8. 可視性の欠如
    • 9. 常に変化する プライオリティ
    • 10. ユーザフィードバック の欠如
    • 11. メジャーリリースに掛かった日数 1チーム当たりのリリースした機能数2000 2001 2002 2003 2004 2005 2006
    • 12. What is ADM? ADM (Adaptive Delivery Methodology) はsalesforce.comに特化した大規模アジャイル開発手法 SCRUM XP開発プラクティス LEANの理念
    • 13. What is ADM? Consistent Rhythm Self-organizing Continuous integrationLean Self-correcting Time-boxed Ftest - Selenium Refactoring Continuous learning Transparent Early Feedback Iterative Code Reviews Just-in-time Collective code ownership Debt freeContinuous improvement Continuously releasable
    • 14. What is ADM? Simple
    • 15. ADM 5つの基本理念
    • 16. ムダの排除
    • 17. クオリティ・ファースト
    • 18. 「人」主導
    • 19. ジャストインタイム の意思決定
    • 20. 迅速なデリバリー
    • 21. 開発は30日の タイムボックス内で作業
    • 22. チームが主役
    • 23. 密度の高い日常のコミュニケーション
    • 24. 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 SprintOpens April May June July August September October Code Line Opens
    • 25. SFDC Release CycleとADMの開発リズムRelease Release Release Release 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 毎月の一定なリズム
    • 26. SCRUM
    • 27. What is SCRUM?  アジャイル開発の代表的なプロジェクトマネージメント手法  作業期間(スプリント)を繰り返しソフトウェアを構築  チーム自身が作業する仕事を決める  スプリント終了後、リリース可能な成果物を生成
    • 28. PRODUCT BACKLOG
    • 29. 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
    • 30. Sprint Planning プロダクト・バックログから優先度の 高い項目を選択 チームが作業量を決める タスクの細分化、見積もり タスクの割り当てはしない
    • 31. 進捗状況の管理
    • 32. Salesforceを使ってScrumタスクを管理バックログの管理、優先度付け
    • 33.  スタンドアップ・ミーティング(15分)で進捗の報告 毎日、同じ時間&同じ場所で行う 簡潔な報告 残り作業量と残り期日のみトラッキング
    • 34. 明確な 「完了」の定義 明確な 「完了」の定 義
    • 35. Doneness Checklist <機能 1> <機能 2> <機能 3>Code checked in and follows department standards   No open regressions. Automated tests written and   reviewed for all regressionsNo 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 passingAll resolved bugs verified and closed   Performance/scalability impact ascertained and sys   testing scheduled if requiredUE has reviewed any new features; P1 and P2 UI bugs   fixedUsability testing completed when necessary, and   feedback incorporated into backlogCode and UI reviewed for 508 compliance; UE team   notified of any non-compliant featuresAll 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 metricsSecurity standards met and critical issues resolved   
    • 36. 「完了」できなかった場合はどうなる?
    • 37. 未完了の機能は無効化させ次のリリースで完了させる
    • 38. Scrum Team @ Salesforce  Cross Functional Team  150以上のScrum Teams  各チームが特定の製品、機能を担当  6-10人のメンバーで構成
    • 39. Salesforce Office in SF
    • 40. 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
    • 41. Scrum of Scrums
    • 42. Chatter @ Salesforce R&D 1400以上のChatter Group チーム、部門をまたがる情報共有、コラボレーション R&D組織全体に関わることを日々活発に議論 仕事以外の雑談もChatterで! – Airing of Grievances – Sign your praises on high – Opportunity Open Market
    • 43. Chatter Groupを活用してチーム/部門をまたいだコラボレーション
    • 44. Salesforce R&D 開発環境
    • 45. “Don’t just clean it. Keep it clean.”
    • 46. 継続的インテグレーション Continuous Integration
    • 47. 継続的インテグレーション SYNC • XPの開発手法のひとつ • 小規模な変更を頻繁にレポジトリ にコミットを繰り返しながらソフ MAKETEST トウェアを構築していく CHANGES • 開発ビルド作業の自動化 • 最低1日1回のコミット BUILD COMMIT
    • 48. 継続的インテグレーションの利点• インテグレーションに伴うリスクの軽減 (Small = Better)• ビルド自動化によるインテグレーション作業の軽減• 自動化テストと併用し、問題や不具合の早期発見と常時モニ タリング• ソフトウェアの品質向上
    • 49. AutobuildContinuous Integration Build System @ SFDC
    • 50. Autobuild• 完全自動化されたビルドプロセス SYNC• 全てのコードライン、変更にビルド+自動化テスト• ビルド問題発生時すぐにコミッターに通知 MAKE TEST• 自動化テストと併用、常時コードラインのモニタリング CHANGES• テスト分散による実行時間の短縮• クリティカルなテスト実行完了 45分以内 BUILD COMMIT
    • 51. ビルドは絶対に壊さない!壊れたビルドの修正 = 最優先事項
    • 52. テストの自動化Why do we automate tests, anyway?
    • 53. 自動化テストへの投資
    • 54. どうしてテストを自動化するのか? 時間とコストの節約 24時間/365日継続して実行可能 リグレッションテスト バグの早期発見、フィードバック
    • 55. コードラインは常にクリーンを維持 自動化テスト結果(成功率)は重要な指標 自動化テスト結果の目標値をR&D全体に設定 毎月の目標値を満たしながら開発作業を進める
    • 56. Lock-the-Line Policyテスト成功率が基準値以下(99.x%)なら
    • 57. Lock-the-Line by Team 各チームにも目標値が設定
    • 58. リリースマネージメント Continuous Deployment
    • 59. リリース・デプロイメント @ SFDC デプロイメントの完全自動化 デプロイ完了後に自動的にリグレッションテスト実行 問題が発生した場合、すぐにロールバック 2011年 250以上のデプロイ実施
    • 60. Dogfooding – まずは自分達で使う 本番環境リリースの2ヶ月前に GUSのアップグレード 自分達で使いながらバグの洗い 出しと修正を繰り返す
    • 61. 段階的なリリース GUS Sandbox Production 段階的リリースによるバグの洗い出しと修正を繰り返す カスタマーへのインパクトを最小限に
    • 62. 継続的モニタリング
    • 63. おさらい1. ADMの概要2. 5つのADM基本概念3. 30日のタイムボックスで作業4. Scrumプロセス5. 継続的インテグレーション6. 自動化テストの役割7. デプロイメント完全自動化8. Dogfooding、段階的なリリース

    ×