2020年3月1日00:41:10
 2 月 28 日，很重要的时刻，相当于"中共一大"的项目回顾会议正式召开，虽然形式还是线上会议，但是过程中可以看出大家对这次转变的认可。

初次印象

 时间往回倒一些，在这周中，我私下和团队的小伙伴们（包括过程中一直旁观的 T）各种形式或多或少的都沟通过，总结一下大家的初次印象。

• C：工时估计少了，自己约的炮含着泪也要打完，只能加班完成，虽然比原来倒是轻松了一些，但依然很累，总结一下就是累的更明白了。。。
• M：挺好的，我知道我每天要干啥了。原来挺乱的，现在这么分任务挺清楚的，这次就这些么？
• Y：你觉得他们估的工时准确么，我的意思不是要压缩他们的时间，咱这个还是有点慢。
• X：你觉得咱们这个敏捷推动的怎么样，有实际的成果不
• K：以前测试的时候我能分析整体的需求，现在比之前提测快了，再加上之前有其他项目，没有充分的时间进行分析需求，感觉测试会漏啊
• T：哥，你要不要给他们说说到底啥是敏捷

所以就有了。。。

第一次回顾会

第一次回顾会参加人员：所有项目人员。
设定会议主题 3 个，计划时间控制在 30 分钟（实际用了 40 分钟）。

主题一、稍微普及一下敏捷尝试，说明此次推动敏捷项目管理的目的：

 拆分最小化可交付模块，快速调整目标，及时调整计划。

主题二、强调本次交付目标：

 完成原计划目标，为了应对并行项目 Z 和线上问题导致的延迟风险，将下周作为冲刺，对于有风险的模块，C 和 K 会也在周六加班处理。

主题三、一周新模式工作下的总结：

优点：

 1、拆分任务后，会使目标更加明确，每天的任务和风险很清晰
 2、可以清楚的了解项目瓶颈和风险

建议：

 1、故事的任务应该拆的更细一些。
按照现在的模式，产品和项目管理一同拆分故事，故事拆分后开发再将故事拆解成更细的任务（过程中可能需要产品和项管的协助）
 2、由于先讲 prd 文档，再拆分故事，会有需求的遗漏（本次出现的问题）
之后再次进行需求讲解的时候，先拆分故事，按照故事去讲解需求
 3、项目管理工具可以与公司的管理方式相一致
当前不支持，而且数据不足去证明敏捷的效果，需要 4 次或者更多迭代评估效果，选择最优的解决方法
 4、更多人参与到故事拆分和工时评估
建议下次迭代的时候，在故事拆分、任务拆分、工时评估可以由核心的人员一同参与
 5、电子看板每个人都需要实际去改变状态
为了看板流动更及时，每个人需要及时的去更新看板任务状态和工时记录

问题：

 1、关于 W 同学同时完成 Z 项目和 S 项目协调问题，帮忙协调————Y
 2、关于线上问题反馈描述需要更加清晰，尽量有截图————X，Z

后记：

 现在小伙伴们对于电子看板会主动进行状态变更，大家对于看板中任务的优先级会积极的进行沟通，保证优先级。