什么是敏捷模式开发是一种以人為核心、迭代、的开发方法在什么是敏捷模式开发中，软件的构建被切分成多个子项目各个子项目的成果都经过测试，具备集成和可運行的特征换言之，就是把一个大项目分为多个相互联系但也可独立运行的小，并分别完成在此过程中软件一直处于可使用状态。

　　它是什么是敏捷模式开发的最重要的部分在ThoughtWorks，我们实现任何一个功能都是从开始首先对业务需求进行分析，分解为一个一个的Story記录在Story Card上。然后两个人同时坐在电脑前面一个人依照Story，从业务需求的角度来编写测试代码另一个人看着他并且进行思考，如果有不同嘚意见就会提出来进行讨论直到达成共识，这样写出来的测试代码就真实反映了业务功能需求接着由另一个人控制键盘，编写该测试玳码的实现如果没有测试代码，就不能编写功能的实现代码先写测试代码，能够让开发人员明确目标就是让测试通过。

　　在以往嘚软件开发过程中集成是一件很痛苦的事情，通常很长时间才会做一次集成这样的话，会引发很多问题比如 build未通过或者单元测试失敗。什么是敏捷模式开发中提倡持续集成一天之内集成十几次甚至几十次，如此频繁的集成能尽量减少冲突由于集成很频繁，每一次集成的改变也很少即使集成失败也容易定位错误。一次集成要做哪些事情呢它至少包括：获得所有源代码、编译源代码、运行所有测試，包括单元测试、功能测试等；确认编译和测试是否通过最后发送报告。当然也会做一些其它的任务比如说代码分析、测试覆盖率汾析等等。在我们公司里开发人员的桌上有一个火山灯用来标志集成的状态，如果是黄灯表示正在集成；如果是绿灯，表示上一次集荿通过开发人员在这时候获得的代码是可用而可靠的；如果显示为红灯，就要小心了上一次集成未通过，需要尽快定位失败原因从而讓灯变绿在持续集成上，我们公司使用的是自己开发的产品CruiseControl

　　相信大家对它都很熟悉了，有很多很多的书用来介绍重构最著名的昰Martin的《重构》，Joshua的《从重构到模式》等重构是在不改变系统外部行为下，对内部结构进行整理优化使得代码尽量简单、优美、可扩展。在以往开发中通常是在有需求过来，现在的系统架构不容易实现从而对原有系统进行重构；或者在开发过程中有剩余时间了，对现茬代码进行重构整理但是在什么是敏捷模式开发中，重构贯穿于整个开发流程每一次开发者check in代码之前，都要对所写代码进行重构让玳码达到clean code that works。值得注意的是在重构时，每一次改变要尽可能小用单元测试来保证重构是否引起冲突，并且不只是对实现代码进行重构洳果测试代码中有重复，也要对它进行重构

　　在什么是敏捷模式开发中，做任何事情都是Pair的包括分析、写测试、写实现代码或者重構。Pair做事有很多好处两个人在一起探讨很容易产生思想的火花，也不容易走上偏路在我们公司，还有很多事都是Pair来做比如Pair学习，Pair翻譯Pair做PPT，关于这个话题钱钱同学有一篇很有名的文章对它进行介绍，名为Pair Programming (结对编程)

　　每天早上，项目组的所有成员都会站立进行一佽会议由于是站立的，所以时间不会很长一般来说是15-20分钟。会议的内容并不是需求分析、任务分配等而是每个人都回答三个问题：1. 伱昨天做了什么？2. 你今天要做什么 3. 你遇到了哪些困难？站立会议让团队进行交流彼此相互熟悉工作内容，如果有人曾经遇到过和你类姒的问题那么在站立会议后，他就会和你进行讨论

　　在什么是敏捷模式开发中，不会出现这种情况拿到需求以后就闭门造车，直箌最后才将产品交付给客户而是尽量多的产品发布，一般以周、月为单位这样，客户每隔一段时间就会拿到发布的产品进行试用而峩们可以从客户那得到更多的反馈来改进产品。正因为发布频繁每一个版本新增的功能简单，不需要复杂的设计这样文档和设计就在佷大程度上简化了。又因为简单设计没有复杂的架构，所以客户有新的需求或者需求进行变动也能很快的适应。

　　其实什么是敏捷模式开发中并不是没有文档而是有大量的文档，即测试这些测试代码真实的反应了客户的需求以及系统API 的用法，如果有新人加入团队最快的熟悉项目的方法就是给他看测试代码，而比一边看着文档一边进行debug要高效如果用书面文档或者注释，某天代码变化了需要对這些文档进行更新。一旦忘记更新文档就会出现代码和文档不匹配的情况，这更加会让人迷惑而在什么是敏捷模式中并不会出现，因為只有测试变化了代码才会变化，测试是真实反应代码的这时有人会问：代码不写注释行吗？一般来说好的代码不是需要大量的注释嗎其实简单可读的代码才是好的代码，既然简单可读了别人一看就能够看懂，这时候根本不需要对代码进行任何注释若你觉得这段玳码不加注释的话别人可能看不懂，就表示设计还不够简单需要对它进行重构。

　　在什么是敏捷模式开发中代码是归团队所有而不昰哪些模块的代码属于哪些人，每个人都有权利获得系统任何一部分的代码然后修改它如果有人看到某些代码不爽的话，那他能够对这蔀分代码重构而不需要征求代码作者的同意很可能也不知道是谁写的这部分代码。这样每个人都能熟悉系统的代码即使团队的人员变動，也没有风险

　　什么是敏捷模式开发中，客户是与开发团队一起工作的团队到客户现场进行开发或者邀请客户到团队公司里来开發。如果开发过程中有什么问题或者产品经过一个迭代后能够以最快速度得到客户的反馈。

　　为了减小人力或者重复劳动所有的测試包括单元测试、功能测试或集成测试等都是自动化的，这对QA人员提出了更高的要求他们要熟悉开发语言、自动化测试工具，能够编写洎动化测试脚本或者用工具录制我们公司在自动化测试上做了大量的工作，包括Selenium开源项目

　　什么是敏捷模式开发中计划是可调整的，并不是像以往的开发过程中需求分析->概要设计->详细设计->开发 ->测试->交付，每一个阶段都是有计划的进行一个阶段结束便开始下一个阶段。而什么是敏捷模式开发中只有一次一次的迭代小版本的发布，根据客户反馈随时作出相应的调整和变化

　　什么是敏捷模式开发過程与传统的开发过程有很大不同，在这过程中团队是有激情有活力的，能够适应更大的变化做出更高质量的软件。

什么是敏捷模式方法主要有两个特点这也是其区别于其他方法，尤其是重型方法的最主要特征:

　　这里说的预设性可以通过一般性的做法理解，比如在这类工程实践中，有比较稳定的同时建设项目的要求也相对固定，所以此类项目通常非常强调施工前的设计规划只要图纸设计得匼理并考虑充分，施工队伍可以完全遵照图纸顺利建造并且可以很方便地把图纸划分为许多更小的部分交给不同的施工人员分别完成。

　　然而在软件开发的项目中，这些稳定的因素却很难寻求软件的设计难处在于软件需求的不稳定，从而导致的不可但是传统的项目模式都是试图对一个软件开发项目在很长的时间跨度内做出详细的，然后依计划进行开发所以，这类方法在不可预测的环境下很难適应变化，甚至是拒绝变化

　　与之相反的什么是敏捷模式方法则是欢迎变化，目的就是成为适应变化的过程甚至能允许改变自身来適应变化。所以称之为适应性方法 　　 　　（2）什么是敏捷模式开发方法是“面向人” (people oriented)而非“面向过程”(process oriented)。

　　Matin Flower认为：“在什么是敏捷模式开发过程中人是第一位的，过程是第二位的所以就个人来说，应该可以从各种不同的过程中找到真正适合自己的过程”这与理論提倡的先过程后人正好相反。 (续致信网上一页内容)

　　在传统的软件开发工作中分配工作的重点是明确角色的定义，以个人的能力去適应角色而角色的定义就是为了保证过程的实施，即个人以的方式被分配给角色同时，资源是可以替代的而角色不可以替代。

　　嘫而传统软件开发的这些方法在什么是敏捷模式开发方式中被完全颠覆。什么是敏捷模式开发试图使软件开发工作能够利用人的特点充分发挥人的创造能力。

　　什么是敏捷模式开发的目的是建立起一个项目团队全员参与到软件开发中包括设定软件开发流程的人员，呮有这样软件开发流程才有可接受性同时什么是敏捷模式开发要求研发人员独立自主在技术上进行，因为他们是最了解什么技术是和不需要的再者，什么是敏捷模式开发特别重视项目团队中的交流有调查显示：“项目失败的原因最终都可追溯到信息没有及时准确地传遞到应该接受它的人。”

实际上什么是敏捷模式开发运动在数年前就开始了但它正式开始的标志是2001年2月的“什么是敏捷模式宣言”（Agile Manifesto），这项宣言是由17位当时称之为“轻量级方法学家”所编写签署的他们的是：个人与交互重于开发过程与工具；可用的软件重于复杂的文檔；寻求客户的合作重于对的；对变化的响应重于始终遵循固定的计划。

　　个人与交互重于开发过程与工具的原因：一个由优秀的人员組成但使用普通的工具要比使用优秀的工具但由普通人组成、紊乱的小组做得更好。多年来人们花了很多时间试图建立一种过程以便紦人当作机器上的一个可以替代的齿轮，但结果却并不成功什么是敏捷模式过程是承认每个人都有特定的能力（以及缺点）对之加以利鼡，而不是把所有的人当成一样来看待更重要的是，在这样的理念下几个项目做下来，每个人的能力都从中得以提高这种人的能力嘚提高，对是无价之宝而不至于把人当成齿轮，随着时间的推移人的能力慢慢被消耗掉，最后变成留之无用、弃之可惜的尴尬人物

　　可用的软件重于复杂的文档的原因:可用的软件可以帮助开发人员在每次迭代结束的时候，获得一个稳定的、逐渐增强的版本从而允許项目尽早开始，并且更为频繁的收集对和开发过程的反馈随着每次迭代完成软件的增长，以保证开发小组始终是处理最有价值的功能而且这些功能可以满足用户的期待。

　　寻求客户的合作重于对合同的谈判的原因:什么是敏捷模式开发小组希望与项目有关的所有团体嘟在朝共同方向努力有时会在一开始就使小组和客户出于争执中。什么是敏捷模式开发追求的是要么大家一起赢要么大家一起输。换呴话说就是希望开发小组和客户在面对项目的时候，以一种合作的态度共同向目标前进当然，合同是必需的但是如何起草条款，往往影响到不同的团体是进行合作式的还是对抗式的努力

　　对变化的响应重于始终遵循固定的计划的原因：什么是敏捷模式开发认为对變化进行响应的价值重于始终遵循固定的计划。他们最终的焦点是向用户交付尽可能多的价值除了最简单的项目以外，用户不可能知道怹们所需要的所有功能的每个细节不可避免地在过程中会产生新的想法，也许今天看起来是必需的功能明天就会觉得不那么重要了。隨着小组获得更多的知识和经验他们的进展速度会比开始的时候慢或者快。对什么是敏捷模式开发来说一个计划是从某个角度对未来嘚看法，而具有多个不同的角度看问题是有可能的

什么是敏捷模式方法很多,包括 Scrum、、功能驱动开发以及统一过程（）等多种法，这些方法本质实际上是一样的什么是敏捷模式开发小组主要的工作方式可以归纳为：作为一个整体工作； 按短迭代周期工作； 每次迭代交付一些成果； 关注业务优先级； 检查与调整。下图是典型的什么是敏捷模式过程总图下面介绍其有关的特点。

　　1、什么是敏捷模式小组作為一个整体工作

　　项目取得成功的关键在于所有项目参与者都把自己看成朝向一个共同目标前进的团队的一员。“扔过去不管”的心悝不是属于什么是敏捷模式开发设计师和架构师不会把程序设计“扔”给编码人员；编码人员也不会把只经过部分测试的代码“扔”给測试人员，一个成功的什么是敏捷模式开发小组应该具有“我们一起参与其中的思想” “帮助他人完成目标”这个理念是什么是敏捷模式开发的根本管理文化。当然尽管强调一个整体，小组中应该有一定的角色分配各种什么是敏捷模式开发方法角色的起名方案可能不哃，但愿则基本上是一样的第一个角色是产品所有者，他的主要职责包括：确认小组成员都在追求一个共同的目标前景；确定功能的优先等级以便总是处理最有价值的功能；作出可以使项目的投入产生良好回报的决定。产品所有者通常是公司的市场部门或者部门的人员在开发内部使用的软件的时候，产品所有者可能是用户、用户的上级、分析师也可能是为项目提供的人。

　　2、什么是敏捷模式小组按短迭代周期工作

在什么是敏捷模式项目中上并没有什么上游阶段、下游阶段，你可以根据需要定义开发过程在初始阶段可以有一个简短的分析、建模、设计但只要项目真正开始，每次迭代都会做同样的工作（分析、设计、编码、测试等等）。迭代是受时间框限制的也就是说即使放弃一些功能，也必须结束迭代时间框一般很短，大部分是 2～4周在 Scrum中采用的是 30个日历天，也就是 4 周迭代的时间长度┅般是固定的，但也有报告说有的小组在迭代开始的时候选择合适的时间长度。

　　3、什么是敏捷模式小组每次迭代交付一些成果

　　仳选择特定迭代长度更重要的是开发小组在一次迭代中要把一个以上的不太精确的需求声明，经过分析、设计、编码、测试变成可交付的软件（称之为功能增量）。当然并不需要把每次迭代的结果交付给用户但目标是可以交付，这就意味着每次迭代都会增加一些小功能但增加的每个功能都要达到发布。每次迭代结束的时候让产品达到可交付状态十分重要但这并不意味着要完成发布的全部工作，因為迭代的结果并不是真正发布产品假定一个小组需要在发布产品之前对软硬件进行为期两个月的“”（）测试，他们不可能缩短这两个朤的时间但这个小组仍然是按照 4 周迭代，除了MTBF测试其它都达到了发布状态。

　　4、什么是敏捷模式小组关注业务优先级

　　什么是敏捷模式开发小组从两个方面显示出他们对业务优先级的关注首先，他们按照产品所有者制定的顺序交付功能而产品所有者一般会按照茬项目上的最大化的方式来确定优先级，并且把它组织到产品发布中去要达到这个目的，需要综合考虑开发小组的能力以及所需功能嘚优先级来建立发布计划。在编写功能的时候需要使工能的依赖性最小化。如果开发一个功能必须依赖其它 3 个功能那产品所有者这就佷难确定功能优先级。功能完全没有依赖是不太可能的但把功能依赖性控制在最低程度还是相当可行的。

　　5、什么是敏捷模式小组检查与调整

　　任何项目开始的时候所建立的计划仅仅是一个当前的猜测。有很多事情可以让这样的计划失效：项目成员的增减某种技術比预期的更好或更差，用户改变了想法迫使我们做出不同的反应，等等对此，什么是敏捷模式小组不是害怕这种变化而是把这种變化看成使最终软件更好地反映实际需要的一个机会。每次新迭代开始什么是敏捷模式小组都会结合上一次迭代中获得新知识做出相应調整。如果认为一些因素可能会影响计划的准确性也可能更改计划。比如发现某项工作比预计的更耗费时间可能就会调整进展速度。吔许用户看到交付的产品后改变了想法，这就产生反馈比如他发现他更希望有另一项功能，或者某个功能并不像先前看得那么重通過先期发布增加更多的用户希望的功能，或者减少某些低价值功能就可以增加产品的价值。迭代开发是在变与不变中寻求平衡在迭代開始的时候寻求变，而在迭代开发期间不能改变以期集中精力完成已经确定的工作。由于一次迭代的时间并不长所以就使稳定性和易變性得到很好的平衡。在两次迭代期间改变优先级甚至功能本身对于最大化是有益处的。从这个观点来看迭代周期的长度选择就比较偅要了，因为两次迭代之间是提供变更的机会周期太长，变更机会就可能失去；周期太短会发生频繁变更，而且分析、设计、编码、測试这些工作都不容易做到位综合考虑，对于一个复杂项目迭代周期选择4周还是有道理的。

　　MIT Sloan Management Review（麻省理工学院项目管理评论）所刊載的一篇为时两年对成功软件项目的研究报告报告指出了软件项目获得成功的共同因素，排在首位的是迭代开发而不是瀑布过程。其咜的因素是：

　　1、至少每天把新代码合并到整个并且通过测试，对做出

　　2、开发团队具备运作多个产品的工作经验。

　　3、很早僦致力于构建和提供内聚的架构

　　从这个报告中所透露出的信息告诉我们，认真研究什么是敏捷模式过程对软件项目的成功是非常有意义的它的意义在于：

　　1）给开发小组的自组织提供了机会

　　经典项目管理就好比一个具备中央调度服务的航空管理系统，这个系統是自治的而且是封闭的，但现实中更庞大的系统似乎并不属于中央调度控制系统，但也同样也是有效的假如我们开车到某个地方，我们可以任意选择所需要的路线我们甚至不需要准确计算停车，只要我们遵守交通法规驾驶员可以临时根据路况改变某个转弯点，茬驾驶游戏规则的框架内依照自身最大利益做出决策。成千上万的驾驶者并不需要中央控制和调度服务，人们仅仅在简单的交通法规嘚框架内就可以完成综合起来看是更庞大的目标，很多事情从管理的角度只要抓住关键点并不需要多么复杂的规则，往往会更有效隨着系统复杂度的提高，中央控制和调度系统面临崩溃仔细研究交通系统的特点，我们会发现这样的系统中独立的个体在一组适当的规則下运行并不需要设计每个个体临时变更的方案，而每个个体只需要知道目标和大致的状况他们完全可以利用自己的聪明才智来决定洎己的行为。

　　2）缩短了反馈通道

　　什么是敏捷模式过程有效运作的另一个原因是它极大的缩短了用户与开发者、预测目标与实施狀况、与回报之间的反馈回路。在面对不断变化的、业务过程以及不断发展的技术状态的时候便需要有一种方法在比较短的时间内发展唍善。事实上所有的过程改进都不同程度的使用着，以研究问题、测试解决方案、评估结果进而根据已知的事实来进行改进，这就称の为基于事实的我们都知道，这比前端预测的更加有效

　　什么是敏捷模式过程能有效应用的另一个原因在于，它可以就一个问题集思广益我们的经验告诉我们当一个问题发生的时候，总有某些人员知道问题所在但他的观点却遭到忽视。例如航天飞机在起飞阶段发苼爆炸事后分析出了各种原因，但这种调查也提供给我们一个惊人的事实就是部分工程师早就意识到这些潜在问题，却无法说服他人偅视这个担忧对这些事实的深入思考，促使我们研究我们应该采取何种管理系统使前线工作人员的经验、观点及担忧得到充分的重视呢？

误解一：什么是敏捷模式对人的要求很高

　　很多人在尝试实施什么是敏捷模式时说：什么是敏捷模式对人的要求太高了我们没有這样的条件，我们没有这样的人因此我们没法什么是敏捷模式。可是什么是敏捷模式对人的要求真的那么高么？ 软件归根到底还是一種创造性活动开发人员的技术水平和个人能力对软件的质量还是起着决定性的作用，各种过程与方法只是帮助开发人员、测试人员等角銫能够更好的合作从而产生更高的生产力。不管用什么方法开发人员的水平永远都是一个主要的因素。

　　从另一个角度来看：过程囷方法究竟能帮开发人员多大忙对于技术水平较低的开发人员，什么是敏捷模式方法和传统方法对他的帮助是差不多的因此看不到显著的效果，甚至有些时候还有反效果；而随着开发人员技术水平的提高什么是敏捷模式方法能够解开对人的束缚，鼓励效果也会越来樾显着。

　　什么是敏捷模式对人的要求并不高而且会帮助你培养各种所需的能力，当然前提是你处在真正什么是敏捷模式的环境中

　　误解二：什么是敏捷模式没有文档，也不做设计

　　这个误解从XP开始就没有停止过XP鼓励“在非到必要且意义重大时不写文档”。这裏面提到的“必要且意义重大”是一个判断标准并不是所有的文档都不写。例如是不是“必要且意义重大”？这取决于客户的要求洳果客户不需要，那就不用写,如果客户需要就一定要写；再如，架构设计文档要不要写复杂要写，不复杂不用写通常架构设计只需偠比较简单的文档，对于有些项目一幅简单的图就够了。因此写不写，怎么写都要根据这个文档到底有多大意义，产出和投入的比唎以及项目的具体情况决定。实际操作时可以让项目组所有人员表决决定尽量避免由某一个人（比如）来决定。

　　至于设计XP奉行嘚是持续设计，并不是不设计这实际上是将设计工作分摊到了每天的日常工作中，不断的设计、改善（重构）使得设计一直保持灵活鈳靠。至于编码前的预先设计Kent Beck等人确实实行着不做任何预先设计的开发方式，但是对于我们这些“非大师”级开发人员必要的预先设計还是需要的，只是不要太多不要太细，要有将来会彻底颠覆的准备

　　误解三：什么是敏捷模式好，其他方法不好

　　有些人一提箌什么是敏捷模式就大呼好只要是什么是敏捷模式的实践就什么都好，而提到等方法就大呼不好不管是什么只要沾上边就哪里都不好，似乎什么是敏捷模式和其他方法是完全对立的牛顿说过，我是站在了巨人的肩膀上什么是敏捷模式同样也吸取了其他方法论的优点，也是站在了巨人的肩膀上什么是敏捷模式依然保持了很多历史悠久的实践和原则，只是表现方式不同罢了

　　从另一个方面来看，方法本没有好环好与坏取决于是否适合解决你的问题。每一种方法都有他最善于解决的问题和最佳的发挥环境在需求稳定、软件复杂喥相对不高的时代，也可以工作的很好而什么是敏捷模式恰好适用于变化快风险高的项目 － 这恰恰是现在很多项目的共性。

　　因此选擇一个方法或过程并不是根据它是否什么是敏捷模式，而应根据它是否适合而要了解一个东西是否适合，还是要尝试之后才知道任哬没有经过实践检验的东西都不可信。

　　误解四：什么是敏捷模式就是XP（）就是Scrum

　　XP 和Scrum只是众多什么是敏捷模式方法中的两种，还有佷多其他的什么是敏捷模式方法龙生九子各个不同，什么是敏捷模式的这些方法看起来差别也是很大的可是他们之所以被称为什么是敏捷模式方法，就是因为他们背后的理念和原则都是相同的这个原则就是《什么是敏捷模式宣言》。学习什么是敏捷模式不仅仅要学习實践还要理解实践后的原则，不仅要理解怎么做还要理解为什么这么做，以及什么时候不要这么做

　　即使将XP或Scrum完全的应用的你的項目中，也未见得就能成功适合别人的东西未必就适合你。什么是敏捷模式的这些实践和方法给了我们一个起点但绝对不是终点，最適合你的方式还要由你自己在实际工作中探索和寻找

　　误解五：什么是敏捷模式很好，因此我要制定标准所有项目都要遵循着个标准

　　没有哪两个项目是一样的，客户是不一样的人员是不一样的，需求是不一样的甚至没有什么可能是一样的。不一样的环境和问題用同样的方法解决，是不可能解决的好的方法是为人服务的，应该为项目团队找到最适合他们的方法而不是先确定方法，再让团隊适应这个方法因此也不存在适合所有项目的统一的方法。任何企图统一所有项目过程的方法都是不正确的

　　同时，对于同一个团隊随着项目的进行，对需求理解的深入对技术理解的深入，一开始适合项目的过程和方法也会渐渐的不适合这时候也需要团队对过程进行及时的调整，保证项目的质量和效率什么是敏捷模式是动态的，而非静止不变的因为这个世界本身就是变化的，在变化的世界使用不变的方法是不现实的。银弹从来就没有过在有限的将来也不会存在。

本条目相关文档参考文档地址：

许多知名的软件专业人员利用什麼是敏捷模式管理 的优点取得了相当大的成功，然而很少有人谈论什么是敏捷模式管理的缺点本文我们将分析这种少见的情况，即什麼是敏捷模式管理失败的情况希望能对大家有所启发。

在讨论什么是敏捷模式失败前我们先了解什么是敏捷模式管理的优点。什么是敏捷模式开发和测试实践为无数企业创造了奇迹比较突出的方面有减少产品投放市场的时间、改善沟通或降低成本等。

? 通过快速而持續交付有用的软件来满足客户的需求

? 强调人员和互动，而不是过程和工具客户、开发人员和测试人员经常相互交流。

? 频繁交付工莋软件(几周而不是几个月)

? 面对面交谈是最好的交流方式。

? 商业人士和开发商之间日常密切的合作

? 持续关注技术的卓越程度和良恏的设计。

? 经常适应不断变化的环境

? 即便是需求的后期更改也是受欢迎的。

什么是敏捷模式开发能加速初始业务价值的交付好处昰不言而喻的。但是不少团队在什么是敏捷模式了一段时间后发现自己陷入了“假什么是敏捷模式”的怪圈又或是什么是敏捷模式失败。什么是敏捷模式失败表现为混乱的流程、较低的质量、错误的传达和其他问题

? 对于某些软件可交付成果，特别是大型软件可交付成果在软件开发生命周期的开始阶段，很难对所需工作量进行评估

? 对必要的设计和文档缺乏重视。

? 如果客户代表不清楚他们想要的朂终结果是什么项目很容易偏离轨道。

? 开发过程中只有高级程序员能够做出所需的决定。因此什么是敏捷模式模式不适合新手程序员，除非结合经验丰富的资源

什么是敏捷模式开发有时也会因为不切实际的期望而失败。什么是敏捷模式通常被认为是一套实践、流程和工具但实际上，什么是敏捷模式更多是一种思维和文化

需要实现新变更时，使用什么是敏捷模式

什么是敏捷模式给予变更的自甴，这非常重要由于产生新增量的频率，新变更可以用非常低的成本加以实现要实现一个新功能，开发人员只需要工作几天甚至几个尛时完成重新运行和实现新功能。

与什么是敏捷模式模式中的瀑布模式不同启动项目所需的计划非常有限。什么是敏捷模式假定终端鼡户的需求在动态的业务和IT世界中不断变化变更可以进行讨论，也可以根据反馈实现新功能或移除功能这能有效地为客户提供他们想偠或需要的最终系统。

系统开发人员和利害关系人发现相较以更严格的顺序方式开发软件，他们获得更多的自由时间和选择有了选择權，他们就能在掌握更多数据或更好的数据甚至整个托管程序时，做出重要的决定这意味着，项目可以继续向前推进不用担心突然停滞不前。

什么是敏捷模式开发模式也是一种增量模式软件是在递增、快速的周期中开发的。这导致小的增量发布版本每个版本都构建在以前的功能上，并且每个版本都经过全面的测试确保软件质量。

如果在大型项目或任务关键项目中使用什么是敏捷模式那么你需偠功能强大的项目管理软件。8Manage PM什么是敏捷模式大项目管理软件(/pm/agile-largeproject.html)的设计是针对解决什么是敏捷模式方法在大型项目里与最终目标脱离的问题能够帮企业完成大型项目的计划，并在每个Sprint周期结束时精确地衡量大型项目的完成率。

以下是8Manage PM提供的运行什么是敏捷模式大项目或关鍵任务项目所需的功能列表：

- 支持传统的大型项目和什么是敏捷模式项目

- 面向实时交易拥有单一事实版本(当前计划和状态)

- 自动准确计算朂终目标的完成率

- 自动和廉洁的审计跟踪

8Manage什么是敏捷模式大项目管理软件使项目既能获得什么是敏捷模式递增的好处，同时又能与大项目目标对齐让团队的子目标和最终目标一直保持一致。

申请创业报道分享创业好点子。共同探讨创业新机遇！