编辑导语：双周迭代是节制团队交付节拍的，但假如没有运行好的话，后续大概会呈现一系列的Bug；怎么节制节拍，让产物无缺陷的准时上线，需要产物司理和整个团队的共同；本文作者分享了关于B端产物双周迭代交付的具体思考，我们一起来看一下。

一、配景

笔者之前在职一祖传统制造业公司做产物，认真的产物线可以分别至电商类B端产物，业务体量每周在几百万级别。

部分基于交付质量及交付周期的一系列考量，在一个风和日丽的日子，奉行双周迭代。

有点雷同火速，但实际不是；熟悉火速的人都知道，火速开拓是轻流程轻文档的，其进程曲线是螺旋上升式的；我司施行的迭代实际就是小型的瀑布式项目，凭据双周的节拍举办交付。

二、已往VS此刻

简而言之，已往版本宣布没有节制节拍，有需求、缺陷落成了就布置上线，视优先级布置宣布；大概极度的环境是一天发屡次，虽然前提是不影响业务正常开展。

此刻则是凭据约定的节拍，只答允双周宣布一次，碰着非凡环境则需申请走紧张宣布。

三、进程执行

双周迭代的大前提下，要求严格凭据瀑布式的流程来走，详细：

需求或缺陷需要从内部系统收集，而且确定理睬办理时间之后进入禅道系统，延期未办理的缺陷可能凭据优先级倾轧的需求没大将扣项目KPI；

每一次双周迭代需要在禅道上维护打算，并关联相应的版本和需求，版今日期与通例宣布的日期一致，定名需凭据类型，不然同上视为不合规，扣合规性KPI；

所有需求需要拆解成为方案、开拓、测试任务，由差异脚色去建设，指派以及跟踪闭环；假如没有界说任务的起止日期也将被审计界说为不及格，扣合规性KPI；为每个需求成立测试用例，开拓完毕提交测试需建测试单以及关联用例，缺陷则不需；

系统宣布可能数据改观，需要走OA流程提倡，并附相应的测试记录清单，流程审批完之后才气宣布上线；

双周即小项目，该有的需求调研，办理方案设计、设计评审、开拓、代码评审、集成测试、UAT测试、上线筹备、宣布、宣布验证，一个都不能省。

看起来一整套的流程十分严谨，该有的都有了，该毗连的都毗连了，该监控的都监控了，我们也在短短双周内做了许多的工作；但实际进程中是总有各类百般的问题，我们的出发点是均衡需求和运维的落成占比，严控上线缺陷指标；同时在这两个大前提下节制版本宣布的节拍，促使业务端养成提真正有代价的需求的习惯，把资源用在有代价的工作上。

四、问题显露

实行了约两个多月之后，我们碰着了很头疼的问题：老是在上线的前1天有问题遗留，无法定时办理；可能磕磕绊绊办理完，上线后质量堪忧，欠下技能债，又要在下个迭代预留时间来办理。

假如这个迭代延期了，无疑要占用下个迭代的时间，导致下个迭代延期，恶性轮回；纵然下个迭代从需求池砍掉需求了，团队照旧感受吃力，按预期上线好像是一件很难告竣的方针。

我们做过相应调解，但每到宣布节点依旧如通魔咒扣在了头上，一方面焦急不已，另一方面陷入宣布照旧不宣布的两难田地；不宣布意味着延期，宣布意味着有bug，欠了技能债。

出来混不就是怕有人说你不靠谱，喊着要你还债么，团队情绪不免陷入负面，甚至有时候会诉苦彼此之间协同不足努力，信息失真或相同不到位；但亏得每次各人都在面临并无逃避，一直在努力寻求改造切入点。

五、问题点阐明

作为亲身经验者，做着对内较概略量的产物线成长、交付和维护的事情，也因为双周火速交付属于值得阐明的交付 *** 。

此间各种配景和近况，引发了笔者的乐趣，就做了一些归纳和思考，抛出了几个问题：

1. 打算层面

1）需求和问题数量难以均衡：每迭代前评估需求进入数量，需求数+bug数的事情量=现有可用人天的事情量，但凡是很常见的环境是——迭代中间有许多需求插入进来，好比某率领要求的，组织架构变革，搞勾当等等；凡是这种插入的需求，要不拆分迭代，要不加班完成；这两种处理惩罚 *** 都对原先拟定的迭代打算发生或多或少的影响，越晚提出的影响越大，越难有效的节制执行结果。

2）排打算仅依赖开拓人员小我私家履历，未记录汗青迭代的事情环境数据举办参考；需求/bug的数量比例、人员分派未形成履历教导数据，开拓人员绩效没有举办复盘阐明，没有数据作为指导举办公道调解。

2. 执行层面

1）没有明晰详细迭代责任人

组内多个产物线同时功课，每次宣布打算开始由产物司理认真，方案或原型确定之后交由开拓，中间的进程险些是放养状态。

乃至邻近宣布时间点，常常呈现这样的画面：

A：xx需求做完了吗？B：做完了。

A：赶忙发测试服啊，说了许多遍提前发啊。B：哦（老系统，宣布挺贫苦）。

A：这个需求怎么这么多bug，您没有自测过吗？！有没有凭据方案来啊。