敏捷实践指南

2 敏捷概述

《敏捷宣言》及思维模式

价值观的十二大原则

我们的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求
欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要关于利用需求变更，帮助客户获得竞争优势
要经常交付可用的软件，周期从几周到几个月不等，且越短越好
项目实施过程中，业务人员与开发人员必须始终通力协作
要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务
无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面的交谈
可用的软件是衡量进度的首要衡量标准
敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该都能够始终保持步调稳定
对技术的精益求精以及设计的不断完善将提高敏捷性
简洁，即尽最大可能减少不必要的工作，这是一门艺术
最佳的架构、需求和设计将出息于自组织团队
团队要定期反省怎样做才能更有效，并相应地调整团队的行为

今天所使用的各种敏捷方法都植根于敏捷思维模式、价值观和原则。

在艾哈迈德·西德基（Ahmed Sidky）启发下提出的模式将敏捷明确表述为一种思维模式，它由《敏捷宣言》的价值观所界定，受《敏捷宣言》原则指导，并通过各种实践实现。
敏捷方法和看板方法视为精益方法的子集。它们都是精益思想的具体实例，都反映了诸如以下概念：“关注价值”“小批量”和“消除浪费”。
图2-4 敏捷是许多方法的一个总称

精益与看板方法

共性非常相似，重点在于交付价值、尊重人、减少浪费、透明化、适应变更以及持续改善等方面。

不确定性、风险和生命周期选择

当团队交付小的增量时，他们能够更快更准确地理解真正的客户需求。
图2-5 受斯泰西复杂性模型启发的不确定性和复杂性模型

团队可以用明确稳定的管理要求规划并管理项目，轻松解决各种技术挑战。
迭代和增量方法减少了浪费和返工。这些方法应用了：

非常短的反馈循环
频繁调整过程
重新进行优先级排序
定期更新计划
频繁交付

适用于具有以下特点的项目：

需要研究和开发
变更速度极快
具有不明确或未知的需求、不确定性或风险
最终目标难以描述

当技术和需求的不确定性都很高时（图2-5右上部分），项目就会极端复杂，陷入无序状态。为了使项目尽可能可靠，需要遏制其中一个不确定性变量。

书

《组织变革管理实践指南》

3 生命周期选择

3.1 项目生命周期的特征

表3-1 四种生命周期的特征

图3-1 生命周期的连续区间

3.1.1 预测型生命周期的特征

计划始终贯穿其中

每种生命周期都有计划要素。生命周期的不同之处并非在于计划是否完成，而在于完成了多少计划以及何时完成。
敏捷项目也有计划。主要区别在于，通过对频繁交付的可交付成果的评审，团队将能获得更多的信息，从而在此基础上进行计划和重新计划。无论采用哪种项目生命周期，项目都需要计划。
图3-2 预测型生命周期

3.1.2 迭代型生命周期的特征

迭代型生命周期通过连续的原型或概念验证来改进产品或成果。
当项目复杂性高、变更频繁或当项目范围受到相关方对所需最终产品的不同观点的支配时，采用迭代型生命周期会有优势。迭代型生命周期可能需要更长的时间，因为它是为学习而优化，而不是为交付速度而优化。
图3-3 迭代型生命周期

图3-4 不同大小的增量的生命周期

3.1.3 增量型生命周期的特征

敏捷团队的一个重要差异化优势在于，他们会经常交付商业价值。

3.3 影响裁剪的项目因素

表3-2 改进配合的裁剪方案

4 实施敏捷：创建敏捷环境

仆人式领导为团队赋权

仆人式领导是一种为团队赋权的方法。仆人式领导是通过对团队服务来领导团队的实践，它注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。
仆人式领导的作用是促进团队发现和定义敏捷。仆人式领导实践并传播敏捷。

考虑这些仆人式领导的职责

教育相关方，使其了解为什么要敏捷以及如何敏捷。根据优先级说明商业价值的好处，对被赋权团队加强问责，提高工作效率，并通过更频繁的评审改进质量。
通过指导、鼓励和帮助为团队提供支持。倡导团队成员的培训和职业发展。仆人式领导的一个关键作用是，培养和发展团队成员，帮助他们超越自身当前的角色，即使团队将失去他们也在所不惜。
通过技术项目管理活动，如量化风险分析来帮助团队。
庆祝团队的成功，为团队与外部团队合作提供支持，并起到桥梁作用。

项目经理的价值不在于他们的岗位，而在于他们能够让每个人都变得更好。

敏捷团队

在实践中，最有效的敏捷团队往往由三到九个成员组成。理想情况下，敏捷团队应该集中在一个团队工作场所工作。团队成员100%为专职成员。敏捷鼓励自我管理团队，由团队成员决定谁执行下一阶段定义的范围内的工作。

敏捷的角色

“Ⅰ型人才和T型人才”

有些人在一个领域非常专业，但是，在这个领域之外，他却很少做出贡献。在敏捷领域，这种人被称为“I型人才”，就像字母“I”一样，这种人有深度，但却缺乏广度。
相反，“T型人才”能够通过支持在一个领域补充自身的专业知识，他们在相关领域的技能虽有所欠缺，但拥有良好的合作技能。

专职小组成员

任务切换时，人员工作效率的损失在20%到40%之间。随着任务数量的增加，效率损失会呈指数级增长。

团队工作场所

分散式团队管理沟通的一些技术包括鱼缸窗口和远程结对：

通过在团队分布的各个地点之间建立长期视频会议链接，创建一个鱼缸窗口。每天工作开始时，人们打开链接，工作结束时，关闭链接。

5 实施敏捷：在敏捷环境中交付

项目章程和团队章程

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

解决敏捷项目的挑战

表5-1 敏捷的痛点和解决痛点的可能性

图5-1 剩余故事点的燃尽图

图5-2 显示已完成故事点的燃起图

图5-3 看板面板示例

在制品（WIP）限制位于各列顶部（此处在框中显示），让团队了解如何从看板上提取工作。达到 WIP 限制后，团队就不能将工作从左边提取到下一列。
团队可以在一个功能燃起图/燃尽图和一个产品待办事项列表中衡量已完成的工作。
图5-4 功能图

如果一个团队需要衡量挣值，可以考虑使用燃起图，以图5-6为例：请注意，左边Y轴代表了故事点的范围，右边Y轴代表项目的支出。
图5-6 敏捷背景下的挣值

传统的挣值管理（EVM）衡量指标，如进度绩效指数（SPI）和成本绩效指数（CPI）可以很容易地转换为敏捷术语。例如，如果团队计划在一次迭代中完成30个故事点，但是只完成了25个，那么SPI是25/30或者 0.83（该团队的工作速度只有计划的 83%）。同样，CPI 是迄今为止的劳动价值（已完成的功能值）除以实际的成本，如图5-6所示，2.2M/2.8M=0.79。这意味着，与计划相比，仅能得到79美分的结果（当然，这假定了预测仍然正确）。
图5-7中所示的累积流图显示了看板上进行中的工作。如果一个团队有许多等待测试的故事，测试团队将会扩大。累积工作可一目了然。
团队在处理累积工作方面有困难：团队有进行中的工作，而不是已完成工作。如果团队有大量进行中的工作，就会延迟整体功能的交付。团队交付的时间越长，在相同时间内有更多功能，团队的压力就越大。
图5-7 已完成功能的累积流图