项目估算是制定健全的项目管理计划的第一步。项目经理花费大量的时间和精力来进行估算，通常情况下，这些估算在到达执行层时就会放大。那么敏捷项目管理中的计划和估算有何不同？
在深入研究细节之前，让我们了解企业中普遍使用的通用估算方法。所有项目管理团队最终都会得出与项目执行的实际情况不同步的估算。
为什么会这样？
项目的估算通常是建筑师、技术项目经理或中小企业做的，他们实际上不会“执行”或处理这些估算的可交付成果。
对于“客户要求的截止日期”，没有考虑实际需求、项目范围、资源管理和/或项目进度管理。
有时，即便是我们的客户服务团队也有过错，为了达成那笔关键交易，他们过度承诺。需求还没有最终确定，但结束日期已经确定。
此外，客户和利害关系人经常更改项目范围，或估算时要考虑特定的专家水平，但现在必须使用经验较少的资源等等，所有这些因素以及更多此类因素都会影响你对项目的评估与执行。
那么，具有如此脆弱方面的项目，执行情况如何？
这个项目会面临：
· 很多加班
· 多次返工
· 质量问题
· 对客户和项目团队的期望管理不当
· 团队压力过大
· 团队士气低迷
· 升级和客户关系破裂
敏捷项目管理是否有助于避免上述问题？
很大程度上是可以的。
如果从整体上看，你会发现敏捷项目是“价值驱动”的，而不是计划驱动。
通常，在敏捷项目中，成本和进度是给定的。例如，我有6个月或1年的时间来启动这个项目，资金为XX元。
因此，估算不是直接根据工作量，而是根据价值。
为此，生产产品或提供特定服务必须包含每个功能的价值。
在敏捷项目管理中，战略和战术计划是健康的结合。
主题（Themes）更具有战略性，通常是跨组织的大型重点领域，涵盖项目的总体目标。例如，降低产品投放市场成本15%。
史诗（Epics）是比主题低一级的更大工作块，可以分解为许多较小的任务，启动是为了实现主题目标。
从最终用户的角度来看，故事（Stories）是明确的面向行动的事项，比如如何使用特定的产品项目、功能或特性。
任务（Tasks）是对用户故事的战术和细化分解，是满足用户故事的可操作事项。
一旦分解完成，如何进行估算？
项目管理协会（PMI.Org）列出了许多敏捷估算技术。其中，我们将重点关注敏捷团队部署的两种非常简单的通用技术。
▪ T恤尺码分类法（T-Shirt Sizing）——顾名思义，关于用非常大的事项来确定积压工作的大小。术语或度量单位通常是XS、S、M、L、XL和XXL。
Scrum团队聚集在一起，对积压事项进行公开讨论，他们通常会考虑时间（通常以天为单位）。
注意，T恤尺码分类法的水平很高，本质上不是数字。
这样做的目的是让技术团队发挥创造性的一面，保持开放的心态，更容易接受其他团队成员的观点和看待手头故事的方式。
这种方法最适合刚开始进行敏捷项目管理的团队。
▪ 计划扑克（Planning Poker）——这是一种更为数值化的敏捷估算方式，也是一种实用的估算方式。总的来说，它包括以下内容：
-所有团队成员参与
-每位成员都获得数字卡片，根据斐波那契数列，从0到21排列
- 一旦故事被读取，每位成员都拿着数字卡片，上面的数字代表他认为所需的工作
-数字最高和最低的成员需要解释选择这个数字的原因
-这个游戏往往会重复，直到团队成员对用户故事实际需要多少工作量达成共识
-经过一段时间，团队对特定的用户故事类型和相关工作有了一定的了解
-敏捷团队对一个又一个故事进行讨论，他们的估算变得更加稳妥，对项目需求的理解更加深入。用更加通用的话来说——见识更加开阔。
敏捷项目管理方法实践
敏捷项目管理方法（如Scrum、看板等）之所以流行，主要原因在于简化和有效处理不确定需求的能力。
这来自于迭代、增量发布、快速测试、最后的经常性检查和验证方法。
最重要的方面是，估算由实际实施者完成。
敏捷关于自组织团队和仆人式领导力，即为团队提供更大的自由、责任心以及为项目目标调整和执行的权力。
每个结果的价值——迭代可交付成果有助于从积压中形成后续项。从根本上说，感知价值和交付价值之间的一致性不断增加。
最终的结果是，除非结果的价值大于努力的价值，否则积压的事项不会被执行，理想情况下会被删除。此外，还消除了每个迭代的混乱，产品路线图变得更加稳健，不确定性程度也有所降低。
敏捷估算与计划更强调集体合作和响应变化。类似8Manage Scrum这样的敏捷管理工具可以跟踪故事，快速响应客户需求，不断适应变化，从而使对估算的反思和重新校准变得更加容易。
项目计划与估算是应对项目不确定性的良好办法，也是对最大化交付价值的重要体现。8Manage Scrum敏捷项目管理通过多个维度来帮助你的团队提升顺畅、高质量地交付价值的能力，包括需求响应周期、持续发布能力和交付质量等，期待能又快又多又好地交付需求。