D3aaSM

D3开始，日记将会变成随手记，想到就写，不拘泥与上下文。

早晨的站会，架构师不在，使用微信接入了Daily Scrum，通过微信来分配任务，解决各位的block。项目除了一个关键点，其他的Task都已经完成了，明天测试就能拿到第一个版本了，有些期待。由于这个Sprint里面的内容基本会烧光了，大家开始把另外一个平行项目的工作项向任务板里面添加，我对这个举动先没有制止，留待观察。

晚些时候，我开始考虑如何组织本次Sprint的评审规划会议，根据我们第一次讨论的结果，评审回顾规划会议会放在一次会议里面结束，我该如何解决这个Sprint里面的发现的问题，可能这些问题并没有影响到项目的进度，但是它不符合Scrum的规则，我就不清楚在未来这些问题会否给团队效率带来负影响。

我打算在规划会议时：

1，引入一个全员回答的问题，让团队成员估算能够在下个Sprint里面投入的时间，来解决这次Sprint由于并行工作带来估算不准的问题。

2，引入全员参与故事点的估算（而不是架构师或者做任务的那个人），来探寻每个人对任务的认知情况，统一大家对于项目的认识，可能会在未来解决掉过于依赖架构师的问题

3，请大家喝咖啡，模糊上下级关系，采用轮流发言的方式调动年轻人积极性

由于在第一个Sprint里，大家更多是从技术架构角度来分解任务，导致的结果是任务板上的任务卡非开发人员看不懂，而且可以提前预见到我们在下一个Sprint里面，如果没有用户故事，我们就没法遇见第二个迭代产品的模样，我们总不能说第二个Sprint交付一个接入了多少API的产品。

我开始提前学习用户故事地图，明天和产品及测试人员一起实践一下，将这个项目看成一个新做的项目（而不是移植），尝试从头的分解，组建用户故事地图，如果外面分解的足够好的话，它将在第二个Sprint里面发挥作用。