敏捷开发（上）- 软件工程篇
193
曹曹曹 曹曹曹 （） 敏敏敏敏 敏敏 （） —— 敏敏敏敏敏
Transcript of 敏捷开发（上）- 软件工程篇
曹刘阳（阿当）
敏捷开发（上）
—— 软件工程篇
目录
• 敏捷从何而来• XP• Scrum
敏捷从何而来
软件危机20 世纪 60 、 70 年代爆发
软件危机的具体体现 ：1. 软件开发进度难以预测 2. 软件开发成本难以控制 3. 用户对产品功能难以满足 4. 软件产品质量无法保证 5. 软件产品难以维护 6. 软件缺少适当的文档资料
软件工程20 世纪 80 年提出“软件工程”
软件生命周期 6 步骤：1. 计划2. 需求分析3. 设计4. 编码5. 测试6. 维护
瀑布开发模型
场景 1X 项目采用了瀑布式开发模型，在历经了 N 重困难之后，终于代码开发完毕。因为设计、编码的一再延期，导致项目进度延迟，到这时时间已经很紧张了，开发人员将开发代码组装并进行了简单测试后交给测试人员，测试人员熟悉系统后开始系统测试，但是将开发人员提交过来的编译代码部署后系统无法正常运行，开发又几经修改，测试方可进行，在系统交付日期的逼近下，项目经理、 team leader 、测试人员和开发人员又连续加班共同解决了一些 bug ，终于进行了一天系统的压力测试。项目经理宣布提交系统。
但是技服人员给客户部署系统时，经常发现莫名其妙地死机，几个未眠之夜也没有解决系统瘫痪问题，用户恼怒了。公司高层连夜派 M 项目经理和团队成员进行现场支持，又经过多天的修改和测试， X 项目开发团队才忐忑离开。然而试运行期间又多次瘫痪和救急，让 X 项目团队顾不应暇。项目经理召开会议总结，开发人员认为测试人员测试不认真，测试人员认为主要责任并不在他们，激烈争吵并反目。到底是谁的问题呢？
瀑布开发模型的缺点 1
测试推迟到项目生命周期的最后阶段进行，当系统出现严重错误并且修改代价很大时，推迟发布日期在所难免。
开发过程中，测试人员处于长期空闲状态。
V 模型
V 模型
将测试开始时间提前，设计和测试两条线并行。瀑布开发模型的一种变形。
场景 2X 项目组开发的系统终于开始在客户方运行，但是随着用户对系统的使用和熟悉程度的加深却批评不断。很多地方来源于双方对需求理解不一致，一些用户需要的功能没有实现，开发的功能又不符合用户的习惯，而且因为设计时没有过多考虑松耦合的原因，变更非常花费时间，甚至有些必需的变更无法实现。 M 项目
经理多次进行协调，项目团队日夜加班，修改用户抱怨极大和比较紧迫的问题，项目延迟加剧，面对用户的指责和公司的不满，项目经理和开发团队疲惫不堪。
瀑布开发模型的缺点 2
瀑布开发模型和 V 模型最突出的缺点是缺乏灵活性，特别是无法解决因软件需求不准确而直接导致最后一些致命性后果出现。这些致命性后果往往直到开发过程最后快完成时才会被人察觉到。
解决方法 1 —— 强化设计和规范
瀑布开发模型是最容易接受和理解的开发方式。
一部分人坚守瀑布开发方式，在“设计”阶段上花费大量时间，争取在“编码”阶段前设计出弹性高、扩展性好的架构设计。并强化规范和文档的作用，用规范约束开发团队，用文档进行沟通，尽量依靠规范和文档使开发过程平滑。
“ 设计”阶段需要考虑各种情况，花费大量时间，导致“编码”阶段非常靠后，用户很久之后才能看到系统，风险高。
即使再小心，也仍然会有遗漏的盲点。为减少盲点，需要加强设计的深度。
“ 设计”进行了大半，需求变更了，容易导致之前的设计浪费，“过度设计”。
缺点
瀑布型开发更多地考虑了做事的流程和规范，而没有考虑人的因素。
“铁打营盘流水兵”，只强调过程重要性，而把人看作过程中可随便即插即用的插件。
弗雷德里克 . 泰勒是第一个工业工程师。创建
了整个工业工程学科。
泰勒主义在技术上、社会上和经济上带来了巨大且深远的影响。
泰勒主义和人月神话
泰勒主义中社会工程学里的第一个步骤是分离计划与执行。即由受过教育的工程师决定工作该怎样做及会持续多长时间，而工人们必须完全忠实地在额定时间内按指定的方式完成指定工作，两相协调，工作才能良好的运转。
在这种信条里，工人们只是机器中的齿轮，尽管没有人想把自己当作齿轮。
泰勒主义社会工程学的第二个步骤是要创建一个单独的质量部门。泰勒假定工人无论何时都是“小兵”（那些工作得又慢又差，但当被注意时就不是如此的慢或差的人）。为此，他创建了一个单独的质量控制部门来确保工人不仅以正确的速度并且用指定的方式工作，目的就是为了达到满足要求的质量级别。
许多软件开发组织都有单独的质量组织： QA。单独的质量部门传递了这样的信息：质量对于工程而言如同市场和销售一样重要，而且工程学和质量是分离和并行的，也就是说，高效地软件开发方法论不用考虑质量问题。工程组中没有人为质量负责，而是由别的人来负责。
泰勒主义有一些严重的缺点，来自于三个简单化了的假设：
1 ）事情通常会按照计划进行。2 ）微观的优化可导致宏观的优化。3 ）人通常是可替换的，需要预先被告知要
他们做什么。
对于传统的流水线生产，复杂度非常低，泰勒主义能很好的工作。但对于复杂的软件开发，它很难适用。
在流水线上，用人数和时间来简单估算生产力是有效的，但在软件开发中，有人数 *时
间来估算生产力，而忽视了“人”，只能是“ 人月神话”。
解决方法 2 —— 敏捷开发
另一种思路，放弃严谨到苛刻的瀑布式开发方式，重视软件开发中的“人”。
“我越是有人情味地对待我自己和别人，我们大家的生产率就越高，成功的关键不在于自我禁欲，而在于承认我们是人，我们生活在人与人之间交往的环境中。”
—— XP极限编程创造者 肯贝克
肯斯瓦伯的回忆客户依照过往经验可推知，团队一般不会正常交付系统，而系统符合客户需求的可能性更加微科其微。
团队的经验则告诉他们，客户一般变化无常，往往在团队确定开发内容时，改变主意。
我开始从事软件开发时，客户参与及合作不是问题。 20 世纪 60 年代，计算机功能不像现在这般强大，使用者较少，应用也较为简单，而所谓里程碑甚至不为人知。我利用 1~2 天的短迭代周期，与客户见面，在纸上草拟出其需求。我们探讨当中的问题，直至我理解透。然后，我将伏案设计，为方案编程，为程序卡打孔，并编译程序。当编译和链接不出错后，我会使用测试数据运行程序。最后，我找客户询问：“这是不是你要的？”那时我们还未意识到，合作竟可以如此简单。
由于应用软件和技术愈发复杂，项目牵涉的利益相关方也更多，于是一些新的实践方法便被使用，以协调众多参与者之间的交流。例如，当项目涉及多位利益相关者时，团队会在开发工作之前，收集各方需求的信息。我们认为系统应满足各方的需求总和。由于文字文档作为交流工具已不能满足需要，我们便开始使用图片配以文本的方式。由于图片的精准度不足，我们开发出建模技术，以表达图片信息。上述每一措施均导致利益相关者和开发者之间的隔膜逐步加深。面对面交流被文档代替。短平快逐渐变成漫长的需求信息收集阶段。
“ 瀑布式方法”的引入，包含了顺序开发的所有缺点。该方法收集全部需求信息，制定设计，编写代码，开发并运行测试，最后实施系统。它通过评审会议连接各个步骤（阶段）。利益相关者受邀参加会议，审核当前为止的进展情况。
开发人员和管理者向客户提问：“我们所收集的需求信息及其展示模型，是否全面精准地表达了你们的需要？一旦给出肯定答复，改变主意的成本将更加昂贵！”
但其实此时用户连产品都没见着，他们其实很难凭着空想，得出“没问题，就是它”的结论，但用户此时被逼给出答复。对立由此开始。
“敏捷”一词如何解释？单从字面理解“敏捷”两字，“敏捷”是什么意思？
敏捷 = 快速 + 灵活
敏捷宣言1. 个体和交互胜过过程和工具。人是获得成功最重要的因素，团队的构建比环境的构建更重要。
2. 可以工作的软件胜过面面俱到的文档。编制和维护众多的文档需要花费大量的时间，最好的两份文档是代码和团队。代码可读性要高，代码即文档。团队的面对面沟通，比起文档更高效。
3. 客户合作胜过合同谈判。瀑布式开发会在需求分析阶段要求与客户制定一个“重量型”无比细致的合同，在进入编码阶段前会封锁需求，不允许用户随便更改需求，合同会成为日后谈判时的武器。敏捷开发提倡和客户“合作”，而非“对立”。
4.响应变化胜过遵循计划。响应变化的能力常常决定着一个项目的成败，比时刻遵循一份详细的计划更能灵活地适应项目的发展。保持长期计划的粗略性使其保持相应变化的灵活性。
5.精益求精胜过简单执行。保持代码的品质，不要以仅满足需求为目标，还要保证代码的高品质。（此条为追加的）
敏捷 12条原则1.我们最优先要做的是通过尽早、持续地交付有价值的软件来使客户满意。
2. 在项目的整个开发期间，业务人员和开发人员必须天天在一起工作。
3.即使到了开发后期，也欢迎需求变化。
4. 经常性地交付可以工作的软件。
5. 可以工作的软件是主要的进度度量标准。
6.围绕被激励起的个体来构建项目。为他们提供所需的环境和支持，并信任他们能胜任工作。
7. 最好的架构、需求和设计来自于自组织的团队。
8. 在团队内部，最有效果和最有效率的传递信息的方法是面对面地交流。
9. 敏捷过程提倡可持续的开发速度。
10. 不断地关注最优秀的技术和良好的设计能增强敏捷能力。
11. 简单是根本的。
12. 开发团队每隔一定时间，都会对如何能有效地工
作进行反省，然后相应地对自己的行为进行调整。
敏捷方法七武器
XP (Extreme Programming)
XP 的 5 个价值观1.沟通
2.反馈
3.简单
4.勇气
5.尊重
场景 3会议室中。
项目经理、市场人员：“哦，对，需求说明书上有点问题，但我们需要马上去做这个东西。系统上线时少不了它。每个人都需要它。它只是个小小的改动。这一定很容易轮到，你们很快就能做出来。”
当你听着他们根据著名的“需要”、“一定”、“容易”、“很快”猜想而得出的要求，你该怎么回答？
你不能控制别人的期望，但你可以告诉他们你所知道的关于项目的所有事情，这样他们的期望才有跟现实匹配的可能性。
“管理”其他人的期望不是我的工作，而是他们自己需要操心的，我要做的就是尽可能地沟通清楚。
价值观和实践
实践是价值观的表现。价值观是在一个高次上的表达。
理解价值观很重要，因为没有价值观，实践很快会变成生搬硬套，而行动而行动，缺乏目的或方向。
“ ……你将这华山派的三四十招融合贯通，设想如何一气呵成，然后全部将它忘了，忘得干干净净，一招也不可留在心中。待会便以甚么招数也没有的华山剑法，去跟田伯光对打。”
——《笑傲江湖》说“无招胜有招”
XP 的 14 个原则
1. 人性化
软件开发通常并不符合人的需要，也没有承认人性的弱点和平衡人的力量。如果忽视软件是由“人”编写的，参与者会付出高昂的代价 —— 例如人员流失、团队氛围糟糕等。
成为一名优秀的开发者需要什么？
. 基本安全感 没有饥饿、身体伤害，不害怕失去工作
. 成就感 项目成功，为社会产出价值
. 归属感 参与团队并从中得到认可
. 成长 拓展自己的能力和前途的机会
. 亲切感 和团队其它成员之间高度理解和被理解
团队软件开发需要平衡个人和团队的需求。
2. 经济学
必须有人为所有的这些买单。不考虑经济学的软件开发会有导致空洞单纯的“技术性成功”的危险。要确定你正在做的东西有商业价值，符合商业目标和商业需求。
3.互惠互利
编写代码要保证质量，保证可维护性。不要试图通过“文档”来保证可维护性，只有代码是不会骗人的。
编写自动化测试代码、重构代码、统一且清晰的代码风格。
人人都为明天来维护代码的人多做一点。
4.自相似性
编写一个大功能和编写一段小代码，开发过程是一样的，无论大小如何，无论周期长短，方式是相同的。
5. 改进
在软件开发中，“完美”是个动词而非形容词。
不要等到完美才开始做。
马上开始行动，随着时间的推移逐步精化结果。
6. 多样性
如果一个团队的成员都很相似，那么这个团队虽然舒适但并不高效。团队需要将不同的技能、态度以及看待问题的缺陷的视角整合在一起。
多样性不可避免地伴随着冲突，一个设计有两种想法，代表的是机会，而不是问题，两个观点都应该得到重视。
7. 反省
好的团队并不只是进行他们的工作，他们会思考如何工作和为什么工作。他们会分析为什么成功或失败。他们不会试图掩藏他们的错误，而是暴露它们并从中学习。
8.流
软件开发的流是指通过同时参与所有的开发活动来交付有价值软件的稳定流。 XP 的实践倾向于活动的连续流，而不是离散的阶段。
许多团队应对压力的倾向是，减少部署和集成的频率，从而使程序块更大——但反馈减少会使风险变大。
9. 机遇
要学会把问题看作改变的机遇。软件开发中你可以“得过且过”蒙混过关，也可以不断优化，不断重构保持代码质量。
要将遇到的每个问题当做机遇：个人成长的机遇、关系升华的机遇、软件改进的机遇。
10.冗余
软件开发中关键的困难问题应该用几种不同的方法解决，如果一种方案最终失败了，其他的方案还可以阻止灾难的发生。
为了保证足够的健壮，冗余是有价值的。虽然冗余有可能造成浪费，但是小心不要去除用来验证的冗余。
11.失败
如果有两三种方法可以选择，但不知道哪种方式好，与其把时间花在争论上，不如动手去逐个尝试一遍。
这并不是说，在你真的知道如何能做到更好的时候故意找借口失败。但当你不知道要怎么做的时候，冒一点风险失败可能是通向成功的最短最稳妥的道路。
12. 质量
通过牺牲质量来控制的手段是没有效率的。质量不是一个控制变量。项目不会因为接受低质量而加快进度。
时间和费用通常是固定的。 XP选择了限制范围作为计划、跟踪和驾驭项目的基本手段。范围是不可能预先精确知道的，因此它是一个好的杠杆。
13.婴儿步
“ 对于你已经知道的方向正确的事，你能做的最小步骤是什么？”
人们总是试图大步地进行大的转变。毕竟有一段很长的路要走，而且要在很短时间内抵达。但突然间发生重大改变是危险的，人们适应变化的速度毕竟是有限的。
14.接受责任
责任不能被指派，只能被接受。如果有人试图给你责任，只有你自己能够决定是否负这个责任。
责任和权力需要并行，两者错位会扭曲团队的沟通。当一个过程专家告诉我该怎么工作，却不承担这些工作及其后果的时候，权力和责任就错位了。
XP 的 N 个实践
1.坐到一起
鼓励面对面的交流，用我们所有的感官知觉进行交流。让开发团队坐到一起。
2. 完整团队
将拥有项目成功所必需的各种技能和视角的人都包含进团队。一个健康的项目需要热烈的交互，这些交互应该主要是按团队来进行组织，而不是以不同的功能组成为单位进行的。
“ 完整团队”的组成是动态的。如果一组技能或意见变得重要，就将懂得那些技术的人吸收进团队。如果某个人不再需要，那么他可以离开团队。
人们需要一种团队的感觉：.我们属于它 ;.我们都在其中 ;.我们相互支持彼此的工作、成长和学习。
人们需要认同感和归属感，周一和周四参与这个项目，周二、周三、周五参与那个项目，没有固定的工作伙伴，这样会破坏团队感，是不利于生产率的。
3.舒适的工作空间
有白板、任务墙方便张贴、记录。水和小吃。干净有序。舒适的沙发，方便坐下来交流。
4.充满活力的工作
每周工作 40小时，不要延长工作时间（加班）。
只要你可以在有效率的时间内高效地完成工作就足够了。今天没有效率地透支自己，从而毁掉接下来两天的工作，这对你和你的团队都不利。
软件开发是一个洞察力的游戏，而洞察力来自于准备好的、休息好的和放松的头脑。
超出自己大脑的临界点，只会开始产出不利于项目的代码。
你生病的时候，安心养病是尊重你自己和团队其他人最好的方式。
5. 结对编程
所有产品程序的编写都由坐在一台机器前的两个人完成。他们同时编程（分析、设计和测试）并尽量编得更好。
结对编程很辛苦，但效果非常好。大部分程序员同一天不能结对超过 5 或 6 小时。结对
时注意力会高度集中，在身边放瓶水对你的健康有好处。
经常地轮换结对。每几个小时（甚至几十分钟）换一次搭档。在结对编程的时候，可以加强团队的技术交流，使知识在团队中间传递。当成对的程序员交换搭档时，每个人都会从其他的某个人那里学到新的知识。
很多程序员在还没有尝试过的情况下就反对成对编程。但百分之九十学习过结对编程的程序员都会喜欢上它。
6.松弛
我记得有两次谈话：一次是和一个有 100 人向其汇报的中层经理，另外一次是和他的主管经理，在组织中管着 300 人。我建议中层经理鼓励他的团队只在他们有信心真正能做到的事情上签字。因为他们很长时间以来都是高承诺，低交付。“哦，我不能那样做。如果我不同意激进的（即不现实的）计划，我会被解雇的。”第二天，我同那个主管经理交谈。“哦，他们从不准时完成，不过无所谓，他们的交付仍足够我们所需的。”
我一直在直接地观察由他们习惯性的高承诺所产生的令人难以置信的消耗：难以管理的缺陷负累，沮丧的士气和敌对的关系。实现承诺，即使是不起眼的，也会起到消除浪费的作用。清晰的，真诚的交流会缓解紧张和可信度。
7. 持续集成
当系统构建是每周或以更低的频率进行时，通常会陷入“集成的地狱”，在那里所有东西都不能运行而且没有人知道为什么。
不超过两个小时就对改变的地方进行一次集成和测试。团队编程并不是分而治之，而是分散、解决问题然后集成。你等待集成的时间越长，代价就越高，就越不可预知。
8. 测试驱动开发
在改变任何代码之前先编写一个自动化测试。
测试驱动开发的节奏是：测试 -> 编码 -> 重构 -> 测试 -> 编码 -> 重构
9. 真实客户参与 （扩展实践）
开发团队中，往往客户代理（产品或运营人员）被假设成了需求方，然而客户代理和真实客户之间也许理解有偏差，这加大了项目的风险。
如果可能的话，尽量将真实客户纳入到团队中来，直接和真实客户进行沟通和反馈。
10.增量部署 （扩展实践）
在更换遗留系统时，从项目早期阶段就要开始逐步承担遗留系统的负荷。
如果几个月没有添加新功能，而只是为了某一天将 N 个新功能一次性部署。员工们长时间工作并且周末加班，即使部署成功了，大家也会疲劳过度，几周或几个月内都不能恢复有效的开发。如果部署没有成功，新系统被迫下马，成本甚至会更高。
找到你能马上处理的一小块功能或少量的数据集，并部署它。
10. 团队连续性 （扩展实践）
在大组织中有一种趋势，那就是将人抽象成物品：即插即用的编程单元。
软件中价值的创造不仅取决于开发人员所知道的和所做的，也取决于他们之间的关系以及他们共同完成的事情。不要忽视关系和信任的价值。
大组织常常忽视团队的价值，把“编程资源”比喻成分子 /流体。一旦项目完成了，他们
重新回到“池”中。这种调度的目标是充分利用所有的程序员。
这种策略可以将微观效率最大化，但是会破坏组织的整体效率，它追求让每个个体都忙于敲打键盘的虚幻效率，而忽略了让员工尽量与熟悉和信任的同事一起工作的价值。
11. 代码集体所有制 （扩展实践）
除了“每个人都为自己”之外，还有其他的团队合作模式。团队成员可以共同承担责任。团队里的任何人可以在任何时候改善系统的任何部分。
集体所有是把双刃剑，在团队培养出集体责任感以前，没有人负责，质量也就会下降。成员会不顾团队整体结果地加以修改。
12.每日部署 （扩展实践）
每天晚上都需要将新代码整合到产品中。因为程序员本地和产品之间的任何差距都有风险。
每日部署很难实现，它有很多先决条件：缺陷率非常低、部署工具必须是自动化的，具有增量产出和失败回滚的能力。
简单设计1.并非要你思考过于简单而无效的东西，只是要求调整你的思想以消除多余的复杂部分。简单的意义与具体的环境相关，它是相对的。
2. 简单设计需要持续更新，昨天的需求，你的设计简单而且足够好，但今天的需求它已经不再是最好的了，那么你需要重构它，让它面对新需求变成最简单而实用的。
从一开始就选择正确的做法，不是更容易吗？
当然可以，除了三件事情：
1.我们可能不知道“正确”的做法是什么。如果我们正在解决一个全新的问题，也许有几种有效的解决方案，也许根本没有明确的解决方案。
2.今天正确的东西明天可能就是错误的。
3.今天按照“正确”的做法去做每一件事，可能需要太长时间，以至于还没有完成之前，明天的环境的变化就使之失效了。
设计过于简单，前期没有考虑清楚，常常是工程师和架构师、产品设计人员争吵的根源。
的确，软件工程不比房屋建设，在房屋建设如果前期没有考虑清楚，地基全都打好了，却在后面改设计，成本是巨大的。
软件工程没有实物，所以常常被产品人员认为“修改成本低，变化没有那么大不了”，而其实修改远没有产品人员想象中那么简单。
产品人员指责工程师开发速度慢，响应修改慢甚至拒绝修改。
工程师指责产品人员前期考虑不周到，不断地变化设计和需求。
产品人员和工程师应该互相尊重和理解。
综合来看，简单设计，渐进加强是最有利于项目开发的方式。修改再所难免。
一方面产品人员需要尊重工程师，重视“修改”的难度 ;另一方面，工程师需要提高代
码质量，在编写代码的过程中随时准备迎接修改。
简单设计是有前提条件的，它必须依赖于技术上的灵活性，代码质量必须非常高，易于修改。这对工程师是巨大的挑战，也是为什么“敏捷很难”的重要原因之一。
（在《敏捷开发》下集——“编码篇”的 ppt中会跟各位分享。）
重构与时间坚持瀑布式的人认为“在前期花足够的时间构思”，在进行编码时会非常顺利，减少了反复修改调试的时间，用不着“重构”这种频繁且麻烦的步骤。
花足够的时间进行设计，然后才开始动手，虽然前期看起来似乎在浪费时间，但因为后面阶段的一帆风顺，从总体上看其实是在节省时间。
但前期花大量时间构思，一方面严重拖后了客户实际见到产品的时间，增大了需求理解有误的“需求风险” ;另一方面，如果构思不够严谨，仍然有没考虑到的问题，可能导致整个前期构思作废，设计变成了“过度设计”，加大了构思这一过程本身的“技术风险”。
如果一切顺利，前期构思完全正确，需求理解没有偏差，技术上的灵活性能很好适应各种“变更”的需求，那么瀑布式开发的确是最节省时间的开发方式。
但这种时间上的快速，付出了“高风险”的代价。很可能因为风险而让开发成本成倍上升。
敏捷开发的简单设计、反复重构、增量开发的思路，加快了客户见到产品的时间——哪怕它只是个简单粗糙的原型，降低了需求理解有误的风险。不断重构，承认昨天最好的方案，并不一定仍是今天最好的方案，每次做到新设计的最优方案即可，无需过度设计，降低了技术上的风险。
时间上比一次性成功的瀑布式开发要慢，但风险非常小。
你如何画圆？
计划与范围计划可以使目标和方向清楚而明确。但计划是复杂的，因为对故事的成本及价值的估算是不确定的，即我们赖以做出决定的信息是变化的。
所以计划不是对未来的预测。计划至多通过表达你今天所知道的来估计明天也许会发生的事情。
“当我还是个年轻的软件工程师时，学会了根据三个变量来管理项目：即速度、质量和价格。项目发起人会设定其中的两个变量，而团队则评估第三个。
这个模型在实践中运行得并不好。时间和成本通常在项目范围之外确定，这使得质量成为你唯一能够操作的变量。”
“降低你工作的质量并不能减少工作量，这只是把工作推后，以这种方式制造的工作进展是假象。不但为以后的开发工作埋下了地雷，同时也减少了工作的成就感和损害团队的关系。”
“牺牲质量是一个糟糕透顶的想法。现在节省下来一点时间，接下来的日子里你就要一直为它付出代价。”
一个病人躺在手术床上：“医生，我的病很紧急，你就不要消毒了，赶紧开刀吧。”
医生会听病人的话吗？会因为“紧急”而不消毒，抢那一点时间吗？
工程师应和医生一样，对不专业的病人说“不”！对产品负责人，对运营，对管理层说“ 不”吧。
我们需要第四个变量 —— “范围”。
“ 时间”和“成本”不是由工程师来控制的，“质量”是工程师不能妥协的，我们需要用“范围”来达到平衡 —— 砍需求。如果你想要在 xxx 天得到交付物，那么我们只能做到你需求中的 a、 b和 c，或者 a和 d。具体要做哪几项由你来决定，但是能做多少由我们来定。“范围”是工程师来控制的。
一旦产品负责人知道“质量”是不可能让步的，他们一般都会处理好其他变量。
是的，我们需要沟通清楚，不要因为不善沟通而承担起实际上无法承担的任务。这其实对项目开发并不利——虽然你很辛苦。
尽早测试、经常测试、自动测试缺陷破坏了有效软件开发所需的信任。客户需要信任软件 ;客户经理需要信任进度报告 ;程序员则需要彼此信任，而缺陷破坏了这种信任。
缺陷不可能完全消除，但可以通过经常测试，尽早测试来保证质量。编写单元测试，实现自动化测试可以帮助工程师减少缺陷。
我应该用 XP吗
你发现有以下问题吗？
.预定的计划和实际开发进度严重不符。
.团队成员关系紧张，开会时会互相指责，或者表现出担心会被自己队友伤害的神情。
.团队成员表现出明显的疲劳和急躁。
如何应用 XP
如同大热天进入一个清凉的游泳池，你可以一次放一个脚趾头入水，也可以沿台阶稳步走下去，像炮弹一样冲下去，或者像跳水比赛那样跳下去。总之，它们都达到了你入水这个目的。你的选择也许基于风格、速度、效率或者恐惧。只有你能决定哪个是适合你的。
纯度
“我的团队是极限的吗？”
极限不是用“是”和“否”衡量的。极限是用“多”和“少”衡量的。 30% 地应用极限
是极限的， 70% 地应用极限也是极限的。
理论上 100% 地极限是很难实现，也是没有必要的，适用你的团队、你的项目才最重要。
XP 名称的由来
极限编程，将开发的各个环节发挥到极限
需求分析：客户参与，所有人坐在一起设计：简单设计编码：通过重构保证高质量输入测试：编写单元测试，测试先于编码
Scrum
Scrum 的设计哲学
从北京到上海 乘飞机 VS 乘汽车
随着复杂程度的提高，中央控制和调度系统面临崩溃。有些人坚持进一步严化管理，迫使控制系统继续运行，另一些人开始使用团队自管理的方式。
造成项目复杂的原因
1. 需求。 客户很可能自己也不清楚自己的需求是什么，随着项目的推进而逐渐清晰起来，这个过程中需求的反复修改变化不可避免。
2. 技术。通常软件开发需使用多项技术，其复杂程度远高于单一技术内的复杂程度。
3. 人。工程师拥有不同的技能、智力水平、经验、观点、态度和偏见。每天早上，每位工程师起床时的心情可能与前一日有所不同。当这些人开始合作，人力资源复杂程度便直线上升。
将人与技术、开发需求综合考虑，总体复杂程度呈指数上升。
Scrum中的角色
你是鸡还是猪？
你对项目的开发工作直接负责吗？
是：猪类人员 —— 开发团队、 scrum master
、产品负责人。
否：鸡类人员 —— 高层管理人员、运营、市场人员和客户
Scrum流程
Scrum由一个个“ sprint” 周期组成，每个“ sprint” 周期我们可以称其为一个轮次，Scrum 将软件开发视化一个个轮次的迭代过
程。
每个轮次开始于一个计划会议，会议由 scrum master 主持。在计划会议上，“产品负责人” 会提出自己的愿景，希望开发哪些功能，这些功能被记录在“产品 backlog” 上，产品backlog记录了一个个“用户故事”，并被标上了优先级。
Scrum master 和开发团队会一起对产品负责
人的“用户故事”进行评审，将“产品backlog” 进一步转化为“ sprint backlog”，也就是将“用户故事”转化为实际要开发的“技术任务”，并对每一项“ sprint backlog” 预估工作量。根据团队的实际开发能力，团队会告诉产品负责人，哪些“用户故事”需要消耗多少工作量，由产品负责人决定挑选哪些功能点在本轮次中实现。
开发团队与产品负责人确认本轮次开发任务，并承诺本轮次的“交付物”。计划会议结束。
计划会议结束之后， scrum master 要将本轮
次的 sprint backlog全部记录到“任务墙”上。
计划会议之后，团队进入开发阶段，在开发阶段团队每天要召开“每日站立会议”。此会议由 scrum master 主持，会议上每人都必须站着，并回答三个问题，“昨天我做了什么”、“今天我打算做什么”、“我遇到了哪些困难需要帮助”。 Scrum master 要记
录每人的回答，并在会后协助遇到困难的成员解决问题。
开发团队在工作时首先要从任务墙上找到尚未进入开发状态的任务，标上自己的姓名，表示认领此任务。并根据任务的进展情况实时更新“任务墙”此任务的“进展状态”。
每天 scrum master 要根据任务墙上的“进展状态”更新“燃尽图”。
在本轮次结束时，要召开“评审会议”和“回顾会议”。
“评审会议”上产品负责人、 scrum master
、开发团队必须出席，另外感兴趣的鸡类人员可以选择出席。会议上由开发团队负责演示本轮次取得的“进展”。
“评审会议”之后召开“回顾会议”。“回顾会议”是开发团队和 scrum master 对本轮
次开发过程的一个反省和总结，目的是为下个轮次总结经验，以使下个轮次的开发可以更顺利。“回顾会议”产品负责人必须参加。没被邀请的鸡类人员一定不能参加。
“回顾会议”之后，表示一个轮次顺利结束。
Scrum流程框架图
Scrum框架
产品负责人产品负责人（ Product Owner ）的职责如下
： • 确定产品的功能。 • 决定发布的日期和发布内容。 • 为产品的 profitability of the product (ROI)负责。 • 根据市场价值确定功能优先级。 • 每个 Sprint ，根据需要调整功能和优先级（每个Sprint 计划会议时调整）。 • 接受或拒绝接受开发团队的工作成果。
产品负责人是一个人，而不是一个委员会。可能会有一些委员会向产品负责人提出建议或影响他的决策，但要想改变某条目的优先级必须先说服产品负责人。实施 Scrum 的企业可能发现这样会影响他
们制定优先级和需求的方法。
为保证产品负责人的工作取得成功，企业中的所有人员都必须尊重他的决定。任何人都不得要求团队按照另一套优先级开展工作，团队也不允许听从任何人带有威胁恐吓性的指令。产品负责人所作的决定需要通过产品 Backlog内容和优先级使其可视化
。这种可视化要求产品负责人全力以赴，同时也使其成为一个费心费力但又值得去做的角色。
Scrum master作为 Team Leader 和 Product owner 紧密地工作在一起，他可以及时地为团队成员提供帮助。
• 保证团队资源完全可被利用并且全部是高产出。 • 保证各个角色及职责的良好协作。 • 解决团队开发中的障碍。 • 做为团队和外部的接口，屏蔽外界对团队成员的干扰。 • 保证开发过程按计划进行，组织 sprint中的各种会议。
Scrum master vs 项目经理
丰田汽车制造部总裁盖里 .康维斯指出：
在一个健康、兴盛的工作环境中，经理的角色不是“强行发挥意志力，下达命令，而是做出表率，给予指导，充分理解，并协助他人实现目标，从而打造企业环境”
scrum master 并不是司令官，并不给团队直接分配工作，和传统项目经理的区别在于团队并不围绕 scrum master 工作，团队是自行管理的，而 scrum master更像是牧羊犬，守护羊群（开发团队）免受恶狼（产品负责人和鸡类人员）的袭击。
scrum master 是 scrum 的灵魂人物，他引导整
个项目按照正确的方式运行。虽然不参与开发，但其实工作量毫不轻松。
场景 4
在一个大房间里， 9 位开发人员正在工作。
scrum master 开始进行每日会议。该 scrum master首先拿出一张清单。他细读清
单条目，绕房间一周，询问在场的每位开发人员是否完成了写在其名字旁边的工作任务。他提出问题，如“玛丽，你完成我昨天布置的屏幕设计任务了吗？今天准备好设计其中的对话框了吗？”在检查完清单中的任务并与屋内所有人谈话后，他询问团队是否需要其帮助。所有成员都保持沉默。
传统项目管理方法里，项目经理制定任务计划，督促团队完成。他是项目的控制者。
scrum master 的权力通常是间接的，它是建
导者，为团队提供帮助，但并不直接控制团队。
scrum强大的地方在于团队自管理时会涌现出强大的生产力，当人们依靠自身力量设法解决问题时，会产生强烈的责任感。团队处理和解决问题的能力是 scrum 的核心，也是scrum 团队强大生产力的基础。而传统项目
经理的角色会扼杀这种团队自管理的能力。
开发团队• 一般情况人数在 5-9 个左右 • 团队要跨职能 （包括开发人员、测试人员、用户界面设计师等） • 团队成员需要全职。（有些情况例外，比如数据库管理员） • 在项目向导范围内有权利做任何事情已确保达到Sprint 的目标。 • 高度的自我组织能力。 • 向 Product Owner演示产品功能。 • 团队成员构成在 sprint内不允许变化。
开发团队人数
开发团队的人数最佳为 7 人，少至 5 人，多至9
人，如果少于 5 人或多于 9 人，生产力会有较大下降。
人数少了，沟通交流可能不够，而且可能技术上无法实现开发需求。人数多了，沟通的内耗较大，人越多内耗越大。
Sprint
Scrum 的项目过程有一系列的 Sprint 组成。
• Sprint 的长度一般控制在 2-4 周。 •通过固定的周期保持良好的节奏。 • 产品的设计、开发、测试都在 Sprint 期间完成。 • Sprint 结束时交付可以工作的软件。 • 在 Sprint 过程中不允许发生变更。
Sprint 周期的长短
如果周期过长，团队会在项目之初表现过于松懈，到了项目中期开始紧张，项目后期拼命加班弥补前期的松懈。
造成的后果：1 ）团队会在项目后期经受非常大的压力。2 ）代码质量不高，缺陷率大。
另外，周期长会妨碍产品负责人对软件功能的控制。过长的周期无法让产品负责人对功能的修改做出更及时的响应。
短周期 = 更频繁的交付 = 更频繁的客户反馈 = 在错误方向上花的时间更少 = 学习和改进的速度更快
但周期短会有如下问题：
1 ）开发团队无法集中精神创造价值，刚进入状态周期就结束了。2 ）会让计划会议和评审会议过多，时间消耗较大。3 ）每周期评审会议上，团队能交付的产品增量过少，甚至无法给出产品增量。
Sprint 周期的长短需要权衡，既保证团队在一定时间内全身心投入工作不受外界打扰，进入“流”的状态，又保证周期长度不至于让产品负责人和鸡类人员无法忍受。
肯思瓦伯建议 sprint 周期最好为一个月。《硝烟中的 scrum 和 xp》作者建议最好为三周
。
产品 backlog• 一个需求的列表。 • 一般情况使用用户故事来表示 backlog条目 • 理想情况每个需求项都对产品的客户或用户有价值 • Backlog条目按照商业价值排列优先级 • 优先级由产品负责人来排列 • 在每个 Sprint 结束的时候要更新优先级的排列
用户故事用户故事需要停留在业务层面，使用用户语言描述。
如果产品负责人有技术背景，可能在描述用户故事的时候会带上技术性意见。而技术实现是开发团队的事，产品负责人可以建议开发团队，但并不能在用户故事中将技术观点带入。
Sprint backlog• 管理 Sprint 的 backlog: • 团队成员自己挑选任务，而不是指派任务 • 对每一个任务，每天要更新剩余的工作量估算 • 每个团队成员都可以修改 Sprint backlog ，增加、删除或者修改任务• Sprint backlog中每项的粒度控制在 4~16小时
，超过 16小时的，要再拆分成多项。
产品 backlog to sprint backlog
在计划会议上，用“索引卡”记录用户故事，并贴在墙上。
开发团队用便签记录 sprint backlog ，并张贴在索引卡下方的位置，通常一个产品 backlog 可以拆分
成多个 sprint backlog ，所以一个索引卡下面通常会有多个便签。
索引卡
索引卡和便签
任务墙任务板（墙）展现了我们在 Sprint 过程中所有要完成的任务。在 Sprint 过程中我们要不断的更新它。–如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。 无论每日站会过程中或者之后，如果估计发生了变化，任务会根据变化在任务墙上做相应的调整。
通常的任务板是下面这个样子 :
任务墙被横竖分割成许多格子，每一行代表一个 Prouct backlog 项也可以称作一个用
户故事，在 Sprint 计划会议期间， Scrum 团
队会分解每个用户故事得到许多的 Sprint backlog 项，每一项作为一个任务卡放到任务墙上。
为了保证项目进度高度可视化， inprocess这
一项还可以进一步拆分，分成“设计”、“编码”、“测试”。
常见任务墙
Outlook 的便签实现的任务墙
Scrum 系统另外可以借助 Scrum 系统，完成 Scrum 的
任务墙管理，（另外包括产品 backlog 、 sprint backlog 、燃尽图等）但经验证明，还是用实体墙的效果最好。
常见的 Scrum 系统有VersionOne 、 ScrumWorks
、 XPlanner 。
燃尽图燃尽图直观的反映了 Sprint过程中，剩余的工作量情况， Y 轴表示剩余的工作， X轴表示 Sprint的时
间。随着时间的消耗工作量逐渐减少，在开始的时候，由于估算上的误差或者遗漏工作量有可能呈上升态势。
健康的燃尽图
估算乐观导致的燃尽图
估算过于保守的燃尽图
Scrum 计划会议
会议前产品负责人需准备好产品 backlog 。
产品 backlog 不一定要那么精确，但必须清晰
，产品负责人须知道每个用户故事的意思，并排好优先级。优先级建议用 0~150 分来标示。
计划会议解决两个问题：“做什么”和“怎么做”。
“做什么”用 4 个小时讨论，产品负责人通过产品 backlog告诉开发团队做什么。
“怎么做”用 4 个小时讨论，开发团队拆解产品 backlog ，形成 sprint backlog ，想出“怎么做”。这个过程开发团队会不停地跟产品负责人询问用户故事的细节。
计划会议的最后，开发团队会告诉产品负责人各个故事的开发任务量，由产品负责人确认本轮次要实现的用户故事。
产品负责人不能强制要求本轮次必须完成的用户故事，也不能“帮助”开发团队完成各任务的时间预估。预估是开发团队的独有的权利。
计划会议非常重要，如果计划会议存在问题，将影响整个轮次的顺利进展。
如果产品负责人期望的故事，开发团队认为本轮次中做不了。产品负责人想在 D 也能在
本轮次中实现。
选择一，调整优先级，把 D 放到前面，扔掉C
。
选择二，减弱 A 的功能。
选择三，将 A 拆分成两个用户故事，在本轮次中实现 A1 ，而 A2留在下个轮次中实现。
“ 完成”的定义
当有人声称某一功能已经“完成”，其真实含义是什么？
一些人可能认为它已完全通过编程、重构、单元测试、构建和验收测试阶段。
另一些人可能认为功能刚刚完成编程。
Scrum 会要求每一轮次切实完成一些功能，这个“完成”指的是经过充分测试、重构、精心编写而成的代码，可立即部署至生产环境上。
在每个轮次的“评审会议”上，要展示的是已“完成”的功能，开发至一半的功能不必展示。
估算
有两次方式：直觉和生产率计算。
估算时最好两者结合起来使用。
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 ：“嗯……”
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 ！”
计算生产力，不考虑团员之间能力的差别，按人 *天数得出粗略的值，这个值称为“故事点”。
“故事点”理解为“理想情况下，团队成员在完全不受打扰，完美、高效没有疲劳造成的消耗的情况下的生产力”，而且还要假设“ 团队不会生病，不会请假”。当然这样的假设绝对是不可能的，所以“故事点”并不等于生产力。
生产力 = 故事点 * 投入度
“投入度”根据上个轮次的实施情况、本轮次中可能出现的节假日等多方面因素而确定，在计划会议上，团队成员会告诉 scrum master 本轮次的投入度，也许是 60% ，也许
是 70% ，但永远不可能是 100% 。
一般默认“投入度”为 70% 。
“投入度”低表示团队估计会受到很大干扰，或者他们觉得自己的时间估算太过理想化。
“投入度”的估算准确与否，可以参考前面几个轮次的“投入度”的平均值。
每个 sprint backlog 需要多少时间？
每个开发团队成员可能都有不同的预期值。谁先回答，都可能影响其他成员发表自己的观点。
我们可以借助“计划纸牌”。
计划纸牌
每个人都会拿到一幅计划纸牌，然后 scrum master 会让开发团队估算 sprint backlog 的时间。每人拿一张自己估算对应的时间，反面扣在桌子上，每个人都被迫自己进行思考，不能依赖其他人估算的结果。
如果每个人估算结果相近，那么时间不会出现较大误判。如果有人的估算结果差异特别大，那么需要大家一起讨论是否忽略了什么。
牌的数值不是连续的，而是几个有代表性的，数值代表的是故事点。数值不连续，所以它并不是那么精确，而是一个大概的估算。
几张特殊的牌。0 ：“这个故事已经完成了”或者“这个故事根本没啥东西，几分钟就能搞定”。？：“我一点概念都没有。没想法。”咖啡杯：“我太累了，先歇会儿吧。”
Scrum如何处理权利与责任
鸡类人员严禁直接对开发团队发出指令！
鸡类人员如果有需求，唯一的接口人是产品负责人
产品负责人可以对开发团队提出需求，但必须遵守游戏规则，只能在 sprint 周期之初的计划会议上提出。
如果有紧急情况出现，一定要在 sprint 开发周期内调整计划，可以和 scrum master协商，立即中止当前 sprint ，并重新召开计划会议。但产品负责人要承担更改计划带来的相应的时间损失。
产品负责人有权在计划会议上提出需求，并指定各条需求的优先级。但产品负责人无权指定开发任务量。
开发团队有权接受开发任务量，有责任在本Sprint 结束时，交付承诺的开发任务。开发
团队有权拒绝鸡类人员的指令，并向 scrum master 反映。
scrum master 有权在计划会议上和团队协商本 sprint 周期内开发任务量，有权对团队进行调整以适应敏捷开发的需要。 scrum master有责任主持计划会议、每日站立会议和项目评审会议，有责任帮助团队在开发周期内免受外界干扰。
项目最终交付日期
预估最终交付日期
项目有最终将付日期吗？
完美是个动词，所以没有最终交付日期。我不能告诉你，从北京到上海，我会在哪一天哪一点到，我能告诉你的是“我会一路上尽最快的速度往上海去，我保证路上不会犯大的错误延误时间，我知道我一路都是按最正确的选择在前进，但我不知道哪天会到达”
如果管理层要求时间及范围
如果管理层既要求了时间，又指定了范围，怎么办？
听听肯斯瓦伯的回答吧。
我也不知道怎么办
要应用敏捷，第一件事，搞定你的管理层，否则别折腾了。
Scrum 的局限性
Scrum只定义了高层次的开发项目的管理流程，并不涉及具体开发方法或者人员的有效沟通技巧。这些未涉及的领域需要有其他相关理论及技能的补充。
应用敏捷
1 ）对整个团队进行培训，从管理层到工程师，理解敏捷的设计哲学。
2 ）说服管理层，敏捷没办法许诺做不到的事情，敏捷更实事求是，但如果管理层不理解，只会让敏捷团队显得“卓而不群”。
3 ）找一个敏捷教练，指导敏捷的进行。经验
不一定是必须的，但要理解敏捷的哲学。
参考资料《解析极限编程——拥抱变化 第二版》《 scrum 敏捷项目管理》《硝烟中的 scrum 和 xp 》《测试驱动开发的 3 项修炼——走出 TDD丛林》 Scrum中文网 http://www.scrumcn.com
Q & A
THANKS！
