戏说敏捷方法

发表于:2012-03-20来源:不详作者:龙道名义 标签:敏捷测试
敏捷(agile)方法现在非常Hot, 特别是Scrum, 在国内各个技术大会上都能见到其身影,许多公司也在考虑引入敏捷方法。 敏捷方法,的确给软件研发带来一阵清新的空气,但一定要客观地看待它。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)