《敏捷开发的常见误区》由会员分享，可在线阅读，更多相关《敏捷开发的常见误区（11页珍藏版）》请在金锄头文库上搜索。
1、敏捷开发的常用误区1. 误区：敏捷项目没有筹划由于产品需求的不拟定性、甚至是未知的,敏捷项目团队很少能在项目之初建立一份类似于WBS任务分解的进度表和甘特图,但敏捷项目仍然是有筹划的,和老式的进度筹划不同，敏捷的筹划不是关注在完毕项目的一种个活动或者说任务，例如说需求分析、概要设计、具体设计，模块一编码等等,而是关注在客户的需要，关注客户价值的优先级,其筹划的对象是顾客规定的功能,例如顾客故事，筹划活动的产出是一种设立了优先级的顾客需要的功能列表。敏捷筹划分为如下几种层次:l 愿景制定产品的长远目的;l 路线图制定实现长远目的的分步实行筹划;l 发布制定一次发布的目的,涉及在一种发布中但愿交付
2、的需求清单,并设立了优先级；l 迭代制定一次迭代的目的,涉及了在一种迭代中团队承诺交付的需求清单及为了达到目的而设立的工作任务；l 每日筹划制定每天的工作目的,涉及了团队中每个成员的工作任务。其筹划的过程是一种持续的过程，从项目开始时制定产品的愿景，到每个迭代开始时制定迭代筹划,敏捷项目的筹划不断的细化，不断的根据变化而调节,是ustI-Tie的筹划。2. 误区：敏捷就是追求速度一次在和几种朋友聊天的时候，有朋友说近来装了有线数字电视,她觉得开发数字电视频道服务的团队应当是采用了敏捷的团队，由于每隔一段时间，就会有新的功能发布，只是系统不稳定，不得不常常的重新启动机顶盒。这无疑是个非常有趣的有
3、关敏捷的理解,似乎敏捷就是关注软件功能的投放市场速度,而往往忽视质量。这是诸多有关敏捷的理解中，比较典型的一种误识。如果我们重读一下敏捷的四句宣言以及12条敏捷原则,应当不难看出,敏捷实际是关注实现客户的价值，而这一价值体目前“可工作的软件”之中,这其实是对质量的规定,它意味着交付的软件是客户需要的并且质量稳定的，是同步对需求质量和开发质量提出规定。此外,由于市场的变化会促使客户重新调节需求,以获取最大的价值,因此敏捷强调“响应变化”，迅速调节方略，以协助客户迅速对市场变化做出响应。3. 误区:敏捷是放之四海而皆准的开发模式敏捷开发模式被互联网公司广泛采用的最重要的因素有两个：1) 产品的功能
4、升级更新换代非常快,人们都必须要在最短的时间内抢占市场，吸引顾客，而需求往往又不是非常的明确,甚至有时只是一种idea，需要市场的反馈；2) 产品的升级是可控的,即便是带着一定缺陷的产品发布（又称为“灰度发布”)，我们都可以在后台悄悄的升级系统或修改BUG，对于顾客来说，任何时间打开浏览器都可以看到最新的产品,因此对顾客的影响是最小的，甚至顾客是不感知的。对于那些需要安装到顾客使用的终端（电脑、手机、平板等）的应用来说,这样的升级方式也许就会导致客户的反感、投诉和客户流失。对于软件提供商来说,还必须要考虑客户回绝升级状况下,后台系统必须要同步支持多种版本的运营,否则就会遭到客户的投诉，甚至会引
5、起负面影响的广泛传播。因此对于不同形式、不同需求阶段、不同质量规定的产品,对于敏捷开发的实际应用是需要谨慎研究的，而不是绝对的生搬硬套和教条主义。4. 误区：敏捷是“一种”过程 敏捷不是一种过程,是一类过程的统称，它们有一种共性，就是符合敏捷价值观,遵循敏捷的原则。敏捷的价值观如下:l 个体和交互 赛过 过程和工具l 可以工作的软件赛过 面面俱到的文档l 客户合伙赛过 合同谈判l 响应变化 赛过 遵循筹划 由价值观引出的条敏捷原则:1) 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。2) 虽然到了开发的后期，也欢迎变化需求。敏捷过程运用变化来为客户发明竞争优势。3) 常常性
6、地交付可以工作的软件，交付的间隔可以从几种星期到几种月,交付的时间间隔越短越好。4) 在整个项目开发期间，业务人员和开发人员必须每天都在一起工作。(注:这并不是地理位置上规定双方在一起,否则跨国公司的协同开发就成了空话)5) 环绕被鼓励起来的个体来构建项目。给她们提供所需的环境和支持，并且信任她们可以完毕工作。6) 在团队内部,最具有效果并且富有效率的传递信息的措施,就是面对面的交谈。7) 工作的软件是首要的进度度量原则。8) 敏捷过程倡导可持续的开发速度。负责人、开发者和顾客应当可以保持一种长期的、恒定的开发速度。9) 不断地关注优秀的技能和好的设计会增强敏捷能力。10) 简朴使未完毕的工作
7、最大化的艺术是主线的。11) 最佳的构架、需求和设计出自于自组织的团队。12) 每隔一定期间，团队会在如何才干更有效地工作方面进行反省，然后相应地对自己的行为进行调节。 建立敏捷联盟的7位大师所创立的敏捷措施涉及:极限编程，Scrum,特性驱动开发，动态系统开发措施,自适应软件开发，水晶措施，实用编程措施。这些措施统称为敏捷措施。每个人都可以从敏捷宣言和原则出发,明确问题，找出某些解决措施,形成自己的过程。要实用而不是要机械式的规范。让开发人员理解并实行，体验到敏捷的好处,而不是盲目机械地实行规范。CM的最高境界(Level 5）也是规定组织有足够的灵活性适应外界环境的变化，灵活的运用规范,而
8、不是教条主义。5. 误区:敏捷只合用于小型项目和团队敏捷实践的确诸多发源于小型的项目团队，但并不是说敏捷只适合小型项目团队。其实,初期的rm项目就已有在00多人的大型项目中成功实行的案例。也许是由于大多数的敏捷团队一般都但愿在59人的规模,并且但愿团队成员在同一种工作区域,因此诸多时候被觉得不适合跨地区,跨团队的大型项目的开发。其实，59人的团队规模是一种类似于一种战斗小组的规模,这个团队小组负责完毕一种共同的目的。对于一种小型的项目而言，也许只需要一种这样的战斗小组就可以了,而对于一种大型的项目,我们就可以建立多种这样的战斗小组来完毕项目目的。在crm中,就有SruScalg,通过把一种大型
9、项目团队合理分解为多种小型的crum团队,每个团队都负责一种相对独立的模块或者功能,再配合其她的敏捷实践，例如持续集成，Scru of Scrs等，加强团队之间的协作，从而保证项目的成功。因此,将敏捷实践应用于大型的、复杂的项目是完全可以的。6. 误区:敏捷开发 = 简化流程敏捷开发不一定能简化工作流程,并且简化流程也并非提出敏捷开发的初衷。敏捷开发最注重的是拥抱变化，至于怎么拥抱,只能随机应变。实际应用中,既有流程相称简朴的典型Scrm过程,也有极为冗繁、不亚于CMMI的P，根据应用场景不同样,项目组应当使用最适合的流程。选择敏捷开发流程时也应带着敏捷开发的思维去选择,即迅速响应项目实际的流
10、程需求、拥抱流程应用过程中遇到的多种变化。没有银弹，也没有长期适合的项目流程，生搬硬套某个看似成熟的敏捷开发流程是大忌。7. 误区：敏捷开发 = 迅速开始编码敏捷开发强调迭代，鼓励开发人员用代码说话，但是绝对不鼓励没想明白就写代码。符合敏捷开发思想的流程往往主张在一种稳定的基本之上迭代完毕多种功能。如果基本都不牢固，迭代就无法进行，整个开发过程就退化成不断重写的过程,挥霍开发时间。敏捷开发实际非常注重“设计”,并且对开发人员的设计水平提出了极高的规定，既要“持续重构”又不能“过度设计”，稍有不慎就会陷入反复推翻已有代码的窘境。对于内功不够的开发人员最佳还是想好再写代码，设计的时候慢一点没关系，
11、尽量少的做无用功才是最重要。8. 误区:敏捷是彻底革命的。敏捷，特别是XP，让人有耳目一新的感觉,觉得此前的所有软件工程理论，设计措施都可以抛弃掉了,推翻一切,从头再来。抱着这种想法实行敏捷，那就错了，敏捷不是“石头里蹦出个孙大圣”，此前的软件过程中也有敏捷的影子，只是没有像敏捷同样上升到价值观和原则的高度,例如迅速原型法。敏捷是在对已有的软件过程措施的改善,抛弃的是老式软件工程低效的外表，以往的软件过程中诸多技巧都是很实用的。实行敏捷应当以既有的软件过程为基本，从敏捷宣言和原则出发，运用敏捷的措施来改善过程。 9. 误区：敏捷是反文档的。 文档只是为了达到目的的一种手段,如果这种手段是低效的
12、,那就换一种手段。可是完全抛弃了文档,如何解决沟通的问题?难道你想每次沟通都完全用手比划,用嘴说,跟不同的人反复表述同样的想法，那样更是低效的。应当清晰文档的本质是把知识显性化。在一种项目中存在诸多需要沟通的知识,知识具有两种形态，显性的和隐性的,老式的观念是尽量把隐性知识显性化，即文档化，而忽视了这其中的代价（特别是更新同步文档的代价）。 因此,在实行敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的最佳效率。 文档不是目的，有效沟通才是目的。就工作量而言，不写文档,减少写文档时间，看起来的
13、确可以加快开发速度,但实际会严重伤害项目。互联网应用开发不需要似老式大型软件开发那样，按照软件工程，花大量时间去写文档。不要为了写文档而写文档,而是为了开发而写文档。例如需求文档(或者功能文档-可以具有版本信息，业务流程文档,互通操作文档)，无论具体形式如何，需要清晰地给出你的应用针对什么,提供什么,解决什么。需求文档有时也可以作为测试的指引。如果是cient+ever,你需要给出本期目的的性能，可以简朴到一两页纸，但是绝对不能缺。在迭代开发中,你不断地修改它,它是你开发的轨迹。例如开发文档,不一定要什么概要设计、具体设计此类学院派的东东，但是你需要有文档可以清晰描述开发对象的架构,模块划分,
14、cliet和sere的交互流程，以及核心的核心技术，例如,如何避免clie和serer中过多连接导致的server压力，为什么采用长连接t而非p（反之亦然）,如何制定心跳,与否需要通过使用底层的socet进行特定优化等等。你至少需要从架构师的角度对产品进行梳理，描述实现的架构、采用的机制和核心技术。开发文档或繁或简,甚至可以在代码中通过注释阐明,运用javdc生产HTL,格式不管。不要让文档成为开发的承当,而是成为协助。目前工作的流动性很大,没有文档，当中一两个开发人员离职,如何后续解决。没有开发文档,在架构和核心技术上没有想清晰,贸然而上，开发的永远只是个emo产品。没有任何文档，极容易导致
15、推出后，疲于奔命地修修补补,每天一种版本。敏捷开发是快,但是快不等于敏捷开发。10. 误区：敏捷是自由的，无约束的。敏捷强调的是自组织团队,发挥人的能动性，以动力替代压力,让人有绝对自由的错觉。但是应当清晰，凡事都是要讲究一种平衡，人也是两面的,悲观的一面和积极的一面同步并存,绝对的自由会放纵人悲观的一面。敏捷并非是绝对自由，无约束的。作为管理者，有一种职责,就是引导团队成员用自己积极的一面去压制悲观的一面，不能放任团队中浮现搭便车的现象，否则将打击整个团队的士气。如果实在无效，那就只能将其排除出团队了,这个惩罚够有约束力吧? 11. 误区：为了敏捷而敏捷“嗯,敏捷这样好,我们也敏捷吧”，也许诸多人会有这种想法。忘了此前是在哪儿看的大师采访录: ：“我们既有的过程较好,不懂得怎么用敏捷改善？”A：“既然较好，那就不要用敏捷”。 做什么事情都要有明确目的的，敏捷虽好，得看你需不需要,能不能解决你目前头疼的问题，如果不是,那就不要给自己找麻烦了。12. 误区:老式开发能随时转变成敏捷开发敏捷开发过于诱人,很容易让深受老式软件开发思想折磨的开发人员感觉敏捷开发就是灵丹妙药。要想转变
