敏捷开发基础概念介绍

敏捷基础概念介绍彭珂Date:July13,2012

敏捷的概念敏捷是一种强调轻量的过程方法论，它强调拥抱变化而不是与之对抗，通过有效的沟通发挥群体的智慧敏捷方法论采用迭代/增量开发的过程模型敏捷门派众多，2001年，成立敏捷联盟，并发布了宣言和原则敏捷宣言个体和交互胜过过程和工具可以工作的软件胜过面面俱到的文档客户合作胜过合同谈判响应变化胜过遵循计划

虽然右边的也有价值，但是我们认为左边的具有更大的价值谁在使用敏捷？微软大规模使用，敏捷列入新员工培训课程NokiaSimens

超过40个产品使用敏捷流程，最大的项目约500名开发人员，跨地域、时差IBM项目经理可以自主选用瀑布或者敏捷流程，将为华为提供敏捷顾问和工具Ericsson从第一代GSM基站开发就采用增量式迭代开发，使用敏捷的部分实践Google大部分项目敏捷，部分采用传统方法开发Wiki Wiki的发明人是敏捷宣言的发起人之一，Wiki的灵感来源于敏捷的“集体代码所有权”思想神舟飞船软件系统在敏捷宣言发表之前即采用敏捷的思想BT：HuaweitoproposehowwecanmeettheagilerequirementsofBT.

迭代的概念相对于传统的瀑布式开发，迭代开发把软件生命周期分成很多个小周期（一般不大于2个月，建议2周），每一次迭代都可以生成一个可运行、可验证的版本，并确保软件不断的增加新的价值。什么是迭代开发？迭代的主要目的

1、验证关键设计方案，避免重大的设计风险（主要设计点）

2、尽快确认和澄清客户需求（主要需求点）

3、缩短验证周期（只有在小粒度迭代上才可能实现），提供灵活的特性交付能力我们的版本开发是不是迭代？

1、宏观上讲，我们也是迭代开发，但颗粒度太大，存在问题

2、周期太长，验证反馈太慢，长周期要承担更多的需求变更风险，导致恶性循环

3、没有真正识别主要需求点和主要设计点，无法尽快确认需求和避免设计风险4、不具备快速验证的能力5、对于大部分的产品，我们应用迭代的主要诉求在2，3两点

小批量交付特性集AA1A2A3=特性集BB1B2B3=B特性集CC1C2C3=CA传统方法:“每件事都很重要！一次就要全部做好！”JanFebMarAprMayJunJulA1B1C1A2B2C2A3B3C3ABC迭代开发:“优先级&关注点!”JanFebMarAprMayJunJulA1B1C1A2B2C2A3B3C3ABC如何处理变化和延迟计划Week1Week2Week3Week4CDAB传统模式下的延迟方式Week1Week2Week3Week4Week5Week6Week7Week8CDAB迭代模式下的延迟方式Week1Week2Week3Week4Week5Week6Week7Week8ABEDAB敏捷与迭代的关系敏捷强调软件的需求、设计、计划都是复杂的，以至于不可能一次就精确的完成，所以要通过快速的反馈对需求、设计、计划进行修正迭代是敏捷建立持续的快速反馈机制的技术手段

敏捷与迭代关系(续)随着软件交付周期的日益加快，迭代化开发已经成为大多数软件开发团队的必选项。但是迭代对整个团队的需求、架构、协同及测试能力都提出了更高的要求，现在许多开发团队都在试图导入迭代化开发的过程中，敏捷可是被看成迭代化开发的一种导入方式，这不过敏捷的范围其实比迭代化开发更大一些敏捷的三个要素是迭代开发、坦诚合作和自适应性。坦诚合作其实才是敏捷的精髓，如Ivar所说，敏捷其实是有关SocialEngineering的。敏捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的领域敏捷宣言遵循的原则-迭代我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好工作的软件是首要的进度度量标准敏捷宣言遵循的原则-团队运作在团队内部，最具有效果且富有效率的传递信息的方法，就是面对面的交谈在整个项目开发期间，业务人员和开发人员必须天天都在一起工作围绕被激励的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作敏捷过程提倡可持续的开发速度，责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度不断地关注优秀的技能和好的设计会增强敏捷能力简单---使未完成的工作最大化的艺术---是根本的敏捷宣言遵循的原则-自组织团队最好的构架、需求和设计出自于自组织的团队每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整敏捷-质量管理每一次迭代结束，项目组坐在一起对迭代进行回顾，回答两个问题：

1、我们的成功经验是什么？

2、有什么能改进？针对项目组当前的问题，自主决策改进方案，并在下一个迭代中实施，即使改进方案无效，也可以在下一个迭代回顾时发现，最多浪费一个迭代周期自我决策改进方案，以适应复杂的需求、人员状况，是敏捷团队的最大特点

敏捷实践敏捷实践(续)敏捷是聪明的工作

敏捷是关于以下三件事情的：最重要的，敏捷是一门社会工程学。这是敏捷最大的特点。它关注的是，如何以一个团队的形式开展工作，如何激励团队成员，如何相互合作等等敏捷是轻量级的。敏捷非常依赖隐性知识，敏捷认为，只要有掌握足够知识的人，才可以开发出优秀的软件敏捷提供技术实践。这其实是敏捷中贡献最微弱的部分敏捷的本质是变得“聪明”，聪明就是做正好合适的事，不是找更广的解决方案，而是正好。对敏捷常见的误区敏捷不写文档敏捷不适合大型软件开发，尤其是高质量要求领域敏捷和CMM对立敏捷导致对人员的极度依赖敏捷导致管理者无法看到项目组的进展，从而导致失控敏捷是银弹！？敏捷=不写文档？只写项目组认为必须的文档如果认为项目组新员工比较多，可能就得写比较多的文档如果需要经常和大量的客户、众多的项目组交流，可能就需要比较多的书面规格、接口文档。因为人多的时候，面对面的沟通带来N平方问题常见的文档为：需求文档，敏捷实际上要求对需求的阐述非常细致，并且可测（部分非功能性需求可能难以测试），现有产品文档根本无法满足要求。但是迭代开发中文档是跟随迭代过程不断完善，而且很多公司是在测试完成后才开始写规格文档。文档是结果记录，而非开发过程中的沟通工具。代码（代码即设计文档）：最好的代码是自注释代码，应当尽量通过重构让代码可以直接阅读，尽可能减少需要注释才能看懂的代码。架构文档（通常是几页纸，参见附录微软对架构的看法）

敏捷不适合大型软件开发胶片前面已经介绍过，众多的电信厂商、微软、IBM、美国军方、神舟飞船系统，均采用或者部分采用敏捷的思想进行开发敏捷认为变化不可预测，如果小型项目的变化都不可预测，大型项目显然更无法预测，所以认为敏捷适用于小型项目，大型项目使用瀑布的说法是错误的。敏捷反CMM？CMM定义的是目标，敏捷的实践可以支撑CMM2、3级的KPA，Scrum的两个掌门人，以及CMM1.1的项目经理Paulk均持此种观点，但是也有很多人不认同此观点。SEI的官方网站2008年11月也发表文章《CMMIorAgileWhyNotEmbraceBoth.pdf》http:///cn/news/2008/11/report-integrating-cmmi-agile，试图融合。敏捷除了关注CMM关注的流程，更多的关注团体智慧、发挥个人能力敏捷和IPD-CMM是截然相反的，一个基于瀑布模型，一个基于迭代模型敏捷导致项目管理失控敏捷虽然强调团队自组织，但是管理者可以通过持续集成和迭代测试结果知道项目组的实际进展特性的完成没有二义性，完成了50%的特性就有很大的把握知道项目组的进展达到了50%。而文档的完善度、正确性根本无法评价，这也是为什么普遍存在的现象：TR4前进度总是可以完成的，TR4以后进度总是拖后的。我们见过TR4以后疯狂的加班，但是有谁见过开发人员加班到12点写详细设计文档？敏捷导致对人员的极度依赖敏捷强调团体的智慧，团队共同决策，实际上减少了人员的依赖结对编程保证了任何一行代码都至少有两个人懂持续集成保证了即使不了解系统也敢于修改系统。同时大量的测试用例是系统最准确的文档。对系统有疑问，而又没人可以咨询的时候，可以通过修改代码、测试用例的方式去探索，而看不懂文档就完全没有办法了IPD-CMM号称可以不依赖于人，但是仅仅是目标，从来都没有做到代码日益腐烂，完全无法看懂，没有人敢改代码。文档糟糕透顶，绝大多数文档是应付流程的产物敏捷不能解决问题，只能让问题暴露的更早敏捷方法是项目的救星吗？不，我认为它依然会失败。敏捷开发可以带给你的一件事情是：让这些项目失败的更快、损失的更少，因为你可以将时间和精力用于开始做下一件事情。

KentBeck总结软件是复杂的，由此引发了一致性和可变性的问题。随着软件规模的日益膨胀，参与的人日益增加，软件的本质问题越来越突出复杂性：1、采用分而治之的思想，把一个大的软件划分为多个小特性，降低了每一轮迭代搜需面临的复杂度一致性：1、按照特性组织团队，发挥群体智慧，团队共同拥有代码，共同为需求、架构、设计、测试负责。2、通过持续的反馈（迭代、面对面的沟通）消除不一致可变性1、变化难以预测，过早的应对变化会导致浪费。Keepitsimple。2、每一个项目都是不同的，每一个人也都是不同的。敏捷团队根据团队成员和项目需求的特性，自己决定流程、方法和工具参考书籍《敏捷软件开发原则模式与实践》《重构》《人月神话》《编写有效用例》《人件》《修改代码的艺术