精益敏捷开发: 带病迭代

前言:

   本文主要探讨在精益敏捷的开发下, 该如何看待与处理所谓的 “带病迭代”? (而不在探讨如何定义带病迭代◦)

本文:

   精益敏捷开发采用迭代的方式进行开发◦许多的团队在这方面往往犯了以下的其中一个错误, 而使得精益敏捷开发最终以失败收场！

1)     完全不理会, 不处理迭代中所出现的软件缺陷 (或根本未进行该有的迭代测试), 便直接进入至下一轮迭代进行开发◦

如此的作法是行迭代开发之名, 却行瀑布开发之实; 标准的挂羊头卖狗肉◦ 最终, 便是仍像瀑布开发一样, 所有版本的问题都在最后的紧要关头才爆发出来◦版本能否上线取决于两个因素: 1) 版本经理是否会掩饰缺陷, 掩饰问题? 2) 祖上是否积德? 是否保佑?

2)     认为迭代是 “带病” 了, 便认为应停止开发下一轮迭代的所有需求, 先将这轮迭代搞 “健康” 了再说◦ 如此的思维, 作法是以 CMMi 的方式在执行精益敏捷开发;标准的借尸还魂◦最终, 团队将无法拥抱变化, 至多产品的质量提升了, 但却与客户, 使用者的期望越来越远, 与客户, 使用者越来越背道而驰◦典型的做的要死, 却被骂要死◦

所以, 该如何看待与处理所谓的“带病迭代”? 很简单….

“每轮迭代有两周的周期, 项目经理需在每轮迭代第二周的周三, 同时审视这轮迭代的问题, 缺陷与下一轮迭代的需求, 重新排定迭代 Backlog 中待处理的 User Story, 重新制订下一轮迭代的迭代计画◦ 然后, 勇敢的带领著团队进入到下一轮迭代！”

结论:

   在精益敏捷的开发下, 看待与处理所谓的 “带病迭代”, 是期望项目经理需根据:

1)     外部客户, 使用者的变化

2)     产品质量的变化

有智慧的做出正确的 “决策”, “计画” 与 “执行’◦

能拥抱变化, 才是真正的精益敏捷开发!