点滴记录里有两篇文章梳理和回顾了我学习PMP和ACP的经历，这边文章记录我从项目经理到ScrumMaster的点滴。
把敏捷框架实际运用到我项目里是在2016年的一个项目，也是我第一次当ScrumMaster，该项目是从0到1 建设一个大数据平台，当时采用敏捷和传统并行的开发模式通过小步快跑和整体规划的方式，团队人数15人在半年时间内完成大数据平台的落地，并为公司所有上层业务系统提供底层数据能力。里面用到敏捷框架主要是Scrum，也结合了传统的项目管理模式，毕竟一个团队要想一上来就完全适应敏捷并顺利开展项目实施是非常困难的，这也算是从传统转敏捷吧。
在项目刚开始，我并未完全采用Scrum框架里所有流程，而是先让研发人员敏捷起来，项目里开始有了迭代的概念，有了Sprint Backlog，有了站立会，有了迭代回顾，并且上了看板「物理白板，上面有迭代里任务进展情况」。现在回头看从传统项目转敏捷，我的最佳实践就是上看板，先保障项目组内的所有信息透明化，并且让需求和任务在看板上流动起来。这个最佳实践到现在我也经常采用。
当时没有完全采用Scrum框架里的所有流程，主要是考虑项目组实际情况，在一个从来没有接触过敏捷的项目组里，需要逐渐适应敏捷而不是一刀切，当时我选择上面几点（迭代，Sprint Backlog，站立会，回顾会，看板）先运用到项目里，也是考虑这几个流程对原有项目管理模式融入度较高，项目组只需要稍微调整和改变就能适应，当项目里的小伙伴逐渐适应和熟悉敏捷思想和框架后，我在进一步指导他们实施敏捷。通过这样逐渐转敏捷，后来分析效果是达到了我的预期。要是一来就全搬Scrum框架，PO就要承担非常重的职责「PO的能力上限，决定了迭代交付物对用户产生的价值，研发也不适应采用用户故事的方式进行需求开发」，在当时行不通会严重影响交付物落地。只有真正熟悉敏捷，掌握敏捷思想和理念后在进行敏捷实施才能起到敏捷所期望达到的效果。
我们当时定的迭代周期是两周，目的是想让团队尽快的把敏捷玩起来，在迭代过程中有啥问题和阻力能尽早的暴露。这也是我们团队的敏捷口号：如果我们会失败，那就让失败来的快些。
就这样项目逐渐的实施起来，在进行了4个迭代后，我们团队成员逐渐熟悉了Scrum框架流程，特别是产品经理也对PO在敏捷里的作用和职责有了深入的了解「主要靠ScrumMaster的培训和指导」，我们团队开始尝试着进行Scrum全流程，也就是从：Product Backlog -> 用户故事 -> 故事优先级 -> Sprint计划会 -> Sprint Backlog -> 物理看板 -> 每日站立会 -> 燃尽图 -> Sprint评审会 -> Sprint 回顾会 -> 下一个迭代。
这是我实施的第一个敏捷项目，这里回顾也只是记录一个整体过程，从传统项目管理转敏捷可远远不止我回顾的这么简单和容易，里面有着非常多的理论和思想需要ScrumMaster去掌握和领会的，Scrum框架里的每个流程点都需要深入进去了解它背后的设计理念，后续我在深入到细小流程点去梳理和回顾。
我们常常看到行业里的专家或大神，我觉得他们其实就是针对某个知识领域了解或掌握了比常人更多的知识或实践「专研的更深入」，然后通过自己的实战经验和认知提炼形成了一些自己的方法论和观点。做到这点之前需要深入理解和学习该知识领域的知识并通过实践来获得属于自己的认知。
「专家」 = 「学习比别人多 + 实践比别人多 + 总结比别人多」
以下是我作为ScrumMaster的心得体会：
- 需要缓慢地给团队灌输敏捷实践。「不能急，心急吃不了热豆腐」
- 敏捷变化需要时间，ScrumMaster需要耐心，要像呵护婴儿一样地开展工作。
- 在敏捷转型中，提高情商是提高影响力的基础。
- 敏捷团队不是管理他们，而是指导他们。
- 需要学会一对一指导。
- 从“管事”转变成“交友”。
閱讀更多 小Rain點滴 的文章
