Bringing Continuous Agile to Japan
•Télécharger en tant que PPTX, PDF•
0 j'aime•306 vues
Starts with lean product development for cars, in Japan, circa 1990. Then exposes the details of continuous delivery and service architectures, which are boomeranging back to Japan from the US tech scene.Includes some of the lean philosophy that makes it such a great way to deliver a valuable product. Presentation at from a Perforce / Toyo event in Tokyo, April 2015. Includes English and Japanese. You can just skip the Japanese slides.
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Bringing Continuous Agile to Japan
Similaire à Bringing Continuous Agile to Japan (20)
Bringing Continuous Agile to Japan
- 1. Continuous Delivery and Continuous Agile From Andy Singleton, http://continuousagile.com www.assembla.com
- 3. What we can learn from Japanese Lean Manufacturing • Lean principles • Continuous Integration What Japan can learn from Silicon Valley • Continuous delivery • Continuous agile product development • Building large systems The future • Automation of human programming tasks • Ecosystems and Testbeds • New type of Keiretsu
- 4. 日本のリーン開発から学べる • リーン生産方式の原理 • 継続的インテグレーション（統合） 日本がシリコンバレーから学べる点 • 継続的デリバリー • 継続的アジャイル製品開発 • 大規模なシステムを立てる 未来 • プログラマーの役目をも自動化 • エコシステムとテストベッド • 新しい系列
- 5. Lean Principles Continuous Integration Learning from Japan
- 11. Continuous integration of cars
- 12. 継続的な車両統合
- 13. Make Product, not Quality Continuous Release Inventory Release Improve Quality Improve Product Usage
- 15. Kaizen 1. Release more frequently 2. Improve
- 16. Kaizen（改善） 1. リリースを頻繁にする 2. 改善する / 月割りのリリース
- 17. Continuous Delivery Learning from Silicon Valley
- 19. Survey on Continuous Delivery 46% think their competitors have adopted Continuous Delivery
- 20. 継続的デリバリーについての調査 46% think their competitors have adopted Continuous Delivery
- 21. Problems solved by Continuous • Speed to market • Competitiveness • Quality • Stressful releases • Scaling – building large systems
- 22. 継続的開発が解決する問題 • 市場に製品を出すまでのスピード • 競合性 • 品質 • リリース時のストレス • 拡張 – 大規模なシステムを作る
- 23. Scrum Sprint Validate and Sort Deliverables Select a Sprint Plan Completed = observed velocity Expand stories and estimate tasks Collect Ideas Close Sprint Into next sprint Work on tasks
- 25. Scrumban Iteration Validate and Sort Deliverables Pull Deliverables When Ready Collect Ideas Stabilize Release Into next release Feature Freeze Triage
- 26. スクラム版イテレーション（反復） 成果物を確証し 整理する 成果物の準備が できれば選んで 展開する アイディアを 集める リリースの安定化 次のリ リースに 回す 特徴の フリーズ 優先配給 方式
- 27. Kanban / Continuous Validate and Sort Deliverables Pull Deliverables When Ready Collect Ideas Continuous Release Stay within WIP limit Release Features Continuously
- 29. Code Contribution Patterns Manage code if possible. People are hard to manage and can’t be automated. They want to contribute. • Centralized continuous delivery – No branches, finds and fixes problems as early as possible • Distributed continuous delivery – Release every change with its own branch and test • Temporary branches – Combines benefits of centralized and distributed • MAXOS – Use centralized continuous integration to manage a massively scalable IT system
- 30. コードマージパターン コード管理ができれば,、する。人は管理するのが面倒な 上に自動化できない。人は、管理されるのではなく、貢 献したがる傾向がある。 • 中央型継続的デリバリー – コードバグを早期発見・早期修理する。ブランチは作らな い。 • 分配型継続的デリバリー – リリース時の改変は割り当てられたブランチ内でする • 一時的ブランチ – 中央型と分配型デリバリーの利点を融合したパターン。 • MAXOS（マクソス） – 大規模なデータにも対応できるよう、中央型継続的インテ グレーションをする
- 31. Centralized CI/CD Contributor Commits – “as early as possible” to find problems Continuous Integration tests Fail - alarm Release Candidate Test System Release QA Testing Pass
- 32. 中央型 CI/CD 貢献者は、問題等を早期発見できるために、できるだけ早くコミットする。 継続的なインテグレー ションテストを行う アラーム – 失敗 リリース候補版 テストシステム リリース 品質管理 テスティング 成功
- 33. Continuous delivery at Edmunds.com with PERFORCE
- 35. Assembla spins up many test servers
- 37. The big question: How to test? • We release software in batches so that we can test it. • In continuous delivery, we might get as little at 10 minutes to test a release candidate
- 38. 大事な質問:どうやってテストを行えば いいのか • バッチ（処理単位）でソフトウェアをテストする。 • 継続的デリバリーでは、リリース候補版をテストする のに10分しかかからない場合もあり得る
- 39. Test Layering Monitor your released software: Errors, Usage volume, usage patterns, user feedback QA System with Human test consultants Code review: Both a manual test, and a place to ask for test scripts. Continuous integration: Run automated tests before using human review time Unit tests in the development environment Switch new features and architecture More frequent releases can increase quality
- 40. テスト・レイヤリング 新しいソフトウェアをモニターする: エラー 、従量、顧客利用パターン、顧客フィードバック テストコンサルタントを通し、品質チェックをす る コードレビュー: マニュアルテストとテストスクリプ トを要求する場所 継続的インテグレーション（統合）: 人にテストを 受けさせる前に自動化されたテストを実行する。 単体テストを開発環境内で実施する 機能や特徴の変更を行う。 頻繁なリリースは品質向上につながる
- 41. 9 (sparse) Layers at Edmunds
- 43. Code Review gets you tests
- 44. コードレビューからテストを得る
- 45. Feature Switch and Unveil Hidden Programmer sees a change locally. Change is tested in the main version but not seen. Test Story Owner and testers see the change on test systems. Beta Insiders see it and use it. Story Owner can show it to selected users for feedback or A/B testing. UNVEIL! The big event. Communicate with all users. Measure reaction. Onecodeversion Nospecialtestbuilds Nolong-runningbranches
- 47. Role: Developer • Developers have more power and responsibility. • Developers have more responsibility for testing. • Developers (not QA or PM) decide when to release. This is a strong finding. • Incentives are correct. Developer might have to come back from Friday night beers to fix a problem. This provides a motivation to make good decisions and automate testing. • Features can be released but hidden. Product Managers and Marketers will unveil when they are ready. Unblock! Programmers approve releases, not QA
- 48. デベロッパー（開発者）の役割 • デベロッパーは権限や責任をもっと持っている。 • デベロッパーはテスティングする責任を持っている。 • いつリリースをするのかは、品質管理チームではな く、プログラマーがする！ • コードバグを仕事終わりの宴会から抜けて直さなけ ればならいかもしれないので、的確な決断をするこ とやテストを自動化する動機がある。誘因は正しい。 • 新しい特徴はまだ未公開のまま、ベータユーザー等 にリリースしてもいい。プロダクト・マネージャーや マーケターは、準備ができれば顧客皆にその特徴を 公開する。 リリースの承諾は品質管理チームではなく、プログラマーがする。
- 49. Role: Product Manager/Owner • Batch -> Continuous • Requirements -> User Experience • Strategy -> Measurement – Usage measurements are so important, so underutilized – Double your productivity
- 50. プロダクトマネージャー/オーナーの役割 • バッチ → 継続的 • 要件 → UX（ユーザーエキスペリエンス • 計略 → 測定 – 測定することはものすごく大事だが十分に活用さ れてない。 – 効率向上につながる。
- 51. Product Owner -> Story Owner
- 52. Product Owner -> Story Owner
- 53. Role: IT Vendor Old Agreement • Fixed Price • Fixed deliverables • Large probability of late delivery New Agreement • Fixed price • Fixed Time • Variable deliverables – Small guaranteed deliverable – Weekly meetings to agree on improvements Advantages • No late delivery • Deliverable is better than original specification • Start sooner and finish sooner
- 54. ITベンダーの役割 古い契約 • 固定された生果物 • 生果物の公表が遅れる可能性：大 利点 • 生果物が遅れる可能 性：小 • 生果物が固定されてい ないので、変更に応じ やすい • 早く始め、早く終わる 新しい契約 • 固定費 • 固定時間 • 異なる生果物 – 生果物がバッチ化されてるので 遅れる可能性：小 – 毎週ミィーティングを行い、改善 点等に同意するITベンダーの役 割
- 55. Matrix of Services (MAXOS) Breaking the scale barrier
- 57. The Services Megatrend Desktop Web App Cloud Services App DB Service Service Service
- 58. サービスの傾向 デスクトップ ウェブアプリ クラウドサービス アプリ データベース サービス サービス サービス
- 59. Scale it like Google • 15,000 developers, 5,000 projects, one current version of the code (2013). They can go from an idea to a release in 48 hours • Vast Internet system divided into thousands of "services" • Most programming done by teams of 3-4 • Centralized process with single version of the test system – run 100 million test cases daily • Before developers release a change, they test it with the most recent version of all the other services. If a test script finds conflicts, it tells developers who to contact to resolve them
- 60. Googleの様に拡張 • デベロッパーの数：15,000名, プロジェクトの数：5,000個, 正 式版のコードの数：一つだけ（２０１３）。二日以内で、アイ ディアの工程からリリースまでこなすことができる。 • 数千もの‘サービス’に分けられた莫大なインターネットシス テム • 大抵のプログラミングは、３〜４名のチームで行う • 一つだけのテストシステムのバージョンで中央処理 – 毎日 一億ものテストケースを実行する • 開発者はコード変更をリリースする前に、直近のバージョン でサービス全部をテストする。もしテスト・スクリプトが競合 を発見したら、開発者に誰と連絡をとればいいのか教えてく れる。
- 61. Matrix of Services - MAXOS Prioritized Backlog Current Work Each team releases when ready Hundreds of releases per day Service team Production service Service team Production service Service team Production service Feedback on speed, errors, usage, and requests Test as one system Integration test env Integration test env Integration test env
- 63. Coordinate without big meetings Continuous Integration between latest dev version of each service • Continuous integration helps teams coordinate. • See dependencies between “producers” and “consumers” • Errors and conflicts show related team contact info • Meetings and changes negotiated between two teams, not many Prioritized Backlog Current Work Service team Service team Service team Integration test env Integration test env Integration test env Machines can replace layers of management
- 64. 大きな会議無しで調整する 各サービスでの直近のバージョンで継続的インテグレーション • 継続的インテグレーショ ンはチームの整理に役 立つ • 生産者と消費者の依存 関係を見る • エラーと競合はチームの 連絡先を示す • 打ち合わせやコード変 換は二つのチームの間 で決める 機械は経営の複数の階層を置換できる 重点的な バックロ グ 現在の 仕事 サービスチーム サービスチーム サービスチーム テスト環境 の統合 テスト環境 の統合 テスト環境 の統合
- 65. Teams are largely self-managing Prioritized Backlog Current Work Service team Integration test env Up to 50% of work from backlog At least 50% of work is self-planned Problems get fixed quickly Production service Production service Production service Feedback: quality, reliability, speed, user support Production service Production Server Sense, respond, self manage minimize planning
- 66. チームの大半は自己管理 重点的な バックロ グ 現在の 仕事 サービスチーム テスト環境 の統合 仕事の半分以下は バックログから 仕事の半分以上は自分で計画する 問題は早く解決される フィードバック: 品質, 確実性, スピード,ユーザーサポート プロダクション サーバー 認識, 応答, 自己管理で計画を 立てる時間を短縮 プロダクショ ン・サービス プロダクショ ン・サービス プロダクショ ン・サービス プロダクショ ン・サービス
- 67. Hubspot – Great at Mid-scale • Transformed a monolithic app to 200 services over one year • 3-person programming teams. Each of 20 teams is responsible for about 10 services • Dev teams responsible for design, programming, testing, release, monitoring, and responding to production problems. No full-time QA. Shared PM and UX. 4 Ops guys for 2000 servers. • Lot’s of tooling and dashboards to help teams deploy, manage, and monitor their services • Feedback from customer support also grouped by team
- 68. Hubspot – 中規模拡張が上手 • 一年間でアプリを２００ものサービスに変形した • ３名のプログラミングチーム。各チーム（合計２０チー ム）は１０個のサービス管理をする責任がある。 • 開発チームはデザイン、プログラミング、テスティング、 リリース、モニタリング、そして生産問題に応じる責任 がある。フルタイムで品質保障をする人は、いない。プ ロダクトマネージャーとUXは、共有。４名の作業チー ムが２０００ものサーバーを管理する。 • 色々なツールやダッシュボードを使いサービスをデプ ロイ、マネージ、そしてモニタリングする • 顧客サポートのフィードバックは、チームがまとめる
- 69. Team Building Prioritized Backlog Current Work Each team releases when ready Service team Production service Service team Production service Add capacity fast by building around Single-function programmer/tech leads Integration test env Integration test env Teams are not permanently multifunctional
- 71. Brooks and Mythical Man Month – Hypothesis: Scaling problems comes from n^2 communication explosion – Solution: Cells and hierarchy to contain communication Internet reality – Scaling problems come from dependencies – Solution: more sharing, more communication Mythical Man Month is wrong40 years of awesome insights, but
- 72. 「人月の神話」 - ブルッ クス – 仮説: 拡張問題は通 信の激増（n^2 ）から 起きる。 – 解決策: 通信を保持す るために階層制度を 使い、組織化する。 インターネットの現状 – 拡張問題は依存関係 から起きる – 解決策: もっと通信し、 もっと共有する 「人月の神話」は間違っている４０年間の努力と識見は興味深いが、
- 73. SAFe (Copyright Dean Leffingwell)
- 75. Ways to Scale Scrum + SAFe • Add more hierarchy • Complex multifunction teams • Hold big meetings and teleconferences • Block everyone into one cadence • Coordinate big releases Top Tech Companies Automate management, as well as testing and deployment. Dev-lead teams Communicate peer to peer Unblock! teams to move as fast a possible Release more frequently
- 76. 規模拡張の仕方 スクラム + SAFe（セーフ） • 階層を増やす • 複雑な多機能チーム • テレコンファレンスや大 きな会議を開く • 社員一同を一つの反復 （イテレーション）にまと め、大きなリリースをす る • 「人月の神話」 問題 シリコンバレー • 経営だけではなく、テス ティングやデプロイメント までも自動化する • 開発者率いるチーム • ピアーツーピアーネット ワークを使う • チームをまとめずに準 備が整っている所からリ リースする。 • 大規模なシステムに適 している
- 77. Competing with MAXOS The secret weapon that Silicon Valley is using to disrupt and destroy competitors • Retailer X deploys changes to their monolithic online ordering app once every six weeks. Ops holds for three weeks to make sure the complete system is stable. • Amazon has thousands of services and more than 1000 service teams. They release something about once every 11.6 seconds. In the time that Retailer X takes to try one new release, Amazon has made 100,000 changes. • Amazon hosting competitor: “It’s an emergency”.
- 78. MAXOSと互いに競い合う シリコンバレーが競合者を押しのけて、使っている秘密兵器 • 企業Xは6週間に一度、コードチェンジや変化をデプロイする。オ ペレーションチームはシステムがクラッシュしないよう３週間メン テナンスをする。 • Amazonは何千ものサービスを提供している。社内では一千以上 ものサービスチームが、１１．６秒というありえない早いペースで 新しいリリースをしている。なので、毎回企業Xが一つのリリース サイクルが終わる前にAmazonは100，０００もの改変を行ってい る。 • Amazonのホスティング競合社： 「これは緊急事態だ」
- 81. How to Move to Continuous Delivery and Service Architectures
- 83. Core IT annual budget Reliability & security mission API Layer Marketing Fast IT monthly budget Mission to respond to opportunities
- 84. コア IT 年間予算 確実性とセキュリティを 追求する任務がある API Layer モバイル マーケティング 早い IT 契機に応じる任務がある
- 85. Service team Production service Service team Production service Production service Integration test env Integration test env Integration test env Fast IT (continuous) Core IT (stable service)
- 86. サービスチーム プロダク ションサー ビス サービスチーム プロダク ションサー ビス プロダク ションサー ビス テスト環境 の統合 テスト環境 の統合 テスト環境 の統合 早い IT (継続的) コア IT (安定したサービス)
- 87. Ecosystems and Testbeds The shared future
- 89. Service team Production service Service team Production service Production service Integration test env Integration test env Integration test env Different culture, different company, or no company United by Testbeds Culture does not need to be consistent
- 91. M-City Testbed for Autonomous Cars
- 97. Automated Programming Each team releases when ready Hundreds of releases per day Automated Programming or Machine Learning Service Team Service Team Integration test env Integration test env Integration test env Production Service Production Service Production Service
- 99. Monitor your released software: Errors, Usage volume, usage patterns, user feedback QA System with Human test consultants Code review: Both a manual test, and a place to ask for test scripts. Continuous integration: Run automated tests before using human review time Unit tests in the development environment Switch new features and architecture Automated Code Generation and Machine Learning
- 100. 自動化されたプログラミングか 機械学習 新しいソフトウェアをモニターする: エラー 、従量、顧客利用パターン、顧客フィードバック テストコンサルタントを通し、品質チェックをす る コードレビュー: マニュアルテストとテストスクリプ トを要求する場所 継続的インテグレーション（統合）: 人にテストを 受けさせる前に自動化されたテストを実行する。 単体テストを開発環境内で実施する 機能や特徴の変更を行う。
- 101. Master Plan 1. Release more frequently 2. Improve
- 102. 総合計画 1. リリースを頻繁にする 2. 改善する / 月割りのリリース
- 104. 3 Ways to Be More Productive 1)Practice 2)Do the right thing 3)Use more machines
- 106. 1) Practice We can get more efficient at anything with practice and optimization This effect explains almost all of the productivity difference between Waterfall and Agile. In the agile process, we do more cycles, so we get better at each step. Any periodic release cycle causes a lot of stress around releases. Continuous delivery removes this stress by doing releases more frequently and optimizing down to a button push.
- 108. 2) Do the right thing Users ignore at least 50% of the new stuff you try. If you can measure usage or value and figure out what to ignore in development, you can increase development productivity by 100% for zero extra cost. Measurement is very important. More frequent releases = more measurements
- 109. 2) 効率的な更新をする 半分ほどの顧客は、リリース時の新しい特徴等 を使わない。もしくはそれに気づかない。各種プ ロセスの分析を行い、原因の特定やその対策 を行えば、余分なお金を使わずに効率を向上さ せることができる。 測定はすごく大事！ 頻繁なリリース ＝ 測定できるデータが増える
- 110. 3) Use more machines
- 111. 3) 機械をもっと用いる