总览

原则，模式，实践都是重要的，但是最重要的是人..团队的凝聚力，合作精神，自组织才是团队最大的战斗力。

敏捷实践

缺少实践的指导导致了项目的不可控。于是人们加入了很多的过程，但是冗杂的过程也导致了很多的新问题，人们产生了一种新的价值观，敏捷开发宣言：

• 个体和交互胜过过程和工具(不要直接选择最完备的，可以先使用免费的，或者基础的，等到发现不满足需求的时候，再切换到成熟的，很多时候，更大的，更好的工具造成的障碍大于可以提供的帮助)
• 可以工作的软件胜过面面俱到的文档(真正迫切需要的并且意义重大的时候，再去编写文档，少量文档才是最适合的)
• 客户合作胜过合同谈判(用一个不断变更，不断与客户交流的产品才更容易获得成功，客户不断的参与进来才能够保证软件是适用的)
• 响应变化胜过遵循计划(只做短期的细致计划，长的计划会降低细致度)

敏捷开发原则

• 通过尽早的，持续的交付有价值的软件来使客户满意(就是采用迭代，不断增强功能的方式)
• 即使到了开发的后期，也欢迎改变需求，利用变化来为客户创造竞争优势(其实改变意味着团队如何满足市场的成长，而且会对系统的结构的灵活性有一定的要求)
• 经常性的交付可以工作的软件，交付时间越短越好
• 整个项目开发期间，业务人员与开发人员必须天天在一起工作(必须进行有意义的频繁的交互，持续的引导来指挥项目)
• 围绕被激励起来的个人来构建项目，提供他们所需要的环境与支持，并且信任他们可以完成
• 团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面交谈(文档是迫切且意义重大的时候才会需要，但是默认的交流方式是交谈)
• 工作的软件是首要的进度度量标准(进度应该以整体的功能有多少可以 work 来决定)
• 敏捷过程提倡可持续的开发过程。责任人，开发者和用户应该是长期的。恒定的开发速度(不要透支团队的力量，应该以一个稳定，快速的速度前行)
• 不断关注优秀的技能和好的设计会增强敏捷能力(高的产品质量，今天的混乱，今天就得解决干净，每个人都编写最高质量的代码)
• 简单–使未完成的工作最大化的艺术–是根本的(只在今天以最高质量完成最简单的工作，即使明天发生了问题，也很容易进行处理)
• 最好的架构，需求和设计来自于自组织的团队(任务并不是分配给各个成员的，应该是整个团队来对任务负责，每个成员都有参与所有方面的权力)
• 每隔一段时间，团队对如何更有效的工作进行反省，然后相应的调整自己的行为(不断地对组织方式，规则，规范进行调整)

极限编程

简称 XP，是敏捷方法中最著名的一个。

客户作为团队成员。

测试驱动的开发方法。

集体所有权。

持续集成。

可持续的开发速度。(不是一蹴而就的过程，必须以可持续化的速度前进)

开放的工作空间。(积极讨论的环境里工作，效率不但不会降低，反而会成倍的提高)

计划游戏(其实就是根据最新一次迭代，让客户知道具体实现某个功能所需要的预算)

简单的设计

• 考虑能够 work 的最简单的事情
• 不要为了将来可能的东西而引进某些成熟的东西，只有在知道现在引入更加合算的时候，才会去引入基础结构
• 一次(对于重复的事物的容忍度为 0，学会抽象)

代码会慢慢的腐化，所以我们需要多次的重构，然后通过单元测试来保证没有破坏。是个持续进行的工作

隐喻：感觉就是用生活中的例子来类比中间的开发过程

计划

开发人员共同对这些素材进行估算。素材过大或者过小都会影响到评估

迭代为每两周一次，无论完成了多少也要结束本迭代，这样就得到了一个迭代能够完成的点数。

迭代进行到一般的时候，团队会召开一次会议，就是进行进度的评估与调整。

一次次的迭代和发布之后，项目进入了可预测的，舒适的开发节奏。整个的进度会变得可以把控。

测试

测试驱动能够让我们在写代码的时候就设计为可测试的和易于调用的。(因为一开始就设计了测试用例)

每个功能都能够被验证是可以使用的，后续的开发就可以看到自己是否造成了影响

测试促使代码分离

重构

代码其实有 3 个职责的：

• 运行起来所能够提供的功能
• 应对变化
• 与要阅读他的人沟通

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 981909093@qq.com