微服务产品级敏捷的问与答: PI 节奏

2017.2.25, Ken Fang, 深圳

问:
给团队讲敏捷要固定节奏，PI 要固定，做不完的需求放到下个 PI，本 PI 做总结和回顾。他们问到一个操作问题：迭代开发的 Story 已经合入主干了，如果 SIT 后发现达不到可商用的质量标准，Story 的代码要从主干摘出成本又很高，这时怎么办？

答:
Story 已合入主干的代码，除非是在集成测试时发现严重缺陷, 才需从主干移除, 否则是没任何理由需从主干移除的。
所谓商用的标准, 往往应该只的是从测试人员的角度，测试人员认为某特性有场景遗漏, 所以, 测试人员认为不应发布。所以, 根本的问题, 不是 PI 结奏固定, 而是发布出去，客户投诉后，测试要担责。
所以，测试人员ㄧ定要走到产品经理那, 走到市场, 去真正理解客户、真正理解客户的业务，如此，测试人员才有能力判断出那些场景的遗漏是属于重大的缺陷，才需要求将已上主干的 Story 代码，移除主干。
PI 节奏要固定；6-8 周，甚至更短；主要的用意是唯有 PI 节奏固定了，团队才能持续改善；持续改善发布的周期与质量。
PI 节奏不固定, 等于是开了个后门, 让团队是去证明自己没做错事罢了。

问:
很多产品的架构没那么灵活，当 Story 合入主干后发现有重大缺陷，而代码从主干移除的效率又很低，这时团队首先会选择延迟 PI 的结束时间。这样做就失去了 PI 周期的意义。请问有什么措施可以提升移除的效率呢？
答:
有三个建议：
1.应该由产品 经理，测试经理，SPO 共同决策，产品是否有重大缺陷到影响到整个产品都没法发布？
2. 确定是那些缺陷是真的影响到使整个产品没法发布, SPO 必需要带领团队在 PI 结束前修复。
3. 虽然架构不好，但还是建议试着将会产生重大缺陷的代码移除；因为，还是会有些 Story 相对是比较独立的。
代码移除没什么高效率的作法；只有一步一脚印去做
所以，开发、测试人员协作，做好每日目标管理。测试人员要真正了解业务。产品经理，测试经理，SPO 共同决策；是很重要的核心、基础。