学习目标

理解敏捷，初步了解Scrum。

讨论主题：

1. 什么是敏捷？

2. 什么是敏捷软件开发？

3. Scrum和敏捷宣言之间有什么关系？

讨论内容

1. 什么是敏捷？

【讨论】请各位用“敏捷”这个词造句。

例句：（1） 小猫的动作很敏捷，不一会儿就找到老鼠。（2）猎豹的行动敏捷，在猎物发现之前就已经逮到猎物。（3）思维敏捷的他不到一会儿就把题目正确解答出来。

查百度字典，“敏捷”指反应迅速快捷。查英语牛津字典，“Agile”指 （1）able to move quickly and eaisly (动作)敏捷的，灵活的；（2）able to think quickly and in an intellegent way (思维)机敏的，机灵的。Agile的发起人曾在一次访谈中解释，选用Agile这个词来表达一种新的软件开发方法，基本的意思是“flexible”，即 “灵活的”。

2. 什么是敏捷软件开发？

什么是敏捷软件开发？敏捷宣言是这么说的：

【活动】思考敏捷价值观，填写卡片，并分享统计结果

我解释敏捷宣言的这4句话，请各位对照敏捷价值观，思考自己，也思考自己周围的人。

第一、个体和互动高于流程和工具

个体和互动，指开发团队中，每一位开发人员积极思考、积极与其他开发人员讨论，与项目相关的人员讨论，共同寻找最佳解决方案。每位开发人员活跃起来，整个开发团队活跃起来，这样的工作效率要高于盲目的、按部就班的遵守流程，为了完成任务而使用一些可有可无的工具的工作效率。

闭幕冥想，回忆自己从事软件开发中经历过的一些事情，自己认同“个体和互动高于流程和工具”这个观点吗？如果答案是肯定的，请为自己打个勾。如果是否定的，请打x。你周围的人呢？开发组的同事，自己的领导，其他部门的同事，你觉得他们认同这个观点吗？

第二、工作的软件高于详尽的文档

工作的软件指软件可以运行，对于用户而言，可以完成对用户有价值的操作。在交付给客户的交付物中，必然有软件。对用户而言，软件必须可以工作，可以给用户带来价值，用户在愿意付钱购买这个软件。

而文档要视情况而定。用户手册对用户有帮助，但多数用户不喜欢看用户手册。对用户友好的软件，那些用户不用看手册的，拿来就会用的软件，才是最受欢迎的软件。

如果设计稳定了，应该整理设计文档，供负责维护软件的开发者参考。但设计文档并不要求详尽，最详尽的设计就是源代码。开发者看源代码就看到了所有信息。设计文档重点说明设计思路、设计难点即可。

闭目冥想，回忆自己开发过的软件，自己投入多少时间使软件经常保持可运行的状态？投入多少时间写文档？自己认同“工作的软件高于 详尽的文档”这个观点吗？你觉得你周围的其他人认同这个观点吗？请填表

第三、客户合作高于合同谈判

在座各位未必经历过正式的商务合同谈判，但有一种非正式的合同，相信每位开发者都见过，而且有些还亲身经历过这种非正式的合同谈判。这个非正式的合同就是软件需求规格书。客户经常提需求变更的要求，你通常怎样应对？配合客户，很快的在软件中体现这些变更呢？还是先拿着需求规格书和咬文嚼字的和客户掰扯几轮，再改代码？

闭目冥想，回忆自己在开发软件的过程中，所有为了响应客户需求变更而加班的日日夜夜……想好就可以填表了。

第四、响应变化高于遵循计划

软件开发行业发展的趋势是，市场变化快，客户需求变化快。响应这种变化的速度越快，组织以及组织中的开发团队的生命力就越强，就越容易在市场竞争中占据优势。

这句话喊口号容易，实际做并不容易，不仅要有心态上的转变，更需要管理方法和工程实践的支撑。在管理方法上，要打破传统的瀑布开发模式，改用短周期迭代开发。长期的详细的需求不明确？没关系，先开发短期的确定有价值的需求，长期的目标只关注宏观层面的愿景。在工程实践上，要有自动化测试工具支撑，进行测试驱动开发、结对编程、遵循简单设计原则。需求变更不可怕，代码写的简洁易懂，想改哪里改哪里。改完了会不会出现bug？自动化测试分分钟会告诉你，有问题还是没问题。这里我尤其想强调，软件开发团队的工程实践，比如自动化测试、测试驱动开发、简单设计、结对编程、重构，这些工程实践是能够做到响应变化，交付高质量软件的基石。离开这个基石，要么快速响应变化却交付带有很多bug的软件，要么就无法快速响应变化。这些工程实践，对开发人员的技术素养有很高的要求。“响应变化高于遵守计划”，我和在座各位扪心自问，我认同吗？我能做到吗？

3. Scrum和敏捷宣言之间有什么关系？

刚才我讲解了敏捷软件开发宣言，讲解了敏捷的价值观。下面请各位谈谈，你知道的敏捷是什么样的？无论从其他开发组看到的、听说的、书上读到的，还是参加培训学来的，或者自己实践过的，都可以分享。

敏捷就是每天开站会；敏捷就是迭代；敏捷就是使用Jira, Confluence那些系统；敏捷就是轻流程、简化文档……

这些观点对，也不对。概括起来说，什么是敏捷呢？敏捷指一组价值观、原则和实践。刚才我讲的敏捷宣言，是敏捷的最基础最核心的部分，就像这个冰山在水面以下最下面的部分。在敏捷价值观以上的，是敏捷12条原则。价值观和原则都是水面以下的部分。刚才各位谈到的是敏捷实践，是我们能看的到的。比如Scrum，Kanban，站会，JIRA 系统。

敏捷宣言遵循的原则

我们遵循以下原则：

1.我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

2.欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

3.经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

4.业务人员和开发人员必须相互合作，项目中的每一天都不例外。

5.激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

6.不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

7.可工作的软件是进度的首要度量标准。

8.敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

9.坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

10.以简洁为本，它是极力减少不必要工作量的艺术。

11.最好的架构、需求和设计出自自组织团队。

12.团队定期地反思如何能提高成效，并依此调整自身的举止表现。

敏捷原则是敏捷价值观的体现。以第5、6条原则为例，激发个体斗志，鼓励面对面的交谈，具体体现了敏捷价值的第一条，“个体和交互高于流程和工具”。第7条，可工作的软件是进度的首要度量标准。什么意思呢？比如一个软件要开发10个新功能。第一个月末，第一个功能可用了，叫做进度10%。第5个月末，共有5个功能可用了，叫进度50%。如果第一个月末，写了需求文档和项目计划，用敏捷的度量标准“可工作的软件”来度量，叫做进度多少？对，0%。第5个月末，只写了设计文档，和部分代码，但代码还不能运行。用敏捷的度量标准“可工作的软件”来度量，进度是多少？对，还是0%。

总结

什么是敏捷？敏捷是一组价值观、原则和实践。

Scrum和敏捷宣言的关系是什么？Scrum是敏捷的实践，敏捷宣言是敏捷的价值观。