小谈敏捷

    公司一直采用瀑布模式开发，也通过了CMMI 3级认证，不过最近公司开始向敏捷方式转变。和华为的一个朋友交流，他们由现在的IPD模式也开始向敏捷模式转变，貌似敏捷开始了一股热潮。
    敏捷是一种高效的开发模式，但并非任何项目都适合，而且并非一定要推翻现在的瀑布模式完全采用敏捷。敏捷的本质是什么？敏捷的核心原则是什么？瀑布模式能否将敏捷的思想用过了从而优化现在的模式呢？
    没有任何一种模式说是适合于任何公司，任何项目，还是要从公司特性，项目特性来看。下面就结合敏捷思想一一解读，看那些适合优化瀑布模式。
   
    敏捷宣言：
    1.个体和交互 胜过 过程和工具
    2.可以工作的软件 胜过 面面俱到的文档
    3.客户合作 胜过 合同谈判
    4.响应变化 胜过 遵循计划

    敏捷12原则
    1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
    //这点指导我们要尽可能最早将客户需求明确、细化，当然很难一次性将客户的需求完全挖掘出来，但是我们起码可以试着提高我们的需求挖掘，细化能力，每一次和客户(市场人员)交流能够尽可能多地明确需求，减少需求迭代的次数
 
    2.即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
    //敏捷提出的背景就是应对客户不断改变的需求，除了上述提到的第一点来减少迭代次数外，也要保证迭代影响面尽可能小。这就要求我们设计的代码耦合性尽可能低

    3.经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
    //交付间隔越短，就会越多越明确地了解客户的需求。在瀑布模式中其实也可以指导我们多和需求引入人、合入人交流

    4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
    //1.保证项目的稳定，只有一个稳定的团队才能带来项目的持续进展  2.也可进行结对测试，既减少沟通量，可通过模块责任人制保证质量。

    5.围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
    //团队的成功，离不开项目人员和项目负责人的相互支撑。提供任何需要的环境和其他支撑工作，可通过环境固化提高环境复用率。敏捷是以人为本的模式，离不开团队各成员的互相信任和支持，但这并不代表100%的自由，我们还是需要一定的抽查机制来检验相应的工作成果的

    6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
    //要减少无效沟通，提高沟通质量，确保沟通的高效性。但是并非就不要文档了，有时候项目的过程还是需要一定的显性文档的，如bug管理平台，svn配置管理等来对工作进行归档，检视，做好PDCA。

    7.工作的软件是首要的进度度量标准。
    //软件进度的度量标准有多种，但是不要忘了最重要的一点，我们最终是要开发出高质量的 满足客户需求的软件。可以把需求细化成一个个story，设计并测试完即可认为完成一个功能的build。另外进度的敏捷也可以考虑如下方法或理念：敏捷就将任何可提前做的事，前移，可以采用看板管理进度。doing，done，to do等了解短阶段应该要完成的任务，其实项目中经常会发生这样的现象，前面轻松后面紧张很大一部分原因是，做完前面的事后不知道后面要做什么事，只能再等负责人的安排。

    8.敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
    //这个需要保证项目成员的稳定，不能出现这样的现象，这个人员过几天被抽调了，那个成员过几天又被抽调了。而且需要保证一定的老员工和新员工比例，既保证人员可持续发展，也要保证项目可持续发展。

    9.不断地关注优秀的技能和好的设计会增强敏捷能力。
    //变化是IT最大的杀伤工具，也是IT最大的魅力。要时常拥抱变化，新功能用什么技术可以更高效地开发维护等

    10.简单——使未完成的工作最大化的艺术——是根本的。
    //复杂的事情做简单是一门艺术，很多时候一个js页面，一个cgi都被开发人员设计的相当复杂，如果能够从小事开始做起，简单将不再遥远。不过这个也许需要一定的培训和分享制度

    11.最好的构架、需求和设计出自于自组织的团队。
    //当前代码的高耦合性是因为最开始软件的架构出现问题，如果一个公司有架构师一样的人(当然能力必须达标)，有了一个好的架构，模块的低耦合性也许会不再是空话   

    12.每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
    //一日三省，经常要对自己的工作进行总结反省，进行一定的沉淀，才能在新的起点上更好的前进。不要等项目结束了才开始总结，要经常总结，我为什么没有发现那样的bug，为什么测试效率这么低，只有反省总结了才会有进步。

    其实瀑布模式没有什么错，如果保证第一次就把正确的事情做正确，再结合敏捷的一些思想优化当前的工作，我相信会比单单地用敏捷的“拿来主义”强的多，最重要是理解敏捷的思想。另外完全的敏捷需要公司各平台(自动化，公共技术平台)的强力支撑，如果不能完全敏捷，那就从半敏捷做起，考虑目前哪些事情可敏捷，可优化，先从局部敏捷做起吧。
    以上是我的理解，欢迎各位拍砖交流~