我与合伙人合作制作BP视频，并把这件事当作一个小的敏捷项目来进行管理。
今天，我们到了Sprint 2结束的时候，花了3小时的时间来review成果，因为项目比较小，就没有严格的将Sprint Review和Sprint Plan区分开，在Review当前成果的同时发现有些还需要补充items，或是发现优先级没有之前认为得那样高了，但把某些item移到了靠后的位置，而把重新识别优先级高的item提前到当下来做。
Sprint Review和Sprint Plan结束前，我们又对从该Sprint中识别出来的Issues进行了分析，讨论和行动决策的制定。
之后，我们用半个小时对整体做了一个Sprint Retrospection回顾会，其中把过去的这个Sprint中的交付成果满足DoD的程度，交付成果demo的效果，对优先级重新规划的考虑，以及新识别的Issue对当前项目的影响程度等都做了完整的评估，并给出了相应的理由，经过讨论，认为理由成立且合理，可以接受，并将检查出来的问题都予以记录，将其作为后续跟进的行动写在了To do list中，然后更新了各个相关文档，以反映最新研讨出来的成果和最新的实际状态。整个Sprint Retrospection回顾会，重点放在了PDCA的Check-Action上，发现问题及时分析，能当场解决的就当场解决，不能当场解决的，也用经典的三层问题套路“Start doing, Stop doing, Keep doing”的方式，提出了有建设性的、有效的、可行的方案，检验出来的问题即刻进行矫正，不拖延，很是高效。
当然，我们这仅是个小的敏捷试点项目，但麻雀虽小五脏俱全，可以以小见大，完全可以看出敏捷管理方式的简单、快速、高效的功效，潜移默化中我们应用到了敏捷的“Learn as we go, Change happens, Embrace change, Inspect & Adapt”的试验性过程特征，尤其体现了“个体与互动”和“响应变化”这两条敏捷价值观，更把5个Scrum价值观体现得淋漓尽致。
这是一次很好的机会，来验证Scrum的有效性，为再次应用提供了实践基础，也更为日后我们即将开展的平台产品项目做了很好的pilot作用。感谢敏捷给了我们如此的思维方式，或者说，其实我们早已有敏捷的思维方式，只是现在才发现落地应用它是如此的精妙。
