敏捷项目经理
作为一名经理，当我第一次开始学习敏捷开发时，我对管理和 （或管理自己） 敏捷团队和项目的模糊方式感到困惑 ，并且对管理人员和管理人员的消极态度感到沮丧和失望。
调和项目管理和敏捷的尝试尚未解决这些问题。 PMI-ACP在确保您了解敏捷原则和方法（主要是Scrum和XP，以及一些看板和精益）方面做得很好，但是对于敏捷项目经理的工作或目的却含糊其词令人惊讶。 甚至像软件项目经理的《通往敏捷的桥梁》一书，旨在帮助将PMI的项目管理实践与敏捷联系起来的书，也未能为敏捷世界中的经理或项目经理提出有意义的工作。
在Scrum中（这就是大多数人今天所说的敏捷的意思），项目经理根本没有位置： 管理职责分散在产品所有者，Scrum主管和开发团队中。
我们发现，项目经理的角色在复杂的创造性工作中适得其反。 以项目计划为代表的项目经理的思想，将项目中其他所有人的创造力和智慧限制在计划中，而不是使所有人的智慧都能最好地解决问题。
在Scrum中，我们删除了项目经理。 产品负责人或客户通过每月一次告诉开发团队需要什么来提供及时的计划。 开发团队进行自我管理，将产品所有者想要的尽可能多的东西转化为可用的产品。 结果是高生产力，创造力和忠诚的客户。
我们已经用Scrum Master代替了项目经理，Scrum Master管理流程并帮助项目和组织过渡到敏捷实践。
Ken Schwaber， 敏捷性和PMI ，2011年
项目经理可以选择成为Scrum主管（如果他们可以接受仆人的领导角色并学会成为有效的敏捷教练 ，并且团队可以接受他们）或产品所有者（如果他们具有足够的领域知识和其他知识）技能），或在其他地方找到其他工作。
项目经理，产品负责人
产品负责人是指挥与控制职位， 负责开发项目的“什么”部分 。 辛苦了 产品负责人拥有需要构建的内容的定义，决定要完成的工作和顺序，批准范围的更改并进行范围/进度/成本的权衡，并确定何时完成工作。 产品负责人管理和代表业务涉众，并确保满足业务需求。 产品负责人取代项目经理，成为对项目成功负最大责任的人（“ th之气 ”）。
但是他们并不能控制团队的工作，谁来工作或如何做的技术细节。 这是由团队决定的。
一些项目经理可能具有领域知识和业务经验，分析技能以及客户组织中的联系才能满足此角色的要求。 但是，它也可能由缺席的业务经理或赞助商扮演，由客户代理人 ，业务分析师或团队中没有组织真正责任或权力的其他人作为后盾，从而可能造成严重的项目风险和管理问题。 一些组织试图通过在两个人（项目经理和业务分析师）之间共享角色来解决此问题 ，他们共同工作以处理产品负责人的所有职责。
项目经理担任Scrum Master
对于项目经理来说，似乎最自然的途径就是成为团队的Scrum Master ，尽管在项目经理是否可以有效地（并被接受）为Scrum Master以及他们是否愿意接受变更方面存在很多分歧 。责任和权限，并愿意改变他们与团队和组织其他成员的合作方式。
Scrum Master是“流程所有者”和教练， 而不是项目经理 。 他们帮助团队以及产品负责人了解如何在敏捷流程框架中工作，他们的角色和职责是什么，建立并指导会议和评审，以及通过变化和冲突来指导团队成员。
Scrum Master的工作是一名仆人领导 ，一名（不错的）过程警察，一名秘书和一名上班族。 支持团队和产品负责人的人会为他们“运送食物和水”，试图保护他们免受项目外部的影响，并帮助他们解决问题。 但是Scrum Master 对项目或团队没有直接的权限 ，也不能为他们做出决定，因为敏捷团队应该具有自我指导，自我组织和自我管理的能力。
当然，事情并不是这样开始的。 任何人都必须在塔克曼团队发展的四个阶段中努力工作：形成-存储-规范-执行。 只有当他们到达最后阶段时，团队才能有效地管理自己。 同时，某些人（Scrum Master / Coach）必须帮助团队做出自己还没有准备好做出的决定。 团队要花很长时间才能使人们学会足够信任彼此和组织。 而且可能不会持续很长时间，直到团队无法控制的某些因素使他们退缩：关键人物离开或加入团队，领导层的变化，对项目的冲击，例如方向的重大变化或预算的削减。 然后，需要将它们重新带回高性能状态。
开始时，指导团队并帮助他们可能是一项全职工作 。 团队聚在一起并了解过程之后？ 没那么多。 这就是为什么Scrum Master有时由开发人员兼职，有时甚至在开发团队中的人员 之间轮换的原因 。
但是，即使团队表现出色，管理敏捷项目也要比开会，买比萨饼和尽量避开障碍更多。 我了解到，敏捷并不能使经理的工作消失。 如果有的话，它会扩展它。
前期管理
首先，在项目开始时-必须在迭代零之前完成所有工作。 确定利益相关者。 保护章程。 谈判项目预算和合同条款。 了解和引导组织的官僚机构。 找出治理和合规性要求和约束，以及PMO的需求。 与人力资源，直线经理和职能经理合作，以组建团队，寻找和雇用优秀人员，为其提供工作空间以及所需的工具。 加强合作伙伴，供应商和承包商的联系。 合同和许可等法律内容。
产品负责人可能会做某些工作-但他们做不到。
管理起来
然后，有一些工作需要在团队外部进行管理。
敏捷开发是孤立的，隔离的和内向的。 团队不受外界的影响，因此他们可以集中精力共同构建要素。 但是外面的世界太重要了，不容忽视。 每个开发项目所涉及的不仅仅是设计和构建软件，通常还远远超过开发本身的工作。 每个项目，甚至是一个小项目，都具有依赖性和移交，需要与其他地方的其他团队，其他项目，团队外部的专家，客户，合作伙伴和供应商进行协调。 需要进行前瞻性计划，设置和跟踪停滞日期，定义和维护界面以及集成点和着陆区。
敏捷团队Swift行动并Swift响应变化。 这些更改可能会对团队外部，客户，其他团队和其他项目，组织的其他部分，供应商和合作伙伴产生影响。 您可以尝试使用Scrum of Scrums在一定程度上与其他敏捷团队进行协调，但是仍然有人必须跟踪依赖关系，变更和延迟并安排交接。
根据签约模型以及您的合规性或治理环境，正式变更控制也可能不会消失，至少对于实质性变更而言也是如此。 即使产品负责人和团队感到高兴，仍然有人必须照顾文书工作，以遵守法规可追溯性要求并遵守合同条款。
很多人需要了解开发团队之外的项目中正在发生的事情，尤其是在大型组织中的大型项目中。 与团队外部和公司外部的人员进行外部沟通。 与管理层和赞助商进行向上沟通，使他们了解情况并保持合作。 任务板，燃尽物和墙上可见的大图表可能对团队来说很好，但是高层管理人员，PMO和其他利益相关者还需要更多，他们需要了解项目，计划或业务的整体背景下的开发状态改变主动权。
还有成本管理和采购。 预测，跟踪和管理成本，尤其是开发人工成本以外的成本。 合同和许可需要注意。 需要购买东西。 需要支付账单。
管理风险
正确完成Scrum（仔细缝制XP工程实践 ）可以有效地控制许多常见的软件开发风险 ：范围，进度，需求规格，技术风险。 但是还有其他风险需要管理，这些风险来自团队外部：计划风险，政治风险，合作伙伴风险和其他后勤风险，集成风险，数据质量风险，运营风险，安全风险，财务风险，法律风险，战略风险。
有目的地，Scrum有许多空白，漏洞和裸露的地方，您需要使用这些最佳实践来进行风险管理等最佳实践。
当团队以及产品负责人和Scrum Master专注于优先级和交付功能以及解决技术问题时，某人必须进一步寻找风险，将其带到团队中，并管理不受团队控制的风险。
管理最终游戏
就像在项目开始时一样，当项目接近尾声时 ，有人需要照顾最终批准和合同验收，协调与其他系统以及与客户和合作伙伴的集成，数据设置以及清理和转换，文档和训练。 设置运营基础架构，设施和硬件以及连接性，运行系统所需的人员以及流程和工具。 设置支持功能。 打包和部署，推出计划和回滚计划，移交给客户或操作人员，社区建设和营销以及成功启动所需的其他条件。 没关系，帮助对新系统可能需要的业务工作流和业务流程进行任何更改。
项目管理不会在敏捷中消失
任何项目中都需要解决许多管理问题。 敏捷在团队中分散了一些管理职责，但并没有消除管理问题。 项目无法扩展，团队无法成功，除非有人（项目经理或PMO或拥有所需权限和技能的其他人）来照顾他们。
翻译自: https://www.javacodegeeks.com/2014/04/agile-whats-a-manager-to-do.html
敏捷项目经理