如果你从事过项目管理，你可能听说过敏捷。这是一颗银弹，是一种交付速度更快、官僚主义更少的完美方式，对吧?好吧，不完全是，尽管这是为正确的团队工作的聪明方式。
在本文中，我们将研究什么是敏捷项目管理以及它能为你做什么。
什么是敏捷?
敏捷是一种完成事情的迭代方法。这种方法强调:
- 增量交付
- 团队协作
- 持续的规划
- 持续改进
敏捷专注于小的、增量的特性发布，而不是“大爆炸”的实时发布。敏捷非常适合那些需要定期进行更改并致力于不断演进的产品的团队。
敏捷起源于软件开发，但现在在许多行业中用于各种项目。
敏捷有不同的“风格”，包括Scrum、看板、DSDM等。他们都有共同的原则及价值观，但根据团队和组织的需要以及工作的规模，它们的实现略有不同。
敏捷项目方法的好处
更快的增量交付以及通过产品负责人与客户建立密切的工作关系?你已经可以看到它给你的团队带来的好处。这里还有一些转向敏捷的理由。
它将客户的目标与可能性联系起来
你有没有遇到过这样的客户，他什么都要，镶满钻石，明天就能送到?当客户融入敏捷团队并看到所涉及的工作时，他们会理解所付出的努力——而你甚至不需要告诉他们。客户可以参加迭代评审，并看到团队正在进行的进展。
它将变更的影响最小化
客户会改变主意——所有有经验的项目经理都会告诉你，最初的范围很少是最终交付的。然而，如果在项目后期使用瀑布方法进行更改，则更改的影响可能是巨大的。所有这些在敏捷中都消失了。
产品负责人决定优先级，一次又一次的迭代。在充分了解这对时间轴和成本意味着什么的情况下，可以在任何时候进行更改。此外，由于客户参与功能评估并定期查看产品，他们可以提供实时反馈，以便您更早地了解更改。
它与客户建立长期关系
敏捷依赖于团队中密切的工作关系。敏捷团队建立在信任的基础上:决策被移交给最能做出决策的专家。这会把客户带入你的生态系统。你会更多地了解他们的业务和价值观。他们会更多地了解你的业务。
你可以通过增量交付向他们展示真正的价值。他们可以更快地获得可用的功能，因为他们不必等待“大爆炸”的发布。仅这一点就能让你从其他供应商中脱颖而出。
敏捷团队中的关键角色
敏捷方法提供了极大程度的灵活性。在敏捷运动的早期，团队是在同一地点，由一个多功能小组组成，他们可以在他们之间做所有需要做的事情。今天，随着组织扩展他们的敏捷工作方式，完美的敏捷团队就像你的组织一样独特。这包括远程和离岸员工。
然而，在敏捷团队中有一些常见的团队角色。
Scrum Master
Scrum Master是使用Scrum的个人专家。他们帮助团队理解方法、仪式和价值观背后的理论。他们是过程的守护者，他们指导团队如何使用最佳实践来提高效率。
Scrum Master是Scrum特有的角色，但你可能会发现有人在使用其他敏捷框架的地方担任类似的角色:导师和教练，以确保方法得到适当的实现。
产品负责人
产品负责人是将使用项目输出的人——您为之工作的人。它们定义了产品待办事项列表中的需求。他们负责从backlog中选择对团队来说重要的工作，并设置开发的优先级。他们代表客户的观点，并与其他涉众合作，以确保最终结果符合目的。
开发团队
这些人都在工作!团队可以是多功能的(每个人都可以担任每个角色)，也可以是专业的(由不同领域的专业人员组成，例如程序员、技术作者、质量分析师、UX专家、测试人员等)。
“开发人员”并不一定是IT人员。它只是指“拥有完成项目任务的正确技能的人”。
敏捷仪式和过程
敏捷的循环会议被称为“仪式”。主要仪式如下。
Sprint计划
敏捷是一种基本的迭代工作方式。特性的开发是有时间限制的。冲刺是团队一起工作以交付一定量工作的特定时间。Sprint计划是你决定下一阶段将要发生什么工作的会议。作品被定义为“故事”，代表成品的各个部分。
从技术上讲，“冲刺”是Scrum特有的术语，但许多其他敏捷工作方式也会做类似的事情，为下一个迭代计划工作。
每天的站立会议
你可能对每日站立会议很熟悉。这是一种快速的方式，让团队一起讨论已经完成了什么，当天正在做什么，以及什么阻碍了进展。会议是一个快速的聚会，人们真的站起来了!站立的动作有助于缩短会议时间。
迭代回顾
在冲刺/迭代结束时，团队开会一个小时左右来回顾所做的工作。这是向产品所有者演示可交付成果并获得迄今为止所构建内容的反馈的时候。
回顾
回顾有点像你在更具预见性的项目方法中发现的“经验教训”会议。他们是团队聚在一起讨论他们正在使用的方法是什么，以及如何更有效的时候。这与交付成果无关，而是团队作为一个整体运作的方式。敏捷精神的一部分是持续改进因此，根据回顾的反馈，团队在项目期间改变工作方式以提高效率是很常见的。
超越敏捷:混合和混合项目管理
敏捷方法适用于许多团队，但转向“照章办事”的敏捷对组织和客户来说是一个重大的文化变革。混合项目管理是一个新兴的趋势。
混合项目管理，两全其美．你拥有敏捷的速度和以客户为中心的时间限制，增量交付，以及更传统的项目生命周期的结构。
如果您希望您的开发团队采用敏捷的最佳实践，但组织的其他部分还没有准备好遵循，那么混合方法可以为您提供所有的好处，而不会使客户感到困惑。
高地PowerSteering满足不同用例和项目方法的需求，旨在提供开箱即用的价值，并提供巨大的扩展和增长机会。
敏捷、瀑布和混合:差异
瀑布(顺序)交付方法依赖于“大爆炸”方法，在这种方法中，客户在产品交付之前无法看到最终结果。
混合方法需要两者的混合。项目的总体时间轴是由瀑布生命周期决定的，但是工作的“做”部分使用敏捷技术迭代地交付最终结果。
小抄:敏捷vs瀑布vs混合
| 敏捷 | 瀑布 | 混合动力 | |
|---|---|---|---|
| 团队的方向 | 产品负责人设置 | 项目发起人设定 | 项目发起人设定 |
| 需求 | 一开始不清楚 | 一开始就很清楚 | 清晰但复杂或 一开始不清楚 |
| 团队结构 | 小,自我 包含;资源 根据需要切换角色 |
任何大小;资源 有专门的角色， 项目负责人 经理 |
中型至大型 队;一些 资源有时 如果需要切换角色 要求 |
| 调度 | 定时 迭代 |
基于项目 阶段和a 结构化生命周期: 启动、规划、 执行,近 |
整个项目 生命的时间轴 〇时间周期 的盒装迭代 执行 |
| 管理变更 | 改变是可以实现的 在任何时候 |
改变是可以做到的 任何时候都行，就是不迟到 在工程上可以 昂贵是因为 返工了 |
改变是可以做到的 在任何时候 |
| 进度会议 | 每日站立 | 每周状态 会议 |
每天站起来 状态会议如下 由 团队 |
| 报告 | 重点在于时间 完成/小时 完成了。跟踪 通过燃尽/ 燃耗图表 |
重点在于百分比 完成任务 |
重点在于百分比 完整的整体 与发展 团队使用敏捷 跟踪方法如下 好吧 |
| 交付 | 工作特性 最后交付 每一次迭代 |
工作特性 最后交付 关于项目 |
工作特性 最后交付 每一次迭代 |
敏捷入门
现在您了解了敏捷方法可以为您的团队和客户做些什么，那么如何开始呢?
以下是向敏捷工作方式转变的一些初步步骤。
- 如果您的团队习惯于使用瀑布和预测方法，请查看来自PMI的严格的敏捷资源．有一个多层次的资源工具包，可以满足你所处的位置。
- 如果你从事软件开发工作，来自敏捷联盟会支持你开始。
- 下载官方scrum指南，有30多种语言可供下载，以评估Scrum是否适合您。
- 检查你所拥有的工具，看看它们是否支持敏捷的工作方式。一个健壮的项目管理或PPM工具可以同步来自Jira的数据，包括sprint、故事、史诗和backlog，以及瀑布式数据点，通过提供单个源可见所有项目的性能，提供了最大的灵活性。
