交付能力不及计划30%，为啥你的迭代效率这么低？

在开始正式的迭代开发之前，往往还需要做一些准备工作。

准备阶段的主要工作内容包括了：探索与定义需求、建立团队初始流程规范、技术前期架构及其他奠基工作。

准备工作的目的是让团队进入迭代开发就能正常交付软件功能。这个准备的阶段，我们称之为「迭代0」

那么今天的极限拷问来了：

1、你的项目有这个「提前准备」的迭代0环节吗？

2、 你会做哪些准备工作？

3、 有什么经验或教训可以分享？

我们在群内问了群友，大家关于项目是否进行迭代0的问题，得到的反馈是，普遍都会有 「迭代0」环节。影响 「迭代0」有无的原因有：

团队熟练度。新的团队一般会有 「 迭代0 」环节，若是已有团队切换项目，则会弱化 「 迭代0 」

具体项目情况。可能会取决于：是否是新项目、特殊用户故事性质等原因。

那么 「迭代0」的准备工作应该从以下几方面着手：

需求梳理并确认团队 Sprint 0 的 Scope。「迭代0」，业务拆解、技术准备还不完全，因此有一部分时间是用来做这部分工作，因此迭代0的最终交付内容不一定很多，但是会有。交付多少，需要在 Planning Meting 上来确认。TL会拆分技术卡并安排优先级，BA 会拆分业务，并让一部分 UserStory 开始实施。并在迭代过程中整理并确认迭代 1 要交付的内容。

基础设施搭建。环境准备不应该 「迭代0」全部的内容。可以根据依赖关系，排好技术依赖的优先级。优先解决 Block 开发 UserStory 的依赖。

做好信息收集管理。项目开始了，需要把项目中需要的信息开始组建沉淀。例如建立共享的文件目录，建立技术栈描述、业务背景描述等需要的文档。这个不需要多久时间就能建立完一个团队信息记录的地方。可以不是一个人来完成，建立一个目录，大家共同在迭代中随时更新。

团队组 建和磨合。 不同上下文，团队的是不同的。彼此熟悉再好不过了。如果团队中新同学可以选择 pair，将上下文、技术栈在做卡过程中传递出去。如果新面孔比较多，可以选择长期磨合，先针对要做的事情达成共识，达成共识的过程可以在做事过程中 完成，而不一定单拉时间来处理共识上的问题，哪种对项目有好处用哪种。

对于如何做好「迭代0」，群内的老司机们也提出了由个人经验总结出的建议，在这里分享给大家：

@北京-xxxx-吕哲

根据自己的需要，做一些有意义的工作，不要考虑的太多，不要追求万事俱备。

要学会在迭代中建立自适应机制。

@深圳-力维-夏天

不要一次做完美，基本架构确定就可以实施；

持续集成环境一定要在迭代0构建好

@杭州-道富-阿贵

迭代0建立起好的工作习惯，后面容易执行和坚持。如果第一个迭代没有开好头，后面纠正不好的行为非常费劲。

@广州-安卓开发-罗磊

个人感觉团队做法中规中矩，并没有太多新意，准备虚心听取各种改进意见。

非要说的话，教训就是定义好技术架构后，一定需要针对核心技术点进行早期验证，以及针对不确定的需求及早沟通和明确。

快做完，或者做到一半发现要改核心架构或者部分核心功能需要换方案返工的痛铭记在心。

@陈旭

一个epic拆分成用户故事后，往往有些用户故事之间依然存在依赖关系，有时候多个用户故事之间，可以提取一个简单的实现框架，减少重复代码，如果类似的用户故事没有被发现，大家各自为战，很有可能一万个程序员心中有一万个实现方法，最后合并代码时返工，资源浪费严重。

@上海-银联-子弹的微波

可以看到，要做的准备工作很多。很多工作是可以逐步优化的，比如有规范和制度、文档模板、协作工具链（邮件、IM、看板、需求/bug管理工具等）、开发工具链、代码规范插件、代码扫描工具、依赖包管理/扫描工具、容器化测试环境等

作为开发团队管理者，要确定效能优化的精益求精的路线，发现待优化的关键点提出改进要求，带领团队不断补足短板，构建生产基础设施

@北京-ThoughtWorks-Page

迭代0不是只用来做准备的，还是需要围绕价值交付来试试，有些准备工作可能持续几个迭代，有些根本不需要在迭代0进行。所以把block开发问题（技术、业务）先解决掉。

如果技术能力差异较大，团队还是还是应该聚焦交付价值，Training要做但是不是目的。

避免依赖关系问题，如果有限应该解决或者看是否不解决同样能够往下进行。

迭代0并不是只为了后续的共识，共识在整个项目进行中都会持续达成、添加。

从迭代0开始就需要持续关注业务。

尽早止损。当新面孔比较多时，不要因为刚接触而不将没有做好的事情、没写好的代码讲出来。持续的暴露问题应该就从迭代0开始，暴露这些问题的过程或方式可以使用一些软技能，不让事情太过尴尬。

@北京-下一步free-吴大侃

迭代0之前其实还有相当长的孵化时间，孵化时间里团队可能有人已经参与进来了，但是更多的人应该尚未参与进来。在迭代0里需要对共识进行充分确认，确保大家在一致理解中开工

有群友反馈说，在一次项目中，不做 「迭代0」，直接迭代 1 的话，往往会造成迭代 1 交付能力不及计划的30%。

毕竟我们很难在一开始就把一件事情的发展和结局，面面俱到的安排。而 「迭代0」便是一个很好的突破口，从这个意义上讲，带有 「迭代0」的开发模式，也可以理解为一种探索式与启发式开发模式。团队的表现，体现在 生产率和交付质量上，在后面的迭代里肯定会比前期迭代要好。

极客练功房

什么是极客学院的TDD实践活动呢？

它竟然这么实用吗？什么？竟然可以提高工作效率？

什么？还能实现敏捷开发？

快给俺也整一个！

极客学院线下TDD实践活动——极客练功房

下周又要举办啦！

时间：12月28日13：30

地点：深圳

↓↓↓

基于极限编程的核心实践，直指个人和团队基本能力

全程采用刻意练习方法，不讲废话，只练真功夫

如温馨网友聚会，面基志同道合的小伙伴

社群资深教练现场点拨，打通关窍

↓↓↓

时间：12月28日

地点：深圳

（详情见次条）

内容来源

本期内容整合自 【极限编程中国 | 实践者】

内容贡献者：

如果你也想加入讨论，获取干货

迅速成长，提高效率

欢迎加入我们

↓↓↓

▲【极限编程中国 | 实践者】微信群

↓↓↓

怎样加入我们

限时免费加入

【极限编程中国 | 实践者】微信群

和前ThoughtWorks总监咨询师熊节实践敏捷开发返回搜狐，查看更多

责任编辑：