10倍速原则对工程生产力建设的方向性影响

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. 十倍速原则 对工程生产力建设的 方向性影响 乔梁 2019.05 北京 持续交付2.0 CD
2.
3. 乔梁 敏思特咨询 组织转型 & 研发管理 国内首位持续交付&DevOps布道师 2009 2011 2018 持续交付2.0 CD
4. 一万次实验法则 “ 亚马逊的成功是每年、每月、每周、每天进行多次实验的结果。 ” “ 我最为自豪的事情之一是我们成功的关键在于试验框架…… 在任何时候,都不只有一个Facebook版本正在运行,而是一万个左右 ” CD20 Meetup Beijing 2019. 04 持续交付2.0 CD
5. 一万次实验法则 “ 亚马逊的成功是每年、每月、每周、每天进行多次实验的结果。 ” Data Inform “ 我最为自豪的事情之一是我们成功的关键在于测试框架…… 在任何时候,都不只有一个Facebook版本正在运行,而是一万个左右 ” CD20 Meetup Beijing 2019. 04 持续交付2.0 CD
6. 端到端的业务协作 持续交付2.0 业务 市场 产品 开发 测试 运维 持续交付2.0: 是一种组织能力,应具有可持续性 高质量、低成本、无风险地快速交付服务,提供业务价值 CD20 Meetup Beijing 2019. 04 持续交付2.0 CD
7. 持续交付2.0之双环模型 ——硅谷顶级公司的产品研发理念 5. 构建 1. 提问 ? 2. 目标 4. 选择 科学探索环 (业务创新) 快速验证环 8. 决策 (工程卓越) 6. 运行 7. 监控 3. 共创 CD20 Meetup Beijing 2019. 04 持续交付2.0 CD
8. 持续交付2.0之双环模型 ——硅谷顶级公司的产品研发理念 1. 2. 3. 4. 客户在哪里? 他遇到了哪些困难? 他现在怎么解决这些问题? 你的方案有多优秀? ? 科学探索环 (业务创新) 确定其中 一部分, 快速验证 快速验证环 (工程卓越) 1. 如何衡量你找到了他们 2. 如何衡量你的方案优秀 1. 如何找到他们 2. 你的问题有多少种解决方案 3. 它们的投入和产出如何评估 持续交付2.0 CD
9. 工程生产力 1. 2. 3. 4. 客户在哪里? 他遇到了哪些困难? 他现在怎么解决这些问题? 你的方案有多优秀? 工作流程 ? 确定其中 一部分, 快速验证 科学探索环 (业务创新) 工程素养 支撑工具 快速验证环 (工程卓越) 1. 如何衡量你找到了他们 2. 如何衡量你的方案优秀 1. 如何找到他们 2. 你的问题有多少种解决方案 3. 它们的投入和产出如何评估 持续交付2.0 持续交付2.0 CD
10. 十倍速原则 如果你希望自己的车子能达到50英里的时速, 可能只要对车子稍加改造即可。 然而,如果让它只用1加仑汽油跑500英里,就要对它重新设计了。 ——阿斯特罗·泰勒,Google X 持续交付2.0 CD
11. 十倍速原则 持续交付2.0 CD
12. 十倍速原则 速度 左利手 5秒 119式 20秒 30秒 十式走天下 60秒 120秒 1~2周 3~6月 2年~ 练习时间 (每天四小时) 持续交付2.0 CD
13. 十倍速原则 工作流程 持续交付2.0 CD
14. 每年12 次发布(理想状态) 星期日 星期一 星期二 星期三 星期四 星期五 星期六 Oncall 任务交接 手工 测试… 发布 Oncall 任务交接 CD20 Meetup Beijing 2019. 04 持续交付2.0 CD
15. 每年12 次发布(残酷的现实) 星期日 星期二 星期三 星期四 星期五 星期六 匆忙提交 半成品 Oncall 任务交接 星期一 匆忙提交 半成品 测试 …… …… 最后一分钟 提交关键功能 延迟发布 紧急修复 手工 Oncall 手工 测试 …… 任务交接 发布 Oncall 任务交接 CD20 Meetup Beijing 2019. 04 最后一分钟 发现缺陷 持续交付2.0 CD
16. 不断重复你一贯的做法, 你当然只会得到与以前一样的结果! 只有达到远超要求的水平, 才能轻松实现被要求的结果! 持续交付2.0 CD
17. 提高对自己的要求 1 -1 -1 每月1个正式版本 每周1个RC版本 每天1个Alpha版本 持续交付2.0 CD
18. 流程再造 需求评审 需求评审 开发 开发 测试 灰度 需求评审 需求评审 需求评审 开发 测试 灰度 需求评审 需求评审 开发 测试 全量 测试 测试 开发 RC 测试 测试 测试 灰度 测试 需求评审 开发 测试 测试 开发 灰度 开发 需求评审 开发 RC 测 测试 灰度 灰度 灰度 需求评审 RC 开发 全量 需求评审 灰度 开发 灰度 灰度 需求评审 需求评审 需求评审 开发 开发 灰度 灰度 灰度 需求评审 RC 开发 需求评审 开发 测试 测试 开发 测试 RC 全量 灰度 持续交付2.0 CD
19. 每天两次发布 星期日 星期一 星期二 星期三 星期四 星期五 Alpha Alpha Alpha Alpha RC Alpha Alpha Alpha Alpha RC Alpha Alpha Alpha Alpha RC Alpha Alpha Alpha Alpha PR Alpha Alpha Alpha Alpha RC Alpha Alpha Alpha Alpha RC CD20 Meetup Beijing 2019. 04 星期六 持续交付2.0 CD
20. 工具支持,规则简化 基 础 设 施 管理冲突 管理质量 简 单 原 则 持续交付2.0 CD
21. 十倍速原则 支撑工具 持续交付2.0 CD
22. 支撑工具的特点 • 标准化 • 高要求 • 简单易用 持续交付2.0 CD
23. 工具,更高层次的交互 • • • • 支持大多数编程语言 统一格式 细粒度的项目描述 不允许多依赖 Bazel https://www.reddit.com/r/programming/comments/30ccal/gradle_team_perspective_on_bazel/ 持续交付2.0 CD
24. 依赖管理 持续交付2.0 CD
25. 场景一 持续交付2.0 CD
26. 持续交付2.0 CD
27. 场景二 持续交付2.0 CD
28. 持续交付2.0 CD
29. 十倍速原则下的收益 v 必要的浪费 增值活动 增值活动 q 不必要的浪费 q q v q v v q v v v 无用的功能 等待(等待其他人的支持或帮助、审批) 工作项的移交(Handoffs) 库存(等待开发、等待测试、等待审批) 部分完成的工作(WIP) 寻找信息(上下文切换,反复沟通) 软件缺陷(Defects) 测试 项目管理 …… v 必要的浪费 增值活动 增值活动 q 不必要的浪费 持续交付2.0 CD
30. (2) 原文:https://www.cnblogs.com/Jack47/p/why-not-google-bazel.html 持续交付2.0 CD
31. (1) (2) (3) 持续交付2.0 CD
32. 十倍速原则 工程师能力与素养 持续交付2.0 CD
33. 谷歌工程生产力的三个支柱 持续交付2.0 CD
34. Code Review 我们 他们 • 只有重要需求才做Review • 每行代码都要Review • 紧急情况时不做Review • 代码规范全部一致 • 各团队规范不一致 • 必须具备可读性资质 持续交付2.0 CD
35. 我们常见的是 • 大量Copy & Paste的代码 • 无法写出自动化测试的代码 • 箭头式的代码 • …… 持续交付2.0 CD
36. 现实中的DevOps历程 更多的 (测试)自动化 测试自动化 过多的 (测试)自动化 流程自动化 持续交付2.0 CD
37. 十倍速原则 • 流程方面:以终为始,具有颠覆性,才能大飞跃 • 工具方面:高标准下的简单易用,才能创造更大价值 • 能力素养:有了时间,才能学习,提高工程能力与素养 持续交付2.0 CD
38.
39.
40. Q&A 持续交付2.0公众号 持续交付2.0 CD

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.3. UTC+08:00, 2024-11-28 15:38
浙ICP备14020137号-1 $bản đồ khách truy cập$