随着 DevOps 提高您组织的敏捷性，项目经理角色需要如何改变？
在讨论 DevOps 带来的根本性变化时，我们倾向于关注几个角色：编写代码的人、供应和支持基础设施的人，以及测试和执行 QA 的人。
然而，随着 DevOps 文化的传播，它对组织其他领域的影响也在扩大。以项目管理为例：DevOps从根本上改变了 IT 团队处理项目的方式，从单一的、多月（或在某些情况下为多年）的计划转变为在软件开发生命周期中追求更高的速度和敏捷性。这也意味着项目经理的变化。
但请不要误会：项目经理在 DevOps 时代仍然很有价值。
Janeiro Digital 的技术架构师 Josh Collins 表示：“对速度和速度以及尖端 DevOps 技术和流程的需求并不能取代了解您将用它们做什么的需求。”“需要强大的项目管理实践才能使项目按计划进行，并明确关注依赖关系。”
但是 PM 确实需要为 DevOps 时代发展，就像开发人员、运维从业人员、安全专家和其他人需要摒弃一些旧习惯以支持更适合数字时代的方式一样。
“PM 不能只专注于甘特图和召集会议，”Datical 的联合创始人兼首席技术官罗伯特·里夫斯说。“PM 需要更多地参与开发和发布过程的实际内容。”
我们询问了 Collins、Reeves 和其他 IT 领导者关于项目经理角色需要如何为 DevOps 发展的见解。他们的建议：
将敏捷应用于项目管理
敏捷不仅仅是一种软件开发方法；这是一种与 DevOps 时代的持续集成/持续交付 (CI/CD) 方法相协调的管理对长期项目的持续需求的方法。
“要将 DevOps 的敏捷性和速度与长期项目相协调，您需要了解敏捷开发的本质，”Reeves 说。“如果你不够敏捷，你就会躲进地下室，然后在几个月——几年，也许——发布后出来。而且你会[犯错误]你无法修复，因为没有变更单就没有机会纠正路线。”
对项目采用微服务方法
正如微服务架构将单一的企业应用程序分解为更细粒度的服务一样，项目也可以拆分为更小的、相互依赖的工作。
CYBRIC 的联合创始人兼首席技术官 Mike Kail 表示：“传统上，项目管理更加单一且由瀑布方法驱动。”“通过 DevOps 转型，PMO 职能需要采用‘微服务’方法，由于子项目较小，因此可以实现更高的速度。”
Reeves 说，这种心态已经融入到 PM 的敏捷方法中。它不仅更适合 DevOps 文化，而且只会带来更好的结果。
“使用敏捷，您可以在每次发布时进行修正。你把那个大版本分解成“有趣”的部分，所以很容易显示结果和获得反馈。即使你非常偏离路线，你也可以纠正，”里夫斯说。
PM 应该是依赖项方面的专家
项目管理的微服务方法包括另一个推论：正如以“做一件事并做好”的方式隔离服务有很多潜在好处一样，了解这些较小的部分如何相互协作也很重要。在这里，PM 需要发挥越来越大的作用。
“随着交付速度的提高，[突出] 依赖关系的重要性也在增加。现在，从上游团队集成某些东西的部署之间的时间更少了，或者从利益相关者那里获得完整需求的时间也更少了，”柯林斯说。“使用 Scrum 方法将工作分解为正确的原子单元，其中它们的依赖关系是众所周知的，这一点至关重要。像看板这样的工具可以让您立即查看失效的依赖项和随后被阻止的工作。”
项目计划需要发展
重新思考 DevOps 的项目管理实践需要改变 PM 传统上的重要角色之一：制定和管理项目计划。
“缩短交付周期的时间表意味着您再也负担不起每周更新一次项目计划的费用，”柯林斯说。“项目经理每天都需要了解情况，在火车离开车站之前解决问题。”
“在 DevOps 时代，IT 项目经理必须进行不同的规划，”Atlassian 的开发人员倡导者 Ian Buchanan 说。“一个常见的误解是只针对时间维度进行调整——例如，只在每两周 sprint 结束时计划一个里程碑。这忽略了速度和质量对 DevOps 的重要性。”
Buchanan 为 PM 提供了以下建议，以支持这种重要的组合：
创建解决计划外工作的综合计划。“这意味着为事件和缺陷 [计划外工作] 等事情创建具有过去表现证据的项目缓冲区。”
确保使用从测试、暂存和部署到真实客户的反馈来重新规划。“可能需要根据新信息频繁添加和/或删除范围。”
寻找方法将大型项目分解为能够使企业获得增量价值的块。这又是 PM 的“微服务方法”，但具有衡量每个工作增量组织价值的附加维度。Buchanan 指出，这不一定是一种新的 PM 实践。“例如，如果您在 100 台服务器上升级操作系统，则每台服务器都是一个增量值。但是，DevOps 为实现这一目标开辟了新途径，例如使用功能标志向一部分用户推出功能。”
PM 应该使用与团队相同的工具
除其他外，DevOps 是关于曾经孤立的角色之间更紧密的协调和协作。这包括（或应该包括）工具链上的标准化。PM 在这里也不例外。
“项目管理需要从实践和工具的角度紧密集成。IT 项目经理需要使用工具来帮助团队管理他们的所有工作，而不仅仅是项目工作。”
“项目管理需要从实践和工具的角度紧密集成，”布坎南说。“IT 项目经理需要使用工具来帮助团队管理他们的所有工作，而不仅仅是项目工作。多年来，软件开发人员一直在使用 Scrum 来做这件事。在 DevOps 世界中，这意味着所有工作都通过一个简单的工作跟踪系统进行，包括 IT 项目工作和事件。这对于确保快速变化的优先事项简单明了至关重要。”
Reeves 指出，DevOps 环境中的 PM 应该能够回答“完成了吗？”这个问题。– 或其近亲，“什么时候完成？”– 零人际互动。如果您需要询问某人，这是一个问题，因为这意味着项目管理功能没有与团队其他成员赖以完成工作的相同工具和跟踪机制正确集成。
“项目管理中最大的挑战是查看单个任务是否按时进行。敏捷冲刺消耗、速度和其他指标准确地告诉您这一点，”里夫斯说。“仅仅询问开发和测试团队是否按计划进行是不够的；项目管理就是在像 JIRA 这样的工具中亲自查看这些指标。发布也是如此。仅查看机票以检查状态是不够的。PM 应该寻找 DevOps 团队为他们提供有关发布进度的仪表板。”
项目经理需要采用 MVP 方法
根据 Kail 的说法，在 DevOps 文化中 PM 的成功需要对“完成的”产品不那么宝贵——项目计划可能仍然有结束日期，但在 CI/CD 世界中，工作永远不会真正完成。而且，正如 Reeves 指出的那样，以敏捷的方式管理项目使您能够定期纠正和修复缺陷，而无需进行大量的变更管理工作或整个新项目。
“[项目经理] 需要采取'完成胜于完美'的观点，并接受[最小可行产品[方法]，”凯尔建议道。“持续衡量对项目重要的所有事情是关键，紧密耦合的协作也是如此。”Kail 指出定期的 Scrum 会议或站会是这样做的一个很好的机制。
PM 头衔可能会随着 DevOps 的发展而发展
在可预见的未来，传统的 IT 项目经理角色似乎不太可能消失。但是随着 DevOps 组织的成熟，很可能 PM 的职责和技能与其他职位和角色融合在一起，就像DevOps 工作将继续变化一样。
相关内容
DevOps 需要抛弃旧的 IT 领导理念
“虽然 PM 的技能和经验可以为任何团队带来价值，但这个名字对于软件来说可能已经过时了。DevOps 将重点放在流程上——价值流中的连续工作循环，”布坎南说。“PMBOK建议的那种通用实践被高度依赖自动化的高度专业化技术所取代。越来越多的项目管理职能被重组为 Scrum 主管和产品负责人等角色。”