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 共同决策;是很重要的核心、基础。