前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >精益敏捷开发: 带病迭代

精益敏捷开发: 带病迭代

作者头像
Ken Fang 方俊贤
发布2018-01-04 18:06:58
6920
发布2018-01-04 18:06:58
举报
文章被收录于专栏:Cloud Native - 产品级敏捷

前言:

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

本文:

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

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

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

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

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

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

结论:

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

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

2)     产品质量的变化

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

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

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2014-04-19 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
项目管理
CODING 项目管理(CODING Project Management,CODING-PM)工具包含迭代管理、需求管理、任务管理、缺陷管理、文件/wiki 等功能,适用于研发团队进行项目管理或敏捷开发实践。结合敏捷研发理念,帮助您对产品进行迭代规划,让每个迭代中的需求、任务、缺陷无障碍沟通流转, 让项目开发过程风险可控,达到可持续性快速迭代。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档