敏捷开发中的PO即Product Owner，产品或业务负责人，即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员，一般可由产品经理担任，也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的，建议由产品经理担任，本身产品经理已经是所有业务的接口人，熟悉业务是其本职工作；如果产品经理和开发、测试团队是两地办公的，如设立的研发中心、外包服务等形式的，建议在开发团队内指定一个人来担任PO，这样产品经理在第一次PRD全体review之后，只需跟这个PO讲解清楚产品逻辑，后续开发和测试当中遇到的问题，都可以咨询PO来得到解决，PO不确定的可以联系产品经理确认，这样可以减少一部分的沟通成本。
敏捷开发中的SM即Scrum Master，字面意思是敏捷专家或者敏捷大师，即熟悉敏捷开发模式及敏捷实施流程的人员，一般可由敏捷团队当中的开发负责人担任，部分能力很强且懂技术的产品经理也可担任这个角色，因涉及到工作量评估和分派等工作，最好都是由技术能力较强的人员担任。
Product Owner（PO）
Product Owner角色定义
确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品ROI（profitability of product）负责。 是维护产品需求清单（ product backlog ）的人，代表利益相关者的利益。
Product Owner工作职责
负责最大化产品以及开发团队工作的价值。主要职责如下：
1、确定产品的功能；
2、决定发布的日期和发布内容；
3、为产品的ROI负责；
4、根据市场价值确定功能优先级；
5、每个sprint中，根据需要调整功能和优先级（每个sprint开始前调整）；
6、接受或拒绝开发团队的工作成果；
7、参与Scrum Planning Meetings（Sprint计划会议），Sprint Review Meeting（Sprint评审会）和 Sprint Retrospective Meeting（Sprint回顾会）
Product Owner在团队中的作用
在junior团队中：主要的需求来源，个人确定需求价值和优先级
在intermediate团队中：多角度的收集需求，和团队成员共同确定需求的价值和优先级
在Senior团队中：和团队成员共同提出和收集需求，共同对产品负责
这里的团队分级主要是指团队的敏捷成熟度，即产品团队实施敏捷开发模式后，对敏捷开发模式的适应程度、接受程度和学习程度。后面会专门介绍团队的评估标准。
一句话总结PO这个角色就是：告诉产品团队要做什么，做功能的先后顺序是怎样的，需求有变动时该如何处理。
Scrum Master（SM）
Scrum Master角色定义
是团队的导师和组织者，与Product Owner紧密合作，及时为团队成员提供帮助。促使team按照scrum方式运行，为Scrum过程负责的人。
Scrum Master并非团队的领导（因为团队是自我组织的），而是一个负责屏蔽外界对开发团队干扰的角色。 Scrum Master是规则的执行者，他是Scrum团队中的服务型领导。
Scrum Master工作职责
确保scrum被理解和正确使用并使得Scrum的收益最大化。主要职责如下：
1、保证团队资源合理利用；
2、保证各个角色及职责良好协作；
3、解决团队开发中的障碍；
4、作为团队和团队外部的接口，协调解决沟通中的问题；
5、保证开发过程按计划进行，组织Scrum Planning Meetings（Sprint计划会议）, Daily Stand-up Meeting（每日站会）, Sprint Review Meeting（Sprint评审会）和 Sprint Retrospective Meeting（Sprint回顾会）。
Scrum Master在团队中的作用
在junior团队中：主导和控制
在intermediate团队中：引导和教导
在Senior团队中：辅导和协助
一句话总结SM这个角色就是：教整个团队怎么做，如何估时，跟进每天进度，风险控制，定期总结，计划排定。
---------------------
作者：SmartBrain
来源：****
原文：https://blog.****.net/Peter_Changyb/article/details/90319032
版权声明：本文为博主原创文章，转载请附上博文链接！
Scurm敏捷开发Master的工作职责
在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
链接：https://www.jianshu.com/p/72a5c42cec8b
为引领、规范和保障公司的健康发展，规范公司各种项目立项、计划、实施、交付的过程管理，使项目能够在计划时间和成本内高质量完成，公司IT产品技术中心、VRO及相关业务负责同事经过讨论与决定，并结合公司业务实际发展的要求，具体内容如下：
- 目的
为规范公司各种项目立项、计划、实施、交付的过程管理，使项目能够在计划时间和成本内高质量完成，特制订此制度。
- 范围
适用于与公司业务发展密切相关，有一定时间周期（通常为2个月及以上）的IT研发项目管理。
- 定义
（1）VRO(Value Realization Office)：价值实现办公室，是对公司项目进行集中协调管理的组织。其主要职能为组织制定项目管理规范和流程、培养项目经理团队、建立项目管理信息系统、协调项目资源，提供项目指导，确保项目按时保质完成。
（2）阿里云效系统：云效是阿里云的一款专门针对项目研发管理的产品。产品涵盖了项目协作域、研发域、测试域以及运维域。企业级一站式DevOps平台，支持公共云、专有云和混合云多种部署形态，通过人工智能、自动化技术的应用提升开发者的研发效能，持续交付有效价值。
（3）用户故事：一件用户通过系统实现他的一个有价值的目标的事，即为一个用户故事。用户故事是从用户角度进行描述的故事。
- 职责
4.1 VRO
Ø 确定公司项目需求、优先级，并组织项目评审；
Ø 审批项目发起人项目概要评审；
Ø 为项目任命项目发起人；
Ø 培养项目团队人员，提升研发能力；
Ø 负责在项目推进受阻时，组织召开会议，协调资源，支持项目经理推进项目；
Ø 确定项目管理制度、标准、工具和最佳实践，并不断完善；
Ø 确定项目绩效考核方法，并实施绩效考核；
Ø 组织项目审计，监督项目管理制度实施；
Ø 每季度向CEO汇报项目的计划和进展；
Ø 管理阿里云效系统投资大盘看板项目概要。
4.2 项目发起人
Ø 与项目干系人合作以获得足够多的信息来编写项目概要；
Ø 在投资组合同步会上向投资管理委员会说明项目概要，并争取获得其批准；
Ø 帮助产品经理细化系统功能特性；
Ø 帮助项目经理获得足够的信息和资源。
4.3 产品经理
Ø 把项目发起人定义的项目概要细化为用户故事，确保它们集成在一起可以实现总体目标；
Ø 编写需求规格说明书；
Ø 向项目组成员说明用户故事，使其充分理解业务需求；
Ø 设定用户故事优先级；
Ø 管理阿里云效系统团队看板用户故事需求内容。
4.4 项目经理
Ø 作为项目成败的第一负责人，对项目进行全面管理，确保项目进度、项目成本和项目质量，承担绩效考核指标；
Ø 过程管理，包括项目需求与方案、项目预算与安排、项目执行与控制（进度、成本、质量）、项目验收与交付，项目成员绩效评估及激励分配等；
Ø 管理阿里云效系统团队看板用户故事生命周期；
Ø 管理项目依赖关系和风险，帮助项目组成员排除障碍。
4.5 项目组成员
Ø 提供准确的数据和信息，贡献经验和观点；
Ø 理解和执行项目决策，按时保质完成项目分配任务；
Ø 识别执行中遇到的问题，并协调组织解决。
4.6 CEO
Ø 批准项目管理制度，项目考核及激励政策；
Ø 对项目推进过程中的关键问题进行决策。
