敏捷项目管理专注于持续改进，颠覆了开发产品和服务的传统线性方式。越来越多的组织正在采用敏捷项目管理，因为它利用一系列较短的开发周期来交付功能并持续改进。这种管理风格允许快速开发、持续集成 (CI) 和持续交付 (CD)。
敏捷项目管理允许跨职能团队处理项目的各个部分，解决问题并在更短的阶段推进项目进展。这使他们能够更快地迭代并交付更频繁的更新。
敏捷方法论在增量基础上提供更高水平的质量改进，而不是等待分发完成的项目。敏捷项目管理确实有效。例如，普华永道报告显示，敏捷项目的成功率比传统项目方法论高出 28%。
采用敏捷方法论
当敏捷方法论被引入时，它遇到了怀疑和抵制。随着当今快速的创新步伐，它已成为一种被接受的标准。项目管理协会的年度《职业脉搏》调查发现，71% 的组织报告称正在项目管理中使用敏捷方法，无论是完全敏捷项目还是混合模式。
米其林的 Phillippe Husser 在《职业脉搏》报告中表示：“我们再也无法承受项目需要两到五年才能交付的情况了。“在这段时间里，初始需求已经改变了。”
12 项敏捷原则
虽然敏捷项目管理与传统项目管理非常不同，但进行切换并不令人生畏。敏捷项目管理依赖于 12 项指导原则，这些原则可以帮助您的团队更快地协同工作。
1. 客户至上
使用敏捷管理的团队的首要原则之一是“最高优先级是通过早期和持续交付来满足客户”。这意味着最重要的是，团队致力于为客户解决问题，而不是构建炫酷但难以使用的功能和工具。这种策略鼓励所有产品决策都从客户的角度进行数据驱动。这可能意味着许多团队成员定期与最终用户互动（包括访谈）或访问显示使用情况的数据。
敏捷方法论大大缩短了从项目启动到客户反馈的时间。随着客户的需求或他们与产品互动的方式发生变化，团队可以灵活地响应这些需求，以构建以客户为中心的技术。此过程创建了一个用于持续改进的反馈循环。
2. 唯一不变的是变化
虽然更改需求似乎很激进，但敏捷方法论允许更改需求，即使在开发后期也是如此。
这条原则与第一个原则密切相关。如果团队的最终目标是最好地服务最终用户，则团队必须灵活且能够根据客户的行为和需求进行更改。灵活性还允许组织利用新兴技术或新趋势并获得竞争优势。
3. 更快地交付
敏捷鼓励在确定需求或改进运营时进行定期更新，而不是年度或半年度产品更新和补丁。等待进行重大发布可能会使技术臃肿并产生无法预见的问题，无论经过多少测试。
敏捷鼓励团队在短时间内频繁交付可用的软件。较小、更频繁的发布允许对技术进行定期更新，而不会带来巨大风险。如果发布的内容出现问题，则需要稍微撤回。敏捷方法论还鼓励自动化以帮助持续推送更新。
4. 构建跨职能团队
敏捷方法论认为，最周全、可用和可销售的技术需要跨职能团队朝着共同的目标努力。DevOps（开发和运维）和 DevSecOps（开发、安全和运维）团队协同工作而不是线性进展。这允许业务团队、开发人员、质量保证以及其他必要的团队从始至终共同合作。
这种视角转变意味着所有团队都息息相关，并且使错误或低质量技术更难推给下一个团队。与其找借口，不如大家为了相同的目标一起努力。
为了使跨职能团队发挥作用，需要高层参与。三分之一的项目由于缺乏高层管理人员的参与而失败。
5. 鼓励独立工作
敏捷管理的另一个原则是，个人可以在从事项目的同时拓展工作并学习新技能。由于团队是跨职能的，个人会接触到不同的能力、角色和风格。这种接触培养了更全面的员工，他们可以从不同的角度解决问题。
敏捷团队通常是自我管理的。这需要拥有专注目标的合适团队。
敏捷允许管理者（根据《敏捷宣言》）“围绕积极性高的个人构建项目。为他们提供所需的环境和支持，并信任他们能够完成工作。”
6. 面对面会议
虽然在远程工作者越来越多的时代，这一原则似乎很奇怪，但敏捷管理确实鼓励面对面会议。这是因为许多管理者认为，传递信息最有效的方法是面对面交流。
对于非远程团队，这可能意味着让不同的团队成员坐在一起，甚至为不同的团队创建作战室，以便更有效地沟通。同地办公意味着更快的互动。与其等待回复电子邮件或电话，不如互相交谈。
对于远程团队仍然可以实现此目标。通过使用 Slack 或 Zoom 等工具，您可以模拟面对面会议并快速找到正确的答案。
7. 上线
组织可能有多种方法可以记录计划并衡量目标完成情况。但是，衡量团队在敏捷中成功的最佳方法是通过可用的软件。敏捷团队不会看未来的预测来了解他们的表现如何。相反，可运行的代码是衡量进度的主要标准。
计划和文档固然重要，但如果没有能够完成工作的软件，其他一切都无关紧要。
8. 可持续开发
虽然敏捷开发鼓励快速发布，但团队制作可持续且可扩展的代码仍然至关重要。由于首要原则是服务客户，因此团队必须考虑创建可以长期使用的技术和工具。
团队的管理方式也应支持个人。短时间内可能需要长时间工作，但保持整体工作与生活平衡对于避免倦怠至关重要。
9. 技术卓越
敏捷方法论还认为，团队的每位成员都有责任持续关注技术卓越。即使是那些没有技术能力的人也应该对工作进行质量保证，并确保以简单且易于访问的方式构建。花哨的功能可能很好，但敏捷方法论认为良好的设计可以增强敏捷性。
此外，代码应随着每次迭代而改进。每个人都有责任在整个过程中提供清晰的代码或说明，而不仅仅是在最后。
10. 简化
敏捷团队认为简单至关重要。敏捷圈子里有一句话：“最大限度地减少未完成的工作量。” 尽可能消除和自动化一切，并构建对最终用户来说简单明了的工具。
11. 让团队自组织
《敏捷宣言》说：“最佳架构、需求和设计源于自组织团队。” 虽然管理层需要监督，但最好的敏捷团队会自己弄清楚需要做什么以及如何完成。
12. 花时间反思
定期地，最好的团队会反思如何变得更有效率，然后做出相应的调整。
敏捷团队会内省并评估他们的效率。当他们发现更好的方法时，他们就会进化。
敏捷随着自动化而发展
敏捷管理对团队和最终用户有很多好处。虽然基本原则（如敏捷的本质）已经确立，但策略总是在不断发展。敏捷项目管理现在正在通过利用不同类型的自动化而发展。
例如，IT 团队正在利用 IT 流程自动化来管理重复性任务，这些任务过去需要大量人力资源。这使团队能够更高效地工作，并专注于更大的图景，而不是监控、管理和维护软件、硬件、基础设施和云服务。
可以通过您的流程自动化规则有效处理的任务越多，您就能够越快地迭代、测试和改进。
入门
总的来说，敏捷项目管理有很多好处。它为团队提供了一种更快的方式来交付更好的产品，并且错误更少。它可以鼓励多元化的团队一起工作并互相学习。它可以促进更好的团队沟通，无论是面对面还是远程。并且它可以最终为最终用户创造更好的体验。
然而，敏捷也有一些缺点。如果团队仍在探索要构建什么技术或解决方案，或者没有牢牢掌握目标客户，那么敏捷可能不是最佳方法论。对于非常小的团队来说，敏捷也可能有太多要求，而对于非常大的团队来说，可能又过于灵活。
始终完成尽职调查，以确定哪种管理风格最适合您的团队，并考虑将敏捷与其他方法论相结合，为您创建最佳结构。
3 条评论