Scrum敏捷真的有捷径哦
尝试过Scrum敏捷的人都很清楚，这东西看着简单，但是实施起来还真的不简单。
而小婧也不止一次的说过，很多团队只是披着皮的伪敏捷。披着什么皮呢？至少找个理由不写文档了吧。我个人算是参与过真正的敏捷过程的，那感觉真的很美好。
之前我也在自己的号里分享过一个敏捷Scrum的系列。作为BA的Scrum Master，我把自己的经验和心得记录了下来给大家做分享。
这两天看了一本一个Scrum Master写的书，觉得其中讲述的东西非常实在，迫不及待的想和大家做分享。如果你们已经开始实施敏捷，但是你却对其效果抱有疑虑；如果你觉得你们现在实施的敏捷流于形式；如果你对敏捷不是那么了解，请继续看。
Scrum敏捷真的有捷径哦
作者介绍了30条敏捷Scrum捷径，其实都是一些经验的总结。
第一部分：起步
1一句话推销Scrum
到底要不要实施Scrum，首先需要说服的是项目发起人，然后是团队成员。需要向他们推销Scrum“固定的灵活”这一理念，并让其同意开展并参与试点项目。
2脆弱的敏捷
必须要说明的是，敏捷是一个框架，类似于打麻将的规则一样。要么全盘接受，要么就不接受。没有只接受或者采取一部分的说法。
明确这个也就明确了我们看到的参与的很多团队，其实并不能被称为是敏捷。
3有创意的舒适
敏捷很提倡团队，所以需要想办法提升团队的士气。比如想办法改善办公环境，让一个scrum团队的人坐在一起，最好还有一个临时的讨论桌。另外，给团队起个名字，这样可以帮助团队建立身份认同感和使命感。记得我们以前公司里面有Pandora团队，OX团队，我们团队叫做Waka（成立那年刚好是世界杯，满世界都是夏奇拉的WakaWaka）。
第二部分：态度和能力
4技艺高超的Scrum Master
不要把Scrum Master当做传统意义上的领导，我是比较提倡团队成员自愿的情况下，轮流做Scrum Master。这个角色完全是一个仆人式服务式的角色。作为一个没有权利的领导，你必须完全依靠你的公平、尽责、情商去管理这个团队。
5态度高于能力
Scrum团队的成员肯定各有各的个性，但是都必须认同和符合这样的Scrum价值观：开放、勇气、专注、尊重、承诺。
6选择团队阵容
建议建立Scrum的团队规约，有点类似于我们上学的时候学校制定的“文明公约”一样。主要是为了让团队一开始就达成共识，特别是涉及到多种族多语种一起工作的情况，Scrum不提倡小团队。而针对人员的构成，作者的建议是：3个dev，1个QA，0.5个精深专家。当然他的这个建议是基于自动化测试的基础上的。而我之前在我的经验中给出的建议是：2：1：1的结构。
而Scrum Master是可以同时服务于多个团队的。
第三部分：规划和保护
7搭建Scrum舞台
为了使得Scrum能顺利进行，Scrum Master需要确保团队稳定，“在一起”的办公环境，支持可持续开发，灌输Scrum价值观。
8制定Sprint计划并全力贯彻执行
针对这个部分我在之前的PlanMeeting文中有做详细的说明，作者和我的观感基本一致：准备Backlog的过程是一个迭代的过程。不需要像之前瀑布开发的模式，将需求规格全部都准备妥当再转阶段到下一个部分“设计”。只需要将前面两个Sprint的Backlog准备妥当即可。
9受累于障碍
首先我们需要区别障碍与阻碍。障碍是指这件事情影响到整个团队的Sprint进展了，比如核心人员被抽调。而阻碍是指某一个具体任务在执行时受阻，但是不影响整个Sprint。
在实际的Sprint过程中，是会遇到形形色色的障碍，作为ScrumMaster需要领导团队去及时确认障碍（站会）、进行诊断、消灭、告知团队、并从中总结（回顾会）。
第四部分：需求的细化
10结构化故事
曾经看过有一本书专门介绍怎么写user story。我只能说，这东西真的是技术活，并不像表面上看得那么简单。而我们的故事一个非常重点的划分标准是：对用户来说有价值。另外我觉得有个很困难的工作，就是：划分的粒度。
11制定完成标准
这里说的是完成标准而不是接收标准。有什么区别？
完成标准是针对整个团队的所有story的，比如：符合接收标准、国际化工作完成、操作手册准备完成等。
接收标准是针对单独的每个Story的验收要求，通过则可以标志为这个可以接收了。
12渐进启示
我们不能指望一次就把事情做完美了，有这样或那样的原因需要让我们去对产出进行调整。在调整的时候要注意需求镀金和范围蔓延的问题。并且对所有的信息都需要记录下来。
所以，看吧，敏捷并不是不需要文档，只是不需要不必要的文档而已。
第五部分：估算
这个我就不详细说了，在之前的PlanMeeting的文中有详细说明。使用比较的方法进行story的估算，可以用扑克牌的方式。
13关于估算
14规划扑克
15转向相对估算
转变从现在开始
第六部分质量
16见鬼！Scrum代码错误
首先我们要明确什么是问题，什么是代码错误。
代码错误是指PO已经接收了Story，这个Story已经Done了，结果发现有代码错误。这个时候，不要reopen，而是另外拿一个Story去进行记录评估。
而问题是发生在Story接收前。
17我们仍然青睐测试人员
我们虽然提倡使用自动化测试，但是测试人员的角色会同时转向一些设计、探索测试、咨询方面的工作，而不是常规功能性测试。
18自动化王国
敏捷Scrum非常提倡自动化测试，没有持续集成和自动化测试就是伪敏捷（有专家如此说）。
第七部分监控和指标
19有意义的指标
书中介绍了四个图来衡量敏捷Scrum的执行情况：
- Sprint燃尽图（我之前的文里做过详细说明）
- 增强型交付燃尽图（将Sprint燃尽图的横坐标由天换成SprintN）
- Sprint干扰（每个Sprint花在非Sprint上的任务时间）
- 补救关注点（并不是做的越多越快越好，我们需要衡量每个Sprint发生的问题占了我们总点数的多少）
20出色的站会
21优化任务板
这两个我之前的文也有，就不详细说明了。
第八部分：回顾会、审核会和风险
这个部分我在之前的文也有详细说明，就不一一说明了。
22Sprint Demo会议的事项
23不可或缺的回顾会
24勇担风险，敢于犯错
我们必须承认不论你采用什么方法，肯定都存在风险。如果犯错，需要做的是总结，而不是推卸责任。
第九部分：经理怎么管理
25看法就是现实
虽然说Scrum敏捷是自下而上的管理，但是任何流程模式的变革都需要得到领导的支持。所以，在整个项目过程中，作为Scrum Master必须保持和项目发起人（领导）的信息沟通，并且尽量让其参与（参观）其中。
26我的上帝我的神
虽然我不是很明白这个捷径的标题的意思，但是作者提出可以建立类似PMO的首席Scrum Master以实现在策略层面的运作。这点倒是可以作为有很多Scrum团队的公司的参考。
27矩阵中的经历“变形记”
毫无疑问的是，敏捷Scrum准备“消灭”项目经理，而职能经理的主要职责也会转变为“导师、师傅”的角色。
第十部分更大的经验和教训
28Scrum推广的推算
当试点项目进行了一段时间后，有什么评判的标准：决定是否应该继续推广Scrum？
有这样几个指标供大家作为参考：
- 团队在30天内的产出
- 目标的明确性，即团队计划交付什么内容
- 团队内部的协作与合作
- 团队在30天内产生的商业价值
- 被浪费的时间，返工或者不需要的工作，没有有效产出的Sprint
- 团队产出的总体质量和“确定性”
29有所追求
其实Scrum团队如果能够良性运行，正如我在开篇的时候提到的，是一种非常美好的体验。不论对项目发起人、产品经理、还是团队成员。
Scrum是很反对殉道式的持续加班，因为这个与Scrum的价值不符。要知道Scrum提倡的是：多少资源多少时间就做多少事情，即由人和时间决定范围。而我们通常的做法是：由时间和范围决定人天，但是人就那么几个人，怎么办？加班呗。
30终极捷径
在整个敏捷Scrum的实施准备和过程中，必须要时常的自我审视、大胆尝试，千万不要固步自封。在Scrum的框架中，所有符合Scrum价值观的尝试都值得去试。
写在最后
作者提出的是他从业多年的经验。我一直觉得敏捷在国内团队很难落地的主要原因，是科普做的不够。就是很多人只是知道一个表象，就去干了，而并不了解敏捷的框架到底是什么，摊子铺的又太大，自己了解的有限，导致最后实施成四不像。当然，文化因素也是一个非常重要的原因。
我会建议，如果你真的有心实施敏捷，最好找个专家从一个试点项目开始，一步一步循序渐进的实施。
小婧是一名行走在产品路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！
