Planning Meeting

团队举行了第一次Planning Meeting，有产品经理（PO）、TEAM（研发+测试）还有Scrum Master参与。

Meeting有个三环节：

第一、确定Sprint周期和团队可用故事点 —— 2周，80SP（Story Point）

第二、从需求池（Backlog）中筛选To Do的Story，这个环节由PO讲解每个Story，对TEAM的疑问进行解答 —— 这个环节需要PO会前事先准备好需要的Story，并确定好优先级。

由于我们第一次Planning Meeting，所以这个环节占用大量时间来确定To Do的Story和排优先级。

第三、根据优先级，对每个Story进行扑克牌评估（如果如上环节PO事先准备好，则这个环节在评估之前需要逐一讲解）。

我们是这样评估的，TEAM出牌，PO出牌但仅供参考，出现偏差较大，由最大最低点着进行PK，如果达成一致，则评估SP为达成一致值，如果不能，则重新出牌，二次出牌扔不能达成一致，由PO决定。

如此这样循环，直到达到团队可用的故事点（根据上次SP进行估算），由于我们没有上次经验，所以我们将本次需求都进行评估。

补充：如果第二个Sprint开始后，可以根据第一次Sprint的SP进行估值，如果超过这个LSP，则团队可能不能按时完成任务。

会议结束后，就形成了我们的故事版，我们的第一次冲刺Sprint开始了。

我们向PO承诺，在2周的Sprint内完成这些Story，根据默认的优先级进行开发，每周有2个上线日，我们定义为里程碑。我们在上个里程碑结束后确定下个里程碑的交付，就是小迭代。

产品经理向我们承诺在迭代内，不添加新需求，期间遇到紧急情况或日常琐碎的事情，包括上线，都记做Buffer（缓冲）。

Milestone

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 进行后期追踪。

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

Reivew & Retro

前言

开放平等是我们的宗旨。我们从来不通过一个头衔去授予某个人某种权利，也不会有谁有权利去管理别人，甚至掌握他人的performance review的结果。我们培养leadership。这不是用权利管理，而是通过你的专业，你的经验，你的能力，你的人品去建设你自己的影响力和领导力，给别人提供帮助，指导和解惑。

你需要付出比你的其他朋友、同学、同时更多的时间去学习，实践技术。这个没有捷径。我们会提供各种资源，但我们不能替你学习。

准备

心情看板

整个回顾从这个心情看板说起，其中愤怒的一栏就是我们的问题，通过围绕这些问题展开头脑风暴，然后由Team提出有效建议，并决定要做什么。