Planning Meeting 的两天后，我们迎来了第一个里程碑节点。

通过燃尽图发现，故事燃烧不尽如人意，Planning Meeting 计划的79个故事点，到现在只消灭了5个故事点（一个故事），而且这个故事还留有缺陷，而理想进度应该是是消耗了25个故事点，这大大加大了我们在本次冲刺结束时完成全部故事的风险。

不过，一个十分好的感觉是，产品经理 PO 了解了我们 TEAM 的情况。"以前上线必须上什么什么，而这个必须上到底是谁定的，之前是开发又或者是 PO，搞得测试测试的和上线的内容不一致，大家郁闷又生气。这种现象已经不存在啦"。因为我们 TEAM 在 Planning Meeting 中承诺 PO 会在本次冲刺 Sprint 结束后，交付所有Stroy，并把这个冲刺内的每个上线日定位一个个小的里程碑，而每个里程碑到底上什么，是我们在上个里程碑结束的时候确定好的，并且保证确定上线和实际上线的内容一致。我们会把在期间遇到的问题，只要是影响 Story 进行的一律贴 Buffer，通过看板告诉大家，"我现在正在做的事，由于受到buffer影响，进度滞后"。

为了能让下一个里程碑更高效，我们完善了一些规则：

1. 在每个里程碑结束的 Standing Meeting 确定下一个里程碑的上线内容，确保上线与确认内容一致。

2. 需要测试介入的需在 Planning Meeting 确认放到 To Do 里面，用蓝点标识，此类任务开启需研发与测试一起。

3. 在 Standing Meeting 正式确认提测时间和上线时间，以及之后不能更改测试环境，保障测试质量；并且通过 jdtest 记录整个过程。

不过，我们也发现了问题：

1. 燃尽图下降缓慢，是由于存在几个 SP 20以上的大故事。

2. 对于一个 Story 的 Task 没有做预评估，不仅导致 Strong 停滞不前，还不停的产生 Task，其实这些新的 Task 可以算作 Buffer 进行后期追踪。

这些都是希望在下一次迭代中解决的问题。

本文受原创保护，未经作者授权，禁止转载。 linkedkeeper.com (文／张松然)  ©著作权归作者所有