敏捷实践指南：解决敏捷项目的挑战
ACP认证被引入国内后，每年都有不少项目管理从业者报考ACP认证考试，想借此获得ACP敏捷证书。目前ACP认证考试使用的教材是《敏捷实践指南》，那么具体内容有哪些呢？
解决敏捷项目的挑战
出于解决具有高变化率、不确定性和复杂性的项目相关问题的需要，敏捷方法应运而生。由于这些原因，敏捷方法包含了各种各样的工具和技术，用于处理预测法中出现的问题。
>>敏捷的痛点和解决痛点的可能性：
| 痛点 | 解决痛点的可能性 |
| 团队目标或任务不明确 | 敏捷章程中关于目标的部分一愿景、使命和使命测试 |
| 团队工作协议不明确 | 敏捷章程中关于一致性的部分一价值观、原则和工作协议 |
| 团队环境不明确 | 敏捷章程中关于环境的部分一边界、承诺资产和前暗性分析 |
| 需求不明确 | 帮助发起人和相关方制定产品愿景。考虑使用实例化需求、用户故事地图和影响地图来构建产品路线图。让团队和产品负责人一起来明确需求的期望和价值。逐步将路线图分解为具有更少具体需求的待办事项列表。 |
| 用户体验不佳 | 开发团队的用户体验设计实践应在早期就让用户经常参与 |
| 估算不准确 | 通过分解故事来让故事变小。让整个团队使用相对估算进行估算。考虑通过敏捷建模或刺探来理解故事。 |
| 工作分配或工作进展不明确 | 帮助团队认识到要自我管理工作。考虑用看板面板查看工作流程。考虑利用每日站会，根据看板查看工作进展。 |
| 团队面临障碍 | 仆人式领导能帮助消除这些障碍。如果团队不知道他们都有哪些可选方案，就要考虑聘请教练。有时，团队或仆人式领导无法消除障碍，团队就需要上报故事。 |
| 由于产品待办事项列表不够完善，导致工作延误/超时 | 产品负责人和团队一起研讨故事。为故事创建一个准备就绪的定义。考虑分拆故事以使用更小的故事。 |
| 缺陷 | 考虑对特定环境有效的技术实践。它们可能是：结对工作、产品集体负责制、普适测试（测试驱动方法和自动化测试方法）以及稳健的完成的定义。 |
| 工作未完成 | 团队确定故事完成的定义，包括验收标准在内。另外，还要为项目补充发布标准。 |
| 技术债务（代码质量降级） | 重构、敏捷建模、普适测试、自动化代码质量分析、完成的定义 |
| 产品复杂性过高 | 无论是软件项目还是非软件项目，都要常常鼓励团队思考：“最简单的有效方法是什么？”，并应用“简洁，即尽最大可能减少不必要的工作，这是一门艺术”的敏捷原则。这样故将有助于降低复杂性。 |
| 团队合作过程进展缓慢或没有改善 | 在每次回顾中，选择的改进项目不要超过三个。让仆人式领导帮助团队学习怎样整合这些待改进项。 |
| 前期工作过多导致返工 | 不要做过多的前期工作，而要考虑让团队通过刺探来学习，另外，在项目开始时衡量在制品（WIP），看看哪些部分团队并不需要设计，只需要交付价值。缩短迭代，并创建一个稳健的完成的定义。 |
| 错误的开始，前功尽弃 | 让产品负责人成为团队不可分割的一分子。 |
| 产品待办事项列表杂乱无序 | 按价值排序，并考虑延退成本按持续时间（CD3）和其他价值模型划分。 |
| 仓促/等待，不均匀的工作流程 | 计划要对应团队的能力，而不是超出能力所及。要求人员停止多任务，为一个团队专注工作。请团队利用结对、群集或群体开发等方法，平衡整个团队的能力。 |
| 相关方要求无法满足 | 仆人式领导与这个相关方（可能是产品负责人）一起工作。 |
| 意想不到或不可预见的延误 | 让团队更频繁地检查，使用看板面板检查工作流和在制品限制，了解需求对团队或产品的影响。也可以在障碍板上跟踪障碍和障碍消除情况。 |
| 孤立的团队，而不是跨职能团队 | 让项目人员作为跨职能团队自我组织。使用仆人式领导技巧帮助管理人员理解为什么敏捷需要跨职能团队。 |
温馨提示：因考试政策、内容不断变化与调整，本网站提供的以上信息仅供参考，如有异议，请考生以权威部门公布的内容为准！
