戏说敏捷方法

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

• 敏捷方法并不是一种新的方法，而是快速原型方法的一种延伸，将原来适用于需求分析和设计的方法延伸到整个研发过程。
• 敏捷方法并不是一种新的方法，而是原来迭代方法（螺旋模型、增量模型、RUP）的变种，只是迭代周期更短。
• 敏捷方式是高科技人为自己偷懒而找的借口，这样可以少写文档，或不写文档。
• 敏捷方式是高科技人为自由而寻找的一条乡间小路，这样可以减少公司对自己的约束。
• 敏捷方法是年轻的一代为了获得更多的工作乐趣，将更多的游戏引入到研发之中。
• 没有互联网，就没有敏捷方法生存的土壤。新的土壤需要新的种子——敏捷方法。
• 互联网的许多应用需求不确定、变化迅速，互联网的不少应用又是免费的，对质量的要求不是很高。这一切适合快速迭代，呼唤着一种更灵活的开发方法，那就是敏捷方法。
• 敏捷方法并没有太大的创新，而只是一种改变。这种改变在某些领域是改善，这种改变在某些领域则是倒退。
• 敏捷方法则是将规范的、大规模的软件开发再拉回到最初的“软件小作坊”，是一种新的倒退。
• 小作坊的特征就是团队小、天天可以见面、大家比较熟悉，主要靠口头交流，采用工具也比较原始（白板、贴纸条等），挺像敏捷方法的实践。
• 小团队以人治为主，法治为辅。大团队以法治为主，人治为辅。敏捷方法适合小团队，主要停留在人治的阶段，但说得好听点则是“以人为本”。
• 敏捷方法还是一种倒退，对角色定义越来越不够明确，测试人员和开发人员的界限越来越模糊，而成熟的工业，角色细分，责任明确。
• 敏捷方法违反传统的质量观点“第一次就将事情做对”，而是打着拥抱变化的旗帜，想怎么做就怎么做，然后再不断修改、重构。
• 代码重构实际上就是偿还自己欠下的技术债务。
• • 敏捷方法是对工程学原理的叛逆。Matin Flower认为：“在敏捷开发过程中，人是第一位的，过程是第二位的。”而成熟的工程方法强调先过程，后个人，个人工作要服从于全局，受流程限制。
• 如果说传统的软件工程方法假设“人之初，性本恶”，则敏捷方法的管理假设就是“人之初，性本善”。
• 也有人说，传统的软件工程方法是“中药”，见效慢，但效果持久，治本、重在预防；而敏捷方法是“西药”，见效快，但只治标、不治本，长期有害。
• 敏捷开发模式需要经验丰富、配合良好而又异常稳定的项目组、积极而富有成效的沟通、良好的管理手段和流程、有效的工具与平台，只有满足这些条件敏捷开发模式才能带来收益。如果有了这些条件，用其它方法也能成功。
• • 有了良好的框架，上面的展现就比较容易，敏捷方法才能敏捷起来。

• 关联博客：

  敏捷方法中测试人员的价值?

   

  上善若水——项目管理的真谛

   

  软件开发不是一门艺术

  什么是软件工程？

  先进、成熟的软件工程思想有哪些？