敏捷开发：做一个合格的Scrum Master

转载：http://www.jianshu.com/p/72a5c42cec8b

在Scrum敏捷开发中有三种主要的角色：Product Owner（产品负责人，简称"PO"）; Scrum Master（敏捷教练）; Team（团队）。其中，Scrum Master是其重要的角色之一。那么今天我们就来探讨一下如何做一个合格的Scrum Master。

Scrum Master在许多的项目开发中被视为项目经理，这其实是个误区。同时我也经常看到有人主张将Scrum Master与项目经理完全区分，对于此我也不太同意。在我看来Scrum Master虽然并非项目经理，但是仍然肩负着很多项目经理的职能。那么Scrum Master的职责究竟是什么呢？该怎样做才能成为一名合格的Scrum Master呢？以下六项，供您参考。如有不妥之处，欢迎探讨；）

管理Scrum流程

---

这是Scrum Master最核心的职责，也是Scrum Master区别于项目经理的最显著的特征。Scrum Master需要维护每个sprint的流程，确保每个sprint能够顺利的实施以及完成。

首先，Scrum Master负责主持召开sprint期间的每一个会议，包括sprint plan meeting， daily scrum meeting， sprint grooming meeting，sprint review meeting以及sprint retrospective meeting。

另外，Scrum Master还需要帮助PO建立product backlog与sprint backlog，并确立其中每个story的优先级。

最后，Scrum Master还需要帮助Team清除在开发的过程中遇到的障碍。Scrum Master应该有一个block list用来记录Team在开发中遇到的问题障碍，由Scrum Master自己进行管理并最终使得列表中的每一问题得到及时处理。

保护团队

---

Scrum Master应该最大限度的保护Team，以确保Team不会被外界，尤其是PO干扰。那么Scrum Master该如何保护团队呢？Team在什么情况下需要保护呢？

在每个sprint的初期制定计划的时候，Scrum Master应合理的根据Team的工作能力以及过往经验，承诺工作量。不要盲目乐观的给PO承诺过量的工作。我就遇到过有的Scrum Master可能是对于Team的能力估计不足，也可能是希望通过承诺更过的工作获取老板的芳心，承诺了太多的工作，结果导致Team在sprint的后期连续加班，致使Team的效率严重降低。同时由于时间的匆忙，急于交付，导致了项目的质量很低，最终形成了恶性循环。一个好的Scrum Master在这个时候是应该要懂得如何与PO“周旋”，获取合理的工作量。这里的“周旋”并非消极怠工，故意减少Team的工作量，这其实是通过安排合理的工作量来使团队达到最大的工作效率，同时不会伤害Team的积极能动性。这是一个良性的循环。

我们都知道，需求的变更对于每一个开发人员来说都是噩梦，而敏捷诞生的其中的一个很重要的原因就是为了解决这一问题，让开发者拥抱变化。然而在我们采用敏捷开发的项目中，经常可以遇到Product Owner越过Scrum Master，直接找到Team, 对他们指手画脚，发号施令。这个时候，Scrum Master应该像“猛兽”一样将PO“吼开”，以避免Team受到“伤害”。需求改变可以，但是不应该在sprint的过程中干扰Team, 可以在daily scrum meeting或者sprint plan meeting上提出，共商解决方案。我觉得Scrum Master对Team在很多时候都应该有一种“护犊子”的精神。确保Team神圣不可侵犯。

有效沟通

---

很多时候Scrum Master起到了一种“承上启下”的作用。一头面对的PO以及自己的老板，另一头面对的是Team。很容易使人感觉Scrum Master仿佛在夹缝中求生存，容易两边都不讨好。因此，沟通艺术的重要性不言而喻。如何说服PO，使得老板满意，并且让Team开心，这是一门学问。对于此，下面几点可以作为参考：

1. 面向老板：

应定期及时的通报项目的状态与进展，不要等到老板亲自来问，可以通过表格以电子邮件的方式发送。主要汇报进展状态，避免过于细节的内容；
遇到问题，应及时上报，使得问题在出现时就能得到重视，并被及时解决。如果等到截止时间才发布坏消息，那么就给了你的老板对你进行微观管理的机会。

2. 面向Team:

最重要的一点，应以身作则，态度端正；
充分了解Team中每个成员的能力状况，防止出现工作量盲目承诺的问题；
通过daily scrum meeting让Team中每个人都能明确了解最新的进展与形势；
遇到问题，应对事不对人。

把关质量

---

此刻开始，Scrum Master更像是一个项目经理。无论是质量，进度还是团队建设都更像是项目经理的职责。对于Team来讲，这时的Scrum Master不再是那个“保护”我们的人，而变成了那个“收保护费”的大佬。然而，在实际项目中，Scrum Master确实要承担这些职责，只不过有些已经融入到日常的scrum流程中去了。

关于质量的管理，我想其重要性不言而喻。质量是决定了产品的命运。那么如何把关质量了。在敏捷实践中，如下的经验可供参考：

1）欲速则不达。不应过于强调速度，应保持合理的开发节奏，才会使得产品质量具有一定的保障。Scrum流程在每个sprint应统一完整，使得Team形成习惯，最终达到良好的开发节奏。

2）制定coding style，并坚持代码审查。代码的规范非常重要，好的代码可以提高整体团队的开发与沟通的效率。好的代码会说话。代码审查可以结对完成，只有审查通过，才可以提交代码。可以通过创建pull request来进行代码的审查，通过之后，再merge到代码库中去。

3）写单元测试。单元测试的重要性我想大家都明白，只是很多人觉得写起来痛苦，麻烦，占用开发时间。有了单元测试，你的代码才是经得起考验的代码。

4）冒烟测试。在每天下班之前，停止push代码，然后进行冒烟测试。冒烟测试成功之后，才会下班回家。这是一种很好的方法，它保证了每天功能都是可用的，从而确保了质量。

5）自动化测试。它的好处，不用多说，谁用谁知道：）

6）提早集成，以便频繁获取反馈。这样的好处在于我们可以及时的得到用户的需求反馈，进而能够及早修正。

7）最后，我要强调一句：不要加班，不要加班，不要加班。

跟踪进度

---

进度管理是Scrum Master的又一项项目经理职责。对于scrum中进度的监控，我们有很多的方法，也非常有效。

先说工具，敏捷开发中，比较传统的跟踪进度，同时使用也非常广泛的一种方式是Story Board（故事版）。这种方式简单直观，非常有效。即使现在已经涌现了很多非常优秀的电子管理工具，许多团队仍然对它情有独钟。近些年一些电子的跟踪进度的srcum工具出现了很多。比较有名的像是jira. 它的使用也非常的简单直观，而且功能非常丰富强大，强烈推荐大家使用。

另外，我们可以通过daily scrum meeting获取到Team每天的工作进展。此时我们可以根据进展进行一些必要的调整。

团队建设

---

团队建设是项目开发中绝对不容忽视的一环。团队凝聚力如何，直接影响了整个团队的战斗力。因此，建设好团队，是每个Scrum Master的重要使命。

那么如何有效的进行团队建设呢？

1）放权。敏捷开发的其中的一个重要的特征就是团队自组织。团队自组织的优势就在于，通过放权给团队，让它们自主的思考，设计开发，不对其干预，从而使得团队中每个人具有成就感，进而提高整个团队的积极能动性。

2）打造学习型团队。一个方法就是通过团队内部知识定期分享的方式，使得每个人都能可以学到新的知识，从而逐步使得团队成长。比如每周五的下午4点，可以利用一小时的时间，让团队的成员举办知识讲座。通过这种形式，大家的积极性会变的很高。可以约定分享的内容并非一定是技术方面的，也可以是生活娱乐等，只要大家感兴趣就好。这样做的好处在于不仅提高了团队的技术能力，也使得团队之间能够更轻松愉快的交流，从而提升团队的凝聚力，战斗力。

3）最后，提高团队最有效的一个方法，那就是一个字：吃；）这是拉拢吃货们的大好时机。当然这个需要经费，不过方法总会有的，你懂的；）

作者：Ifdef_Max
链接：http://www.jianshu.com/p/72a5c42cec8b
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。