敏捷迭代开发-管理者指南_敏捷项目管理综合指南

敏捷迭代开发-管理者指南

专注于持续改进，敏捷项目管理颠覆了开发产品和服务的传统线性方式。 组织越来越多地采用敏捷项目管理，因为它利用一系列较短的开发周期来交付功能并不断改进。 这种管理风格允许快速开发，持续集成（CI）和持续交付（CD）。

敏捷的项目管理使跨职能的团队可以处理大量项目，解决问题并在较短的阶段中推进项目。 这使他们可以更快地迭代并提供更频繁的更新。

敏捷方法以增量方式提供更高水平的质量改进，而不必等待分发已完成的项目。 和敏捷项目管理工作。 例如，PWC报告说， 敏捷项目的成功率比传统项目方法高出28％ 。

采用敏捷方法

当引入敏捷方法论时，它遭到了怀疑和抵制。 随着当今创新的快速发展，它已成为公认的标准。 项目管理协会的年度“职业脉搏”调查发现，有71％的组织表示在项目管理中使用敏捷方法 ，无论是完全敏捷的项目还是混合模型。

米其林的菲利普·胡塞尔（Phillippe Husser）在“行业脉搏”报告中说：“我们再也无法承担需要两到五年才能交付的项目。 “在这段时间里，最初的要求已经改变。”

12条敏捷原则

尽管敏捷项目管理与传统项目管理有很大不同，但进行转换并不一定要令人畏惧。 敏捷项目管理依赖于12条指导原则 ，可以帮助您的团队更快地共同前进。

1.客户至上

团队使用敏捷管理的首要原则之一是“最优先考虑的是通过早期和持续交付来满足客户需求 ”。 这意味着，最重要的是，团队致力于为客户解决问题，而不是构建酷炫但难以使用的功能和工具。 从客户的角度来看，这种策略鼓励所有产品决策都由数据驱动。 这可能意味着许多团队成员会定期与最终用户进行互动（包括访谈），或者有权访问显示使用情况的数据。

敏捷方法极大地减少了从项目启动到客户反馈的时间。 随着客户需求或他们与产品互动的方式的变化，团队可以灵活地响应这些需求以构建以客户为中心的技术。 此过程创建了一个反馈环，用于持续改进。

2.唯一不变的是变化

尽管更改需求看似激进，但敏捷方法可以更改需求，甚至可以在开发后期进行。

该原则与第一个原则紧密相关。 如果团队的最终目标是最好地为最终用户提供服务，则团队必须具有灵活性并能够根据客户的行为和需求进行更改。 灵活性还使组织能够利用新兴技术或新趋势来获得竞争优势。

3.交付速度更快

敏捷不鼓励年度或半年度产品更新和补丁，而是在发现需求或改善运营时鼓励定期更新。 等待进行重大发布可能会使该技术膨胀，并导致无法预料的问题，无论已对其进行了多少测试。

敏捷鼓励团队在短时间内频繁交付工作软件。 更小，更频繁的发行允许对技术进行定期更新而不会带来巨大风险。 如果出现故障并且无法正常工作，则需要稍稍后退。 敏捷方法还鼓励自动化以帮助不断推出更新。

4.建立跨职能团队

敏捷方法论认为，最深思熟虑，最实用和最畅销的技术需要跨职能的团队朝着共同的目标努力。 DevOps（开发和运营）和DevSecOps（开发，安全和运营）团队协同工作，而不是线性发展。 这使业务团队，开发人员，质量保证和其他重要团队可以从头到尾一起工作。

这种观点上的改变意味着所有团队都在比赛中占有一席之地，这使得将错误或低质量的技术推向下一个团队变得更加困难。 每个人都不会为自己找借口，而是为共同的目标而共同努力。

为了使跨职能团队能够工作，需要高层的参与。 由于缺乏高层管理人员的参与，三分之一的项目失败了 。

5.鼓励独立工作

敏捷管理的另一个原则是，人们可以在从事项目时扩展自己的工作并学习新技能。 由于团队是跨职能的，因此个人面临不同的能力，角色和风格。 这种接触会造就更全面的工人，他们可以从不同的角度来解决问题。

敏捷团队通常是自我指导的。 它需要正确的团队并有针对性的目标。

敏捷使经理能够（按照敏捷宣言）“围绕有积极性的人建立项目。为他们提供所需的环境和支持，并信任他们能够完成工作。”

6.亲自见面

尽管在增加远程工作人员的时代这个原则可能看起来很奇怪，但是敏捷管理确实鼓励了面对面的会议。 这是因为许多管理人员认为，最有效的信息传递方法是面对面的交谈。

对于非远程团队，这可能意味着让不同的团队成员坐在一起，甚至创建不同小组的作战室，以更有效地进行交流。 主机代管意味着更快的交互。 彼此交谈，而不是等待电子邮件或电话被退回。

对于远程团队，仍然可以实现此目标。 通过使用Slack或Zoom之类的工具，您可以模拟面对面的会议并快速找到正确的答案。

7.上线

组织可能有几种方法来记录计划并根据目标衡量成功。 但是，衡量团队在敏捷方面的成功的最好方法之一是通过可运行的软件。 敏捷团队不会看未来的预测来了解他们的表现。 相反，实时代码是进度的主要衡量标准。

计划和文档编制非常出色，但是如果没有软件可以完成工作，那么其他所有内容都是无关紧要的。

8.可持续发展

尽管敏捷开发鼓励快速发布，但团队开发可持续且可扩展的代码仍然至关重要。 因为第一原则是为客户服务，所以团队必须考虑创建可以长期使用的技术和工具。

还应该以支持个人的方式管理团队。 虽然在短时间内可能需要较长时间，但保持整个工作与生活的平衡对于避免倦怠至关重要。

9.技术卓越

敏捷方法论还认为，团队的每个成员都有责任持续关注技术卓越。 即使没有技术能力的人员也应该进行质量检查，并确保以简单易用的方式进行构建。 虽然风吹草动可能不错，但敏捷方法论认为，好的设计可以增强敏捷性。

此外，代码应随着每次迭代而改进。 每个人都有责任在整个过程中提供清晰的代码或说明，而不仅仅是在最后。

10.简化

敏捷团队认为简单至关重要。 敏捷圈子里有句谚语：“最大化未完成的工作量”。 消除并自动执行任何操作，并构建对于最终用户而言直接的工具。

11.让团队自我组织

“最佳的体系结构，需求和设计来自自组织团队，”敏捷宣言说。 尽管需要管理来进行监督，但最好的敏捷团队会自己确定需要做什么以及如何完成。

12.花一些时间进行反思

最好的团队会定期思考如何提高效率，然后进行相应调整。

敏捷团队进行内省，并评估其效率。 当他们发现更好的方法时，他们就会进化。

敏捷与自动化一起发展

敏捷管理对团队和最终用户都有很多好处。 虽然已经确立了基本原则（如敏捷的本质），但该策略始终在发展。 通过利用不同类型的自动化，敏捷项目管理正在不断发展。

例如，IT团队正在利用IT流程自动化来管理过去占用大量人力资源的重复性任务 。 这使团队可以更高效地工作，并专注于更大范围，而不是监视，管理和维护软件，硬件，基础架构和云服务。

您的流程自动化规则可以有效处理的任务越多，您就能越快地进行迭代，测试和改进。

入门

总体而言，敏捷项目管理带来许多好处。 它为团队提供了一种更快的方式，以更少的错误提供更好的产品。 它可以鼓励不同的团队一起工作，互相学习。 它促进了现场和远程团队之间更好的沟通。 最终可以为最终用户创造更好的体验。

但是，敏捷有一些缺点。 如果团队仍在探索要构建什么技术或解决方案，或者对目标客户没有把握，那么敏捷可能不是最佳方法。 敏捷对于小型团队可能也有太多的要求，而对于大型团队可能过于灵活。

始终进行尽职调查，以确定哪种管理风格最适合您的团队，并考虑将敏捷与其他方法结合起来为您创建最佳的结构。

翻译自: https://opensource.com/article/19/8/guide-agile-project-management

敏捷迭代开发-管理者指南