敏捷(四)：在敏捷环境中交付
1、项目章程和团队章程
1.1、项目章程
每个项目都需要一个项目章程，这项目团队就能了解团队的前进方向、项目的目标。
但仅有敏捷团队是不够的，需要有团队规范以及对一起工作方式的理解,团队可能需要一个团队章程。
制定章程的过程能帮助团队学习如何一起工作，怎样围绕项目协作。
对于敏捷项目而言，团队至少还需要项目愿景或目标，以及一组清晰的工作协议。敏捷项目章程要回答以下问题：
|
为什么要做这个项目？
|
项目愿景
|
|
谁会从中受益？如何受益？
|
是项目愿景和/或项目目标的一部分
|
|
达到哪些条件才意味着项目完成？
|
项目的发布标准。
|
|
怎样合作？
|
说明预期的工作流。
|
仆人式领导可以促进章程的制定过程。团队可以通过一起工作实现协作，而制定项目章程是一种很好的开始工作的的方式。
1.2、团队章程
团队制定章程的过程中，使团队了解如何一起工作。
下面是对团队成员制定章程的一些建议，可以将其作为制定团队社会契约的基础：
|
团队价值观
|
可持续的开发速度和核心工作时间
|
|
工作协议
|
如“就绪”如何定义，这是团队可以接受工作的前提；
“完成”如何定义，这样团队才能一致地判断完整性；
考虑时间盒；或使用工作过程限制。
|
|
基本规则
|
有关一个人在会议上发言的规定
|
|
团队规范
|
团队如何对待会议时间
|
团队的社会契约，即团队章程，将规定团队成员之间彼此互动的方式。
团队章程的目标是创建一个敏捷的环境，在这个环境中，团队成员可以发挥他们作为团队的最大能力。
2、常见的敏捷实践
2.1、回顾
回顾能让团队学习、改进和调整其过程。回顾是让团队从以前的工作中学习并做出小的改进。
回顾可以帮助团队从之前的产品开发工作及其过程中学习。《敏捷宣言》背后的原则之一是：“团队要定期反省如何能够做到更加有效，并相应地调整团队的行为。
团队成员可以决定在这些关键时刻进行回顾：当团队完成一个发布或者加入一些功能时；自上次回顾以来，又过了几周时间；当团队出现问题时，以及团队协作完成工作不顺畅时；团队达到任何其他里程碑时。
2.2、代办事项列表编制
待办事项列表是所有工作的有序列表，它以故事形式呈现给团队。
不需要为整个项目创建所有的故事，只需要了解第一个发布的主要内容正确即可，然后就可以为下一个迭代开发足够的项目。
2.3、代办事项列表的细化
细化故事，让团队了解故事的内容，以及故事之间的相互关系。
基于流程的敏捷的即时细化；基于迭代的敏捷团队的多次细化。
产品负责人有很多方法处理待办事项列表的细化准备与会议，其中包括：
|
鼓励团队在开发、测试、业务分析和产品负责人三方面开展合作，讨论和撰写故事
|
|
把整个故事的概念呈现给团队。团队进行讨论，并根据需要将其细化为许多故事
|
|
与团队一起寻找各种方法探索和撰写故事，确保所有的故事都足够小，
以便团队能源源不断地交付完成的工作
|
2.4、每日站会
团队成员利用每日站会对彼此做出小的承诺，发现问题，并确保团队工作顺利进行。
为每日站会规定时间盒，不超出 15 分钟。团队以某种方式“过一下”看板或任务板，而团队中的任何人都可以主持站会。
每日站会能够让团队自我组织，并让团队成员为完成之前和整个迭代中承诺完成的工作承担彼此的责任。
每日站会需确定的内容：
|
基于迭代的敏捷
|
基于流程的敏捷
|
|
上次站会以来完成的工作
|
需要做些什么来推进这一工作
|
|
现在到下一次站会，计划完成的工作
|
有人在做看板上所没有的事情吗？
|
|
遇到的问题是什么
|
遇到的问题是什么
|
2.5、展示和评审
团队以用户故事的形式完成特定功能时，团队会定期展示工作产品。看过展示后，产品负责人接受或拒绝故事。
在基于迭代的敏捷中，团队在迭代结束时展示所有已完成的工作项。在基于流程的敏捷中，团队在需要时展示完成的工作，通常是当完成的功能累积到足以构成一个连贯组合时。
使项目敏捷的一个基本要素是频繁地交付工作产品。一个没有展示或发布的团队，其学习的速度不会快，并且很可能并未采用敏捷技术。团队可能需要额外的引导来保证频繁的交付。
2.6、规化基于迭代的敏捷
团队需考虑自身故事大小，避免提交更多的故事，而超出团队在一个迭代中所能完成工作的能力。
敏捷团队会开始计划一点，交付、学习，然后在一个持续的循环中重新规划更多的东西。
2.7、帮助团队交付价值的执行实践
帮助团队以最快的速度交付的方式：
|
持续集成
|
频繁地将工作集成到整体中，然后再进行重新测试，以确定整个产品仍然按照预期工作
|
|
在不同层面测试
|
对端到端信息使用系统级测试，对构建块使用单元测试。
冒烟测试有助于测试工作产品是否良好；
回归测试，可以帮助他们在维护产品质量的同时，良好地构建性能；
自动化测试。
|
|
验收测试驱动开发 (ATDD)
|
整个团队聚集一堂讨论工作产品的验收标准。
|
|
测试驱动开发 (TDD)和行为驱动开发 (BDD)
|
在编写/创建产品之前编写自动化测试，实际上可以帮助人员设计产品，防范产品错误。
|
|
刺探（时间盒研究或实验）
|
刺探对学习很有用，可以在诸如评估、验收标准定义以及通过产品了解用户行为的流程中使用。
在团队需要学习一些关键技术或功能要素时，刺探会很有帮助。
|
3、解决敏捷项目的挑战
敏捷的痛点及解决痛点的可能性：
4、敏捷项目的衡量指标
使用敏捷意味着要审视对团队和管理层都很重要的新指标。
状态报告的一个问题是，团队预测完成或使用交通灯状态来描述项目的能力。
预测型衡量指标的问题在于，它们往往并不反映真实的情况。
敏捷项目的衡量指标包含有意义的信息，这些信息提供了历史记录，因为敏捷项目要定期交付价值（完成的工作）。项目团队可以利用这些数据改进预测和决策。
替代衡量指标（如完成百分比）不如经验指标（如已完成功能）更有用。
4.1、敏捷团队的衡量结果
敏捷倾向于使用基于经验和价值的衡量指标，而不是预测型衡量指标。敏捷衡量团队所交付的成果，而不是团队预测将交付的成果。
敏捷是基于对客户有可见价值的工作产品。
基准通常是尝试预测的产物。
完成迭代或流程中的工作后，团队就可以进行重新规划。敏捷并不能创造出更多的工作能力。
团队需要在平衡不确定性的同时为客户提供价值。团队要规划项目要完成的下一个小部分。团队报告经验数据，并重新规划其他小的增量，以此管理项目的不确定性。
4.1.1、燃尽图和燃起图
某些基于迭代的项目使用燃尽图查看项目随时间的进展情况。虚线表示计划：
燃尽图显示未完成的工作，剩余故事点燃尽图：
燃起图显示已完成的工作，已完成故事点的燃起图：
燃起图将显示迭代过程中范围内的变化。利用燃起图，团队能查看他们已经完成的工作，这将有助于团队进行下一项工作。
速度，也即本次迭代中实际完成功能的故事点大小的总和，让团队得以通过观察历史表现来更准确地规划下阶段的能力
基于流程的敏捷团队使用不同的衡量指标：交付周期、周期时间和响应时间。团队通过衡量周期时间发现瓶颈和延迟问题，问题不仅限于团队内部。
交付周期，从第一次查看特定功能到向客户发布该功能所需的周期时间。
燃起图、燃尽图（能力衡量指标）和交付周期，以及周期时间（可预测的衡量指标），可帮助团队了解他们共有多少工作，以及团队是否能按时完成工作。
4.1.2、功能图
根据自身的指标单位进行衡量，团队就能更好地评估和估算自己的工作，并最终交付。相对估算的缺点是，无法比较各个团队或者在团队之间增加速度。
团队可以在一个功能燃起图/燃尽图和一个产品待办事项列表中衡量已完成的工作。这些图表提供了随时间变化的完成趋势。
功能燃起图/燃尽图可显示项目期间需求的发展。功能完成线显示团队以正常速度完成功能。总功能线显示了项目的总功能随时间的变化。剩余的燃尽线显示功能完成速度的变化。每次在项目中添加功能时，燃尽线都会有改变。
4.1.3、产品待办事项列表燃起图
在敏捷中的挣值是基于已完成的功能，产品待办事项列表燃起图显示已完成的工作与区间里程碑或迭代中的预期工作总量的比较。
产品待办事项列表燃起图：
产品待办事项列表燃起图来显示已完成的价值，若一个团队需要衡量挣值，可以考虑使用燃起图。
左边Y轴代表故事点的范围，右边Y轴代表项目的支出。
传统的挣值管理 (EVM) 衡量指标，如进度绩效指数 (SPI) 和成本绩效指数 (CPI) 可以很容易地转换为敏捷术语。
4.1.4、已完成功能的累计流图
累积流图显示了看板上进行中的工作。若一个团队有许多等待测试的故事，测试团队将会扩大。累积工作可一目了然。
已完成功能的累计流图：
在处理累积工作方面的困难：团队有进行中的工作，而不是已完成工作。如果团队有大量进行中的工作，就会延迟整体功能的交付。团队交付的时间越长，在相同时间内有更多功能，团队的压力就越大。
