传统开发模式能从敏捷开发中借鉴什么？

     我手头的这本《硝烟中的Scrum和XP》是互动出版社赠送的，在这里谢谢"图灵教育－晓敏"和互动出版社。
    在读这本书之前，我对敏捷开发基本上一无所知，虽说也听过结对编程，极限编程等概念，但没深究过。
   我下面主要会说到2件事：
   一，简要说明我所在公司所用的软件开发方法（估计也是大多是公司采用的）
  二，敏捷开发中有哪些值得借鉴的（很多话可能摘自本书原文）
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  一，
    我所在的部门所用的软件开发有点像“瀑布模型”，从产品的spec确定（主要由PM负责）--->需求分析（主要由项目经理以及RD参与）--->软件设计（项目经理和RD--->程序编码（RD负责）--->测试（测试人员和RD负责）--->运行维护（RD负责）。期间可能为了方便维护产生大量文档：PS（规格说明书），Mockup（产品雏形）， ES（需求说明书），DS（设计说明书），TP（测试计划）等等。确实很耗费时间，最耗费时间的2个点是：
    1，ES这点（PS是由PM确定，所以我不知道实际情况），常常到编码完成了ES还会改变，PM有时自己都不知道需求，一天变一个说法，RD和PM有时交流有问题，大部分PM不会写code，有些问题跟他们说不清楚，当然RD有时也乱七八糟的。
    2，测试阶段，我们的方法是先内侧，然后交给专门的测试人员，把所有feature测一遍，回归测试等，如果时间比较紧的话，RD没很多时间做单元测试，代码质量有待商榷，而且RD一般都不喜欢测试自己代码，现在测试自动化应用也没那么广泛，很多还是要手工测试，这又取决于测试人员的效率和素质，测试人员（QA）有时和RD沟通有时会有困难，尤其是异地！产生bug后，有些bug还需要跟PM确认，甚至会影响ES，RD修复然后再给QA测试，总之很耗费时间。
    如果一款产品从Ps制定到交付给客户需要6个月，真正用于编码的时间可能只有1.5月，不顺的话，测试和修复bug阶段可能要占据接近2月。
   效率是比较偏低的。当然这样出来的产品应该比较稳，但却是耗费了很多人力和时间。那么，我们可以从敏捷开发中学到什么？
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  二，
   我对scrum和xp了解甚少，以后会持续关注，这我的水平也不适合阐述scrum和xp的种种。
   这儿我主要提2个东西，backlog和sprint。

   backlog就像需求分析文档，不过它是以条目的形式组织在一起，而不是分散在文档中，用excel等工具展示出来的话比较清晰。
    有几点值得借鉴的是，它有一个字段是important，标识这个item的重要性。还有一个字段标识，这个item（比如添加一个用户）会花多少时间完成。还有个字段讲如何做演示（这里就考虑到测试了）。而且它的字段是弹性的，所以可以加一些其他标识字段，这样一来即便新人接手也会一目了然，总比看ps和Es文档来得快！！

   Sprint就感觉像一个project（或者project阶段）从开始到结束的过程。
    制定sprint计划，这里涉及到resource和时间的分配以及确定产品的哪些feature需要完成还有很多细节，我觉得站着开会是个不错idea。
然后把讨论后的规划贴出来，让大家都能看见，这样目标也比较明确，用小黑板和墙是个不错的建议。根据项目的进度更新小白板和墙是个更不错的建议。让别人知道你们在干嘛...在小白板上把任务分解，用一些曲线或者其他几何形状标识一些东西，这样客户心里也有底：哦，他们在干嘛干嘛...领导心里也有底，这些家伙没有混日子的。加入新人也能一目了然得知道你们在干嘛...自己人也看到进度条在动或者自己做了些事情。
    
  RD之间坐的近，相互充分交流有助于开发效率的提高，遇见问题也可以立马问，总之团队气氛要活跃，死气沉沉不是好事。

  像做销售一样，为了让项目经理知道项目进展状况，每日例会是个不错的建议，而且时间也短，大家早上来上班就制定计划，今天要干嘛干嘛，周围人也知道，你也偷不了懒，你也不好意思拖进度，没事可以给你找事做。
 
   做阶段性的产品演示可以让rd感觉自己在完成某种东西，至少不是虚度年华！！！

  集体进行阶段性的回顾。

  多用维基百科(感觉这样文档只有一份，而且不会丢，便于查找，放在server上有时不方便，而且本地还有多份拷贝）。版本控制系统就不说了。

  让员工有时间思考自己的工作，加入自己的idea或者完成自己的想法(这个要求太高，不是每个公司都像google）


  发布产品最好不要延期，同时要确保质量，如果可以放到下一版，那就下一版本吧。

   测试是个难题，测试是提高代码质量的最可靠方法之一。但测试需要时间，所以如何利用工具或者脚本多做自动化测试，如何提高手工测试效率等等问题都值得探讨。

   结对编程不好实施。

   提高自己的编码素质，变得更牛更牛！！

  书中讲到的团队管理这里就不多copy了。

  总之是本很具参考价值的书籍。