敏捷之以交付用户想要的软件为目的

没有任何计划在遇敌后还能继续执行

                                                ——Helmuth von Moltke(德国陆军元帅)

上面这句话的意思是，我们需要制定计划，但是我们的未来不是按照计划运行的。

场景一：

       客户把需求交给你，要你几年后交付该系统，然后你基于这些需求构建系统，几年后按时交付，然后客户看了以后连声叫好。从此你又多了一个忠实客户，然后你又专心的转向另外一个项目。

场景二：

       客户最后看到了软件，要么震惊要么不高兴。他们不喜欢他们看到的软件。他们认为软件需要很多修改。他们的这些需求并不在文档中。

       场景一，我没遇见过，而场景二则已司空见惯。

       在各种软件开发项目中，我们真正的敌人是变化。这就像一场战争，战场形势，瞬息万变，包括需求的变化，或者对需求理解的变化，以及随着项目深入，由需求导致的使用技术的变化，当前流行技术的变化，等等。这些变化在项目进行之前是无法通过指定计划的，否则也不能叫做变化了。

       敏捷开发的真谛是快速应对变化，这需要我们有应对变化的预案，即所谓的留一手。

       敏捷开发应对需求变化的方法是，让客户做决定。这其实类似迭代开发，我们做出一个新功能，我们给客户做一个demo，客户提出意见。我们修改，然后我进行下一个功能的迭代。

       如果你自己都不清楚你所谈论的东西，那你根本不可能精确的描述他，这不知道是哪位boss说的，这句话带给我们的信息是，在和客户交流的时候，一定要注意精确，不如说他们的概念中的一天中的最后一秒是11:59还是12:00，诸如此类的问题，可能会给项目带来很多ugly的麻烦。

      关于项目中使用技术的选取，有一个原则就是，敏捷，不一定要十分流行，重要的是要适合这个项目。还有一个原则是，不要开发你能下载到的东西。还有一个说法是，盲目的选择技术，就相当于为了打折而买一堆无用的东西。另外还有一点要注意的是，千万不要为了让你的简历增加一些新技术的经历，而选取一些流行的技术，这种情况貌似在我们之中十分常见。

       另外一个要十分注意的是，要保持代码随时可以发布。代码库中的任何一个版本，最好是保证它能发布出去。在进行一些bug的修订的时候，最好是先更新本地代码到最新版本，然后修改bug,调试，通过以后最后再更新一遍，再重新测试，说不定又会有新的冲突发现，你的同事和你修改了同一部分的代码，在你解决所有的冲突，系统能正常运行之后，你方能将你的代码提交到代码仓库。只要你坚持上面的原则，代码仓库中的任何版本都可以运行。无外乎是一些功能性的缺失而已。

      提早集成，频繁集成。如果你和同事们分别开发独立的模块，这个时候我们的原则是及早的集成，而且频繁的集成，尽管你认为我们的接口定义的已经十分完善，我们在执行的时候也十分严格，但是谁能保证集成后不出问题呢。而通常这个问题就像病毒一样。随着时间的增长会变的十分麻烦，所以我们建议尽早集成，频繁集成。千万不要做大爆炸式的集成。

      最后一个原则就是提早实现自动化部署，这一点笔者感触尤其深。你在开发机器上搭建了一个很复杂的环境，安装各种有着复杂依赖关系的库。然后终于开发环境搭建起来了。等你项目进行到中间，需要部署到临时服务器上，对外发布了，你这个时候又得纠结一遍你当时部署开发环境的时候的过程，我们的建议是，尽早实现自动化部署。用脚本或者其他的方式，自动化开发环境或者部署环境的搭建。这样一劳永逸。一个原则是如果部署很复杂，可能项目后期的维护也很复杂，你就需要考虑下是不是程序的设计或者其他的方面出现了问题。

 

转载于:https://www.cnblogs.com/xuq22/archive/2011/11/19/3769289.html