敏捷开发的常见误区

《敏捷开发的常见误区》由会员分享，可在线阅读，更多相关《敏捷开发的常见误区（8页珍藏版）》请在金锄头文库上搜索。

1、敏捷开发的常见误区1. 误区：敏捷项目没有计划由于产品需求的不确定性、甚至是未知的，敏捷项目团队很少能在项目之初建立一份类似于WBS任务分解的进度表和甘特图，但敏捷项目依然是有计划的，和传统的进度计划不同，敏捷的计划不是关注在完成项目的一个个活动或者说任务，比如说需求分析、概要设计、详细设计，模块一编码等等，而是关注在客户的需要，关注客户价值的优先级，其计划的对象是用户要求的功能，例如用户故事，计划活动的产出是一个设置了优先级的用户需要的功能列表。敏捷计划分为以下几个层次：l 愿景制定产品的长远目标；l 路线图制定实现长远目标的分步实施计划；l 发布制定一次发布的目标，包含在一个发布中希望交付

2、的需求清单，并设置了优先级；l 迭代制定一次迭代的目标，包含了在一个迭代中团队承诺交付的需求清单及为了达成目标而设置的工作任务；l 每日计划制定每天的工作目标，包含了团队中每个成员的工作任务。其计划的过程是一个持续的过程，从项目开始时制定产品的愿景，到每个迭代开始时制定迭代计划，敏捷项目的计划不断的细化，不断的根据变化而调整，是Just-In-Time的计划。2. 误区：敏捷就是追求速度一次在和几个朋友聊天的时候，有朋友说最近装了有线数字电视，他觉得开发数字电视频道服务的团队应该是采用了敏捷的团队，因为每隔一段时间，就会有新的功能发布，只是系统不稳定，不得不经常的重新启动机顶盒。这无疑是个非常

3、有趣的关于敏捷的理解，似乎敏捷就是关注软件功能的投放市场速度，而往往忽略质量。这是很多有关敏捷的理解中，比较典型的一种误识。如果我们重读一下敏捷的四句宣言以及12条敏捷原则，应该不难看出，敏捷实际是关注实现客户的价值，而这一价值体现在“可工作的软件”之中，这其实是对质量的要求，它意味着交付的软件是客户需要的并且质量稳定的，是同时对需求质量和开发质量提出要求。另外，因为市场的变化会促使客户重新调整需求，以获取最大的价值，因此敏捷强调“响应变化”，迅速调整策略，以帮助客户迅速对市场变化做出响应。3. 误区：敏捷是放之四海而皆准的开发模式敏捷开发模式被互联网企业广泛采用的最重要的原因有两个：1) 产

4、品的功能升级更新换代非常快，大家都必须要在最短的时间内抢占市场，吸引用户，而需求往往又不是非常的明确，甚至有时只是一个idea，需要市场的反馈；2) 产品的升级是可控的，即便是带着一定缺陷的产品发布（又称为“灰度发布”），我们都可以在后台悄悄的升级系统或修改BUG，对于用户来说，任何时间打开浏览器都可以看到最新的产品，因此对用户的影响是最小的，甚至用户是不感知的。对于那些需要安装到用户使用的终端（电脑、手机、平板等）的应用来说，这样的升级方式可能就会导致客户的反感、投诉和客户流失。对于软件提供商来说，还必须要考虑客户拒绝升级情况下，后台系统必须要同时支持多个版本的运行，否则就会遭到客户的投诉，

5、甚至会引发负面影响的广泛传播。因此对于不同形式、不同需求阶段、不同质量要求的产品，对于敏捷开发的实际应用是需要谨慎研究的，而不是绝对的生搬硬套和教条主义。4. 误区：敏捷是“一个”过程敏捷不是一个过程，是一类过程的统称，它们有一个共性，就是符合敏捷价值观，遵循敏捷的原则。敏捷的价值观如下：l 个体和交互 胜过 过程和工具l 可以工作的软件 胜过 面面俱到的文档l 客户合作 胜过 合同谈判l 响应变化 胜过 遵循计划由价值观引出的12条敏捷原则：1) 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。2) 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

6、3) 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。4) 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。（注：这并不是地理位置上要求双方在一起，否则跨国公司的协同开发就成了空话）5) 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。6) 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。7) 工作的软件是首要的进度度量标准。8) 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。9) 不断地关注优秀的技能和好的设计会增强敏捷能力。10) 简单使

7、未完成的工作最大化的艺术是根本的。11) 最好的构架、需求和设计出自于自组织的团队。12) 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。建立敏捷联盟的17位大师所创立的敏捷方法包括：极限编程，Scrum，特征驱动开发，动态系统开发方法，自适应软件开发，水晶方法，实用编程方法。这些方法统称为敏捷方法。每个人都可以从敏捷宣言和原则出发，明确问题，找出一些解决方法，形成自己的过程。要实用而不是要机械式的规范。让开发人员理解并实施，体验到敏捷的好处，而不是盲目机械地实施规范。CMMI的最高境界（Level 5）也是要求组织有足够的灵活性适应外界环境的变化，灵

8、活的运用规范，而不是教条主义。5. 误区：敏捷只适用于小型项目和团队敏捷实践确实很多发源于小型的项目团队，但并不是说敏捷只适合小型项目团队。其实，早期的Scrum项目就已经有在500多人的大型项目中成功实施的案例。可能是由于大多数的敏捷团队一般都希望在59人的规模，并且希望团队成员在同一个工作区域，所以很多时候被认为不适合跨地域，跨团队的大型项目的开发。其实，59人的团队规模是一个类似于一个战斗小组的规模，这个团队小组负责完成一个共同的目标。对于一个小型的项目而言，可能只需要一个这样的战斗小组就可以了，而对于一个大型的项目，我们就可以建立多个这样的战斗小组来完成项目目标。在Scrum中，就有S

9、crum Scaling，通过把一个大型项目团队合理分解为多个小型的Scrum团队，每个团队都负责一个相对独立的模块或者功能，再配合其他的敏捷实践，比如持续集成，Scrum of Scrums等，加强团队之间的协作，从而确保项目的成功。所以，将敏捷实践应用于大型的、复杂的项目是完全可以的。6. 误区：敏捷开发 = 简化流程敏捷开发不一定能简化工作流程，而且简化流程也并非提出敏捷开发的初衷。敏捷开发最重视的是拥抱变化，至于怎么拥抱，只能随机应变。实际应用中，既有流程相当简单的经典Scrum过程，也有极为冗繁、不亚于CMMI的RUP，根据应用场景不一样，项目组应该使用最适合的流程。选择敏捷开发流程

10、时也应带着敏捷开发的思维去选择，即快速响应项目实际的流程需求、拥抱流程应用过程中遇到的各种变化。没有银弹，也没有长期适合的项目流程，生搬硬套某个看似成熟的敏捷开发流程是大忌。7. 误区：敏捷开发 = 快速开始编码敏捷开发强调迭代，鼓励开发人员用代码说话，不过绝对不鼓励没想明白就写代码。符合敏捷开发思想的流程往往主张在一个稳定的基础之上迭代完成各种功能。如果基础都不牢固，迭代就无法进行，整个开发过程就退化成不断重写的过程，浪费开发时间。敏捷开发实际非常重视“设计”，并且对开发人员的设计水平提出了极高的要求，既要“持续重构”又不能“过度设计”，稍有不慎就会陷入反复推翻已有代码的窘境。对于内功不够的

11、开发人员最好还是想好再写代码，设计的时候慢一点没关系，尽量少的做无用功才是最重要。8. 误区：敏捷是彻底革命的。敏捷，特别是XP，让人有耳目一新的感觉，觉得以前的所有软件工程理论，设计方法都可以抛弃掉了，推翻一切，从头再来。抱着这种想法实施敏捷，那就错了，敏捷不是“石头里蹦出个孙大圣”，以前的软件过程中也有敏捷的影子，只是没有像敏捷一样上升到价值观和原则的高度，比如快速原型法。敏捷是在对已有的软件过程方法的改进，抛弃的是传统软件工程低效的外表，以往的软件过程中很多技巧都是很实用的。实施敏捷应该以现有的软件过程为基础，从敏捷宣言和原则出发，利用敏捷的方法来改善过程。9. 误区：敏捷是反文档的。文

12、档只是为了达成目标的一种手段，如果这种手段是低效的，那就换一种手段。可是完全抛弃了文档，怎样解决沟通的问题？难道你想每次沟通都完全用手比划，用嘴说，跟不同的人重复表述同样的想法，那样更是低效的。应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识，知识具备两种形态，显性的和隐性的，传统的观念是尽量把隐性知识显性化，即文档化，而忽略了这其中的代价（特别是更新同步文档的代价）。因此，在实施敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的最佳效率。文档不是目的，有效沟通才是目的。就

13、工作量而言，不写文档，减少写文档时间，看起来确实可以加快开发速度，但实际会严重伤害项目。互联网应用开发不需要似传统大型软件开发那样，按照软件工程，花大量时间去写文档。不要为了写文档而写文档，而是为了开发而写文档。例如需求文档（或者功能文档-可以含有版本信息，业务流程文档，互通操作文档），无论具体形式如何，需要清晰地给出你的应用针对什么，提供什么，解决什么。需求文档有时也可以作为测试的指导。如果是client+server，你需要给出本期目标的性能，可以简单到一两页纸，但是绝对不能缺。在迭代开发中，你不断地修改它，它是你开发的轨迹。例如开发文档，不一定要什么概要设计、详细设计这类学院派的东东，但

14、是你需要有文档能够清晰描述开发对象的架构，模块划分，client和server的交互流程，以及关键的核心技术，例如，如何避免client和server中过多连接造成的server压力，为何采用长连接tcp而非upd（反之亦然），如何制定心跳，是否需要通过使用底层的socket进行特定优化等等。你至少需要从架构师的角度对产品进行梳理，描述实现的架构、采用的机制和关键技术。开发文档或繁或简，甚至可以在代码中通过注释说明，利用javadoc生产HTML，格式不论。不要让文档成为开发的负担，而是成为帮助。现在工作的流动性很大，没有文档，当中一两个开发人员离职，如何后续处理。没有开发文档，在架构和关键技

15、术上没有想清楚，贸然而上，开发的永远只是个demo产品。没有任何文档，极容易导致推出后，疲于奔命地修修补补，每天一个版本。敏捷开发是快，但是快不等于敏捷开发。10. 误区：敏捷是自由的，无约束的。敏捷强调的是自组织团队，发挥人的能动性，以动力代替压力，让人有绝对自由的错觉。但是应该清楚，凡事都是要讲究一个平衡，人也是两面的，消极的一面和积极的一面同时并存，绝对的自由会放纵人消极的一面。敏捷并非是绝对自由，无约束的。作为管理者，有一个职责，就是引导团队成员用自己积极的一面去压制消极的一面，不能放任团队中出现搭便车的现象，否则将打击整个团队的士气。如果实在无效，那就只能将其排除出团队了，这个惩罚够有约束力吧？11. 误区：为了敏捷而敏捷“嗯，敏捷这么好，我们也敏捷吧”，可能很多人会有这种想法。忘了以前是在哪儿看的大师采访录：Q：“我们现有的过程很好，不知道怎么用敏捷改进？”A：“既然很好，那就不要用敏捷”。做什么事情都要有明确目标的，敏捷虽好，得看你需不需要，能不能解决你现在头疼的问题，如果不是，那就不要给自己找麻烦了。12. 误区：传统开发能随时转变成敏捷开发敏捷开发过于诱人，很容易让深受传统软件开发思想折磨的开发人员感觉敏捷开发就是灵丹妙药。要想