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