这个项目进入第三次迭代了，今天是第一天。

不算圆满的第一个正式的迭代计划会

前两次都因为各种原因，团队并没有在一起开过正儿八经的迭代计划会，今天我和开发团队一起，完成一次正式的迭代计划会。

虽然上周五的回顾会上，大家决定团队成员开始轮流坐庄，一个人负责一轮迭代的会议组织和主持工作，但迭代计划会开发团队没有人经历过，所以仍然由我来主持。

会议开始，我给大家讲了下这个会议的目的，讲完了发现自己有点啰唆，会议前自己并没有准备，临时上马，还是有点问题，自己还没有对这套内容做到精熟。

上个迭代有很多故事都只完成了部分，延续到这次了，很多故事都是开发完刚进入了测试状态。虽然说让他们预测下这些遗留的有多大工作量，但发现他们每个迭代能完成多少，现在也是笔糊涂账，因为前面刚开始的时候没做估算，后来虽然做了估算又很多没有完成，经过这两个迭代还估算不了团队容量。

我临时给他们看了团队的迭代速率，第一个迭代规划了一堆任务，完成了很少的一点。第二个迭代，完成了规划的不到一半。这个本来是上周回顾会应该展示的，当时忘记了，这次给他们看看。

在往迭代里放新故事的时候，发现需求准备得还不充分，有几个要放进来的故事设计了原型，但还没跟开发团队沟通过。幸亏这几个比较简单，临时拿着原型讲了下，没有什么不清晰的地方。

还有几个复杂的，需要与用户进行确认后才能进行开发，但还一直没有约用户，因为想部署上前两个迭代的成果了，连着前面的成果演示和新的需求沟通一起做。

上周的回顾会上，有成员提出开发人员的交付质量不高，他当时给出的原因是缺乏自测，要加强自测。我当时问他们是否可能因为开发人员对任务要做成什么样并不清晰，他们想了想觉得任务不清晰相对于自测不够可能是更重要的原因。

也有成员提出了迭代目标不清晰的问题。

这次他们将新加入的三个故事进行了比较详细的任务拆分，包括一些界面上的校验、关联等等都描述出来了。一个故事拆分出来了差不多10来个任务。

好多任务都是1个小时，两个小时这样的。

待他们拆分完成了一个故事，准备拆分下一个故事的时候，我提出来有些任务都比较小，又都是一个页面上的，是否可以考虑合并写成一个任务，在描述中把这些都写上就可以了，这样拆分起来会快点。

但团队说他们拆分成这样就可以分给不同的人开发了。

没想到他们解决了一个以前在别的团队一直不能解决的问题：每次我跟团队说能不能多个人合伙同时去干一个功能模块，他们就会说这些任务没法拆分了，相互依赖太严重，云云，每次都是一个人领一个大模块，可能一周两周都干不利索。

迭代计划会结束的时候，我问他们，这次是否解决了他们上次说的那个任务不清晰的问题，他们说“是”。当然有一种可能是他们不好意思说不是。但我的直观感受，应该是参与的每个人都清晰多了。

比较心塞的演示准备

经过了两次迭代，让开发团队将前面两次的成果打个包，我们要部署上，给客户做个演示。

团队提出还有几个模块在进行测试，能否等测试、回归完了再一起部署。

我说“不能”。趁机讲了下为什么一直强调每个迭代团队都要尽力的去完成那些已经开工的故事，而不是开工了一堆，这里啃一口，那里啃一口，迭代结束却都不能拿出来部署。

今天下午部署了一套。我上去只点了几下，就出了比较低级的问题，新增数据保存时提示400错误。发给团队看，他们找了原因，说是开发平台有一个bug，他们很快就发来一个新包。这是个啥bug，我还比较好奇，计划明天问问其他人。

新包部署上后，又点了两下，发现新增数据后左边的树和右边的列表都刷不出来这条新增记录。没法往下操作了。

开发用了20来分钟，找到了原因，又发了个新包部署上了。但这个时候我已经下班了。

原本打算约用户明天上午演示的，幸亏还没有约，如果这样的状况让用户见着，只会引起对我们质量的担忧了。

这次的事故计划留到这个迭代结束时的回顾会上抛出来，看看团队如何分析、如何制定改进措施。也可以这两天针对这件事情组织一个分析会议，更及时一些。