敏捷开发是不是一个模块一个模块的开发?

谢邀。

严格来说不是，敏捷开发是一个迭代一个迭代的开发，每一个迭代内的内容不允许变更。如果需要变更就加入待办列表，在下一次迭代会上讨论必要性和优先级，然后再排入新的迭代中。

参考之前回答：

真的很想说不是。

可是在实际的工作环境中，非常多的公司，使用的开发方式，就是将需求模块化，然后一个模块一个模块的开发。

实际上，这样模块的形成以及优先级，就是用敏捷的方法来获取和排列的。

所以，非常多不了解的人，就将这个视作敏捷开发。

如果想要了解敏捷开发更多的内容，欢迎来电咨询哦~

只是外包软件公司，在压榨码农的道路上一个折衷方案，说起来高大上，其实深层原因是，没有一个好的项目管理，一个好的需求把控，没有一个能够全盘掌控项目能力的人，没有一个如何做好需求的人。

为什么呢？因为培养这种比较全能性的人需要时间，外包项目最缺少的是时间。以前从底层做起的人很多十几年后已经具备这种能力了。但是公司又不需要这种人了，他们认为这种人工资高，不好使。说的不符合外包项目的情况，已经接近于如何做好一个项目了，外包公司不需要啊，只需要一些所谓的考过证件的pmp，只需要会书本上聊技术的拥有2年工作经验的大牛。这些人有拼劲肯加班，能吃苦，有福报。

所以这些所谓的迭代，所谓的敏捷，所谓的模块开发，根本不是在做一个好的系统平台，他们只是在流水线生产可以忽悠客户群体的东西，不行就重来迭代，公司得到项目资金，客户得到一个所谓的快速开发版本，大牛又贡献了自己的技术，所以一凑合，大家在这个敏捷开发上各取所需：公司领导赚钱了，客户也得到了满足，技术大牛也不需要掌控更多的能力，只需要敏捷开发和加班就OK了，发现原来自己技术水平什么了得。

谢邀！我在此想说下敏捷开发的常见误区：

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的最高境界（Level 5）也是要求组织有足够的灵活性适应外界环境的变化，灵活的运用规范，而不是教条主义。

5. 误区：敏捷只适用于小型项目和团队

敏捷实践确实很多发源于小型的项目团队，但并不是说敏捷只适合小型项目团队。其实，早期的Scrum项目就已经有在500多人的大型项目中成功实施的案例。可能是由于大多数的敏捷团队一般都希望在5～9人的规模，并且希望团队成员在同一个工作区域，所以很多时候被认为不适合跨地域，跨团队的大型项目的开发。

其实，5～9人的团队规模是一个类似于一个战斗小组的规模，这个团队小组负责完成一个共同的目标。对于一个小型的项目而言，可能只需要一个这样的战斗小组就可以了，而对于一个大型的项目，我们就可以建立多个这样的战斗小组来完成项目目标。在Scrum中，就有Scrum Scaling，通过把一个大型项目团队合理分解为多个小型的Scrum团队，每个团队都负责一个相对独立的模块或者功能，再配合其他的敏捷实践，比如持续集成，Scrum of Scrums等，加强团队之间的协作，从而确保项目的成功。所以，将敏捷实践应用于大型的、复杂的项目是完全可以的。

6. 误区：敏捷开发 == 简化流程

敏捷开发不一定能简化工作流程，而且简化流程也并非提出敏捷开发的初衷。敏捷开发最重视的是拥抱变化，至于怎么拥抱，只能随机应变。实际应用中，既有流程相当简单的经典Scrum过程，也有极为冗繁、不亚于CMMI的RUP，根据应用场景不一样，项目组应该使用最适合的流程。

选择敏捷开发流程时也应带着敏捷开发的思维去选择，即快速响应项目实际的流程需求、拥抱流程应用过程中遇到的各种变化。没有银弹，也没有长期适合的项目流程，生搬硬套某个看似成熟的敏捷开发流程是大忌。

7. 误区：敏捷开发 == 快速开始编码

敏捷开发强调迭代，鼓励开发人员用代码说话，不过绝对不鼓励没想明白就写代码。

符合敏捷开发思想的流程往往主张在一个稳定的基础之上迭代完成各种功能。如果基础都不牢固，迭代就无法进行，整个开发过程就退化成不断重写的过程，浪费开发时间。敏捷开发实际非常重视“设计”，并且对开发人员的设计水平提出了极高的要求，既要“持续重构”又不能“过度设计”，稍有不慎就会陷入反复推翻已有代码的窘境。对于内功不够的开发人员最好还是想好再写代码，设计的时候慢一点没关系，尽量少的做无用功才是最重要。

8. 误区：敏捷是彻底革命的。

敏捷，特别是XP，让人有耳目一新的感觉，觉得以前的所有软件工程理论，设计方法都可以抛弃掉了，推翻一切，从头再来。抱着这种想法实施敏捷，那就错了，敏捷不是“石头里蹦出个孙大圣”，以前的软件过程中也有敏捷的影子，只是没有像敏捷一样上升到价值观和原则的高度，比如快速原型法。敏捷是在对已有的软件过程方法的改进，抛弃的是传统软件工程低效的外表，以往的软件过程中很多技巧都是很实用的。实施敏捷应该以现有的软件过程为基础，从敏捷宣言和原则出发，利用敏捷的方法来改善过程。　

9. 误区：敏捷是反文档的。

文档只是为了达成目标的一种手段，如果这种手段是低效的，那就换一种手段。可是完全抛弃了文档，怎样解决沟通的问题？难道你想每次沟通都完全用手比划，用嘴说，跟不同的人重复表述同样的想法，那样更是低效的。　

应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识，知识具备两种形态，显性的和隐性的，传统的观念是尽量把隐性知识显性化，即文档化，而忽略了这其中的代价（特别是更新同步文档的代价）。　　

因此，在实施敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的最佳效率。　

文档不是目的，有效沟通才是目的。

就工作量而言，不写文档，减少写文档时间，看起来确实可以加快开发速度，但实际会严重伤害项目。互联网应用开发不需要似传统大型软件开发那样，按照软件工程，花大量时间去写文档。不要为了写文档而写文档，而是为了开发而写文档。

例如需求文档（或者功能文档-可以含有版本信息，业务流程文档，互通操作文档），无论具体形式如何，需要清晰地给出你的应用针对什么，提供什么，解决什么。需求文档有时也可以作为测试的指导。如果是client+server，你需要给出本期目标的性能，可以简单到一两页纸，但是绝对不能缺。在迭代开发中，你不断地修改它，它是你开发的轨迹。

例如开发文档，不一定要什么概要设计、详细设计这类学院派的东东，但是你需要有文档能够清晰描述开发对象的架构，模块划分，client和server的交互流程，以及关键的核心技术，例如，如何避免client和server中过多连接造成的server压力，为何采用长连接tcp而非upd（反之亦然），如何制定心跳，是否需要通过使用底层的socket进行特定优化等等。你至少需要从架构师的角度对产品进行梳理，描述实现的架构、采用的机制和关键技术。开发文档或繁或简，甚至可以在代码中通过注释说明，利用javadoc生产HTML，格式不论。

不要让文档成为开发的负担，而是成为帮助。现在工作的流动性很大，没有文档，当中一两个开发人员离职，如何后续处理。没有开发文档，在架构和关键技术上没有想清楚，贸然而上，开发的永远只是个demo产品。

没有任何文档，极容易导致推出后，疲于奔命地修修补补，每天一个版本。敏捷开发是快，但是快不等于敏捷开发。

10. 误区：敏捷是自由的，无约束的。

敏捷强调的是自组织团队，发挥人的能动性，以动力代替压力，让人有绝对自由的错觉。但是应该清楚，凡事都是要讲究一个平衡，人也是两面的，消极的一面和积极的一面同时并存，绝对的自由会放纵人消极的一面。敏捷并非是绝对自由，无约束的。作为管理者，有一个职责，就是引导团队成员用自己积极的一面去压制消极的一面，不能放任团队中出现搭便车的现象，否则将打击整个团队的士气。如果实在无效，那就只能将其排除出团队了，这个惩罚够有约束力吧？

对了，想要了解更多敏捷开发解决方案可前往CORNERSTONE，注册体验。