1. 曹刘阳（阿当） 敏捷开发（上） —— 软件工程篇

4. 敏捷从何而来

7. 瀑布开发模型

10. V 模型

39. 敏捷方法七武器

40. XP (Extreme Programming)

44. 价值观和实践 实践是价值观的表现。价值观是在一个高次 上的表达。 理解价值观很重要，因为没有价值观，实践 很快会变成生搬硬套，而行动而行动，缺乏 目的或方向。

45. “…… 你将这华山派的三四十招融合贯通， 设想如何一气呵成，然后全部将它忘了，忘 得干干净净，一招也不可留在心中。待会便 以甚么招数也没有的华山剑法，去跟田伯光 对打。” —— 《笑傲江湖》说“无招胜有招”

46. XP 的 14 个原则 1. 人性化 软件开发通常并不符合人的需要，也没有承 认人性的弱点和平衡人的力量。如果忽视软 件是由“人”编写的，参与者会付出高昂的 代价 —— 例如人员流失、团队氛围糟糕等 。

47. 成为一名优秀的开发者需要什么？ . 基本安全感 没有饥饿、身体伤害，不害怕失去工作 . 成就感 项目成功，为社会产出价值 . 归属感 参与团队并从中得到认可 . 成长 拓展自己的能力和前途的机会 . 亲切感 和团队其它成员之间高度理解和被理解

48. 团队软件开发需要平衡个人和团队的需求。

49. 2. 经济学 必须有人为所有的这些买单。不考虑经济学 的软件开发会有导致空洞单纯的“技术性成 功”的危险。要确定你正在做的东西有商业 价值，符合商业目标和商业需求。

50. 3. 互惠互利 编写代码要保证质量，保证可维护性。不要 试图通过“文档”来保证可维护性，只有代 码是不会骗人的。 编写自动化测试代码、重构代码、统一且清 晰的代码风格。 人人都为明天来维护代码的人多做一点。

51. 4. 自相似性 编写一个大功能和编写一段小代码，开发过 程是一样的，无论大小如何，无论周期长短 ，方式是相同的。

52. 5. 改进 在软件开发中，“完美”是个动词而非形容 词。 不要等到完美才开始做。 马上开始行动，随着时间的推移逐步精化结 果。

53. 6. 多样性 如果一个团队的成员都很相似，那么这个团 队虽然舒适但并不高效。团队需要将不同的 技能、态度以及看待问题的缺陷的视角整合 在一起。 多样性不可避免地伴随着冲突，一个设计有 两种想法，代表的是机会，而不是问题，两 个观点都应该得到重视。

54. 7. 反省 好的团队并不只是进行他们的工作，他们会 思考如何工作和为什么工作。他们会分析为 什么成功或失败。他们不会试图掩藏他们的 错误，而是暴露它们并从中学习。

55. 8. 流 软件开发的流是指通过同时参与所有的开发 活动来交付有价值软件的稳定流。 XP 的实践 倾向于活动的连续流，而不是离散的阶段。 许多团队应对压力的倾向是，减少部署和集 成的频率，从而使程序块更大——但反馈减 少会使风险变大。

56. 9. 机遇 要学会把问题看作改变的机遇。软件开发中 你可以“得过且过”蒙混过关，也可以不断 优化，不断重构保持代码质量。 要将遇到的每个问题当做机遇：个人成长的 机遇、关系升华的机遇、软件改进的机遇。

57. 10. 冗余 软件开发中关键的困难问题应该用几种不同 的方法解决，如果一种方案最终失败了，其 他的方案还可以阻止灾难的发生。 为了保证足够的健壮，冗余是有价值的。虽 然冗余有可能造成浪费，但是小心不要去除 用来验证的冗余。

58. 11. 失败 如果有两三种方法可以选择，但不知道哪种 方式好，与其把时间花在争论上，不如动手 去逐个尝试一遍。 这并不是说，在你真的知道如何能做到更好 的时候故意找借口失败。但当你不知道要怎 么做的时候，冒一点风险失败可能是通向成 功的最短最稳妥的道路。

59. 12. 质量 通过牺牲质量来控制的手段是没有效率的。 质量不是一个控制变量。项目不会因为接受 低质量而加快进度。 时间和费用通常是固定的。 XP 选择了限制范 围作为计划、跟踪和驾驭项目的基本手段。 范围是不可能预先精确知道的，因此它是一 个好的杠杆。

60. 13. 婴儿步 “ 对于你已经知道的方向正确的事，你能做 的最小步骤是什么？” 人们总是试图大步地进行大的转变。毕竟有 一段很长的路要走，而且要在很短时间内抵 达。但突然间发生重大改变是危险的，人们 适应变化的速度毕竟是有限的。

61. 14. 接受责任 责任不能被指派，只能被接受。如果有人试 图给你责任，只有你自己能够决定是否负这 个责任。 责任和权力需要并行，两者错位会扭曲团队 的沟通。当一个过程专家告诉我该怎么工作 ，却不承担这些工作及其后果的时候，权力 和责任就错位了。

62. XP 的 N 个实践 1. 坐到一起 鼓励面对面的交流，用我们所有的感官知觉 进行交流。让开发团队坐到一起。

63. 2. 完整团队 将拥有项目成功所必需的各种技能和视角的 人都包含进团队。一个健康的项目需要热烈 的交互，这些交互应该主要是按团队来进行 组织，而不是以不同的功能组成为单位进行 的。

64. “ 完整团队”的组成是动态的。如果一组技 能或意见变得重要，就将懂得那些技术的人 吸收进团队。如果某个人不再需要，那么他 可以离开团队。

65. 人们需要一种团队的感觉： . 我们属于它 ; . 我们都在其中 ; . 我们相互支持彼此的工作、成长和学习。 人们需要认同感和归属感，周一和周四参与 这个项目，周二、周三、周五参与那个项 目，没有固定的工作伙伴，这样会破坏团队 感，是不利于生产率的。

66. 3. 舒适的工作空间 有白板、任务墙方便张贴、记录。水和小吃 。干净有序。舒适的沙发，方便坐下来交流 。

67. 4. 充满活力的工作 每周工作 40 小时，不要延长工作时间（加班 ）。 只要你可以在有效率的时间内高效地完成工 作就足够了。今天没有效率地透支自己，从 而毁掉接下来两天的工作，这对你和你的团 队都不利。

68. 软件开发是一个洞察力的游戏，而洞察力来 自于准备好的、休息好的和放松的头脑。 超出自己大脑的临界点，只会开始产出不利 于项目的代码。 你生病的时候，安心养病是尊重你自己和团 队其他人最好的方式。

69. 5. 结对编程 所有产品程序的编写都由坐在一台机器前的 两个人完成。他们同时编程（分析、设计和 测试）并尽量编得更好。 结对编程很辛苦，但效果非常好。大部分程 序员同一天不能结对超过 5 或 6 小时。结对时 注意力会高度集中，在身边放瓶水对你的健 康有好处。

70. 经常地轮换结对。每几个小时（甚至几十分 钟）换一次搭档。在结对编程的时候，可以 加强团队的技术交流，使知识在团队中间传 递。当成对的程序员交换搭档时，每个人都 会从其他的某个人那里学到新的知识。 很多程序员在还没有尝试过的情况下就反对 成对编程。但百分之九十学习过结对编程的 程序员都会喜欢上它。

71. 6. 松弛 我记得有两次谈话：一次是和一个有 100 人向其汇报 的中层经理，另外一次是和他的主管经理，在组织 中管着 300 人。我建议中层经理鼓励他的团队只在他 们有信心真正能做到的事情上签字。因为他们很长 时间以来都是高承诺，低交付。“哦，我不能那样 做。如果我不同意激进的（即不现实的）计划，我 会被解雇的。”第二天，我同那个主管经理交谈。 “ 哦，他们从不准时完成，不过无所谓，他们的交 付仍足够我们所需的。”

72. 我一直在直接地观察由他们习惯性的高承诺 所产生的令人难以置信的消耗：难以管理的 缺陷负累，沮丧的士气和敌对的关系。实现 承诺，即使是不起眼的，也会起到消除浪费 的作用。清晰的，真诚的交流会缓解紧张和 可信度。

73. 7. 持续集成 当系统构建是每周或以更低的频率进行时， 通常会陷入“集成的地狱”，在那里所有东 西都不能运行而且没有人知道为什么。 不超过两个小时就对改变的地方进行一次集 成和测试。团队编程并不是分而治之，而是 分散、解决问题然后集成。你等待集成的时 间越长，代价就越高，就越不可预知。

74. 8. 测试驱动开发 在改变任何代码之前先编写一个自动化测试 。 测试驱动开发的节奏是：测试 -> 编码 -> 重构 -> 测试 -> 编码 -> 重构

75. 9. 真实客户参与 （扩展实践） 开发团队中，往往客户代理（产品或运营人 员）被假设成了需求方，然而客户代理和真 实客户之间也许理解有偏差，这加大了项目 的风险。 如果可能的话，尽量将真实客户纳入到团队 中来，直接和真实客户进行沟通和反馈。

76. 10. 增量部署 （扩展实践） 在更换遗留系统时，从项目早期阶段就要开 始逐步承担遗留系统的负荷。 如果几个月没有添加新功能，而只是为了某 一天将 N 个新功能一次性部署。员工们长时间 工作并且周末加班，即使部署成功了，大家 也会疲劳过度，几周或几个月内都不能恢复 有效的开发。如果部署没有成功，新系统被 迫下马，成本甚至会更高。

78. 10. 团队连续性 （扩展实践） 在大组织中有一种趋势，那就是将人抽象成 物品：即插即用的编程单元。 软件中价值的创造不仅取决于开发人员所知 道的和所做的，也取决于他们之间的关系以 及他们共同完成的事情。不要忽视关系和信 任的价值。

79. 大组织常常忽视团队的价值，把“编程资源” 比喻成分子 / 流体。一旦项目完成了，他们重 新回到“池”中。这种调度的目标是充分利 用所有的程序员。 这种策略可以将微观效率最大化，但是会破 坏组织的整体效率，它追求让每个个体都忙 于敲打键盘的虚幻效率，而忽略了让员工尽 量与熟悉和信任的同事一起工作的价值。

80. 11. 代码集体所有制 （扩展实践） 除了“每个人都为自己”之外，还有其他的 团队合作模式。团队成员可以共同承担责任 。团队里的任何人可以在任何时候改善系统 的任何部分。 集体所有是把双刃剑，在团队培养出集体责 任感以前，没有人负责，质量也就会下降。 成员会不顾团队整体结果地加以修改。

81. 12. 每日部署 （扩展实践） 每天晚上都需要将新代码整合到产品中。因 为程序员本地和产品之间的任何差距都有风 险。 每日部署很难实现，它有很多先决条件：缺 陷率非常低、部署工具必须是自动化的，具 有增量产出和失败回滚的能力。

83. 从一开始就选择正确的做法，不是 更容易吗？

105. Scrum

111. Scrum 中的角色 你是鸡还是猪？

112. 你对项目的开发工作直接负责吗？ 是：猪类人员 —— 开发团队、 scrum master 、产品负责人。 否：鸡类人员 —— 高层管理人员、运营、市 场人员和客户

121. Scrum 流程框架图

122. Scrum 框架

127. Scrum master vs 项目经理 丰田汽车制造部总裁盖里 . 康维斯指出： 在一个健康、兴盛的工作环境中，经理的角 色不是“强行发挥意志力，下达命令，而是 做出表率，给予指导，充分理解，并协助他 人实现目标，从而打造企业环境”

128. scrum master 并不是司令官，并不给团队直 接分配工作，和传统项目经理的区别在于团 队并不围绕 scrum master 工作，团队是自行 管理的，而 scrum master 更像是牧羊犬，守 护羊群（开发团队）免受恶狼（产品负责人 和鸡类人员）的袭击。 scrum master 是 scrum 的灵魂人物，他引导整 个项目按照正确的方式运行。虽然不参与开 发，但其实工作量毫不轻松。

129. 场景 4 在一个大房间里， 9 位开发人员正在工作。 scrum master 开始进行每日会议。该 scrum master 首先拿出一张清单。他细读清 单条目，绕房间一周，询问在场的每位开发人员是否完成了写在其名字旁边的工 作任务。他提出问题，如“玛丽，你完成我昨天布置的屏幕设计任务了吗？今天 准备好设计其中的对话框了吗？”在检查完清单中的任务并与屋内所有人谈话后 ，他询问团队是否需要其帮助。所有成员都保持沉默。

130. 传统项目管理方法里，项目经理制定任务计 划，督促团队完成。他是项目的控制者。 scrum master 的权力通常是间接的，它是建 导者，为团队提供帮助，但并不直接控制团 队。

131. scrum 强大的地方在于团队自管理时会涌现出 强大的生产力，当人们依靠自身力量设法解 决问题时，会产生强烈的责任感。团队处理 和解决问题的能力是 scrum 的核心，也是 scrum 团队强大生产力的基础。而传统项目经 理的角色会扼杀这种团队自管理的能力。

135. Sprint 周期的长短 如果周期过长，团队会在项目之初表现过于 松懈，到了项目中期开始紧张，项目后期拼 命加班弥补前期的松懈。 造成的后果： 1 ）团队会在项目后期经受非常大的压力。 2 ）代码质量不高，缺陷率大。

136. 另外，周期长会妨碍产品负责人对软件功能 的控制。过长的周期无法让产品负责人对功 能的修改做出更及时的响应。 短周期 = 更频繁的交付 = 更频繁的客户反 馈 = 在错误方向上花的时间更少 = 学习和 改进的速度更快

137. 但周期短会有如下问题： 1 ）开发团队无法集中精神创造价值，刚进入 状态周期就结束了。 2 ）会让计划会议和评审会议过多，时间消耗 较大。 3 ）每周期评审会议上，团队能交付的产品增 量过少，甚至无法给出产品增量。

138. Sprint 周期的长短需要权衡，既保证团队在一 定时间内全身心投入工作不受外界打扰，进 入“流”的状态，又保证周期长度不至于让 产品负责人和鸡类人员无法忍受。 肯思瓦伯建议 sprint 周期最好为一个月。《硝 烟中的 scrum 和 xp 》作者建议最好为三周。

151. 常见任务墙

152. Outlook 的便签实现的任务墙

158. Scrum 计划会议 会议前产品负责人需准备好产品 backlog 。 产品 backlog 不一定要那么精确，但必须清晰 ，产品负责人须知道每个用户故事的意思， 并排好优先级。优先级建议用 0~150 分来标 示。

159. 计划会议解决两个问题：“做什么”和“怎 么做”。 “ 做什么”用 4 个小时讨论，产品负责人通过 产品 backlog 告诉开发团队做什么。 “ 怎么做”用 4 个小时讨论，开发团队拆解产 品 backlog ，形成 sprint backlog ，想出“怎么 做”。这个过程开发团队会不停地跟产品负 责人询问用户故事的细节。

160. 计划会议的最后，开发团队会告诉产品负责 人各个故事的开发任务量，由产品负责人确 认本轮次要实现的用户故事。 产品负责人不能强制要求本轮次必须完成的 用户故事，也不能“帮助”开发团队完成各 任务的时间预估。预估是开发团队的独有的 权利。

161. 计划会议非常重要，如果计划会议存在问题 ，将影响整个轮次的顺利进展。

163. 如果产品负责人期望的故事，开发团队认为 本轮次中做不了。产品负责人想在 D 也能在本 轮次中实现。

164. 选择一，调整优先级，把 D 放到前面，扔掉 C 。

165. 选择二，减弱 A 的功能。

166. 选择三，将 A 拆分成两个用户故事，在本轮次 中实现 A1 ，而 A2 留在下个轮次中实现。

167. “ 完成”的定义 当有人声称某一功能已经“完成”，其真实 含义是什么？ 一些人可能认为它已完全通过编程、重构、 单元测试、构建和验收测试阶段。 另一些人可能认为功能刚刚完成编程。

168. Scrum 会要求每一轮次切实完成一些功能， 这个“完成”指的是经过充分测试、重构、 精心编写而成的代码，可立即部署至生产环 境上。 在每个轮次的“评审会议”上，要展示的是 已“完成”的功能，开发至一半的功能不必 展示。

169. 估算 有两次方式：直觉和生产率计算。 估算时最好两者结合起来使用。

170. Scrum master ：“伙计们，我们在这个 sprint 里面能完成 故事 A 吗？” Lisa ：“呃。当然可以。我们有三个星期，这只是个微不 足道的特性。 Scrum master ：“ OK ，那加上 B 怎么样？” Tom 和 Lisa 一起回答：“自然没问题。” Scrum master ：“ OK ，那 A 、 B 、 C 一起呢？” Sam （对产品负责人说）：“故事 C 要包括高级错误处理么 ？” 产品负责人：“不，你现在可以跳过它，只需要完成基本的 错误处理。” Sam ：“那 C 应该没问题。” Scrum master ：“ OK ，那再加上 D 呢？” Lisa ：“嗯……”

171. Tom ：“我觉得能完成。” Scrum master ：“有多少把握？ 90% ？还是 50% ？” Lisa 和 Tom ：“差不多 90% ” Scrum master ：“ OK ， D 也加进来。那再加上 E 呢？” Sam ：“也许吧。” Scrum master ：“ 90%? 50%?” Sam ：“差不多 50%” Lisa ：“我没把握。” Scrum master ：“ OK ，那先把它放一边去。我们要做完 A 、 B 、 C 和 D 。如果有时间的话当然还可以做完 E ，不过既然没人 指望它能做完，所以我们不会把它算到计划里面来。现在怎 么样？” 所有人：“ OK ！”

172. 计算生产力，不考虑团员之间能力的差别， 按人 * 天数得出粗略的值，这个值称为“故事 点”。 “ 故事点”理解为“理想情况下，团队成员 在完全不受打扰，完美、高效没有疲劳造成 的消耗的情况下的生产力”，而且还要假设 “ 团队不会生病，不会请假”。当然这样的 假设绝对是不可能的，所以“故事点”并不 等于生产力。

173. 生产力 = 故事点 * 投入度 “ 投入度”根据上个轮次的实施情况、本轮 次中可能出现的节假日等多方面因素而确定 ，在计划会议上，团队成员会告诉 scrum master 本轮次的投入度，也许是 60% ，也许 是 70% ，但永远不可能是 100% 。 一般默认“投入度”为 70% 。

174. “ 投入度”低表示团队估计会受到很大干扰 ，或者他们觉得自己的时间估算太过理想化 。 “ 投入度”的估算准确与否，可以参考前面 几个轮次的“投入度”的平均值。

175. 每个 sprint backlog 需要多少时间？ 每个开发团队成员可能都有不同的预期值。 谁先回答，都可能影响其他成员发表自己的 观点。 我们可以借助“计划纸牌”。

176. 计划纸牌

177. 每个人都会拿到一幅计划纸牌，然后 scrum master 会让开发团队估算 sprint backlog 的 时间。每人拿一张自己估算对应的时间，反 面扣在桌子上，每个人都被迫自己进行思考 ，不能依赖其他人估算的结果。 如果每个人估算结果相近，那么时间不会出 现较大误判。如果有人的估算结果差异特别 大，那么需要大家一起讨论是否忽略了什么 。

178. 牌的数值不是连续的，而是几个有代表性的 ，数值代表的是故事点。数值不连续，所以 它并不是那么精确，而是一个大概的估算。 几张特殊的牌。 0 ：“这个故事已经完成了”或者“这个故事 根本没啥东西，几分钟就能搞定”。 ？：“我一点概念都没有。没想法。” 咖啡杯：“我太累了，先歇会儿吧。”

179. Scrum 如何处理权利与责任 鸡类人员严禁直接对开发团队发出指令！ 鸡类人员如果有需求，唯一的接口人是产品 负责人 产品负责人可以对开发团队提出需求，但必 须遵守游戏规则，只能在 sprint 周期之初的计 划会议上提出。

180. 如果有紧急情况出现，一定要在 sprint 开发周 期内调整计划，可以和 scrum master 协商， 立即中止当前 sprint ，并重新召开计划会议。 但产品负责人要承担更改计划带来的相应的 时间损失。 产品负责人有权在计划会议上提出需求，并 指定各条需求的优先级。但产品负责人无权 指定开发任务量。

181. 开发团队有权接受开发任务量，有责任在本 Sprint 结束时，交付承诺的开发任务。开发团 队有权拒绝鸡类人员的指令，并向 scrum master 反映。

182. scrum master 有权在计划会议上和团队协商 本 sprint 周期内开发任务量，有权对团队进行 调整以适应敏捷开发的需要。 scrum master 有责任主持计划会议、每日站立会议和项目 评审会议，有责任帮助团队在开发周期内免 受外界干扰。

183. 项目最终交付日期 预估最终交付日期 项目有最终将付日期吗？

184. 完美是个动词，所以没有最终交付日期。我 不能告诉你，从北京到上海，我会在哪一天 哪一点到，我能告诉你的是“我会一路上尽 最快的速度往上海去，我保证路上不会犯大 的错误延误时间，我知道我一路都是按最正 确的选择在前进，但我不知道哪天会到达”

193. THANKS ！