敏捷开发四大原则,敏捷开发的基本原则

敏捷开发的遵循原则

我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。

工作的软件是首要的进度度量标准。

敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

n 不断地关注优秀的技能和好的设计会增强敏捷能力。

简单是最根本的。

n 最好的构架、需求和设计出自己组织的团队。

n 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

当软件开发随需求的变化而变化时，软件设计会出现坏味道，当软件中出现下面任何一种气味时，表明软件正在腐化。

n 僵化性：很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。

n 脆弱性：对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。

n 牢固性：很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。

n 粘滞性：做正确的事情比做错误的事情要困难。

不必要的复杂性：设计中包含有不具任何直接好处的基础结构。

n 不必要的重复性：设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。

晦涩性：很难阅读、理解。没有很好地表现出意图。

敏捷团队依靠变化来获取活力。团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性，持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。

为了改变上面软件设计中的腐化味，敏捷开发采取了以下面向对象的设计原则来加以避免，这些原则如下：

单一职责原则（SRP)

就一个类而言，应该仅有一个引起它变化的原因。

开放-封闭原则（OCP)

软件实体应该是可以扩展的，但是不可修改。

n Liskov替换原则（LSP)

子类型必须能够替换掉它们的基类型。

n 依赖倒置原则（DIP)

抽象不应该依赖于细节。细节应该依赖于抽象。

n 接口隔离原则（ISP)

不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。

n 重用发布等价原则（REP)

重用的粒度就是发布的粒度。

共同封闭原则（CCP)

包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。

共同重用原则(CRP)

一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。

环依赖原则（ADP)

在包的依赖关系图中不允许存在环。

稳定依赖原则（SDP)

朝着稳定的方向进行依赖。

稳定抽象原则（SAP)

包的抽象程度应该和其稳定程度一致。

上述中的包的概念是：包可以用作包容一组类的容器，通过把类组织成包，我们可以在更高层次的抽象上来理解设计，我们也可以通过包来管理软件的开发和发布。目的就是根据一些原则对应用程序中的类进行划分，然后把那些划分后的类分配到包中。

敏捷设计是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。

敏捷开发的敏捷开发团队原则

敏捷型方法发源于20世纪90年代的 IT 软件开发行业。

2001年，软件开发业的17位领导者在美国犹他州聚会，发布了《软件开发敏捷宣言》，进而从《敏捷宣言》派生出了12条敏捷原则，他们分别是：

（1) 我们的最高目标是，通过尽早地、持续地交付有价值的软件来使客户满意。

（2) 即使是在项目开发后期，也欢迎对需求提出变更。敏捷过程利用适应变化来帮助客户创造竞争优势。

（3) 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。

（4) 项目过程中，业务人员与开发人员必须在一起工作。

（5) 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

（6) 无论是团队内还是团队间，最有效的沟通方法是面对面的交流。

（7) 可用的软件是衡量进度的主要指标。

（8) 敏捷过程提倡可持续的平稳开发。项目方、开发人员和用户应该能够保持恒久稳定的开发速度。

（9) 对技术的精益求精以及对设计的不断完善将提升敏捷性。

（10) 简单——尽最大可能减少不必要的工作。这是一门艺术，是根本。

（11) 最佳的架构、需求和设计出自于自组织的团队。

（12) 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

以上就是敏捷开发的十二原则，希望可以解答您的问题。

敏捷开发原则

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动 高于 流程和工具

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

尽早并持续的交付有价值的软件以满足客户需求。

行为：

以最少的功能尽早交付客户

以最短的周期持续的交付客户

结果：

早期交付功能越少，最终交付质量越高

交付的越频繁，交付质量越高

敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势。

行为：保持开放和学习的心态，欢迎变更。并积极应对变更或者进行创新。

结果：客户满意度增加，人员技能和学习能力提升，产品质量提高，团队灵活度增加。

经常发布可用的软件，发布间隔可以从几周到几个月，能短则短。

行为：尽早并且经常发布可用软件，而不是文档。

结果：客户满意度和产品质量提高。

业务人员和开发人员在项目开发过程中应该每天共同工作。

行为：

引导团队成员共同理解软件

团队成员一起沟通理解项目进度

团队成员一起相互沟通理解彼此的想法

结果：

沟通效率大幅提升，产品质量提高，客户满意度增加

以有进取心的人为项目核心，充分支持信任他们。

行为：以有进取心的员工为核心，充分支持并信任他们

结果：你给我一个机会，我还你一个惊喜

无论团队内外，面对面的交流始终是最有效的沟通方式。

行为：无论团队内外，文档不是默认的沟通方式，沟通方式都推荐面对面的交流

结果：沟通效率大幅提升，产品质量提高

可用的软件是衡量项目进展的主要指标。

行为：使用可用的软件作为项目的主要指标

结果：需求的完成度和软件的可用程度提高

敏捷流程应能保持可持续的发展。领导，团队和用户应该能按照目前的步调持续合作下去。

行为：保持一致的速率开发

结果：快速可持续的发展

持续关注卓越的技术和优良的设计，会增强敏捷能力。

行为：

关注卓越的技术和优良的设计

结果：

随时准备对项目使用最好的技术和优良的设计

在当前的需求下当前的设计是最好的，技术是最合适的

简明为本——它是极力简化不必要的工作量的技艺。

行为：

不做过度设计和华而不实的设计

直到新需求出现时才考虑它

结果：

改善用户体验，产品就是说明书，降低学习曲线

简化不必要的工作量

只有自我管理的团队才能创造最优秀的架构，需求和设计。

时时总结如何提高团队效率并付诸行动。

敏捷软件开发的软件四条原则

递增，而不是连续的：如果开发实践是真正的敏捷精神，那么交付的工作软件是一小部分一部分递增的。不必等到一个阶段完全完成后才开始另一个，工作也不是向大的发布日期而努力。完成的工作，但并不是业务最终期限，驱动着敏捷交付。但敏捷精神也承认业务操纵着最后截止日期。 避免不必要的开销：如果实践仍然是真正的敏捷精神，那么团队就致力于尽可能多地减的项目计划和文档。与其讨论要做什么，然后再写下来，不如赶紧动手云做。否则，就是在浪费时间在工作的工作上。在工作对工作中，敏捷精神有利于于实际的工——作交付工作软件。而且它也值面对面的交流通过邮件和其他书面文件。 协作：根据需求，团队成员一直与其它人进行交互，以及一些外部利益相关者。在敏捷教练世界中，整个团队的负责人Lisa Crispin能够解决所有问题，在问题出现之前 。真正的敏捷精神团队是自助的。他们分配需要做的工作。虽然每个成员承担的任务都在他们的专业技能范围内，他们还是需要与团队协作的。没有人的工作孤立的，也没有团队本身是独立工作的。没有业务利益相关者，以及诸如用户体验方面的外部专家的重大投入，团队就不可能使项目向前发展， 说真话：为是保证真正的敏捷，团队探讨的与项目相关的一切都要是真实的。在一些至关重要的专业领域，如冲刺测试的编码技能，他们承认存在差距。关于实际生产力，他们的要讲事实；这也就是说，在y时间内，团队是否有能力做x。他们承认错误。说真话是一项挑战，因为我们害怕承认缺点会让我们显得很弱。但敏捷精神知道说出事实需要勇气。承认问题需要信心，然后快速地去解决问题。

敏捷开发的敏捷开发的原则

1. 快速迭代

相对那种半年一次的大版本发布来说，小版本的需求、开发和测试更加简单快速。一些公司，一年仅发布仅2~3个版本，发布流程缓慢，它们仍采用瀑布开发模式，更严重的是对敏捷开发模式存在误解。

2. 让测试人员和开发者参与需求讨论

需求讨论以研讨组的形式展开最有效率。研讨组，需要包括测试人员和开发者，这样可以更加轻松定义可测试的需求，将需求分组并确定优先级。 同时，该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。

3. 编写可测试的需求文档

开始就要用“用户故事”（User Story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早的提及技术实施方案，会降低对需求的注意力。

4. 多沟通，尽量减少文档

任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。在圈子里面混得越久，越会强调良好高效的沟通的重要性。

团队要确保日常的交流，面对面沟通比邮件强得多。

5. 做好产品原型

建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。

6. 及早考虑测试

及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。