敏捷开发的常见误区11-20：敏捷需要走出的纸上谈兵

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

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

　　“嗯，敏捷这么好，我们也敏捷吧”，可能很多人会有这种想法。忘了以前是在哪儿看的大师采访录：

　　Q：“我们现有的过程很好，不知道怎么用敏捷改进?”

　　A：“既然很好，那就不要用敏捷”。

　　做什么事情都要有明确目标的，敏捷虽好，得看你需不需要，能不能解决你现在头疼的问题，如果不是，那就不要给自己找麻烦了。
 

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

　　敏捷开发过于诱人，很容易让深受传统软件开发思想折磨的开发人员感觉敏捷开发就是灵丹妙药。要想转变，首先需要从思想上正确认识敏捷开发的含义，了解它能解决什么问题、会带来什么新的问题、对现有软件/硬件资源有什么要求等。

　　例如在原先采用CMM的团队中，想利用敏捷开发简化冗余的文档、降低沟通成本，那么敏捷开发确实能在一定程度上缓解这些问题，但也会造成内部文档缺失、沟通不够深入的问题，在应用敏捷开发之前需要先确定适合团队的新的文档流程(代码注释能够自动/半自动的变成团队需要的文档么?)，并且确定沟通的一些原则(比如，对于一些重要的沟通，是否还是用邮件来进行，不要过于“敏捷”?)。.

　　有趣的是，有可能在回答这几个问题之后会发现，敏捷开发并不能解决项目中遇到的问题，反倒是其他方面出了问题。

　　举例来说。如果此前的开发方法是简单的目标管理，遇到的问题是项目进度不可控、开发+测试的周期较长、不能及时响应需求变化，那么敏捷开发能解决的是快速响应需求变化，对项目进度和开发测试周期帮助不大(没有一种流程能够承诺改善项目的开发效率!)，但前提是开发人员必须懂得怎样正确的去迭代开发，并且必须认识到一次迭代的结束是以完成测试为标准的。

　　在这个例子中可以看到，敏捷开发能带来的好处非常有局限性，如果开发人员达不到一定的层次是很难受益的。与其号召使用敏捷开发，不如想想如何增加执行力，以及找到周期偏长的根本原因(是因为设计不充分而返工?还是因为没有可以快速回归的测试用例?等等)。
 

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

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

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

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

　　极限编程、Scrum等流程是具体的实施方法，它们都声称符合敏捷开发的思想，但执行起来是否真的“敏捷”，还得看参与者究竟思想上是否真的接受敏捷开发的原理。

　　如果把结对编程、daily scrum当做是敏捷开发的表现，那更是本末倒置，可悲的是，不少人还真是这么认为的。
 

　　15. 误区：迭代就是敏捷，UP属于敏捷。

　　UP是重型的过程，虽然引入了迭代，但是其原则和价值观与敏捷是不同的。敏捷注重的是反馈，迭代周期尽量的短，重在客户的参与，通过客户的参与，获取持续的反馈，不断调整使整个项目走在正确的方向上。同时也给客户一个感受和思考的机会，因为对于大多数客户而言，目标是明确的(不排除有些客户目标也不明确)，但是具体怎么做，开始时是没有想法的，只有看到具体的东西的时候，才知道“噢，原来可以这样，那我想把这里调整一下”。
 

　　16. 误区：重做就是重构

　　重做不等于重构，很多场合这两个概念是混淆的。但是在敏捷中，重构的一个特征是必须可控的。当对系统结构进行大的调整时，如果没有测试驱动辅助的话，那么可控性就会很差，这不能叫做重构。.
 

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

　　每天一个新版本。这种情况，最大可能是产品没有经过严格的测试，根本不稳定，就直接放出来，结果在实际使用中bug漫天飞，开发人员不断地推出版本来补窟窿。这种情况，别说商用版本，用户无法接受如此频繁的升级(升级毕竟耗时麻烦，而且流量是用户自己掏的钱)，即便是内测版本，也绝不应该如此频繁和随意。

　　内测版本或试用版本也是经过开发人员验证和测试后放出来，通过实际使用情况，收集用户对功能和操作中的意见，并对实际使用中测试案例无法覆盖的可能异常情况进行验证。不是发现一个bug，就改一个，发布一个，而是收集反馈，统一修订后，再释放新版本(而这，通常时间是按周来计算的)，除非这个bug是个极其严重，必须马上更正。
 

每天一个版本，混乱。在Android上，你可以自行发布更新，但如果基于iOS的，在Apple的App Store上发布，别说每天一个版本，就算每周一个版本，Apple的软件审核流程还没走完，就又扔一个新的版本，这就很容易造成下游工作根本没法正常进行。

　　将版本更新速度视为敏捷开发，是完全错误的。敏捷开发在于你能够准确抓住市场，在时间窗口内快速推出产品。由于市场的不确定性和用户喜好/需求的不确定性，用户通常不清楚需要什么，你先给他，他再去判断，这需要在需求-开发-市场验证中进行循环迭代，以用户为最终目标，而不是机械地将敏捷视为快，而判断什么为快，又机械地用版本推出速度来说明，每天推一个版本，只能说明开发流程出了问题，整个学生小作坊。

　　敏捷开发也仍然是和版本更新有一定的关系。但这个版本，不是小修小补的小版本，而是有新功能，新UI，新互动方式，在用户体验上有新的感受。这样的版本，不可能一两天就升级。另外，你推给客户的都应该是个稳定的版本。
 

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

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

　　必要的系统架构和设计从来都是非常重要的。只是这里的分析设计有别于传统的开发模式，应该应用敏捷的思想，简单设计，持续重构，尽快反馈等。
 

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

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

　　(1)需求质量的审核，仍然需要改进，需求方向性的错误将导致后续一系列的工作浪费，所以团队内部应该设定里程碑和review标准，从而确保基本的需求质量。

　　(2)在Iteration里需求尽量不要变更，明确Iteration的边界。否则频繁的变更导致团队没有成就感，方向和目标不明确。

　　(3)敏捷讲求业务价值导向，有些变更从业务价值上看，可能并非真正需求急切变更。

　　有些变更通过更好的Impact分析和设计应该也可以避免。BA和SA等不同的角色应该一起配合来做出Impact分析，以供决策
 

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

　　一些敏捷实践容易实行，一些比较困难，所以大家习惯性的会割裂敏捷实践的关联，孤立地实践少数易于实现的敏捷实践。敏捷开发之所以可以替代以往传统开发模式，是因为一组(系列)的开发实践来共同代替以往开发模式。孤立的引入少数实践，通常不能给团队成员感觉有大的改进，从而也放弃对敏捷开发的信心。

　　例如Stand-up Meeting(站立会议)这是一个比较容易的实践，但是如果没有背后的需求转化为比较容易衡量的Story-base，没有BA、QA等共同参与基于Story-base去沟通，没有OfflineofMeeting更多的面对面沟通交流，没有大家彼此知道对方的工作内容(CodeOwnership)，那么可以设想这种Stand-up meeting和以往的传统的开发模式，Leader布置任务检查任务进度没有任何区别。

　　再如简单设计实践，如果没有背后的结对编程、重构等实践，必然导致比较混乱的代码，很难维护的架构，难于扩展，重复实现类似功能等弊端。bbs.

　　再如持续集成(CI)，即使这是公认敏捷软件领域内相对没有争议的一个实践，但是如果没有与TDD结合，没有与持续重构，没有与小的Story，快速频繁Deliver等实践结合在一起，并且坚持保持CI的健康，也会让团队成员觉得CI效果不如宣传，从而对敏捷实践等产生质疑。

敏捷 (Agile) 作为一种快速应对需求变化的新兴软件开发模式，正受到越来越广泛的关注和应用。它强调快速验证，表现为快速上线、快速根据反馈迭代产品。
OneProject 敏捷研发管理解决方案特点为全角色、全流程、支持中大型团队 :
提供包含项目管理、产品、运营、研发、测试等各职能角色在内的完整解决方案。
为需求管理、迭代规划、进度跟踪等经典 Scrum 环节提供工具支撑。
兼具组织架构管理、资源管理与全局进度管控等能力，可扩展为多团队并行开发，帮助中大型团队开展敏捷实践。
提供研发数据统计与可视化报表引擎，可衡量并持续提升研发效能。
打造业务专家与研发团队高效的协作环境，快速响应需求的同时更好更快的发布产品。
以上内容源于网络，如有侵权联系即删除。