PMP备考之路 - 敏捷实践第五讲（实施敏捷：在敏捷环境中交付）

1. 项目章程和团队章程

每个项目都需要一个项目章程，这样项目团队就能了解项目之所以重要的原因、团队的前进方向以及项目的目标。同时需要有团队规范以及对一起工作方式的理解，需要一个团队章程。

项目章程：

• 项目愿景：我们为什么做这个项目？
• 项目愿景的一部分：谁会从中受益？如何受益？
• 项目发布的标准：对此项目而言，达到哪些条件才意味着项目完成？
• 预期的工作流：我们将怎样合作？

团队章程：

• 团队价值观：例如可持续的开发速度和核心工作时间。
• 工作协议：如“就绪”如何定义，这是团队可以接收工作的前提。
• 基本规则：例如有关一个人在会议上发言的规定。
• 团队规范：例如团队如何对待会议时间。

2. 常见的敏捷实践

2.1 回顾

回顾是最重要的一个实践，原因是它能让团队学习、改进和调整其过程。

什么时候回顾？

• 当团队完成一个小发布或者加入一些功能时。
• 自上次回顾以来，又过了几周时间。
• 当团队出现问题时，以及团队协作完成工作不顺畅时
• 当团队达到任何其他里程碑是。

首要的是，回顾并不是责备；回顾是让团队从以前的工作中学习并作出小的改进。

2.2 待办事项列表编制

待办事项列表是所有工作的有序列表，他以故事形式呈现给团队。

产品负责人可能会绘制一个产品路线图，以显示预期的可交付成果序列。

产品负责人根据团队的实际成果重新规划路线图。

2.3 待办事项列表的细化

在基于迭代的敏捷中，产品负责人往往在迭代中期的一次或多次会议中与团队合作，为即将进行的迭代准备一些故事，主要的目的是细化足够的故事，让团队了解故事的内容。

至于细化过程与应该有多长时间，还没有达成共识，但是有一个连续区间：

• 基于流程的敏捷的即时细化，团队将下一张卡片从待办事项列表中拿出来讨论。
• 许多基于迭代的敏捷团队在两周的迭代中用1小时的时间盒讨论。
• 基于迭代的敏捷团队的多次细化讨论。

考虑使用影响地图查看产品如何组合在一起。正常情况下，由产品负责人领导这项工作。作为向项目提供服务的一种方式，仆人式领导可以主持召开任何必要的会议。

2.4 每日站会

团队成员利用每日站会对彼此做出小的承诺，发现问题，并确保团队工作顺利进行。

每日站会规定时间盒，不超过15分钟。

在基于迭代的敏捷中，每个人都轮流回答下列问题：

• 上次站会以来我都完成了什么？
• 从现在到下次站会，我计划完成什么？
• 我的障碍（或风险问题）是什么？

要鼓励任何团队成员主持会议而不是由项目经理或领导主持，以确保它不会变成状态报告会议，而是作为团队进行自我组织和相互承诺的会议。

2.5 展示/评审

当团队以用户故事的形式完成特定功能时，团队会定期（每两周至少展示一次）展示工作产品。

看过展示后，产品负责人接受或拒绝故事。

2.6 规划基于迭代的敏捷

团队估算能够完成的工作，这也是一种能力的衡量。团队不能100%确定自己能交付什么，因为他们无法知道意外情况。

当产品负责人拆分故事使其更小时，团队看到的是产品的完成进度，团队就知道他们将来能够做什么。

将团队的注意力吸引到发模式，并帮助团队发现如何改进站会。

2.7 帮助团队交付价值的执行实践

如果团队不注重质量，很快就会无法快速发布任何东西。

下面技术实践中，很多都来自于极限编程，它们可以帮助团队以最快的速度交付：

• 持续集成：频繁将工作集成到整体中
• 在不同层面测试：对端对端信息使用系统级测试，对构建块使用单元测试。
• 验收测试驱动开发（ATDD）：在ATDD中，整个团队聚集一堂讨论工作产品的验收标准。
• 测试驱动开发（TDD）和行为驱动开发（BDD）：在编写/创建产品之前编写自动化测试，实际上可以帮助人员设计产品。
• 刺探（时间盒研究或实验）：刺探对学习很有用，可以在诸如评估、验收标准定义以及通过产品了解用户行为的流程中使用。

2.8 迭代和增量如何帮助交付工作产品

迭代可以帮助团队为交付和多种反馈创建一个节奏。

团队会为交付和反馈创建增量。交付的第一部分是一次演示。

3. 解决敏捷项目的挑战

团队应该经常为反馈进行演示，并展示进度。鼓励PMO和其他感兴趣的人观看演示，以便决定项目组合的人能够看到实际的进展。

敏捷的痛点和解决痛点的可能性：

4. 敏捷项目的衡量指标

替代衡量指标（如完成百分比）不如经验指标（如已完成功能）更有用，敏捷帮助团队发现问题和难题，以便团队能够诊断和解决问题。

除了定量指标外，团队还可以考虑收集定性衡量指标（侧重于团队选择的实践，评估团队使用这些实践的情况，例如交付功能的满意度、团队的士气、团队希望跟踪的任何东西等）。

4.1 敏捷团队的衡量结果

某些基于迭代的项目使用燃尽图查看项目随时间的进展情况：

某些项目团队更喜欢使用起燃图：

团队可能会发现，可能需要四到八次迭代才能达到稳定的速度。团队需要从每个迭代中获得反馈，了解他们的工作情况以及如何改进。

看板面板示例：

团队可以在一个功能燃起图/燃尽图和一个产品待办事项列表中衡量已经完成的工作，这些图表提供了随时间变化的完成趋势：

在敏捷中的挣值是基于已完成的功能，如下图：

如果一个团队需要衡量挣值，可以考虑使用燃起图：

累积流程图显示了看板上进行中的工作，如下图：