网站地图
【www.arisingsemi.com--软件系统】
敏捷的意思 敏捷开发◆ 敏捷方法的产生-
2001年2月，17个方法学家在美国犹他州Snowbird成立了敏捷软件开发联盟()，并共同起草了《敏捷软件开发宣言》，这标志着敏捷开发的诞生。这一模式随后被硅谷创业公司大量应用，并于近几年被引入国内。
敏捷开发模式中，一个项目被分解为多个部分或多个步骤。
在每个阶段完成后，项目都可以拿出一定程度可交付的产品。
这样做便于实现产品交付目标，降低整个项目的复杂度，同时在项目早期就能拿出初具雏形的产品。
◆ 敏捷宣言的4条价值观
1)个体和交流胜于过程和工具
2)工作软件胜于综合文档
3)客户协作胜于洽谈协议
4)回应变革胜于照计划行
◆ 敏捷宣言的12条基本原则
l)最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意
2)即使到了开发的后期也欢迎改变需求，敏捷方法得用变化来为客户创造竞争优势
3)经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好
4)在整个项目开发期间，商务人员和开发人员必须天天都工作在一起
5)围绕被激励起来的个体来构建项目，给他们提供所需的环境和支持，并且信任他们能够完成工作
6)在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈
7)工作的软件是首要的进度度量标准
8)敏捷方法提倡可持续的开发速度，责任人、开发者各用户应该能够保持一个长期的、恒定的开发速度
9)不断地关注优秀设计的技能和好的设计会增强敏捷能力
10)简单——使未完成的工作最大化的艺术——是最根本的
11)最好的架构、需求和设计出自于自组织的团队
12)每隔一定时间，团队会在如何才能更有效工作方而进行反省，然后相应地对自已的行为进行调整
主要的几种敏捷方法的过程模型如下：
SCRUM
极限编程XP
自适应软件开发Adaptive Software Development
精益软件开发Lean Software Development
特征驱动开发Feature Driven Development
敏捷统一开发过程Agile Rational Unified Process
动态系统开发方法Dynamic System Development Method
水晶系列方法Crystal
这些敏捷方法的共同点是：使用短的固定长度迭代和反馈快速递交测试过的工作软件
Scrum的英文意思是橄榄球运动的一个专业术语，表示。争球。的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。
而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。
产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
流程管理员（Scrum Master）
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
开发团队（Scrum Team）
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。
图 1 Scrum流程图
如何进行Scrum开发。
1、 我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；
2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；
3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；
4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；
6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；
7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Sprint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
那么什么是XP呢。
XP是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。
与其他方法论相比，其最大的不同在于：
● 在更短的周期内，更早地提供具体、持续的反馈信息。
● 在迭代的进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断的发展它。
● 依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。
● 依赖于口头交流、测试和源程序进行沟通。
● 倡导持续的演化式设计。
● 依赖于开发团队内部的紧密协作。
● 尽可能达到程序员短期利益和项目长期利益的平衡。
●
Kent Beck曾经说过“开车”就是一个XP的范例，即使看上去进行得很顺利，也不要把视线从公路上移开，因为路况的变化，将使得你必须随时做出一些这样那样的调整。而在软件项目中，客户就是司机，他们也没有办法确切地知道软件应该做什么，因此程序员就需要向客户提供方向盘，并且告知我们现在的位置。
XP包括写什么呢。如图，XP由价值观、原则、实践和行为四个部分组成，它们彼此相互依赖、关联， 并通过行为贯穿于整个生命期。
图 5 XP极限编程
1. 沟通
XP方法论认为，如果小组成员之间无法做到持续的、无间断的交流，那么协作就无从谈起，从这个角度能够发现，通过文档、报表等人工制品进行交流面临巨大的局限性。
因此，XP组合了诸如对编程这样的最佳实践，鼓励大家进行口头交流，通过交流解决问题，提高效率。
2. 简单
XP方法论提倡在工作中秉承“够用就好”的思路，也就是尽量地简单化，只要今天够用就行，不考虑明天会发现的新问题。
正如对传统开发方法的认识一样，许多开发人员也会质疑XP，保持系统的扩展性很重要，如果都保持简单，那么如何使得系统能够有良好的扩展性呢。
其实不然，保持简单的理由有两个：
开发小组在开发时所做的规划，并无法保证其符合客户需要的，因此做的大部分工作都将落空，使得开发过程中重复的、没有必要的工作增加，导致整体效率降低。
另外，在XP中提倡时刻对代码进行重构，一直保持其良好的结构与可扩展性。
也就是说，可扩展性和为明天设计并不是同一个概念，XP是反对为明天考虑而工作，并不是说代码要失去扩展性
3. 反馈
在许许多多项目中，当开发团队经历过了需求分析阶段之后，在相当长的一段时间内，是没有任何反馈信息的，整个开发过程对于客户和管理层而言就像一个黑盒子，进度完全是可见的。而且在项目的过程中，这样的现象不仅出现在开发团队与客户、管理层之间，还包括在开发团队内部。
反馈对于任何软件项目的成功都是至关重要的，而在XP方法论中则更进一步，通过持续、明确的反馈来暴露软件状态的问题。具体而言就是：
在开发团队内部，通过提前编写单元测试代码，时时反馈代码的问题与进展。
在开发过程中，还应该加强集成工作，做到持续集成，使得每一次增量都是一个可执行的工作版本，也就是逐渐是软件长大，整个过程中，应该通过向客户和管理层演示这些可运行的版本，以便及早地反馈，及早地发现问题。
4. 勇气
总之这一切，使得你立刻处于变化之中，因此这时就需要你有勇气来面对快速开发，面对可能的重新开发。也许你会觉得，为什么要让我们的开发变得如此零乱，但是其实这些变化若你不让它早暴露，那么它就会迟一些出现，并不会因此消亡，因此，XP方法论让它们早出现、早解决，是实现“小步快走”开发节奏的好办法。
也就是XP方法论要求开发人员穿上强大、自动测试的盔甲，勇往直前，在重构、编码规范的支持下，有目的地快速开发。
1. 快速反馈
及时地、快速地获取反馈，并将所学到的知识尽快地投入到系统中去。也就是指开发人员应该通过较短的反馈循环迅速地了解现在的产品是否满足了客户的需求。
这也是对反馈这一价值观的进一步补充。
2. 简单性假设。