软件开发敏捷方法论.docx

软件开发敏捷方法论.docx

《软件开发敏捷方法论.docx》由会员分享，可在线阅读，更多相关《软件开发敏捷方法论.docx（11页珍藏版）》请在冰豆网上搜索。

软件开发敏捷方法论

软件开发-敏捷方法论

　　2001年在软件工程界首次出现“敏捷”这个名词，17个过程方法学家举行了一个讨论会。

发现他们的“轻量级”的方法有很多共同的地方，因此一致同意把这些方法统称为“敏捷”的方法。

并且成立了个叫敏捷联盟的组织，还定下了所谓的“敏捷宣言”。

从此，越来越多的人了解到敏捷方法。

　　敏捷方法有一些共同的特征。

其中有两个最主要的特征是：

轻量和简单。

敏捷方法论包含最少的流程和文档，减少正式性。

目的是做眼前能做的事情，而不去预测太远的未来，首先完成紧迫的事情。

快速的、增量的开发能更快地交付客户使用，更快得到反馈。

开发方法要称之为敏捷，需要具备4个基本特征：

增量的、协作的、直接的、适应性强的。

　　1.SCRUM（橄榄球里的争球）方法论

　　关键词：

30天迭代粒度，每日站立会议，进度透明，客户参与

　　Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。

Scrum在英语的意思是橄榄球里的争球。

虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法。

在SCRUM方法论中其核心仍然迭代和增量，首先对于产品需求会划分为多个迭代或增量，每个迭代都需要在1个月能够交付，而一个月即是一次冲刺，而一个迭代版本又需要转化到每天的进度跟踪和问题解决，这就是每天的15分钟会议（每日站立会议），在会议上必须回答当天的进度，明天的计划和是否存在问题。

　　Scrum是一个包括了一系列实践和预定义角色的过程骨架。

Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。

管理Scrum过程有很多实施方法，从白板上的即时贴到软件包。

Scrum最大的好处是它非常容易学习，而且应用Scrum不需要太多的投入。

　　每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。

举行冲刺回顾会议是为了进行持续过程改进。

会议的时间限制在4小时。

Scrum提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范（disciplines），这些有助于创造自我组织的团队。

　　Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。

同样，Scrum采用了经验方法–承认问题无法完全理解或定义，而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。

其实践主要包括:

　　客户成为开发团队中的一部分。

（例如客户肯定对开发的结果真正感兴趣。

）

　　频繁的包含可以工作的功能的中间可交付成果。

　　频繁的风险和缓解计划是由开发团队自己制定。

　　计划和模块开发的透明–让每一个人知道谁负责什么，以及什么时候完成。

　　频繁的利益所有人会议，以跟踪项目进展

　　平衡的（发布，客户，员工，过程）仪表板更新–拥有预警机制提前了解可能的延迟或偏差。

　　没有问题会被藏在地毯下。

认识到或说出任何没有预见到的问题并不会受到惩罚。

　　在工作场所和工作时间内必须全身心投入。

–完成更多的工作并不意味着需要工作更长时间。

　　2.FDD（Feature-DrivenDevelopment）-特征驱动开发

　　关键词：

Feature，客户价值，两周迭代粒度，DomainModel

　　Feature-Driven本质上还是ModelDriven，是先规划出整套的DomainModel，做为系统起始的核心。

接下来就是依据Model，开始找出所有的Feature。

而Feature=可以为客户产生价值的最小开发单位。

群集后的Feature称之为FeatureSet。

而系统的某一个主题领域就是组合了很多FeatureSet。

接下来，项目经理就是依据Feature来规画开发的周期，书上建议每次的周期是两周，所以每个Feature必然不可以超过两周，会超过两周的Feature必须再予以细分。

所谓两周内的工作，包含为这个Feature设计、开发、测试、布置。

所谓两周内的工作，包含为这个Feature设计、开发、测试、布置。

　　在RUP中强调的是用例驱动，通过用例进行需求的分析和建模，再过渡到架构设计和后续的开发中。

而在FDD中强调特征驱动，特征是比用例更加小的粒度单位，而且特征更加能够体现客户价值。

在传统的瀑布模型中我们往往在后续编码完成后才能够看到交付的功能，而FDD本身也是一种迭代的思路，只是迭代的单位是Feature，而这些Feature将贯彻从需求到编码测试的全过程，只到每个功能都能够满足一个客户价值的实现。

因此通过特征和特征集将传统的瀑布方法进行了横切，一切软件开发活动包括项目计划都是以特征为单位和特征驱动。

在FDD中主要包括5步流程，具体如下：

　　DevelopanOverallModel（开发一个主域模型）

　　BuildaFeaturesList（通过主域模型分解特征集合）

　　PlanByFeature（根据特征制定项目计划和编排进度）

　　DesignByFeature（根据特征进行设计,开始迭代）

　　BuildByFeature（根据特征进行编码，测试和构建）

　　3.DSDM-动态系统开发方法，也称业务中心框架开发方法

　　关键词：

业务为中心用户参与迭代快速交付团队协作和沟通

　　DSDM（动态系统开发方法，也称业务中心框架开发方法）是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效的进行系统开发。

我们可以把DSDM看成一种控制框架，重点在于快速交付、并补充如何应用这些控制的指导原则的框架。

　　DSDM是一整套的方法论，不仅仅包括软件开发内容和实践，也包括了组织结构，项目管理，估算，工具环境，测试，配置管理，风险管理，重用等各个方面的内容。

　　DSDM的基本观点是，任何事情都不可能一次性的圆满完成，应该用20%的时间完成80%的有用功能，以适合商业目的为准。

实施的思路是，在时间进度和可用资源预先固定的情况下，力争的最大化满足业务需求（传统方法一般是需求固定，时间和资源可变），交付所需要的系统。

对于交付的系统，必须达到足够的稳定程度以在实际环境中运行;对于业务方面的某些紧急需求，也要求能够在短时间内得到满足，然后在以后迭代阶段中对功能进行进一步完善。

对于DSDM主要包括以下9条基本原则:

　　用户必须持续参与

　　必须授予DSDM团队制定决策的权力

　　注重产品的经常交付

　　满足业务用途是接受交付品的主要依据

　　迭代和增量式开发对得到正确的业务解决方案是必不可少的

　　开发过程中的所有变化可逆

　　在高层次上制定需求的基线

　　测试自始自终贯穿于开发周期之中

　　所有项目涉众间的通力合作是不可或缺的

　　4.CrystalMethods-水晶方法族

　　关键词：

协作角色文档迭代风险管理

　　水晶方法论由AlistairCockburn在20实际90年代末提出。

之所以是个系列，是因为他相信不同类型的项目需要不同的方法。

虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。

　　水晶方法把开发看作是一系列的协作游戏，而写文档的目标就是只要能帮助团队在下一个游戏中取得胜利就行了。

水晶方法的工作产品包括用例、风险列表、迭代计划、核心领域模型，以及记录了一些选择结果的设计注释。

水晶方法也为这些产品定义了相应的角色。

然而，值得注意的是，这些文档没有模板，描述也可不拘小节，但其目标一定要清晰，那就是满足下次游戏就可以了。

我总是将这些思想以下面的方式向我的团队成员表达：

通过它们，你只要了解你明天加入这个团队所要知道的内容就行了。

　　对于水晶方法论，根据方法论的轻重可以分为透明水晶和橙色水晶等。

透明水晶一般是轻量级的团队适用。

不管是哪种水晶，都会对团队的角色，团队的工件和产出，核心实践，支持过程等进行定义。

　　5.XP（极限编程）

　　关键词：

UserStory测试驱动结对编程持续集成重构小版本发布沟通

　　ExtremeProgramming（极限编程，简称XP）是由KentBeck在1996年提出的。

KentBeck在九十年代初期与WardCunningham共事时，就一直共同探索着新的软件开发方法，希望能使软件开发更加简单而有效。

Kent仔细地观察和分析了各种简化软件开发的前提条件、可能行以及面临的困难。

1996年三月，Kent终于在为DaimlerChrysler所做的一个项目中引入了新的软件开发观念——XP。

　　XP是一个轻量级的、灵巧的软件开发方法;同时它也是一个非常严谨和周密的方法。

它的基础和价值观是交流、朴素、反馈和勇气;即，任何一个软件项目都可以从四个方面入手进行改善：

加强交流;从简单做起;寻求反馈;勇于实事求是。

XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期;通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

　　XP采用紧凑的迭代开发方式。

强调交流、简洁、反馈、勇敢四种价值观。

强调能满足用户需求的可用的软件（workingsoftware）为最终目标，而不是漂亮的文档。

XP通过12条原则来保证目标的达成。

　　通过客户、开发人员、经理三方共同参加的计划游戏（planninggame）来确定开发计划

　　小版本发布----尽快发布，尽早发布

　　通过系统隐喻（metaphor）来让每个人了解整个系统

　　简单设计----为明确的功能进行最优的设计，不考虑未来可能需要的功能。

　　重构（refactoring）---不断优化系统设计，使之保持简单

　　单元测试----先写测试，后写代码

　　结对编程（pairprogramming）----系统的每一行代码都是2个人用一个键盘完成的。

　　代码集体拥有--开发队伍中任何人可以修改任何其他人的代码，代码不属于某个个人。

　　持续集成----至少每天将整个系统集成一次，保持一个能运转的系统。

　　40小时工作制----保证休息，保持体力

　　现场客户----客户自己也是软件开发队伍的重要一份子

　　编码标准----必须有统一的编码规范，确保代码的可读性

　　6.ASD（AdaptiveSoftwareDevelopment）-自适应软件开发

　　关键词：

领导预测协作学习自适应

　　这种方法强调的是速度和灵活性。

它最适合这种场合:

公司需要应用软件能够迅速见效，还能随客户使用需求的增长而灵活变化。

这种方法的发明者是JimHighsmith。

预测—协作—学习是自适应的模型的。

“预测—协作—学习”不断迭代，从而让团队不断进化，不断适应多变的环境。

　　预测—就是对目标做一个分析，给出一个大的方向，但不要太具体，但是大方向一定要对。

这不仅是提供给团队目标，还有就是让团队中的每个人会因为这个目标而兴奋，而产生激情。

在这个过程中，项目组中要定期的散焦，在一个过程开始时不要太关注于细节实现，而过程进行时要从散焦变成聚焦，逐步协商合作，统一每个人的思想，逼近正确目标，以为后续的工作提供可靠的保证。

　　协作—第一个障碍是强权管理，第二个障碍是个人主义。

相互信任、相互尊重、相互参与、相互承诺是创造双赢的核心。

无论是和客户也好，还是人与人之间也好，还是公司与公司也好，协作绝对是一个人，一个团队，一个公司最具竞争力的核心。

能不能在内部和外部出现协作，是能否自动适应各种环境的重要因素。

协作需要的是努力得整合自己和别人观点的分歧。

　　学习—学习是一种态度。

自我批评、反馈、信息共享是其核心。

我们一定要不停地问自己至少下面三个问题：

和客户讨论时，我们要反复地问，“我们在做正确的事吗?

”，在设计编码测试时，我们要反复地问，“我们用正确的手段做这件事吗?

”，在事后分析时，我们也要反复地问，“还能有更好的方法做这件事吗?

”，在项目过程中要给予这种时间进行反馈、自我批评、并交流个人的心得体会。

于是，我们就在一种高速—慢速—再高速—再慢速—超高速的发展。

　　2001年在软件工程界首次出现“敏捷”这个名词，17个过程方法学家举行了一个讨论会。

发现他们的“轻量级”的方法有很多共同的地方，因此一致同意把这些方法统称为“敏捷”的方法。

并且成立了个叫敏捷联盟的组织，还定下了所谓的“敏捷宣言”。

从此，越来越多的人了解到敏捷方法。

　　敏捷方法有一些共同的特征。

其中有两个最主要的特征是：

轻量和简单。

敏捷方法论包含最少的流程和文档，减少正式性。

目的是做眼前能做的事情，而不去预测太远的未来，首先完成紧迫的事情。

快速的、增量的开发能更快地交付客户使用，更快得到反馈。

开发方法要称之为敏捷，需要具备4个基本特征：

增量的、协作的、直接的、适应性强的。

　　1.SCRUM（橄榄球里的争球）方法论

　　关键词：

30天迭代粒度，每日站立会议，进度透明，客户参与

　　Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。

Scrum在英语的意思是橄榄球里的争球。

虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法。

在SCRUM方法论中其核心仍然迭代和增量，首先对于产品需求会划分为多个迭代或增量，每个迭代都需要在1个月能够交付，而一个月即是一次冲刺，而一个迭代版本又需要转化到每天的进度跟踪和问题解决，这就是每天的15分钟会议（每日站立会议），在会议上必须回答当天的进度，明天的计划和是否存在问题。

　　Scrum是一个包括了一系列实践和预定义角色的过程骨架。

Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。

管理Scrum过程有很多实施方法，从白板上的即时贴到软件包。

Scrum最大的好处是它非常容易学习，而且应用Scrum不需要太多的投入。

　　每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。

举行冲刺回顾会议是为了进行持续过程改进。

会议的时间限制在4小时。

Scrum提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范（disciplines），这些有助于创造自我组织的团队。

　　Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。

同样，Scrum采用了经验方法–承认问题无法完全理解或定义，而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。

其实践主要包括:

　　客户成为开发团队中的一部分。

（例如客户肯定对开发的结果真正感兴趣。

）

　　频繁的包含可以工作的功能的中间可交付成果。

　　频繁的风险和缓解计划是由开发团队自己制定。

　　计划和模块开发的透明–让每一个人知道谁负责什么，以及什么时候完成。

　　频繁的利益所有人会议，以跟踪项目进展

　　平衡的（发布，客户，员工，过程）仪表板更新–拥有预警机制提前了解可能的延迟或偏差。

　　没有问题会被藏在地毯下。

认识到或说出任何没有预见到的问题并不会受到惩罚。

　　在工作场所和工作时间内必须全身心投入。

–完成更多的工作并不意味着需要工作更长时间。

　　2.FDD（Feature-DrivenDevelopment）-特征驱动开发

　　关键词：

Feature，客户价值，两周迭代粒度，DomainModel

　　Feature-Driven本质上还是ModelDriven，是先规划出整套的DomainModel，做为系统起始的核心。

接下来就是依据Model，开始找出所有的Feature。

而Feature=可以为客户产生价值的最小开发单位。

群集后的Feature称之为FeatureSet。

而系统的某一个主题领域就是组合了很多FeatureSet。

接下来，项目经理就是依据Feature来规画开发的周期，书上建议每次的周期是两周，所以每个Feature必然不可以超过两周，会超过两周的Feature必须再予以细分。

所谓两周内的工作，包含为这个Feature设计、开发、测试、布置。

所谓两周内的工作，包含为这个Feature设计、开发、测试、布置。

　　在RUP中强调的是用例驱动，通过用例进行需求的分析和建模，再过渡到架构设计和后续的开发中。

而在FDD中强调特征驱动，特征是比用例更加小的粒度单位，而且特征更加能够体现客户价值。

在传统的瀑布模型中我们往往在后续编码完成后才能够看到交付的功能，而FDD本身也是一种迭代的思路，只是迭代的单位是Feature，而这些Feature将贯彻从需求到编码测试的全过程，只到每个功能都能够满足一个客户价值的实现。

因此通过特征和特征集将传统的瀑布方法进行了横切，一切软件开发活动包括项目计划都是以特征为单位和特征驱动。

在FDD中主要包括5步流程，具体如下：

　　DevelopanOverallModel（开发一个主域模型）

　　BuildaFeaturesList（通过主域模型分解特征集合）

　　PlanByFeature（根据特征制定项目计划和编排进度）

　　DesignByFeature（根据特征进行设计,开始迭代）