【专家视点】敏捷开发给企业带来的价值

企业在商业方面取得成功的要素是产品（Product），人才（People和流程（Process

中培可以通过敏捷咨询，从产品，人才和流程层面帮助客户改变。

1.产品提高

敏捷可以帮助客户：

响应变化的需求

缩短首次上线周期，缩短反馈周期

提高产品质量

降低已有系统维护成本，降低需求变更成本

我们通过如下实践来达到：

迭代式开发?

相比瀑布式过程，更好的方式是迭代式开发，它将整个软件的开发过程分成了若干阶段，客户根据优先级或者风险高低选择需求进行增量的设计和开发。每次迭代完成时都会生成一个经过测试的最终产品，开发团队可以通过它获得更多的反馈，继续完善软件产品。

迭代式开发的好处是：??

快速交付投入使用，快速获得投资回报?

快速得到反馈，快速调整?

把项目分成较小周期，更容易管理?

更直观看到项目的进展，风险更小?

迭代帮助客户及早地创造价值，开发团队可以通过它得到反馈，?不断地修正各种错误。分析人员可以得到更进一步的需求。　

持续集成?

要得到迭代产物，产品的开发人员必须将产品代码不断与现有系统进行集成。　这意味着团队

需要通过使用版本控制工具有效的管理代码，并做到频繁提交。　

持续集成的好处是：?

自动从版本控制库取出最新的源程序?

运行自动构建脚本，从头进行构建和部署?

针对构建出来的软件运行全部测试?

自动发布集成结果?

测试驱动开发?

测试驱动开发基本思路就是通过测试来推动整个开发的进行。而测试驱动开发技术并不只是单纯的测试工作。　

测试驱动开发的好处是：?

正确的描述了需求。需求向来就是软件开发过程中感觉最不好明确描述、易变的东西。编写正确的测试代码，就是对需求最好的描述，当测试通过时，产品代码也就自然满足了需求。　

正确的注释代码。开发人员通常对编写文档非常厌烦，但要使用、理解别人的代码时通常又希望能有文档进行指导。而测试驱动开发过程中产生的测试用例代码就是对代码的最好的解释。

保证项目质量。开发人员可以容易的保证测试覆盖率，并且不断完善测试用例，来达到符合质量要求的测试密度，为开发人员增强信心?

测试不仅是质量保证部门的事情，它贯穿了整个软件生命周期。中培的测试策略覆盖了应用系统的各个方面，并且帮助客户使整个测试过程自动化，覆盖单元测试、功能测试、验收测试、性能测试、回归测试、集成测试、以及验收测试，测试脚本的可重用性很高。频繁的进行测试活动，可以在早期发现问题，使修正问题的质量成本降低，大幅提高产品质量，并提高测试和开发人员工作效率。

2.人才培养

敏捷沟通?

敏捷开发强调开发过程中人的重要性。重点在于：?

以人为本，注重编程中人的自我特长发挥，鼓励建立自组织的团队。

客户与开发者的关系是协作，而不仅是合同关系

项目成功的一个重要因素就是充分的交流。中培通过结对编程等敏捷实践，促进项目团队的交流，创造一种开发人员交流分享的文化，构筑学习型组织。

结对编程

结对编程，指的是这样一种程序设计实践：两名程序员并肩工作在同一台计算机前，共同探讨设计方案、共同设计算法、共同编写程序代码、共同完成各种测试。在这两个人中，被称为“驾驶员”的那个人负责实际操作或做设计方案，被称为“领航员”的另一个负责其他工作，包括随时观察“驾驶员”的工作情况，发现并纠正其操作?性和策略性失误。　

结对编程的好处在于：?

在团队中传递知识。经验少的开发人员和经验多的一起工作，从实际工作中学习到很多难以言传的知识和技能，比光看文档效果好得多?

降低人员风险。开发人员一起开发相同功能，并经常交换配对，大家互为备份。当出现人员变动或者休假等情况，仍然有人熟悉其他人的工作，开发收到的影响相对小得多?

提高代码质量。　一个人思路难免受到局限，两个人一起工作考虑的要全面；更进一步，如果一个人的设计，结对的另一方不能理解，说明设计还不够简单明了，需要继续改进。　直接的，持续的CodeReview，使代码质量大大提高。

提高工作效率。在有人在旁边盯着的时候，去偷懒要困难的多；同时，在遇到困难的时候，可以更容易更及时的得到他人的帮助?

增进团队凝聚力。敏捷方法创造一种公开和交流的团队气氛，鼓励通过一起工作来互相学习，相互了解，增进信任?

团队内部知识库

通过内部知识库的形式（如Wiki），鼓励大家将开发过程中的得到的领域知识，最佳实践变成组织过程资产，促进公司内部的知识积累。个人技能提高的过程，也会成为组织成长的过程。建立自组织的团队和学习型组织，可以从知识层面打破了因组织结构形成的边界，大家都能分享自己的知识，并能从其他人那里获得新的知识。　

这样的团队能最大程度上激发个体的主观能动性，吸引更多的优秀人才加入，达到企业和个人共赢。　?

3.流程改善

敏捷开发强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。所有流程是为了开发软件服务的，而不是为开发团队增加不必要的负担。　

流程简化?

敏捷开发和CMM/CMMI并不冲突。在CMMI过程域中，OPD（组织级过程定义）和IPM（集成项目管理），也强调流程剪裁，因地制宜。这一点往往在传统开发实践中被忽视。开发团队把很多时间和精力花费在制作格式一致，美观华丽的文档上，而忽视了文档作为沟通媒介这一重要属性。　

敏捷不是不要文档，而是减少无效的文档，使项目团队把更多精力放在可以创造商业价值的可运行的软件产品上。文档和计划的详细程度是根据项目的特点、开发阶段和内容的重要性来决定的。需要项目开发团队在实践中不断摸索最适合项目的实践。　

在敏捷开发中，MS Word不是唯一的文档格式，项目团队可以使用多种多样的文档工具来进行沟通，如MSPowerPointMSExcel，团队Wiki，甚至把白板上讨论的内容用数码相机拍摄下来，存为图片。选择最适合的工具，传递合适的信息，达到消除浪费和冗余，加强沟通的目的。　

敏捷项目计划?

计划是为了交付，而不是按计划交付。敏捷项目的计划是：?

做长计划?变成?常做（短）计划?

价值驱动型，首先做对业务价值（或者投资回报率）最大的部分

在开发过程中，一种常见的浪费是“为将来准备的投资”。例如为了应付将来可能出现的需求变化而提前引入的灵活设计，如果需求没有发生变化，这些灵活设计就会成为浪费。因为这样的设计是空想出来的，而不是来源于实际。这种做法消耗了很多开发成本。制造业为了降低库存成本而创造出“JustInTime”的生产和决策方法同样适用于软件行业。　

如何消除预测错误的浪费？避免预测错误的?根本办法就是推迟决策：决策下得越晚，就越不容易因为预测失准而造成浪费。当然也不能晚到错过了时机、耽误了工作才下决策，决策也要JustInTime。过早的、含有太多预测成分的决策也会造成浪费，其危害丝毫不亚于过晚的决策。　

拥抱变更?

在开发全过程中，敏捷方法能很好的接受客户的需求增加和变更，同时和客户风险共担。　

随时可提出变更  

变更在迭代开始时引入，开发中的需求不做变更。根据变更，确定优先级，调整下个迭代的计划

保持计划工作量（工作时间）与团队的能力相当

因为是采取的较短的交付周期，项目团队可以尽早的提交可工作的软件。客户可以根据实际的软件，能尽早的对开发做出反馈，不断完善需求，提出新的更有价值的特性，降低变更带来的成本。　

以故事（Story）为单位管理需求?

通过故事卡片（Story Card）和故事墙（Story Wall）等敏捷实践来管理需求和开发过程，提高开发效率，降低文档量，使项目更加可控。这些方法可以促进技术人员和非技术人员的沟通和交流，使管理者一目了然的了解项目的进展。