最近介绍了有关新版本Scrum指南的变化，可以看出这份指南越来越向着原则指导方向演进，换句话说可提供参考的落地实操内容越来越少了，这也给我们在企业内部实施敏捷开发转型提出了很大挑战。比如在帮助团队落地Scrum方法的过程中，我发现很容易被一个新的敏捷团队忽视或者对冲刺过程产生影响的是冲刺计划会的组织，有团队会将估算与计划混淆，故事与任务混淆，工作排布并没有在冲刺待办中得到体现，也没有在冲刺开始得到所有成员的承诺。
Scrum方法并没有设定项目经理这一角色（传统的计划制定和控制者），主要是由于Scrum团队规模一般不大，工作相对专注，产品增量也是通过冲刺分批次实现的，这些先决条件很大程度降低了计划制定与控制的复杂度。更重要的是Scrum方法还希望团队成员充分沟通并对计划、进度、目标的认识达到高度统一，从而实现团队自管理。实际情况是我们在企业内要面临交付时间盒，而且绝大多数Scrum团队都是由前端开发、后端开发及测试不同职能的成员组成，这些限制很难在有限时间内达到我们认知的“理想”状态，所以如果仅仅靠概率和勇气进行承诺有可能带来的不是惊喜而是惊吓。
在怎样做计划的实践层面10个团队可能有10种不同的做法，笔者也认为没必要专门为小的Scrum团队配置专门的项目经理，下面我只介绍自己在辅导新团队过程中的一个tip，可以在一定程度上避免冲刺内工作配合的混乱，降低故事无法按DoD完成的可能。
具体操作方法：在需求梳理会以及反讲等工作后团队基本上已经对需求内容及实现方案进行了沟通，估算规模较大的故事也会在过程中进行拆解，那么在计划会剩余部分团队可以使用一个非常简单的故事计划日历来共同对具体工作进行铺排（10人左右团队一般可以在30分钟内完成计划）。过程中不同职能成员配对充分交流并敲定所认领的故事启动顺序及关键时间点（如联调、提测等），最重要的是时间安排要以计划板的方式在整个冲刺过程中透明给团队所有成员，共同计划、共同维护、共同负责，计划板完成即冲刺计划完成。
物理计划板：
电子计划板：
最后对于实际情况是否能和计划吻合以及过渡计划带来浪费的顾虑，我们完全可以参照需求梳理的实践经验来进行类比操作。过远周期（如年度、季度）且比较模糊的事项主要依靠经验性评估来进行粗颗粒度的计划，在执行过程中不断调整和修正（变更概率大）；而由于需求的明晰和确认，冲刺计划精度反而应该要求相对较高（变更概率小），这也是团队冲刺承诺的基本依据。
