戏说敏捷方法

　　敏捷(agile)方法现在非常Hot, 特别是Scrum, 在国内各个技术大会上都能见到其身影，许多公司也在考虑引入敏捷方法。 敏捷方法，的确给软件研发带来一阵清新的空气，但一定要客观地看待它。正如人们常说，软件工程中没有银弹，没有适合一切企业或开发模式的方法。上次在北京开会，有一个重量级专家就特别强调，团队是主要的，方法是次要的，他所在的团队很强，用什么办法都可以成功。如果团队差，寄希望于方法来解决问题，几乎是不会获得成功。只有好的团队，采用适当的方法，才会获得更大的成功。让我们回到主题，如何看待敏捷方法呢?我下面尽量简单地用通俗易懂的话来解释，所以说得不对的地方，敏捷方法的粉丝也不要激动，因为本文的标题就是“戏说敏捷方法”，会故意夸张、有所片面，请不要太在意。当然，也是有一定的道理，值得大家思考。

　　敏捷方法并不是一种新的方法，而是快速原型方法的一种延伸，将原来适用于需求分析和设计的方法延伸到整个研发过程。

　　敏捷方法并不是一种新的方法，而是原来迭代方法(螺旋模型、增量模型、RUP)的变种，只是迭代周期更短。

　　敏捷方式是高科技人为自己偷懒而找的借口，这样可以少写文档，或不写文档。

　　敏捷方式是高科技人为自由而寻找的一条乡间小路，这样可以减少公司对自己的约束。

　　敏捷方法是年轻的一代为了获得更多的工作乐趣，将更多的游戏引入到研发之中。

　　没有互联网，就没有敏捷方法生存的土壤。新的土壤需要新的种子——敏捷方法。

　　互联网的许多应用需求不确定、变化迅速，互联网的不少应用又是免费的，对质量的要求不是很高。这一切适合快速迭代，呼唤着一种更灵活的开发方法，那就是敏捷方法。

　　敏捷方法并没有太大的创新，而只是一种改变。这种改变在某些领域是改善，这种改变在某些领域则是倒退。

　　敏捷方法则是将规范的、大规模的软件开发再拉回到最初的“软件小作坊”，是一种新的倒退。

　　小作坊的特征就是团队小、天天可以见面、大家比较熟悉，主要靠口头交流，采用工具也比较原始(白板、贴纸条等)，挺像敏捷方法的实践。

　　小团队以人治为主，法治为辅。大团队以法治为主，人治为辅。敏捷方法适合小团队，主要停留在人治的阶段，但说得好听点则是“以人为本”。

　　敏捷方法还是一种倒退，对角色定义越来越不够明确，测试人员和开发人员的界限越来越模糊，而成熟的工业，角色细分，责任明确。

　　敏捷方法违反传统的质量观点“第一次就将事情做对”，而是打着拥抱变化的旗帜，想怎么做就怎么做，然后再不断修改、重构。

　　代码重构实际上就是偿还自己欠下的技术债务。

　　敏捷方法是对工程学原理的叛逆。Matin Flower认为：“在敏捷开发过程中，人是第一位的，过程是第二位的。”而成熟的工程方法强调先过程，后个人，个人工作要服从于全局，受流程限制。

　　如果说传统的软件工程方法假设“人之初，性本恶”，则敏捷方法的管理假设就是“人之初，性本善”。

　　也有人说，传统的软件工程方法是“中药”，见效慢，但效果持久，治本、重在预防;而敏捷方法是“西药”，见效快，但只治标、不治本，长期有害。

　　敏捷开发模式需要经验丰富、配合良好而又异常稳定的项目组、积极而富有成效的沟通、良好的管理手段和流程、有效的工具与平台，只有满足这些条件敏捷开发模式才能带来收益。如果有了这些条件，用其它方法也能成功。

　　有了良好的框架，上面的展现就比较容易，敏捷方法才能敏捷起来。

原文转自：http://www.ltesting.net