敏捷开发的常见误区.docx
《敏捷开发的常见误区.docx》由会员分享，可在线阅读，更多相关《敏捷开发的常见误区.docx（11页珍藏版）》请在冰点文库上搜索。
敏捷开发的常见误区
敏捷开发的常见误区
1.误区：
敏捷项目没有计划
由于产品需求的不确定性、甚至是未知的，敏捷项目团队很少能在项目之初建立一份类似于WBS任务分解的进度表和甘特图，但敏捷项目依然是有计划的，和传统的进度计划不同，敏捷的计划不是关注在完成项目的一个个活动或者说任务，比如说需求分析、概要设计、详细设计，模块一编码等等，而是关注在客户的需要，关注客户价值的优先级，其计划的对象是用户要求的功能，例如用户故事，计划活动的产出是一个设置了优先级的用户需要的功能列表。
敏捷计划分为以下几个层次：
●愿景–制定产品的长远目标；
●路线图–制定实现长远目标的分步实施计划；
●发布–制定一次发布的目标，包含在一个发布中希望交付的需求清单，并设置了优先级；
●迭代–制定一次迭代的目标，包含了在一个迭代中团队承诺交付的需求清单及为了达成目标而设置的工作任务；
●每日计划–制定每天的工作目标，包含了团队中每个成员的工作任务。
其计划的过程是一个持续的过程，从项目开始时制定产品的愿景，到每个迭代开始时制定迭代计划，敏捷项目的计划不断的细化，不断的根据变化而调整，是Just-In-Time的计划。
2.误区：
敏捷就是追求速度
一次在和几个朋友聊天的时候，有朋友说最近装了有线数字电视，他觉得开发数字电视频道服务的团队应该是采用了敏捷的团队，因为每隔一段时间，就会有新的功能发布，只是系统不稳定，不得不经常的重新启动机顶盒。
这无疑是个非常有趣的关于敏捷的理解，似乎敏捷就是关注软件功能的投放市场速度，而往往忽略质量。
这是很多有关敏捷的理解中，比较典型的一种误识。
如果我们重读一下敏捷的四句宣言以及12条敏捷原则，应该不难看出，敏捷实际是关注实现客户的价值，而这一价值体现在“可工作的软件”之中，这其实是对质量的要求，它意味着交付的软件是客户需要的并且质量稳定的，是同时对需求质量和开发质量提出要求。
另外，因为市场的变化会促使客户重新调整需求，以获取最大的价值，因此敏捷强调“响应变化”，迅速调整策略，以帮助客户迅速对市场变化做出响应。
3.误区：
敏捷是放之四海而皆准的开发模式
敏捷开发模式被互联网企业广泛采用的最重要的原因有两个：
1）产品的功能升级更新换代非常快，大家都必须要在最短的时间内抢占市场，吸引用户，而需求往往又不是非常的明确，甚至有时只是一个idea，需要市场的反馈；
2）产品的升级是可控的，即便是带着一定缺陷的产品发布（又称为“灰度发布”），我们都可以在后台悄悄的升级系统或修改BUG，对于用户来说，任何时间打开浏览器都可以看到最新的产品，因此对用户的影响是最小的，甚至用户是不感知的。
对于那些需要安装到用户使用的终端（电脑、手机、平板等）的应用来说，这样的升级方式可能就会导致客户的反感、投诉和客户流失。
对于软件提供商来说，还必须要考虑客户拒绝升级情况下，后台系统必须要同时支持多个版本的运行，否则就会遭到客户的投诉，甚至会引发负面影响的广泛传播。
因此对于不同形式、不同需求阶段、不同质量要求的产品，对于敏捷开发的实际应用是需要谨慎研究的，而不是绝对的生搬硬套和教条主义。
4.误区：
敏捷是“一个”过程
敏捷不是一个过程，是一类过程的统称，它们有一个共性，就是符合敏捷价值观，遵循敏捷的原则。
敏捷的价值观如下：
●个体和交互胜过过程和工具
●可以工作的软件胜过面面俱到的文档
●客户合作胜过合同谈判
●响应变化胜过遵循计划
由价值观引出的12条敏捷原则：
1）我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2）即使到了开发的后期，也欢迎改变需求。
敏捷过程利用变化来为客户创造竞争优势。
3）经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
4）在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
（注：
这并不是地理位置上要求双方在一起，否则跨国公司的协同开发就成了空话）
5）围绕被激励起来的个体来构建项目。
给他们提供所需的环境和支持，并且信任他们能够完成工作。
6）在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7）工作的软件是首要的进度度量标准。
8）敏捷过程提倡可持续的开发速度。
责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9）不断地关注优秀的技能和好的设计会增强敏捷能力。
10）简单——使未完成的工作最大化的艺术——是根本的。
11）最好的构架、需求和设计出自于自组织的团队。
12）每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
建立敏捷联盟的17位大师所创立的敏捷方法包括：
极限编程，Scrum，特征驱动开发，动态系统开发方法，自适应软件开发，水晶方法，实用编程方法。
这些方法统称为敏捷方法。
每个人都可以从敏捷宣言和原则出发，明确问题，找出一些解决方法，形成自己的过程。
要实用而不是要机械式的规范。
让开发人员理解并实施，体验到敏捷的好处，而不是盲目机械地实施规范。
CMMI的最高境界（Level5）也是要求组织有足够的灵活性适应外界环境的变化，灵活的运用规范，而不是教条主义。
5.误区：
敏捷只适用于小型项目和团队
敏捷实践确实很多发源于小型的项目团队，但并不是说敏捷只适合小型项目团队。
其实，早期的Scrum项目就已经有在500多人的大型项目中成功实施的案例。
可能是由于大多数的敏捷团队一般都希望在5～9人的规模，并且希望团队成员在同一个工作区域，所以很多时候被认为不适合跨地域，跨团队的大型项目的开发。
其实，5～9人的团队规模是一个类似于一个战斗小组的规模，这个团队小组负责完成一个共同的目标。
对于一个小型的项目而言，可能只需要一个这样的战斗小组就可以了，而对于一个大型的项目，我们就可以建立多个这样的战斗小组来完成项目目标。
在Scrum中，就有ScrumScaling，通过把一个大型项目团队合理分解为多个小型的Scrum团队，每个团队都负责一个相对独立的模块或者功能，再配合其他的敏捷实践，比如持续集成，ScrumofScrums等，加强团队之间的协作，从而确保项目的成功。
所以，将敏捷实践应用于大型的、复杂的项目是完全可以的。
6.误区：
敏捷开发==简化流程
敏捷开发不一定能简化工作流程，而且简化流程也并非提出敏捷开发的初衷。
敏捷开发最重视的是拥抱变化，至于怎么拥抱，只能随机应变。
实际应用中，既有流程相当简单的经典Scrum过程，也有极为冗繁、不亚于CMMI的RUP，根据应用场景不一样，项目组应该使用最适合的流程。
选择敏捷开发流程时也应带着敏捷开发的思维去选择，即快速响应项目实际的流程需求、拥抱流程应用过程中遇到的各种变化。
没有银弹，也没有长期适合的项目流程，生搬硬套某个看似成熟的敏捷开发流程是大忌。
7.误区：
敏捷开发==快速开始编码
敏捷开发强调迭代，鼓励开发人员用代码说话，不过绝对不鼓励没想明白就写代码。
符合敏捷开发思想的流程往往主张在一个稳定的基础之上迭代完成各种功能。
如果基础都不牢固，迭代就无法进行，整个开发过程就退化成不断重写的过程，浪费开发时间。
敏捷开发实际非常重视“设计”，并且对开发人员的设计水平提出了极高的要求，既要“持续重构”又不能“过度设计”，稍有不慎就会陷入反复推翻已有代码的窘境。
对于内功不够的开发人员最好还是想好再写代码，设计的时候慢一点没关系，尽量少的做无用功才是最重要。
8.误区：
敏捷是彻底革命的。
敏捷，特别是XP，让人有耳目一新的感觉，觉得以前的所有软件工程理论，设计方法都可以抛弃掉了，推翻一切，从头再来。
抱着这种想法实施敏捷，那就错了，敏捷不是“石头里蹦出个孙大圣”，以前的软件过程中也有敏捷的影子，只是没有像敏捷一样上升到价值观和原则的高度，比如快速原型法。
敏捷是在对已有的软件过程方法的改进，抛弃的是传统软件工程低效的外表，以往的软件过程中很多技巧都是很实用的。
实施敏捷应该以现有的软件过程为基础，从敏捷宣言和原则出发，利用敏捷的方法来改善过程。
9.误区：
敏捷是反文档的。
文档只是为了达成目标的一种手段，如果这种手段是低效的，那就换一种手段。
可是完全抛弃了文档，怎样解决沟通的问题？
难道你想每次沟通都完全用手比划，用嘴说，跟不同的人重复表述同样的想法，那样更是低效的。
应该清楚文档的本质是把知识显性化。
在一个项目中存在很多需要沟通的知识，知识具备两种形态，显性的和隐性的，传统的观念是尽量把隐性知识显性化，即文档化，而忽略了这其中的代价（特别是更新同步文档的代价）。
因此，在实施敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。
哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的最佳效率。
文档不是目的，有效沟通才是目的。
就工作量而言，不写文档，减少写文档时间，看起来确实可以加快开发速度，但实际会严重伤害项目。
互联网应用开发不需要似传统大型软件开发那样，按照软件工程，花大量时间去写文档。
不要为了写文档而写文档，而是为了开发而写文档。
例如需求文档（或者功能文档-可以含有版本信息，业务流程文档，互通操作文档），无论具体形式如何，需要清晰地给出你的应用针对什么，提供什么，解决什么。
需求文档有时也可以作为测试的指导。
如果是client+server，你需要给出本期目标的性能，可以简单到一两页纸，但是绝对不能缺。
在迭代开发中，你不断地修改它，它是你开发的轨迹。
例如开发文档，不一定要什么概要设计、详细设计这类学院派的东东，但是你需要有文档能够清晰描述开发对象的架构，模块划分，client和server的交互流程，以及关键的核心技术，例如，如何避免client和server中过多连接造成的server压力，为何采用长连接tcp而非upd（反之亦然），如何制定心跳，是否需要通过使用底层的socket进行特定优化等等。
你至少需要从架构师的角度对产品进行梳理，描述实现的架构、采用的机制和关键技术。
开发文档或繁或简，甚至可以在代码中通过注释说明，利用javadoc生产HTML，格式不论。
不要让文档成为开发的负担，而是成为帮助。
现在工作的流动性很大，没有文档，当中一两个开发人员离职，如何后续处理。
没有开发文档，在架构和关键技术上没有想清楚，贸然而上，开发的永远只是个demo产品。
没有任何文档，极容易导致推出后，疲于奔命地修修补补，每天一个版本。
敏捷开发是快，但是快不等于敏捷开发。
10.误区：
敏捷是自由的，无约束的。
敏捷强调的是自组织团队，发挥人的能动性，以动力代替压力，让人有绝对自由的错觉。
但是应该清楚，凡事都是要讲究一个平衡，人也是两面的，消极的一面和积极的一面同时并存，绝对的自由会放纵人消极的一面。
敏捷并非是绝对自由，无约束的。
作为管理者，有一个职责，就是引导团队成员用自己积极的一面去压制消极的一面，不能放任团队中出现搭便车的现象，否则将打击整个团队的士气。
如果实在无效，那就只能将其排除出团队了，这个惩罚够有约束力吧？
11.误区：
为了敏捷而敏捷
“嗯，敏捷这么好，我们也敏捷吧”，可能很多人会有这种想法。
忘了以前是在哪儿看的大师采访录：
Q：
“我们现有的过程很好，不知道怎么用敏捷改进？
”
A：
“既然很好，那就不要用敏捷”。
做什么事情都要有明确目标的，敏捷虽好，得看你需不需要，能不能解决你现在头疼的问题，如果不是，那就不要给自己找麻烦了。
12.误区：
传统开发能随时转变成敏捷开发
敏捷开发过于诱人，很容易让深受传统软件开发思想折磨的开发人员感觉敏捷开发就是灵丹妙药。
要想转变，首先需要从思想上正确认识敏捷开发的含义，了解它能解决什么问题、会带来什么新的问题、对现有软件/硬件资源有什么要求等。
例如在原先采用CMM的团队中，想利用敏捷开发简化冗余的文档、降低沟通成本，那么敏捷开发确实能在一定程度上缓解这些问题，但也会造成内部文档缺失、沟通不够深入的问题，在应用敏捷开发之前需要先确定适合团队的新的文档流程（代码注释能够自动/半自动的变成团队需要的文档么？
），并且确定沟通的一些原则（比如，对于一些重要的沟通，是否还是用邮件来进行，不要过于“敏捷”？
）。
有趣的是，有可能在回答这几个问题之后会发现，敏捷开发并不能解决项目中遇到的问题，反倒是其他方面出了问题。
举例来说。
如果此前的开发方法是简单的目标管理，遇到的问题是项目进度不可控、开发+测试的周期较长、不能及时响应需求变化，那么敏捷开发能解决的是快速响应需求变化，对项目进度和开发测试周期帮助不大（没有一种流程能够承诺改善项目的开发效率！
），但前提是开发人员必须懂得怎样正确的去迭代开发，并且必须认识到一次迭代的结束是以完成测试为标准的。
在这个例子中可以看到，敏捷开发能带来的好处非常有局限性，如果开发人员达不到一定的层次是很难受益的。
与其号召使用敏捷开发，不如想想如何增加执行力，以及找到周期偏长的根本原因（是因为设计不充分而返工？
还是因为没有可以快速回归的测试用例？
等等）。
13.误区：
敏捷是CMM的反义词
CMM只是一种衡量软件成熟度的标准，并非过程，和敏捷不是一类概念。
如果要给敏捷找一个反义词，传统的瀑布式开发应该更合适一些。
14.误区：
敏捷开发==极限编程/Scrum/…
敏捷开发是一种方法论，只是一些基本原则的集合，并非具体流程。
极限编程、Scrum等流程是具体的实施方法，它们都声称符合敏捷开发的思想，但执行起来是否真的“敏捷”，还得看参与者究竟思想上是否真的接受敏捷开发的原理。
如果把结对编程、dailyscrum当做是敏捷开发的表现，那更是本末倒置，可悲的是，不少人还真是这么认为的。
15.误区：
迭代就是敏捷，UP属于敏捷。
UP是重型的过程，虽然引入了迭代，但是其原则和价值观与敏捷是不同的。
敏捷注重的是反馈，迭代周期尽量的短，重在客户的参与，通过客户的参与，获取持续的反馈，不断调整使整个项目走在正确的方向上。
同时也给客户一个感受和思考的机会，因为对于大多数客户而言，目标是明确的（不排除有些客户目标也不明确），但是具体怎么做，开始时是没有想法的，只有看到具体的东西的时候，才知道“噢，原来可以这样，那我想把这里调整一下”。
16.误区：
重做就是重构
重做不等于重构，很多场合这两个概念是混淆的。
但是在敏捷中，重构的一个特征是必须可控的。
当对系统结构进行大的调整时，如果没有测试驱动辅助的话，那么可控性就会很差，这不能叫做重构。
17.误区：
版本更新很快，甚至每天都有新版本。
每天一个新版本。
这种情况，最大可能是产品没有经过严格的测试，根本不稳定，就直接放出来，结果在实际使用中bug漫天飞，开发人员不断地推出版本来补窟窿。
这种情况，别说商用版本，用户无法接受如此频繁的升级（升级毕竟耗时麻烦，而且流量是用户自己掏的钱），即便是内测版本，也绝不应该如此频繁和随意。
内测版本或试用版本也是经过开发人员验证和测试后放出来，通过实际使用情况，收集用户对功能和操作中的意见，并对实际使用中测试案例无法覆盖的可能异常情况进行验证。
不是发现一个bug，就改一个，发布一个，而是收集反馈，统一修订后，再释放新版本（而这，通常时间是按周来计算的），除非这个bug是个极其严重，必须马上更正。
每天一个版本，混乱。
在Android上，你可以自行发布更新，但如果基于iOS的，在Apple的AppStore上发布，别说每天一个版本，就算每周一个版本，Apple的软件审核流程还没走完，就又扔一个新的版本，这就很容易造成下游工作根本没法正常进行。
将版本更新速度视为敏捷开发，是完全错误的。
敏捷开发在于你能够准确抓住市场，在时间窗口内快速推出产品。
由于市场的不确定性和用户喜好/需求的不确定性，用户通常不清楚需要什么，你先给他，他再去判断，这需要在需求-开发-市场验证中进行循环迭代，以用户为最终目标，而不是机械地将敏捷视为快，而判断什么为快，又机械地用版本推出速度来说明，每天推一个版本，只能说明开发流程出了问题，整个学生小作坊。
敏捷开发也仍然是和版本更新有一定的关系。
但这个版本，不是小修小补的小版本，而是有新功能，新UI，新互动方式，在用户体验上有新的感受。
这样的版本，不可能一两天就升级。
另外，你推给客户的都应该是个稳定的版本。
18.误区：
没有分析和设计
敏捷开发强调简单设计，团队每个成员都从接触客户到分析设计，到编码，全部承担。
但是实际上团队成员的素质参差不齐，如果只有简单设计、立即编码，而没有后续的持续重构等实践，将导致设计混乱不一致，尤其是对老系统的功能升级，如果对原有系统的影响分析不够，弱化了分析设计，将导致很多工作在后期频繁变更，使得团队的挫折感增强，产生较多的重复工作和浪费。
必要的系统架构和设计从来都是非常重要的。
只是这里的分析设计有别于传统的开发模式，应该应用敏捷的思想，简单设计，持续重构，尽快反馈等。
19.误区：
敏捷拥抱变化，因此前期需求可以随意简单
因为敏捷的导向，可能造成的问题是，前期需求比较随意，对需求质量的控制弱化，需求变更更加频繁，但是这并不意味着对需求可以不做深究，甚至可以随意变更需求。
（1）需求质量的审核，仍然需要改进，需求方向性的错误将导致后续一系列的工作浪费，所以团队内部应该设定里程碑和review标准，从而确保基本的需求质量。
（2）在Iteration里需求尽量不要变更，明确Iteration的边界。
否则频繁的变更导致团队没有成就感，方向和目标不明确。
（3）敏捷讲求业务价值导向，有些变更从业务价值上看，可能并非真正需求急切变更。
有些变更通过更好的Impact分析和设计应该也可以避免。
BA和SA等不同的角色应该一起配合来做出Impact分析，以供决策。
20.误区：
可以孤立地实践少数的敏捷实践
一些敏捷实践容易实行，一些比较困难，所以大家习惯性的会割裂敏捷实践的关联，孤立地实践少数易于实现的敏捷实践。
敏捷开发之所以可以替代以往传统开发模式，是因为一组（系列）的开发实践来共同代替以往开发模式。
孤立的引入少数实践，通常不能给团队成员感觉有大的改进，从而也放弃对敏捷开发的信心。
例如Stand-upMeeting（站立会议）这是一个比较容易的实践，但是如果没有背后的需求转化为比较容易衡量的Story-base，没有BA、QA等共同参与基于Story-base去沟通，没有OfflineofMeeting更多的面对面沟通交流，没有大家彼此知道对方的工作内容（CodeOwnership），那么可以设想这种Stand-upmeeting和以往的传统的开发模式，Leader布置任务检查任务进度没有任何区别。
再如简单设计实践，如果没有背后的结对编程、重构等实践，必然导致比较混乱的代码，很难维护的架构，难于扩展，重复实现类似功能等弊端。
再如持续集成（CI），即使这是公认敏捷软件领域内相对没有争议的一个实践，但是如果没有与TDD结合，没有与持续重构，没有与小的Story，快速频繁Deliver等实践结合在一起，并且坚持保持CI的健康，也会让团队成员觉得CI效果不如宣传，从而对敏捷实践等产生质疑。
升级会员 