本文共 2922 字，大约阅读时间需要 9 分钟。
敏捷迭代开发-管理者指南
专注于持续改进，敏捷项目管理颠覆了开发产品和服务的传统线性方式。 组织越来越多地采用敏捷项目管理，因为它利用一系列较短的开发周期来交付功能并不断改进。 这种管理风格允许快速开发，持续集成（CI）和持续交付（CD）。
敏捷的项目管理使跨职能的团队可以处理大量项目，解决问题并在较短的阶段中推进项目。 这使他们可以更快地迭代并提供更频繁的更新。
敏捷方法以增量方式提供更高水平的质量改进，而不必等待分发已完成的项目。 和敏捷项目管理工作。 例如，PWC报告说， 率比传统项目方法高出 。
当引入敏捷方法论时，它遭到了怀疑和抵制。 随着当今创新的快速发展，它已成为公认的标准。 项目管理协会的年度“职业脉搏”调查发现，有在项目管理中 ，无论是完全敏捷的项目还是混合模型。
米其林的菲利普·胡塞尔（Phillippe Husser）在“行业脉搏”报告中说：“我们再也无法承担需要两到五年才能交付的项目。 “在这段时间里，最初的要求已经改变。”
尽管敏捷项目管理与传统项目管理有很大不同，但进行转换并不一定要令人畏惧。 敏捷项目管理依赖于 ，可以帮助您的团队更快地共同前进。
团队使用敏捷管理的首要原则之一是“最优先考虑的是来 ”。 这意味着，最重要的是，团队致力于为客户解决问题，而不是构建酷炫但难以使用的功能和工具。 从客户的角度来看，这种策略鼓励所有产品决策都由数据驱动。 这可能意味着许多团队成员会定期与最终用户进行互动（包括访谈），或者有权访问显示使用情况的数据。
敏捷方法极大地减少了从项目启动到客户反馈的时间。 随着客户需求或他们与产品互动的方式的变化，团队可以灵活地响应这些需求以构建以客户为中心的技术。 此过程创建了一个反馈环，用于持续改进。
尽管更改需求看似激进，但敏捷方法可以更改需求，甚至可以在开发后期进行。
该原则与第一个原则紧密相关。 如果团队的最终目标是最好地为最终用户提供服务，则团队必须具有灵活性并能够根据客户的行为和需求进行更改。 灵活性还使组织能够利用新兴技术或新趋势来获得竞争优势。
敏捷不鼓励年度或半年度产品更新和补丁，而是在发现需求或改善运营时鼓励定期更新。 等待进行重大发布可能会使该技术膨胀，并导致无法预料的问题，无论已对其进行了多少测试。
敏捷鼓励团队在短时间内频繁交付工作软件。 更小，更频繁的发行允许对技术进行定期更新而不会带来巨大风险。 如果出现故障并且无法正常工作，则需要稍稍后退。 敏捷方法还鼓励自动化以帮助不断推出更新。
敏捷方法论认为，最深思熟虑，最实用和最畅销的技术需要跨职能的团队朝着共同的目标努力。 DevOps（开发和运营）和DevSecOps（开发，安全和运营）团队协同工作，而不是线性发展。 这使业务团队，开发人员，质量保证和其他重要团队可以从头到尾一起工作。
这种观点上的改变意味着所有团队都在比赛中占有一席之地，这使得将错误或低质量的技术推向下一个团队变得更加困难。 每个人都不会为自己找借口，而是为共同的目标而共同努力。
为了使跨职能团队能够工作，需要高层的参与。 三分之一的项目 。
敏捷管理的另一个原则是，人们可以在从事项目时扩展自己的工作并学习新技能。 由于团队是跨职能的，因此个人面临不同的能力，角色和风格。 这种接触会造就更全面的工人，他们可以从不同的角度来解决问题。
敏捷团队通常是自我指导的。 它需要正确的团队并有针对性的目标。
敏捷使经理能够（按照敏捷宣言）“围绕有积极性的人建立项目。为他们提供所需的环境和支持，并信任他们能够完成工作。”
尽管在增加远程工作人员的时代这个原则可能看起来很奇怪，但是敏捷管理确实鼓励了面对面的会议。 这是因为许多管理人员认为，最有效的信息传递方法是面对面的交谈。
对于非远程团队，这可能意味着让不同的团队成员坐在一起，甚至创建不同小组的作战室，以更有效地进行交流。 主机代管意味着更快的交互。 彼此交谈，而不是等待电子邮件或电话被退回。
对于远程团队，仍然可以实现此目标。 通过使用Slack或Zoom之类的工具，您可以模拟面对面的会议并快速找到正确的答案。
组织可能有几种方法来记录计划并根据目标衡量成功。 但是，衡量团队在敏捷方面的成功的最好方法之一是通过可运行的软件。 敏捷团队不会看未来的预测来了解他们的表现。 相反，实时代码是进度的主要衡量标准。
计划和文档编制非常出色，但是如果没有软件可以完成工作，那么其他所有内容都是无关紧要的。
尽管敏捷开发鼓励快速发布，但团队开发可持续且可扩展的代码仍然至关重要。 因为第一原则是为客户服务，所以团队必须考虑创建可以长期使用的技术和工具。
还应该以支持个人的方式管理团队。 虽然在短时间内可能需要较长时间，但保持整个工作与生活的平衡对于避免倦怠至关重要。
敏捷方法论还认为，团队的每个成员都有责任持续关注技术卓越。 即使没有技术能力的人员也应该进行质量检查，并确保以简单易用的方式进行构建。 虽然风吹草动可能不错，但敏捷方法论认为，好的设计可以增强敏捷性。
此外，代码应随着每次迭代而改进。 每个人都有责任在整个过程中提供清晰的代码或说明，而不仅仅是在最后。
敏捷团队认为简单至关重要。 敏捷圈子里有句谚语：“最大化未完成的工作量”。 消除并自动执行任何操作，并构建对于最终用户而言直接的工具。
“最佳的体系结构，需求和设计来自自组织团队，”敏捷宣言说。 尽管需要管理来进行监督，但最好的敏捷团队会自己确定需要做什么以及如何完成。
最好的团队会定期思考如何提高效率，然后进行相应调整。
敏捷团队进行内省，并评估其效率。 当他们发现更好的方法时，他们就会进化。
敏捷管理对团队和最终用户都有很多好处。 虽然已经确立了基本原则（如敏捷的本质），但该策略始终在发展。 通过利用不同类型的自动化，敏捷项目管理正在不断发展。
例如，IT团队正在利用过去占用大量人力资源的 。 这使团队可以更高效地工作，并专注于更大范围，而不是监视，管理和维护软件，硬件，基础架构和云服务。
您的流程自动化规则可以有效处理的任务越多，您就能越快地进行迭代，测试和改进。
总体而言，敏捷项目管理带来许多好处。 它为团队提供了一种更快的方式，以更少的错误提供更好的产品。 它可以鼓励不同的团队一起工作，互相学习。 它促进了现场和远程团队之间更好的沟通。 最终可以为最终用户创造更好的体验。
但是，敏捷有一些缺点。 如果团队仍在探索要构建什么技术或解决方案，或者对目标客户没有把握，那么敏捷可能不是最佳方法。 敏捷对于小型团队可能也有太多的要求，而对于大型团队可能过于灵活。
始终进行尽职调查，以确定哪种管理风格最适合您的团队，并考虑将敏捷与其他方法结合起来为您创建最佳的结构。
翻译自:
敏捷迭代开发-管理者指南
转载地址：http://npbzd.baihongyu.com/