敏捷开发：摆脱纸上谈兵的误区

　　敏捷开发的常见误区之11-20

　　11. 误区：为了敏捷而敏捷

　　很多人都会认为敏捷开发是一种好方法，于是他们也想使用敏捷开发。但是我们要记住一句话：“如果你的现有过程已经很好了，那就不需要使用敏捷开发。”

　　在做任何事情之前都需要明确目标，敏捷开发虽然好，但是要看你是否需要它以及它能否解决你当前的问题。如果不需要，就不要给自己找麻烦。

　　12. 误区：传统开发能随时转变成敏捷开发

　　敏捷开发对于那些深受传统软件开发思想折磨的开发人员来说非常诱人。但要想转变，首先需要正确理解敏捷开发的含义，了解它能解决什么问题，会带来什么新问题，对现有资源有什么要求等。

　　举个例子，如果原来的团队采用的是传统的CMM开发方法，并想借助敏捷开发简化文档冗余、降低沟通成本，那么敏捷开发确实可以在一定程度上缓解这些问题。但同时也会造成文档缺失、沟通不深入等问题。在应用敏捷开发之前，需要确定适合团队的新的文档流程，并确定沟通的原则。而且有可能在回答了这几个问题之后，发现敏捷开发并不能解决项目中遇到的问题，反而会引发其他问题。

　　13. 误区：敏捷是CMM的反义词

　　CMM只是一种衡量软件成熟度的标准，并非过程，和敏捷不是一类概念。如果要找一个和敏捷相反的概念，传统的瀑布式开发更合适。

　　14. 误区：敏捷开发 == 极限编程/Scrum/…

　　敏捷开发是一种方法论，只是一些基本原则的集合，并非具体的流程。

　　极限编程、Scrum等流程是具体的实施方法，它们声称符合敏捷开发的思想，但是实施起来是否真的“敏捷”，取决于参与者是否真正接受敏捷开发的原理。

　　举个例子，如果把结对编程、每日站立会议当做敏捷开发的表现，那就是本末倒置了。可悲的是，有些人确实这样认为。

　　15. 误区：迭代就是敏捷，统一过程属于敏捷

　　统一过程是一种重型过程，虽然引入了迭代，但其原则和价值观与敏捷是不同的。敏捷注重反馈，迭代周期尽量短，重在客户参与，通过客户的参与获取持续的反馈，不断调整使项目走向正确的方向。同时也给客户一个思考的机会。

　　16. 误区：重做就是重构

　　重做和重构是两个不同的概念，在很多场合这两个概念被混淆。在敏捷开发中，重构的一个特点是必须可控。当对系统结构进行大的调整时，如果没有测试驱动辅助的话，可控性就会很差，这不能被称为重构。

　　17. 误区：版本更新很快，甚至每天都有新版本

　　每天都推出新版本很可能意味着产品没有经过严格测试，根本不稳定，直接放出来后会出现很多bug。用户无法接受如此频繁的升级，即使是内测版本也不应该如此频繁和随意。

　　内测版本或试用版本应该经过开发人员验证和测试后发布，通过实际使用情况收集用户反馈，并验证实际使用中测试案例无法覆盖的异常情况。不应该发现一个bug就改一个，发布一个，而是收集反馈，统一修订后再发布新版本。

　　18. 误区：没有分析和设计

　　敏捷开发强调简单设计，团队每个成员都从接触客户到分析设计、编码，承担全部责任。但实际上团队成员的素质参差不齐，如果只有简单设计、立即编码，没有后续的持续重构等实践，就会导致设计混乱不一致，尤其是对老系统的功能升级，如果对原有系统的影响分析不够，弱化了分析设计，就会导致后期频繁变更，增加团队的挫折感和重复工作。

　　必要的系统架构和设计始终非常重要，只是这里的分析设计与传统的开发模式不同，应该应用敏捷的思想，简单设计，持续重构，尽快反馈等。

　　19. 误区：敏捷拥抱变化，因此前期需求可以随意简单

　　因为敏捷的导向，可能会导致前期需求比较随意，对需求质量的控制弱化，需求变更更加频繁。但这并不意味着对需求可以不加深究，甚至可以随意变更需求。

　　首先，需求质量的审核仍然需要改进，因为需求方向性的错误将导致后续工作的浪费。团队应该设定里程碑和评审标准，确保基本的需求质量。

　　其次，在迭代过程中尽量避免需求变更，明确迭代的边界。频繁的变更会导致团队没有成就感，方向和目标不明确。

　　还要注意，敏捷开发注重业务价值导向，有些变更并非真正需要急切变更，通过更好的影响分析和设计应该可以避免一些变更。不同角色的业务分析师和系统分析师应该一起进行影响分析，以便做出决策。

　　20. 误区：可以孤立地实践少数的敏捷实践

　　一些敏捷实践比较容易实施，一些较困难。很多人习惯性地只实施少数容易实现的敏捷实践，而忽略了它们之间的关联。敏捷开发之所以可以替代传统开发模式，是因为一组(系列)的开发实践共同代替了以往的开发模式。孤立地引入少数实践通常无法给团队成员带来大的改进，从而对敏捷开发失去信心。

　　举个例子，站立会议是一种容易实施的实践，但是如果没有背后的需求转化为可衡量的故事，没有业务分析师、质量分析师等共同参与，没有线下会议的面对面沟通交流，没有大家彼此了解对方工作内容，那么站立会议和传统的开发模式就没有任何区别。

　　再如简单设计实践，如果没有结对编程、重构等实践，必然会导致代码混乱、架构难以维护、难以扩展、重复实现相似功能等问题。

　　持续集成(CI)是一个公认的敏捷实践，但是如果没有与测试驱动开发(TDD)、持续重构、小的故事、快速频繁交付等实践结合，并坚持保持CI的健康状态，团队成员可能会觉得CI的效果不如预期，从而对敏捷实践产生质疑。

　　敏捷是一种快速应对需求变化的软件开发模式，正受到越来越多的关注和应用。它强调快速验证，通过快速上线、快速迭代来满足用户的需求。

　　OneProject敏捷研发管理解决方案特点为全角色、全流程、支持中大型团队:

　　提供包含项目管理、产品、运营、研发、测试等各职能角色在内的完整解决方案。

　　为需求管理、迭代规划、进度跟踪等经典Scrum环节提供工具支持。

　　兼具组织架构管理、资源管理和全局进度管控等能力，可扩展为多团队并行开发，帮助中大型团队开展敏捷实践。

　　提供研发数据统计与可视化报表引擎，可衡量并持续提升研发效能。

　　打造业务专家与研发团队高效的协作环境，快速响应需求的同时更好更快地发布产品。

　　以上内容来源于网络，如有侵权请联系删除。