敏捷团队中的角色 agile role
Contents
‘敏捷团队中的角色 agile role’
在ThoughtWorks一个典型的敏捷团队中，大致有四种不同角色: 项目经理、业务分析师、开发工程师、测试工程师。同时，根据项目不同可能还需要: 迭代经理，美术设计师、数据库工程师、系统工程师、交互设计师等不同人员。虽然在项目中不同的人需要确定一个角色，并担负相应的责任，但在ThoughtWorks内部，人与人之间是完全平等没有级别区分的。公司这种平等的文化，使得人与人之间的交流不会因为等级差距而丧失。同时，公司鼓励每个人向其感兴趣的其他领域发展，成为综合性人才。例如某个人现在是开发人员，但他也可以通过帮助项目经理做一些辅助工作，来学习项目管理方法，从而最终成为独当一面的项目经理。
以前公司同事写过一篇团队角色定义的文章: http://news.csdn.net/n/20060429/89961.html， 补完一些。
- Project Manager
作为团队的精神支柱存在。与团队的每个人进行必要的沟通以保障项目成员的士气和稳定性。
维持开发秩序，保障团队间交流的效率和效果，负责主持必要的活动
消除外部干扰，负责与客户进行协调和协作。管理来自与客户的scope变更
跟踪团队的开发效率，维持开发速率，进行适当调整以保证开发的顺利进行
管理项目风险，维护项目风险日志，识别风险并采取措施防治风险
负责最终的项目交付成功
- Business Aanlyst
需求获取与管理，与客户持续交流获取新的需求，并保持良好的客户关系。管理需求的优先级。
保障下一个迭代需要开发的需求能够预备到位。提前准备好需要的Story卡片，在Iteration Kickoff会议解释每个Story的具体需求给Developer
主持必要的会议，例如Iteration Kickoff和需求的评估活动
对需求进行初步的功能验收，保证功能的交付符合原始需求
- Developer/Architect:
了解系统业务和需求，设计和演进系统整体架构，能够做出适当的技术决策
编码，并对系统的每行代码负责，保持代码的干净，保持较高的测试覆盖率
维护项目基础设施如持续集成服务器、版本控制服务器等
评估需求，并在开发完成后演示开发的需求
- Quality Assurance
负责了解需求并编写需求验收条件，负责制定测试计划
负责测试开发人员完成的需求，并报告错误
负责对软件进行性能、压力、容量、负载测试等，负责项目的手工功能测试和发布测试
- Iteration Manager - 小团队多由项目经理或分析师兼任
负责项目过程的顺利进行，协调项目资源
主持各种迭代会议，如Standup和Retrospective
负责跟踪需求的状态
负责项目的其他日常事务
- User Interaction Designer -多和分析师为同一人
在项目初期参与前期需求的收集，提出可行的交互设计方案，保证软件的可用性
建立和维护Lo-fi prototype，负责指导项目的界面开发原则
进行用户测试，持续改进系统的可用性
- Database Administrator
维护软件所需的数据库，定期进行数据备份
了解数据库重构和演化方法，负责维持数据库的每一条更新脚本
- System Engineer/Webmaster
维护软件所需的各种硬件和网络系统
了解敏捷开发中的发布过程，保证每次迭代发布的实施
- Art Designer - 一般团队最缺少优秀的Art Designer，了解敏捷的Art Designer更甚
了解项目的远景和规划，了解迭代方法，应用增量式美术设计方法
了解软件的交互设计，能够设计出可用性良好的系统
有一类角色，在敏捷团队中至关重要，不得不重视起来的，就是Customer。
- Customer
理解迭代开发的过程，与团队进行频繁和和谐的交流，参与团队的各种必要的活动如Showcase
理解需求和排序需求的优先级
验收需求，并及时的提出反馈
我经常说，分类学毫无用处，因为很多时候分类无法cover到所有的情况，尤其是两者皆有的时候。我在项目中曾经同时担任过BA/QA/IM，这些角色的职责都是我应该了解的。同时，有些职责，例如随时发现和识别项目中的风险，保证尽最大努力完成任务，主动交流，遇到难以完成的任务及时尽早告诉相关人员等，是每个角色都应当承担的。
为了项目的成功，尽可能多的做一些事情，对个人和对项目都是有利的。
| 作者 Adam Pahlevi ，译者 刘嘉洋 发布于 2017年2月21日. 估计阅读时间: 不到一分钟 | 讨论分享到: 微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单
本文要点
产品负责人在领导敏捷、scrum团队中扮演着同等重要的角色。
尽管很多公司宣称自己规范化地使用敏捷，但敏捷实际上一直是被误解的。
产品负责人负责整个产品，而不仅仅负责功能、特性或是文档。
产品负责人和产品经理可能大不相同。然而，根据scrum guide所述，scrum团队根本没有产品经理，所以可能需要像对待利益相关者一样对待产品经理。
产品负责人是服务型领导。
软件开发一直以来都是一项花费较多且存在风险的业务。Standish Group在其Chaos Manifesto 2013中指出在调查期间，不到三分之一的项目按时且按预算成功完成。在2015年，Standish Group一项研究的结果也显示了相同的数字，也就是说只有29%的项目被认为是成功的。这是什么造成的呢？
在业务发展迅猛的世界里，不可否认的是，每家企业都需要优秀的产品负责人。产品负责人负责控制混乱，管理风险，提前思考，扭转中断，解决利益相关者之间的冲突，并为他们支持的团队提供明确的方向。
从2001年以来，敏捷作为传统瀑布方法的替代方法出现，瀑布方法已被证明很难在现代软件工程中实施。但是，敏捷一直是被误解的。
许多敏捷方法的新手试图通过将敏捷和瀑布方法结合，删除某些敏捷实践来实施，但他们却认为自己成功实施了敏捷方法。对于敏捷的常见误解之一是产品负责人在团队中扮演的角色，这也是本文的主题。
所以产品负责人的存在意义是什么？为什么会有这样一个职位存在？
谁是产品负责人 (PO) ？
简单来说，产品负责人就是拥有产品的人。他负责的是产品，不仅仅是功能、特性或是文档，他与整个产品相关。产品负责人是敏捷团队的决策者。用Midtrans公司CEO Ryu Kawano Suliawan的话来说: “产品负责人就相当于小型CEO。“他或她通过指导开发团队产出最大、最好的结果，对管理的产品的成功负最大责任。
产品负责人:
在产品积压列表中创建可以理解的、可行的故事。
根据优先级调整产品积压列表中的故事完成顺序，以最好地实现设定的目标。
优化并最大化scrum团队的输出。
通过尽可能整理清楚团队内外事物来管理混乱。
帮助团队计划迭代。
参加所有scrum会议，尤其是站会和回顾会议。
为产品定义验收标准和/或关键性能指标。
服务型领导是成为优秀的产品负责人需要扮演的关键角色。
他们甚至没有强制要求下个sprint要完成多少故事的权力。
他有维护sprint的权力。所以在sprint中，产品负责人可以在和工程师团队协商之后，决定从当前部署计划中移除故事。产品负责人是团队中唯一决定什么可以得到部署的人。比如说，如果这个功能需要其他团队的工作优先完成后才能开始处理，而其他团队还在处理这个功能，那么就理应不把这个功能包括进去。再举个例子，比如说一个功能所依赖的第三方产品还没实现，那也应该排除出去。
| 作者 Adam Pahlevi ，译者 刘嘉洋 发布于 2017年2月21日. 估计阅读时间: 不到一分钟 | 讨论分享到: 微博微信FacebookTwitter有道云笔记邮件分享
稍后阅读
我的阅读清单
本文要点
产品负责人在领导敏捷、scrum团队中扮演着同等重要的角色。
尽管很多公司宣称自己规范化地使用敏捷，但敏捷实际上一直是被误解的。
产品负责人负责整个产品，而不仅仅负责功能、特性或是文档。
产品负责人和产品经理可能大不相同。然而，根据scrum guide所述，scrum团队根本没有产品经理，所以可能需要像对待利益相关者一样对待产品经理。
产品负责人是服务型领导。
软件开发一直以来都是一项花费较多且存在风险的业务。Standish Group在其Chaos Manifesto 2013中指出在调查期间，不到三分之一的项目按时且按预算成功完成。在2015年，Standish Group一项研究的结果也显示了相同的数字，也就是说只有29%的项目被认为是成功的。这是什么造成的呢？
在业务发展迅猛的世界里，不可否认的是，每家企业都需要优秀的产品负责人。产品负责人负责控制混乱，管理风险，提前思考，扭转中断，解决利益相关者之间的冲突，并为他们支持的团队提供明确的方向。
从2001年以来，敏捷作为传统瀑布方法的替代方法出现，瀑布方法已被证明很难在现代软件工程中实施。但是，敏捷一直是被误解的。
许多敏捷方法的新手试图通过将敏捷和瀑布方法结合，删除某些敏捷实践来实施，但他们却认为自己成功实施了敏捷方法。对于敏捷的常见误解之一是产品负责人在团队中扮演的角色，这也是本文的主题。
所以产品负责人的存在意义是什么？为什么会有这样一个职位存在？
简单来说，产品负责人就是拥有产品的人。他负责的是产品，不仅仅是功能、特性或是文档，他与整个产品相关。产品负责人是敏捷团队的决策者。用Midtrans公司CEO Ryu Kawano Suliawan的话来说: “产品负责人就相当于小型CEO。“他或她通过指导开发团队产出最大、最好的结果，对管理的产品的成功负最大责任。
产品负责人至少要完成这些任务:
在产品积压列表中创建可以理解的、可行的故事。
根据优先级调整产品积压列表中的故事完成顺序，以最好地实现设定的目标。
优化并最大化scrum团队的输出。
通过尽可能整理清楚团队内外事物来管理混乱。
帮助团队计划迭代。
参加所有scrum会议，尤其是站会和回顾会议。
为产品定义验收标准和/或关键性能指标。
产品负责人也可以选择完成通常由产品经理完成的任务。因为不是所有公司都同时拥有产品负责人和产品经理。
产品负责人职位描述中最重要的方面是，管理混乱。
产品负责人需要完成的重要任务
了解业务和团队
作为产品负责人，对于公司的业务和团队本身必须有深入的了解。因此，当需要修改一些业务需求或是对产品有新的改进的时候，要询问产品负责人完成这样事情的可能性，提供的解决方案是否能改善整体体验，比如是否可以帮助缩短时间等等，产品负责人还需要给出如何最好地解决问题的建议或方法。
做团队和利益相关者之间的桥梁
产品负责人最主要的工作是帮助团队和业务利益相关者直接沟通。在联系所有相关人员方面，他需要起到如虎添翼的作用。因此，产品负责人扮演敏捷团队中利益相关者的代理人是非常常见的。
然而，准确来说利益相关者扮演了什么角色呢？产品负责人可以代理利益相关者的这些角色:
管理角色
相关领域专家
终端用户
评估审计员
支持团队
其他相关的产品负责人角色
维护并准备积压列表
只要有产品，就有积压列表。在Agile lingo中，积压列表只是简单的待办事项。列表中的每一项都叫一个故事。每个故事都有类型，它可能只是零星事项，也可能是需要开发的功能。每个故事通过估计其难度 (估计工作在sprint计划阶段由工程师完成) 来"规划大小”，同样重要的是需要详细描述故事就绪阶段和完成阶段的标准。
在工程师可以开始处理故事之前，故事必须先放到积压列表中，并在sprint计划活动中被选为这个sprint的积压故事。因此，积压列表的优先级选择必须权衡以下方面:
客户价值 (解决正确的问题)
业务价值 (产生的收益)
技术价值 (可以促进学习，减少风险，有牢靠的解决方案和智能工作流)
质量价值 (缓解风险)
同样值得注意的是，利益相关者不应该强迫产品负责人承担故事。产品负责人必须充分评估故事，了解将故事包含在迭代中的风险。
设置并维护sprint
如果你会说: “嗯好的，我们还有这么多故事要处理，但我们只剩下四个月了。所以我希望你们在这次sprint结束能完成四分之一的产品积压列表。"，那你就不是很好的服务型领导，而服务型领导是成为优秀的产品负责人需要扮演的关键角色。
重要的是要记住产品负责人永远不能在团队的讨论中表现出他或她的话语是最重要的、最值得关注的。他们甚至没有强制要求下个sprint要完成多少故事的权力。
然而，他有维护sprint的权力。所以在sprint中，产品负责人可以在和工程师团队协商之后，决定从当前部署计划中移除故事。产品负责人是团队中唯一决定什么可以得到部署的人。
比如说，如果这个功能需要其他团队的工作优先完成后才能开始处理，而其他团队还在处理这个功能，那么就理应不把这个功能包括进去。再举个例子，比如说一个功能所依赖的第三方产品还没实现，那也应该排除出去。
其他产品负责人经常要做的事
设计关键绩效指标 (KPI)
利益相关者想知道产品取得了怎么样的成功。是否表现良好？这个产品如何帮助使用它的人？使用起来是否足够快？
产品负责人必须提供可测量的KPIs列表，通过列表可以判断产品是否良好运行。产品负责人监控这些KPIs，并通过它们提供的反馈调整积压列表。
测试并验证需要部署的故事
一旦工程师将一个故事标记为准备测试，产品负责人就要负起该产品各方面被彻底测试的责任。他们需要在将该功能添加到部署包之前，努力找出不合常规的、奇异的问题和错误。他们需要和测试工程师以及用户代表一起工作，来保障测试。
保障有凝聚力的工作环境
嗯，很明显，她需要保证每个人正常工作，保证scrum master有所帮助，保证工程师各司其职，保证团队是有凝聚力的和愉快的。这并非易事，而是必须有人认真处理并安排的工作。如果失败，团队也会失败，然后会一片混乱，失去了原来的工作效率。
发表发布日志
好的，那在每次部署之后，哪些功能得到了部署？发生了什么改变？新构建的产品会对客户和业务产生什么影响？如果可能的话，它怎么帮助事情变得更好、更快，并让工作变得更少？
建议产品负责人发表"发布日志”，或是简单地在公司内部或向外界发表发布的简单介绍。他可以使用Slack、Email或whatnots发布合适的发布说明。
分享产品会议
产品负责人可能需要做demo演示产品如何运作。这就是为什么产品负责人要先自己测试产品，了解其局限性以及预期的性能等等是非常重要的。
招聘
团队的产品规模可能会扩大。在这种情况下，产品负责人需要和人力资源部门联络，咨询他想给团队添加一名新成员的事宜。
然而，决定是否要招聘某人不是由产品负责人决定的，而是由工程副总裁、CTO或是其他类似角色决定的。产品负责人还要保证万一有人离开团队，团队工作不会中断，团队还能正常运作。
产品负责人 vs 产品经理
印度尼西亚工作目录网站Karir.com的CTO Sky Kok说，产品经理是更加以市场为中心的角色。他们通常和市场团队紧密合作，有时候直接和首席市场官合作。
传统上，产品经理负责的工作包括:
通过找寻新的方法提升产品整体体验开发业务案例。
认真倾听，扮演市场和客户的专家。不要负责寻找解决方案，因为这是工程团队的工作。
定义产品年度或季度的路线图。
管理产品的定价、销售和营销。
获取、购买或建立决策。
但是在Scrum Guide中没有提到产品经理，因此在采纳scrum的组织里，产品经理的角色可能更偏向于利益相关者。实际上，采纳scrum的团队可能根本没有产品经理这个职位，因此这个角色和解决方案部门、业务开发部门和产品负责人有所区别
Author -
LastMod 2013-02-27