一、敏捷的框架
对比PMP项目管理过程的五大阶段：启动、规划、执行、监控、收尾，敏捷项目管理同样可以把整个框架分为五个阶段，分别是：构想、推测、探索、适应和结束阶段。
- 1、构想：确定产品的构想、项目范围、项目团队以及团队共同的工作方式
- 2、推测：制定基于功能发布计划、里程碑和迭代计划，确保交付构想的产品
- 3、探索：在短期内提供经测试的功能，不断致力于减少项目风险和不确定性。
- 4、适应：审核提交的结果、当前情况以及团队的绩效，必要时做出调整。
- 5、结束：终止项目，交流主要的学习成果并庆祝。
敏捷项目管理阶段.jpeg
二、敏捷的常见问题解答
(一)、对于敏捷中文档的度，我们应该如何把握？什么样的文档是需要的，什么样的文档可裁剪？
答：
有价值的文档是需要的。什么样的文档有价值? 一是客户需要的文档，比如在软件行业的随机手册、使用说明书、用户手册等；二是有人维护的文档。例如，在有的项目中，代码频繁变更，但是对应的详细设计就没有变更，导致详细设计没有被维护，也就失去了存在的价值。对于类似的文档，在敏捷中认为都是可以裁剪的，前提是确保输出的可交付成果不变形，满足预期的标准和要求。
(二)、敏捷宣言提出"客户合作胜过合同谈判"，针对不断变更的需求如何签订敏捷的合同？
答：
敏捷的合同需要签订，但是签订合同的方式与传统的瀑布式合同签订方式稍有不同。根据DSDM的方法，敏捷合同的生效必须是业务人员与开发人员一起工作。
(三)、敏捷拥抱变化，是否在任何一个时间点客户端都可以提出变更
敏捷项目聚焦于客户价值，所以只要是可以给客户带来竞争优势的更变，都可以进行，所以在任何一个时间点都应该允许客户提出变更。
(四)、团队既要保证迭代的不被干扰，又要响应变更，岂不是矛盾
虽然客户在生命周期的任何一个时间点上都可以提出变更，但是团队并不会立刻响应变更，通常会在迭代计划中梳理每个用户故事的优先级，根据价值排序，将需要增加的需求可以加入产品待办事项；同样，价值相对比较低的可以排到产品代办事项的最低端或者直接删除。变更时，需要考虑敏捷的合同，如果要维持合同的不变，增加一个故事，就要拿走一个等价故事点数的故事。
(五)、在原则4中提出业务人员与开发人员每天要在一起工作，这在实际中是不可能实现的，业务人员通常都比较忙，不可能参加到乙方的开发中，这样如何确保可以一起工作？
在现实中，业务人员的确不太可能与开发人员每天一起工作，所以通常在团队内部会有一个角色代表客户，可以是PO，也可以是BA，这可以根据每个组织的的不同进行设定。这个人在一整个团队中代表客户，需要频繁跟客户沟通，理解和挖掘客户的真实业务需求
