敏捷开发
人与人之间的交互是复杂的，并且其效果从来都是难以预期的，但却是工作中最重要的方面。
-- Tom DeMacro和Timothy Lister
敏捷软件开发宣言：
n 个体和交互 胜过 过程和工具
n 可以工作的软件 胜过 面面俱到的文档
n 客户合作 胜过 合同谈判
n 响应变化 胜过 遵循计划
虽然右项也有价值，但是我们认为左项具有更大的价值。
敏捷宣言遵循的原则：
n 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
n 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
n 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
n 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
n 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
n 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。
n 工作的软件是首要的进度度量标准。
n 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
n 不断地关注优秀的技能和好的设计会增强敏捷能力。
n 简单是最根本的。
n 最好的构架、需求和设计出于自组织团队。
n 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
当软件开发需求的变化而变化时，软件设计会出现坏味道，当软件中出现下面任何一种气味时，表明软件正在腐化。
n 僵化性： 很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。
n 脆弱性： 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
n 牢固性： 很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。
n 粘滞性： 做正确的事情比做错误的事情要困难。
n 不必要的复杂性： 设计中包含有不具任何直接好处的基础结构。
n 不必要的重复性： 设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。
n 晦涩性： 很难阅读、理解。没有很好地表现出意图。
敏捷团队依靠变化来获取活力。团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性，持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。
文章来源于领测软件测试网 https://www.ltesting.net/
