敏捷开发与Scrum详解-CSDN博客

Scrum敏捷方法

工程式项目管理机制，无法快速响应市场需求。运营商通常采用的流程是：列出需求点、项目建议书评审、设计、招标、建设、试点上线、正式上线，是以“年”作为周期来实现需求。从移动互联网产业的角度来看，是非常可笑的。在快鱼吃慢鱼的今天，这种模式必须做出调整。工程式项目管理还带来的问题包括：过度追求项目收益评估、重视风险远高于重视机遇、管理模式落后等等。

敏捷软件开发

敏捷软件开发又称敏捷开发，是一种新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

敏捷软件开发的价值观，强调人和（人与人的）交互优先于过程和工具；可以工作的软件优先于求全责备的文档；客户协作优先于合同谈判；随时应对变化
优先于循规蹈矩。

个体和交互胜过过程和工具，人是首要关键的因素，不好的过程可以使得优秀的团队失去作用；一个优秀的团队成员可能是一个平均水平的程序员，但是能够很好的合作，比单纯编程能力更重要，更难获得成功；合适的工具辅助团队出色的完成工作，但是避免庞大笨重的工具；团队的构建比环境的构建更重要。

可以工作的软件胜过面面俱到的文档，没有文档的软件是一种灾难，团队需要编制易阅读的文档，来对系统及其设计进行描述，过多的文档比过少的文档更糟糕，需要花费大量的时间对文档与代码保持同步，如果文档和代码不同步，文档就变成庞大和复杂的谎言。文档短小，主题突出，描述系统的结构和概括的设计原理，团队中保持系统的脉络图，并且通过人与人的交互传授是最有效最快的方式。

客户合作胜过合同谈判，系统不能以描述性合同式的委托开发，成功的项目需要有序和频繁的客户反馈，让软件的客户和开发团队密切工作一起，项目需求得以响应，合同支持这样的变更和合作，而不是规定项目的范围细节和固定成本模式的项目进度。

响应变化胜过遵循计划，相应变化的能力决定软件项目的成败，计划是灵活的，适应商务和技术的变化，计划不能考虑的过远，商务环境的变化引起的需求变更，需求变得难以估计工时；团队对系统的认识增加，客户对需求的认识的深入都有可能影响原计划任务的变更，计划的策略是，为下两周做详细的计划，为三个月做粗略的计划，为以后做粗糙的计划。

宣言中还包括以下原则：

对敏捷而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要；欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势；经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好；业务人员和开发者应该在整个项目过程中始终朝夕在一起工作；围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务；在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈；可以工作的软件是进度的主要度量标准；敏捷过程提倡可持续开发，出资人、开发人员和用户应该总是维持不变的节奏；对卓越技术与良好设计的不断追求将有助于提高敏捷性。

简单——尽可能减少工作量的艺术至关重要；最好的架构、需求和设计都源自自我组织的团队；每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

1、通过尽早的、持续的交付有价值的软件来是客户满意,尽早地交付具有部分功能的系统和系统质量之间有很强的相关性，以逐渐增加功能的方式经常性地交付系统和最终质量之间也有很强的相关性；

2、即使到了开发的后期，也欢迎改变需求，敏捷过程的参与者不惧怕变化，改变需求是好的时期，与围着团队学到了如何满足市场需求的知识；

3、经常性交付可以总做的软件，交付的间隔可以从几周到几个月，越短越好，而不是交付大量的文档和计划，交付满足客户需求的软件；

4、开发期间，业务人员和开发人员必须每天都在一起工作，为了能够以敏捷的方式进行项目开发，客户、开发人员以及相关人员之间必须要进行有意义的频繁的交互。

5、围绕被激励起来的个人构建项目，给他们提供所需的环境和支持，并且信任他们能否完成工作，人被认为是项目取得成功的最重要因素，过程，环境和管理等因素是次要的。

6、团队内部，最具有效果并且富有效率的传递信息的方法是面对面的交谈，文档是次要的沟通方式。

7、工作的软件是首要的进度度量标准，通过度量当前软件满足客户需求的数量来衡量开发的进度。

8、敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能否保持一个长期的、恒定的开发速度。团队测量自己的速度，不需要快速冲刺而让自己过于疲劳，工作在一个可以使整个项目开发期间保持最高质量的标准速度上。

9、不断地关注优秀的技能和好的设计会增强敏捷能力。保持软件的简洁、健壮，编写高质量的代码，拒绝混乱代码然后进行清理。

10、简单，使得未完成的工作最大化的艺术是根本，采取和目标一致的最简单方法，不去构建华而不实的系统，不看重明天可能会出现的问题的预测，今天的工作高质量完成。

11、最好的构架、需求和设计出自于自组织的团队。敏捷团队是自组织的团队，成员共同来解决项目中的所有方面的问题，都有参与的权利，团队共同担责，共同影响。

12、每隔一定时间，团队会如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。团队不断地对团队的组织方式、规则、规范、关系进行调整，适应环境的变化。

敏捷方法强调适应性而非预见性，适应性的方法集中在快速适应现实的变化，当项目的需求起了变化，团队应该迅速适应。敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。

相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。相比瀑布式开发，两者没有很多的共同点，瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行，步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等。瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

衡量敏捷方法的适用性：从产品角度看，敏捷方法适用于需求萌动并且快速改变的情况，如系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；从组织结构的角度看，组织结构的文化、人员、沟通则决定了敏捷方法是否适用。跟这些相关联的关键成功因素有：组织文化必须支持谈判，人员彼此信任，人少但是精干，开发人员所作决定得到认可，环境设施满足成员间快速沟通之需要，敏捷软件开发的原则、模式和实践都是重要的，但是使得它们发挥作用的是人，必须构建具有合作精神和自组织的团队。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，40人以内。大规模的敏捷软件开发尚处于积极研究的领域。

目前列入敏捷方法的有：

Scrum

极限编程，XP Extreme
Programming

XBreed

软件开发之韵，Software
Development Rhythms

敏捷数据库技术，AD/Agile
Database Techniques

敏捷建模，AM/Agile
Modeling

自适应软件开发，ASD/Adaptive
Software Development

水晶方法，Crystal

特性驱动开发，FDD/Feature
Driven Development

动态系统开发方法，DSDM/Dynamic
Systems Development Method

精益软件开发，Lean Software
Development

AUP（Agile Unified Process）

探索性测试

敏捷技术

测试驱动开发，TDD/Test-Driven
Development

行为驱动开发，BDD/Bahavior-Driven
Development

极限编程介绍

极限编程的哲学思想，一种社会性的变化机制，一种开发模式，一种改进的方法，一种协调生产率和人性的尝试，一种软件开发方法，

XP的价值：沟通、简单、回馈、勇气、尊重。
极限编程的实践

极限编程核心的实践包括：小规模回馈，测试驱动开发，策划游戏，全队又叫在场客户，结对程序设计，反复性程序而不是批量的，持续集成，设计优化又叫软件重构，小型发布。

极限编程的共识：简单的设计，系统隐喻，集体代码所有，程序设计标准／程序设计规约。

极限编程程序员的利益：恒定速路，可反复性速率（原名：每周40小时）

开发人员和客户之间的沟通交互是有帮助的。因此，一个极限编程的小组从理论上要求需要一个软件用户在身边，这个用户制定软件的工作需求和优先等级，并且尽可能在各种问题出现的时候马上就能回答。

如果学习是好的，那么就把它做到底，这样减少了开发和回馈周期的长度，测试也能更早完成。

简单的代码更可能工作，极限编程的软件工程师在一个软件专案中唯写出能够满足目前实际需求的代码，这样或多或少降低了代码的复杂性和重复性。

如果简单的代码是好的，那么把变得复杂的代码改写成简单的。

代码评审是好的。因此，极限编程的程序设计师以两人搭档的方式工作。他们共享一个屏幕和键盘，增加了队员之间的交流，也让代码在一被写出的时候就被人评审了。

测试代码是好的。因此，在极限编程中，测试用例在实际代码之前就被写出来了。代码只有在通过测试的时候才被认为完成了。（当然，需要进一步分解来降低复杂性）。整个软件系统用一种周期化的，实时的，被预先编好的自动化测试方式来保证它的确有作用。参看
测试驱动的开发。

一般来说，极限编程被认为对于少于12人的小团队很有用。一些人认为极限编程可以用于大的团队，但是其它人认为Rational统一过程更适合大的团队。然而，极限编程在一些超过100人的开发小组中获得成功。并不是极限编程不能够推广到更大的团队，而是很少有更大的团队来试著用它。极限编程的人员也拒绝去随便推测这个问题。

Scrum介绍

Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发，Scrum在英语的意思是橄榄球里的争球。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法，Scrum之间的合作称为“Scrum of Scrums”。

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

n Scrum中的主要角色包括：

Scrum Master是Scrum教练和团队带头人，确保团队合理的运作Scrum，并帮助团队移除实施中的障碍；

产品负责人（Product Owner），确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品ROI负责；

开发团队（Team），一个跨职能的小团队，人数3-9人，团队拥有交付可用软件需要的各种技能。

在每一次冲刺（一个15到30天的周期，其长度由开发团队决定）当中，开发团队创建可用的（可以随时推出）软件的一个增量。每一个冲刺所要实现的功能来自产品订单（product backlog）。产品订单是按照优先级排列的要完成的工作的概要的需求，哪些订单项会被加入一次冲刺将由冲刺计划会议决定。
在会议中，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。

在冲刺的过程中，没有人能够变更冲刺订单（sprint
backlog），这意味着在一个冲刺中需求是被冻结的。

管理Scrum过程有很多实施方法，从即时贴、白板，一直到软件包。Scrum最大的好处之一是它非常容易学习，而且启动Scrum应用并不需要太多的投入。

Scrum当中定义了许多角色。按照对开发过程的参与情况，这些角色被分为两组，即猪组和鸡组。

n "猪"组的角色

猪是在Scrum过程中全身投入项目的各种角色，他们在项目中承担实际工作。他们有些像上边那个笑话里的猪，要把自己身上的肉贡献出来。

产品负责人：产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写用户故事，排出优先级，并放入产品订单。

Scrum主管（或促进者）：Scrum主管促进
Scrum过程，他的主要工作是去除那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导（因为团队是自我组织的），而是一个负责屏蔽外界对开发团队的干扰的角色。Scrum主管确保Scrum过程被按照初衷使用。Scrum主管是规则的执行者。

开发团队：负责交付产品的团队。一个团队通常由5至9名具有跨职能技能的人（设计者，开发者等）组成，承担实际的开发工作。

n "鸡"组的角色

鸡并不是实际Scrum过程的一部分，但是必须考虑他们。敏捷方法的一个重要方面是使得用户和利益相关者参与到过程中的实践。参与每一个冲刺的评审和计划，并提供反馈对于这些人来说是非常重要的。

用户：软件是为了人而开发的。假如软件没有被使用，那么它算是被开发出来了么？

利益相关者（客户，提供商）：影响项目成功的人，但只直接参与冲刺评审过程。