来自敏捷教练的几个问题
1 其他公司的敏捷是怎么做的，做的好的是什么样子呢？好的点和不好的点可以举例说明一下吗？
管理实践和工程实践，管理实践大部分是导入 Scrum，少部分导入看板方法。 工程实践包括 CI（持续集成），单元测试，SonarQube 代码扫描，自动化测试，自动化部署等。
大部分企业的敏捷是流于形式的。体现在流程僵化，工程实践缺失。
- 站会开成了汇报会；
- 团队看板更新不及时，不能反映真实状态；
- 需求拆分粒度太大，几天都看不到进展；
- 代码扫描问题没有及时修改，技术债累积；
- 后补单元测试，为了覆盖率而编写测试；
- ...
做得好的团队呢，会体会到敏捷的好处：
- 状态透明了，协作加强了
- 客户能更快看到成果，提供反馈
- 质量和效率都有提升
- 团队觉得工作有趣味，有价值和意义
- ...
2 敏捷教练的价值是什么？
敏捷教练是团队敏捷转型中的伙伴，给团队提供敏捷经验，解答团队敏捷实施中的疑惑，减少转型阵痛，加速转型过程。 你列举的应该是 Scrum Master 的工作，理想状态下，Scrum Master 是一位团队教练，能辅导 PO 拆解，排序需求，辅导团队发现和排除障碍，引导团队持续改进。 但实现中，Scrum Master 往往不具备足够的技能，所以需要「敏捷教练」去辅导 PO，辅导团队，并教会 Scrum Master 如何辅导 PO 和团队。
3 持续改进和度量部分可以讲讲吗？敏捷度量的体系有哪些？
从「人事果」三方面来度量。 人：
- 团队成员的开心指数，成就指数
- 团队内部协作顺畅度
- 客户满意度
- 领导满意度
- ...
事：
- 缺陷率
- 一次通过率
- 发布频率
- 发布成功率
- 交付周期
- 发布时长
- 构建时长
- 重复率
- 代码圈复杂度
- 测试覆盖率
- 问题修复周期
- ...
果：
- 营收，利润
- 新增用户数，活跃用户数
- 复购率，单用户价值
- ...
持续改进，就是不断发现和消除瓶颈，发现和消除的过程。 《精益软件开发》定义了软件开发的常见浪费，比如半成品，残次品，开发完了不能上线的需求等。 最常见的浪费是「等待」，需求分析完了等待开发，开发完了等待测试，测试完了等待部署。 这块的方法论 TOC（约束理论），推荐看一本小说《目标》。
4 一般标准的敏捷团队是什么样的组织架构？
要放弃「标准」思维，一旦标准了，就不敏捷了。 敏捷团队需求编写的「标准」方式是什么？我用一个例子来说明。 一个新团队，大家第一次合作，这时要做一个列表，那需求就要讲得很细：
- 带不带翻页
- 一页几条数据
- 没有数据如何展示
- 要不要 Loading 浮层
- 日期字段用什么格式展示
- 空值如何展示
- ...
同样是这个团队，一起工作半年后，PO 只需要说要一个列表，开发人员就知道 PO 要什么。 敏捷就是要持续改进，持续成长。根据当下的情况，不断引入新工具和方法，不断调整协作模式。
敏捷团队组建的基本的原则是「特性团队」，能够在团队内完成端到端交付。按 Scrum 的定义，一个 PO，一个 SM，UI/UX，QA，数名 Developer，书上定义是 7±2 人，也叫 Two Pizza Team。
5 如果对方问到作为敏捷教练能给他们公司带来什么，这种问题什么维度回答合适呢？
问这个问题，说明他们还没有想清楚：他们要什么，他们缺什么。 公司引入敏捷，有不同的诉求：
- 缩短 Time-to-market
- 提升用户响应力
- 降低成本
- 提升质量
- 激发员工活力
- ...
问对方想要什么。
然后，问他们缺什么？ 需求管理能力不足？ 团队协作不畅？ 产品质量差？ 研发过程不可信？
根据自己的专长和经验，告诉对方你在哪些方面可以提供价值。