前言:
本文主要探讨在精益敏捷的开发下, 该如何看待与处理所谓的 “带病迭代”? (而不在探讨如何定义带病迭代◦)
本文:
精益敏捷开发采用迭代的方式进行开发◦许多的团队在这方面往往犯了以下的其中一个错误, 而使得精益敏捷开发最终以失败收场！
1) 完全不理会, 不处理迭代中所出现的软件缺陷 (或根本未进行该有的迭代测试), 便直接进入至下一轮迭代进行开发◦
如此的作法是行迭代开发之名, 却行瀑布开发之实; 标准的挂羊头卖狗肉◦ 最终, 便是仍像瀑布开发一样, 所有版本的问题都在最后的紧要关头才爆发出来◦版本能否上线取决于两个因素: 1) 版本经理是否会掩饰缺陷, 掩饰问题? 2) 祖上是否积德? 是否保佑?
2) 认为迭代是 “带病” 了, 便认为应停止开发下一轮迭代的所有需求, 先将这轮迭代搞 “健康” 了再说◦ 如此的思维, 作法是以 CMMi 的方式在执行精益敏捷开发;标准的借尸还魂◦最终, 团队将无法拥抱变化, 至多产品的质量提升了, 但却与客户, 使用者的期望越来越远, 与客户, 使用者越来越背道而驰◦典型的做的要死, 却被骂要死◦
所以, 该如何看待与处理所谓的“带病迭代”? 很简单….
“每轮迭代有两周的周期, 项目经理需在每轮迭代第二周的周三, 同时审视这轮迭代的问题, 缺陷与下一轮迭代的需求, 重新排定迭代 Backlog 中待处理的 User Story, 重新制订下一轮迭代的迭代计画◦ 然后, 勇敢的带领著团队进入到下一轮迭代！”
结论:
在精益敏捷的开发下, 看待与处理所谓的 “带病迭代”, 是期望项目经理需根据:
1) 外部客户, 使用者的变化
2) 产品质量的变化
有智慧的做出正确的 “决策”, “计画” 与 “执行’◦
能拥抱变化, 才是真正的精益敏捷开发!
