在敏捷回顾会议中引导使用ORID

头一次接触ORID方法在2015年的一次敏捷回顾上，但是还不知道它，当天围坐在小会议室中通过该方法总结迭代开发经验，使我很有收获。

ORID工作法很好理解，几乎一听就会，只是日常工作中我们总会选择更偷懒的方法，而忽略了总结过程中思考和逻辑的重要性。根据百度百科，ORID是一种通过催化师引导来开展的结构化汇谈（会议、交谈）形式。该方法常被用作对事实进行分析和感觉某一工具和方法。

通过这个方法，在两年后我自己主导转型敏捷迭代开发中再次利用到，可以设计引导结构：

• Objective: 上个迭代有哪些让你印象深刻的事情发生？你看到了什么？
• Reflective：哪些场景让你兴奋？哪些地方不那么顺利？
• Interpretive：为什么会不顺利？这些数据使你意识到了什么？我们如何才能做得更好？
• Decisional：什么是下个迭代我们可以立刻开始动手的？

此次通过该引导，我得到这样的结论：

Objective

1. 团队很和谐，研发节奏很好。
2. 项目每到上线发布时刻，很紧急。
3. 便利贴对工作帮助很大。
4. 对功能细节的评审缺乏。
5. 产品有太多的优化空间。

Reflective

1. 工作交流比较开心。
2. 虽然加班，但是也很有劲。
3. 看到产品没有人使用，不开心。
4. 看不到决策层反馈，比较迷茫。

Interpretive

1. 每天的计划可以做的更细致。
2. 研发过程中还是需要多沟通。
3. 定期的传达决策层的建议。
4. 需要有更好的用户体验。
5. 团队需要保持。
6. 需要团建。

Decisional

1. 希望研发团队能有经费做一次聚餐
2. 希望看到领导层面对这个项目的期望以及信息的传达
3. 希望针对这个项目招聘一个推广运营
4. 每一个研发迭代需求文档提早一个迭代期出来
5. 每个便利贴都有一个负责人标示在便利贴上
6. 尽量在周二上午就提交这个一个迭代的功能验收测试版本
7. 每天站会细致的定义今天的工作必须完成的内容
8. 迭代的需求评审会议议定要订出本次迭代的功能目标

将Decisional作为下一个迭代要去执行的工作，如此看来相当有难度，说明我的团队管理还是做得不够。