【敏捷软件开发：原则、模式与实践】之敏捷实践

参与公司的敏捷开发也有一段时间了，还没有系统的学习过敏捷开发。比如早上的站会，每个月的迭代会，还有自己领取任务去开发故事，这些都是敏捷开发的流程之一。敏捷开发需要不断的学习，不断的实践。现在开始写一些关于敏捷开发的博客。

一  敏捷联盟

   

  1  个体和交互胜过过程和工具

      一个优秀的团队成员未必是一个一流的程序员，可能他只是一个平均水平的程序员，但是却能够很好地与他人合作。合作、沟通以及交互能力要比单纯的编程能力更为重要。

  合适的工具对于成功来说是非常重要的。建议从小工具开始，直到发现它不再适用才去更换它。不要急着去购买哪些昂贵的代码控制系统，在使用庞大、高性能的数据库系统前，先适用平面文件（flat file）。不要认为更大、更好的工具能够自动帮你做的更好，它们往往造成的障碍要远远大于帮助。

  记住，团队的建设要比环境的搭建重要的多。

  2  可以工作的软件胜过面面俱到的文档

直到迫切需要并且意义重大时，才去编写文档。 没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。然而，过多的文档比过少的文档更糟。编制更多的文档需要花费大量的时机，并且要是这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，文档就会变成庞大的、复杂的谎言，会造成误导。

 3 客户合作胜过合同谈判

   为开发团队和客户提供的协同方式提供指导的合同才是最好的合同。举个例子，在项目开发期间，我们和客户紧密的在一起工作。几乎每个周五，我们都会把软件提交给客户。到写一个周的周一或周二，客户会给我们一份关于软件的变更列表。我们会把这些变更放在一起排定优先级，然后把他们安排在随后几周的工作中。客户和我们如此紧密地在一起工作，以至于验收测试根本不是问题。因为他们周复一周的观察着每一个功能块的演进，所以他们知道何时这个功能块能满足他们的需要。

4 响应变化胜过遵循计划

   较好的计划策略是：为下周做详细的计划，为下三个月做粗略的计划，在以后就做极为粗糙的计划。我们应该清楚的知道下两周完成的任务，粗略的了解以后三个月要实现的需求。至于系统一年后将要做什么，有一个模糊的想法就行。

二  12项原则