敏捷开发:做一个合格的Scrum Master
2017-09-04 23:06
288 查看
转载: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 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自己进行管理并最终使得列表中的每一问题得到及时处理。
在每个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中每个人都能明确了解最新的进展与形势;
遇到问题,应对事不对人。
关于质量的管理,我想其重要性不言而喻。质量是决定了产品的命运。那么如何把关质量了。在敏捷实践中,如下的经验可供参考:
1)欲速则不达。不应过于强调速度,应保持合理的开发节奏,才会使得产品质量具有一定的保障。Scrum流程在每个sprint应统一完整,使得Team形成习惯,最终达到良好的开发节奏。
2)制定coding style,并坚持代码审查。代码的规范非常重要,好的代码可以提高整体团队的开发与沟通的效率。好的代码会说话。代码审查可以结对完成,只有审查通过,才可以提交代码。可以通过创建pull request来进行代码的审查,通过之后,再merge到代码库中去。
3)写单元测试。单元测试的重要性我想大家都明白,只是很多人觉得写起来痛苦,麻烦,占用开发时间。有了单元测试,你的代码才是经得起考验的代码。
4)冒烟测试。在每天下班之前,停止push代码,然后进行冒烟测试。冒烟测试成功之后,才会下班回家。这是一种很好的方法,它保证了每天功能都是可用的,从而确保了质量。
5)自动化测试。它的好处,不用多说,谁用谁知道:)
6)提早集成,以便频繁获取反馈。这样的好处在于我们可以及时的得到用户的需求反馈,进而能够及早修正。
7)最后,我要强调一句:不要加班,不要加班,不要加班。
先说工具,敏捷开发中,比较传统的跟踪进度,同时使用也非常广泛的一种方式是Story Board(故事版)。这种方式简单直观,非常有效。即使现在已经涌现了很多非常优秀的电子管理工具,许多团队仍然对它情有独钟。近些年一些电子的跟踪进度的srcum工具出现了很多。比较有名的像是jira. 它的使用也非常的简单直观,而且功能非常丰富强大,强烈推荐大家使用。
另外,我们可以通过daily scrum meeting获取到Team每天的工作进展。此时我们可以根据进展进行一些必要的调整。
那么如何有效的进行团队建设呢?
1)放权。敏捷开发的其中的一个重要的特征就是团队自组织。团队自组织的优势就在于,通过放权给团队,让它们自主的思考,设计开发,不对其干预,从而使得团队中每个人具有成就感,进而提高整个团队的积极能动性。
2)打造学习型团队。一个方法就是通过团队内部知识定期分享的方式,使得每个人都能可以学到新的知识,从而逐步使得团队成长。比如每周五的下午4点,可以利用一小时的时间,让团队的成员举办知识讲座。通过这种形式,大家的积极性会变的很高。可以约定分享的内容并非一定是技术方面的,也可以是生活娱乐等,只要大家感兴趣就好。这样做的好处在于不仅提高了团队的技术能力,也使得团队之间能够更轻松愉快的交流,从而提升团队的凝聚力,战斗力。
3)最后,提高团队最有效的一个方法,那就是一个字:吃;)这是拉拢吃货们的大好时机。当然这个需要经费,不过方法总会有的,你懂的;)
作者:Ifdef_Max
链接: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
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
相关文章推荐
- 敏捷开发:做一个合格的Scrum Master
- 敏捷开发:做一个合格的Scrum Master
- 使用jira的sprint面板进行敏捷开发——scrum master笔记(待完善)
- 敏捷开发之Scrum扫盲篇
- 敏捷软件开发模型--SCRUM
- Scrum敏捷开发实践之有道云笔记
- 敏捷教练(Scrum Master)的26个成功特质
- SCRUM敏捷团队开发体会
- 敏捷开发之Scrum扫盲篇
- 瀑布式开发、迭代开发、敏捷开发、XP与SCRUM的区别
- Scrum敏捷开发实践
- 敏捷开发之Scrum扫盲篇
- 敏捷开发之Scrum扫盲篇
- SCRUM:敏捷软件开发模型
- [转载]敏捷开发之Scrum扫盲篇
- 敏捷开发 与 Scrum
- 敏捷软件开发模型--SCRUM
- 敏捷软件开发模型Scrum通俗讲义
- [转]敏捷软件开发--scrum
- 敏捷开发之Scrum扫盲篇