常见的敏捷实践
1 回顾
回顾是最重要的一个实践，原因是它能让团队学习，改进和调整其过程。
回顾可以帮助团队从之前的产品开发工作及其过程中学习。《敏捷宣言》背后的原则之一是：“团队要定期反省如何能够做到更加有效，并相应地调整团队的行为。”
许多团队使用迭代，尤其是为期两周的迭代，因为迭代在最后会提示进行演示和回顾。不过，团队回顾并不需要迭代。团队成员可以决定在这些关键时刻进行回顾：
- 当团队完成一个发布或者加入一些功能是时。这不一定是一个巨大的增量。他可以是任何发布，无论它有多小。
- 自上次回顾以来，又过了几周时间。
- 当团队出现问题时，以及团队协作完成工作不顺畅时。
- 当团队达到任何其他里程碑时。
团队可以通过分配足够的时间学习收益，无论是在项目中间回顾，还是在项目结束时回顾。团队需要了解他们的工作产品和工作过程。例如，有些团队在完成工作时遇到困难。团队可以计划用充足的时间组织回顾，以此收集数据、处理数据，再决定之后要尝试的实验做法。
首要的是，回顾并不是责备；回顾是让团队从以前的工作中学习并作出小的改进。
回顾针对定性的（人的感觉）和定量的（衡量指标）数据，然后利用这些数据找到根源，设计对策，并制定行动计划。项目团队可以采取许多行动事项来消除障碍。
考虑限制行动事项的数量，是团队在即将进行的迭代或工作期间有能力改进。尝试一次改进太多的事情却没有完成其中任何一件，比计划完成较少的事情并成功全部完成要糟糕的多。然后，在时间允许的情况下，团队可以进行列表中的下一个改进。团队选择改进时，要决定如何衡量结果。然后，在下一段时间内要衡量结果，以验证每个改进成功与否。
来自团队的一位促进者引导团队通过一个活动对所有改进事项的重要性进行排序。完成对改进事项的排序后，团队为下一次迭代选择合适的数量（或者在流程基础上增加工作）。
2 待办事项列表编制
待办事项列表是所有工作的有序列表，它以故事形式呈现给团队。工作开始之前，不需要为整个项目创建所有的故事，只需要了解第一个发布的主要内容正确即可，然后就可以为下一个迭代开发足够的项目。
产品负责人（或产品负责人价值团队，包括产品经理和产品领域的所有相关产品负责人）可能会制作一个产品路线图，以显示预期的可交付成果序列。产品负责人根据团队的实际成果重新规划路线图。
3 待办事项列表的细化
在基于迭代的敏捷中，产品负责人往往在迭代中期的一次或多次会议中与团队合作，为即将进行的迭代准备一些故事。这些会议的目的是细化足够的故事，让团队了解故事的内容，以及故事之间的相互关系。
至于细化过程应该有多长时间，还没有达成共识。有一个连续区间：
- 基于流程的敏捷的及时细化。团队将下一张卡片从代办事项列表中拿出来讨论。
- 许多基于迭代的敏捷团队在两周的迭代中用1小时的时间盒讨论。（团队选择一个迭代持续时间，为他们提供足够频繁的反馈。）
- 基于迭代的敏捷团队的多次细化讨论。团队可以在陌生的产品、产品领域或问题领域使用这一技巧。
细化会议上，产品负责人可以向团队介绍故事的创意，让团队了解故事中潜在的挑战或问题。如果产品负责人不确定依赖关系，还可以请求团队对相应功能进行刺探，以了解风险。
产品负责人有很多方法处理代办事项列表的细化准备和会议，其中包括：
- 鼓励团队在开发人员、测试人员、业务分析人员和产品负责人三方面开展合作，一起讨论和撰写故事。
- 把整个故事的概念呈现给团队。团队进行讨论，并根据需要将其细化为许多故事。
- 把团队一起寻找各种方法探索和撰写故事，确保所有的故事都足够小，以便团队能源源不断地交付完成的工作。考虑每天至少完成一个故事。
团队通常有一个目标，就是每周用不超过1小时的时间来为下一批工作细化故事。团队希望把时间尽可能花在工作上，而不是计划上。如果团队需要每周花1小时以上的时间来细化故事，那么，产品负责人可能会过度准备，或者团队可能缺乏评估和细化工作所需的一些关键技能。
4 每日站会
团队成员利用每日站会对彼此做出小的承若，发现问题，并确保团队工作顺利进行。
为每日站位规定时间盒，不超过15分钟。团队以某种方式“过一下”看板或者任务板，而团队中的任何人都可以主持站会。
在基于迭代的敏捷中，每个人都轮流回答下列问题：
- 上次站会以来我都完成了什么？
- 从现在到下一次站会，我计划完成什么？
- 我的障碍（或风险或问题）是什么？
从这样的问题得出的答案能够让团队自我组织，并让团队成员为完成之前和整个迭代中的承诺完成的工作承担彼此的责任。
基于流程的敏捷有一种不同的方法，可以将注意力集中在团队的产出上。团队从右到左对看板进行评估。问题包括：
- 我们还需要做什么来推进这一工作？
- 有人在做看板上没有的事情吗？
- 作为一个团队，我们需要完成什么？
- 工作流程是否存在瓶颈或阻碍？
站会中常见的一个反模式是，站会变成了状态报告会议。传统上在预测环境中工作的团队可能倾向于采取这种反模式，因为他们习惯于报告状态。
另一个典型的反模式是，当问题变得明显时，团队才开始解决问题。站会是为了发现存在问题，而不是解决它们。将问题添加到停车场区，然后创建另一次会议，它可以在站会之后立即召开，并在会议上解决问题。
团队可以举办自己的站会。只要体现团队工作需要的密切合作，进行顺利，站会便会非常有用。要针对团队何时需要站会，站会是否有效等问题有意识地做出决定。
5 展示/评审
当团队以用户故事的形式完成特定功能时，团队会定期展示工作产品。看过展示后，产品负责人接受或拒绝故事。
在基于迭代的敏捷中，团队在迭代结束时展示所有已完成的工作项。在基于流程的敏捷中，团队在需要时展示完成的工作，通常是当完成的功能累积到足以构成一个连贯组合时。团队，包括产品负责人在内，都需要反馈来决定何时需要产品反馈。
一般的指导方针是，每两周至少展示一次团队的工作产品。这种频率对于大多数团队来说是足够的，这样，团队成员就可以得到反馈，防止他们朝着错误的方向前进。这种频率也足够频繁，让团队可以保持产品开发足够清晰，按照自己希望或需要的频率构建一个完整的产品。
使项目敏捷的一个基本要素是频繁地交付工作产品。一个没有展示或发布的团队，其学习速度不会快，并且很可能并未采用敏捷技术。团队可能需要额外的引导来保证频繁的交付。
6 规划基于迭代的敏捷
不同团队的能力各不相同。不同产品负责人的典型故事大小也各不相同。团队应考虑自身故事大小，避免提交更多的故事，而超出团队在一个迭代中所有完成工作的能力。
产品负责人了解，当人员不可用时（例如，公共假期、度假期间或阻止人员参加下一组工作的任何事情），团队能力降低。团队将无法完成与前一时期相同的工作量。在能力降低的情况下，团队只会计划相应能力能够完成的工作。
团队估算能够完成的工作，这也是一种能力的衡量。团队不能100%确定自己能交付什么，因为他们无法知道意外情况。当产品负责人拆分故事使其变小时，团队看到的是产品的完成进度，团队就会知道他们将来能够做什么。
敏捷团队在一个工作块中不会只计划一次。相反，敏捷团队会开始计划一点，交付、学习，然后在一个持续的循环中重新规划更多的东西。
7 帮助团队交付价值的执行实践
如果团队不重视质量，很快就会无法快速发布任何东西。
下面的技术实践中，很多都是来自极限编程，它们可以帮助团队以最快的速度交付：
- 持续集成。 无论产品如何，都要频繁地将工作集成到整体中，然后再进行重新测试，以确定整个产品仍然按照预期工作。
- 在不同层面测试。 对端到端信息使用系统级测试，对构建块使用单元测试。在两者之间，了解是否需要进行集成测试，以及在何处进行测试。团队发现冒烟测试有助于测试工作产品是否良好。团队发现，决定何时可以对哪些产品运行回归测试，可以帮助他们在维护产品质量的同时，良好地构建性能。敏捷团队非常偏爱自动化测试，因此他们可以借此构建和保持交付的势头。
- 验收测试驱动开发（ATDD）。 在ATDD中，整个团队聚集一堂讨论工作产品的验收标准。然后，团队创建测试，这让团队能够编写足够的代码，进行自动化测试，满足标准要求。对于非软件项目，要考虑怎样在团队完成大量价值时对工作进行测试。
- 测试驱动开发（TDD）和行为驱动开发（BDD）。 在编写/创建产品之前编写自动化测试，实际上可以帮助人员设计产品，防范产品错误。对于非软件项目，要考虑如何通过“测试驱动”团队的设计。硬件和机械类项目经常使用模拟进行设计的中间测试。
- 刺探（时间和研究或实验）。 刺探对学习很有用，可以在诸如评估、验收标准定义以及通过产品了解用户行为的流程中使用。在团队需要学习一些关键技术或功能要素时，刺探会很有帮助。
8 迭代和增量如何帮助交付工作产品
迭代可以帮助团队为交付和多种反馈创建一个节奏。团队会为交付和反馈创建增量。交付的第一部分是一次演示。团队会收到关于产品的外观和运行方式的反馈。团队成员回顾如何检查和调整有关过程以取得成功。
演示或评审是敏捷项目流程的必要组成部分。为团队的交付节奏安排适当的演示。
