第三章 术语与工具
本章主要介绍前面两章中没有提到的一些额外的重要概念和术语。这些知识点会出现在考试中。
3.1 团队管理
仆人式领导（Servent Leader）
又称服务型领导。敏捷项目经理（另称敏捷教练）不对团队进行命令和控制，而是以支持者的角色参与项目，积极服务于团队，为团队创造环境、帮助团队消除会对工作效率产生影响的障碍和干扰，并善于激励团队和解决团队冲突。
自组织团队
各成员可以用其知识决定如何最好地完成工作，包括具体工作方式、工作量估算、开发方法等；需要成员之间相互信任、分享以及尊重；对项目的成果具有集体所有权。
团队章程（Team Chapter）
又称团队工作协议，对团队的共识、价值观、行为规范、基本规则做出规定，团队全员必须遵守。重要考点是此文件必须由团队共创，而非项目经理一个人制定。
T 型通才
敏捷团队提倡 T 型通才。T 型通才有一个明确的、公认的专业化主要角色，同时还具有必要时与人协作、帮助他人的技能、多种才能及能力，也即“一专多能”。这种能力和协作减少了人员流失、只有特定的人才能完成特定工作等所带来的项目风险。
培养 T 型通才有很多种方法，比较常见的方法有交叉培训、结对编程等。
结对编程（Pair Programming）
一种敏捷软件开发的方法，两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人实时审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）。
两个程序员经常互换角色。
这项实践看上去是低效的，但是极限编程认为是可以节约时间的，因为结对编程可以及早发现错误，还能两人共享知识。结对工作也可以在团队中扩散技术知识。
代码集体所有权（Collective Code Ownership）
一种加速项目的团队协作技术。团队中的任何成员都有权修改任何项目工作产品或可交付成果，强调整个团队对产品的责任和最终责任。
集体代码所有权所引出的另一个概念为“成果的集体所有制”。即自组织团队通过协作、共同参与、共同决策等方式作为一个整体解决产品的质量问题，所有人均对最终产品的质量均负有责任。
3.2 质量管理
测试驱动开发（TDD）
在编写某个功能的代码之前先编写测试用例，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。测试驱动开发将测试工作提到编码之前，并频繁地运行所有测试，可以尽早地发现错误，极大地降低后续测试及修复的成本，提高代码的质量。在测试的保护下，不断重构代码，以消除重复设计，优化设计结构，提高代码的重用性，从而提高软件产品的质量。
持续集成（Continuous Integration）
无论产品如何，都要频繁地将工作集成到整体中，然后再进行重新测试，以确定整个产品仍然按照预期工作。此实践能够有效避免产品缺陷，从而提升产品质量。这项实践很关键，因为可以在更多代码被完成之前尽早发现错误，或者在不完善的设计之前，将问题尽早暴露出来。团队经常集成他们的工作，每次集成都通过自动化构建来验证。持续集成每天可以进行一次或多次。
完成的定义（Definition of Done， DOD）
团队需要满足的所有标准，包括需求的验收标准。只有可交付成果满足这些标准才能视为功能就绪，可供客户使用。团队与相关方就 DOD 事先达成共识是有效避免产品质量缺陷的手段之一。
小增量
为促进频繁的增量交付，敏捷方法关注小增量工作。敏捷通过多个短周期来持续交付产品增量，以获得客户的持续参与和频繁反馈。小增量交付方法可以在项目生命周期早期发现不一致和质量问题。
频繁的确认与验证
在敏捷项目中，会进行频繁的确认与验证，以此来改进和提升产品交付的质量。因为人都有可能会犯错，导致错误结果，同时表述和内心的真实期望之间也会有偏差，所以借助频繁的确认和验证，不断检验项目运行是否符合预期标准很有必要。这样，即使中间存在偏差，也能迅速找到应对的方案。
以下几个工具都属于频繁的确认与验证的具体方法。结对编程：一个人写代码，另一个人实时审查，编码错误或对需求的误解会立即被发现并获得反馈。单元测试：每开发出一个小单元就及时进行测试。每日站会：每天反馈前一天的工作进展以及遇到的障碍。评审会：迭代结束后给客户演示产品功能，获得客户反馈，以确保功能是客户真正想要的，也是一种确认和验证。
技术债务与重构
考试中涉及的两种技术债务：1. 随着产品开发的进行，为了应对需求变更、不断增加新功能或修复功能缺陷等原因，导致产品的整体设计架构越来越不可靠、不稳定。消除这种技术债务只能通过重构来进行。2. 由于产品开发前期缺少充分的质量保证（如测试不充分等），从而导致后期的技术风险越来越高。解决方法是要保证质量保证和质量控制活动贯穿项目全过程。
重构的定义：不改变系统的外部功能，只对产品内部架构进行整理和优化，使得产品的整体结构更加合理、可靠、稳定。
3.3 流程工具
最小可行产品
也称最小可行版本、最小可售功能。由产品待办列表中最高价值优先级功能所组成的可运行的第一个版本，可以上市而产生市场价值。敏捷提倡尽早规划和交付最小可行产品，不仅可以尽早获得市场的反馈、尽早曝光问题，而且还能尽早产生收入。当项目预算、进度受到制约时，应优先规划最小可行产品。
SCRUM 流程
一种敏捷框架。与第二章所描述的敏捷通用流程框架类似，只是更为简化。SCRUM 流程中没有涉及产品路线图、发布计划等，可以看成是通用流程框架的一个子集。所包含的核心要素有：三大角色（产品负责人、敏捷教练、开发团队）、四大会议（迭代计划会、每日站会、评审会、回顾会）、三大工件（产品待办列表、迭代待办列表、功能增量）。
速度
团队在一个迭代周期中实际已经完成的用户故事的点数之和，用于衡量敏捷团队的生产率。
燃起图（Burnup Chart）
与燃尽图的作用类似，反映迭代/发布的实际工作进度。燃起图的横轴是时间，纵轴是已完成的工作量。
合规性需求
属于非功能需求。使得产品符合法律、法规、监管等外部条款的需求。合规性需求属于最小可售产品的一部分。所开发的产品必须要满足此类需求才能够上市售卖。否则会导致罚款甚至是产品被强制退市。
极限编程（Extreme Programming）
一种轻量级的敏捷软件开发方法。不仅能提高软件质量、改善软件、对不断变化的客户需求作出及时响应，还能缩短软件版本发布周期并提高发布频率。
MoSCoW 方法
一种价值优先级排序方法。这种方法把需求从高价值到低价值的顺序分成四大类，依次为：必须要有的需求（Must have）、应该要有的需求（Should have）、可以有的需求（Could have）和当前迭代/版本不会开发的需求（Won’t have this time）.
KANO 分析
卡诺分析是一种价值优先级排序方法。这种方法的特点是以客户对需求的喜好程度对需求分类。通常会被分成四类：惊喜属性（让客户感到惊喜的需求）、满意属性（让客户感到满意的需求）、不满意属性（也称基本属性，如果缺少，客户会感到不满意）、无关紧要属性（客户对此类需求根本无所谓）。
风险的“负价值”
在敏捷中，风险可以被等价为“负价值”，即风险一旦发生就会降低项目的整体商业价值。因此，为了最大化项目价值，必须要把风险的处理纳入到产品待办列表中与其他工作项一起进行价值优先级排序。
风险处理项在产品待办列表中进行价值优先级排序的依据为风险的预期货币价值（EMV 值），风险 EMV 值=风险发生概率×风险发生导致的损失。EMV 值的绝对值越高，对应的风险处理项在产品待办列表中就应排得越靠顶端。越高的风险越早做，能促进问题尽早曝光、尽早解决，从而提升项目成功率。
刺探（Spike，也称探测、探针）
刺探是一个简短的研究性试验。团队可以运用刺探来熟悉新技术或新领域、证明他们前面做出的假设、评估解决问题或风险的选项、或提升对用户故事工作量估算的确定性。注意，刺探本身应该足够小（一个小时间盒），以便在迭代中计时。一旦试验目的达到，刺探就会停止。
故事地图
一种二维形式的产品路线图。横向把各个用户故事按照主题进行分类、分组，纵向按照价值优先级对用户故事排序。重要考点：为团队提供了一个关于“需求是如何组装起来构成可发布产品”的全景大图。
故事点数
一种衡量需求工作量的单位，比如“故事 A 的工作量是 30 个故事点”。敏捷的方法论中并没有对“一个故事点代表多少工作量”做出统一的规定。因此不同的团队可以有不同的故事点定义。例如一些团队可能会把团队一天的工作量定义为 1 个故事点，而另一些团队可能会把团队一天的工作量定义为 50 个故事点等等。
计划扑克
一种用于估算需求项工作量的专用扑克牌。一般用于发布计划或迭代计划。团队成员通过出牌的方式对需求项工作量给出估算数值。扑克牌上的数字属于菲波那契数列，即对小的需求项估算更精确，而对大的需求项估算比较粗略。
亲和估算
一种用于估算需求项工作量的粗略级估算技术，一般用户产品路线图的规划。用 T 恤衫尺码（XS、S、M、L、XL、XXL）或咖啡杯尺寸来表征需求项的工作量。
待办事项细化
产品负责人和开发人员一起对需求进行切分、细化、明确验收标准等，保证为下一次迭代准备充分的用户故事。待办事项的细化可以作为迭代计划会的前半部分内容，也可以作为一个独立的会议在迭代计划会之前开。
迭代燃尽图
反映迭代进度和状态的可视化图形。如上图所示，横轴是迭代中的每一天，纵轴是当前迭代的剩余工作量（以故事点数为单位）。每天都需要更新（一般是每日站会后更新）。若实际剩余工作量比计划的剩余工作量要多，说明目前进度落后。
发布燃尽图
与迭代燃尽图类似，反映整个发布周期内的进度和状态。横轴是发布周期内的每个迭代，纵轴是当前发布的剩余工作量（以故事点数为单位）。在每个迭代结束之后更新。
看板与限制 WIP
看板面板利用列进入和退出策略以及限制 WIP（Work in Progress， 在制品）等制约因素，可提供一目了然的工作流、瓶颈、阻碍和整体状态信息。此外，面板可作为面向所有观众的信息发射源，提供团队工作状态的最新信息。
在看板方法中，完成工作比开始新工作更为重要。从未完成的工作中无法获得任何价值，因此团队将协作实施和遵从在制品 (WIP) 限制，即每一列中正在并行的任务不可超过一定的数量，让整个系统中的每份工作得以“完成”。
就绪的定义（Definition of Ready， DOR）
看板的最左边一列是“待办事项”，这上面的工作项源自迭代待办列表或产品待办列表。进入此列的工作项必须要满足一系列就绪的定义。所谓就绪的定义是指需求能正式进入开发所应满足的一系列前提条件，比如：需求足够细化、需求具有可衡量的验收标准、需求具有团队开始工作所需的全部信息等等。不同的团队可能会有不同的 DOR，关键是团队成员应该跟产品负责人、客户等关键相关方就 DOR 达成共识.
信息发射源（Information radiator）
在集中办公的区域设立一块大白墙或白板，上面用高可视化、图形化的方式展示出项目的实时状态和信息，内容可以包括看板、产品待办列表、问题列表、迭代燃尽图等等。可以最大程度促进团队成员间、团队和相关方间透明式的信息流通。敏捷提倡引导相关方观看信息发射源以获得项目状态，而不是单独发送项目状态报告。
3.4 合同类型
敏捷的合同不会固定范围，而是具有动态特性，这样才能做到最大程度地拥抱变更。设计敏捷中的动态特性合同签署技术包括：
多层结构合同（Multi-tiered structure）
除了在单个文档中正式说明整个合同关系，项目方可以通过在不同文档中说明不同方面来提高灵活性。通常固定项目（如担保、仲裁）可以锁定在主协议中。同时，所有方将可能会变更的其他项目（如服务价格、产品说明）列在服务明细表中。合同主要服务协议中注明这些服务参考。最后，范围、进度计划和预算等更多动态变化项目可以列在轻量级工作说明书中。通过将合同中的更多变化因素隔离到单独的文档中，将会简化修改工作并提高灵活性。
动态范围方案合同（Dynamic scope option）
动态范围方案合同会固定预算/时间，项目的全范围可以灵活变更。最终项目会在相对固定的资源限制内交付高价值、高质量的那部分功能给客户。换句话说，客户获得的不是所规划的 100%的功能，而是最好的那 70~80%。一种名为动态系统开发（Dynamic System Development Method）的敏捷实践所采用的就是这种合同。
固定时间和材料合同（Not-to-exceed time and materials）
将整体预算限制为固定数量。这样就允许客户在最初未计划的项目中纳入新的观点和创新。如果客户需要纳入新的观点，则必须管理给定能力，用新的工作来替代原有工作。应密切监控工作，防止所分配的时间超过限制。下面的图 3-4 展示了固定时间和材料合同的两种模式。一种是单纯地固定工作项的数量，另一种是综合考虑时间期限和投资回报率最低界限。
累进时间和材料合同（Graduated time and materials）
另一种方法是共担财务风险法。在敏捷方法中，质量标准是已完成工作的一部分。因此，如果在合同期限之前交付，则可对供应商的高效率进行奖励。相反，如果供应商延迟交付，则将扣除一定费用。
3.5 扩展框架
敏捷团队的规模通常是 5～9 人。若团队的规模显著超过了这个人数，那么就应该采用敏捷的扩展框架以实现对大规模团队的管理。考试中最常出现的敏捷扩展框架是 Scrum of Scrums.
Scrum of Scrums
Scrum of Scrums (SoS) 也称为“meta Scrum”，是由两个或多个 Scrum 团队而不是一个大型 Scrum 团队所使用的一种技术，其中一个团队包含三到九名成员来协调其工作。每个团队的代表会与其他团队代表定期召开会议，可能是每日例会，但通常是一周两次或三次。每日例会的执行方式类似于 Scrum 的每日站会，其中代表将报告已完成的工作、下一步工作设置、任何当前障碍以及可能会阻碍其他团队的潜在未来障碍。其目标是确保团队协调工作并清除障碍，以优化所有团队的效率。
具有多个团队的大型团队可能要求执行 Scrum of Scrum of Scrums，其遵循的模式与 SoS 相同，每个 SoS 代表向更大组织的代表报告，如图 3-5 所示。
