我们理解，事物是用来连接已知与未知的。首先，让我们比较一下。我们首先了解瀑布模型，然后它不是敏捷的。瀑布式开发模型将开发分为需求、设计、开发、测试等一系列阶段，如下图所示。形似瀑布，故称瀑布开发。问题是，需求的交付不都是经过这些阶段的吗？瀑布式开发的本质不在于阶段，而在于批。需求一起批量设计，然后批量开发，批量测试，交付等等。批处理有什么问题？首先，批处理延迟了价值交付，所有需求只能在最后阶段交付，价值交付相对较晚。谷歌执行董事长施密特提出了反摩尔定律，表述为：“如果18个月后我们只能卖和今天一样的东西，我们将只能得到一半的收入。”价值的交付时间将直接影响收益。敏捷目标1：敏捷开发的首要目标是更快地交付价值。这里的快不是指绝对的速度，而是更早的交货。在项目的最后阶段，一定是对产品和项目的知识和理解得到充分了解的时候。很明显我们在项目过程中积累了知识，尤其是产品交付给用户的时候，用户反馈：“这不是我想要的，我说的是……”，这个时候，你的知识会瞬间增加，惊呼“怎么不早说？”。中间可能会出现沟通问题，但更有可能的是用户此时已经清楚或者能够描述自己想要的是什么。更何况，一开始我们甚至可能无法准确定义用户是谁。产品和业务的发展本质上是一个探索的过程，开始一定是最懵懂的时刻。项目中的绝大部分决策也必须在项目开始时做出，这就会产生一个重大悖论，即最重要、最重要的决策是在最无知的时刻做出的，并作为后续执行的基础.面对不确定的技术和市场环境，传统的开发模式已经不能满足要求，矛盾越来越突出。敏捷开发将通过迭代来处理这个问题，只做初步的决定并设定一个大方向。通过市场反馈不断修正产品认知、增量决策和调整。敏捷目标2：在产品开发过程中，技术环境、市场环境、竞品策略、团队认知都会发生变化。面对不断变化的环境，我们必须承认自己的无知，在开发过程中积极有效地学习，不断吸收反馈，灵活调整。这也是敏捷、有效学习和灵活应对变化的第二个业务目标。敏捷开发工具敏捷过程敏捷开发是一种以人为中心、迭代递进的开发方法，其软件开发过程称为“敏捷过程”。在这个过程中，软件项目的构建被分成多个子项目，每个子项目的成功都经过检验，具有集成和运行的特点。2001年初，一些行业专家成立了敏捷联盟，并起草了敏捷软件开发宣言。针对一些企业的现状，宣言提出了几个使软件开发团队能够快速工作、快速响应的价值观和原则，包括4个简单的价值观和敏捷开发方法应该遵循的12条原则。敏捷开发价值观1.个人和交互优于流程和工具。2.可工作的软件胜过全面的文档。3.客户合作胜过合同谈判。4.响应变化胜于遵循计划。敏捷开发的12条原则1.通过尽早持续交付有价值的软件来满足客户。2.即使在开发后期，也欢迎不断变化的需求。敏捷流程使用变化为客户创造竞争优势。3.以几周到几个月的周期尽可能快速和连续地交付操作软件。4.在整个项目开发期间，业务人员和开发人员必须每天一起工作。5、关注积极向上的员工，建立项目团队，为他们提供所需的环境和支持，对他们的工作给予充分的信任。6、在团队内部，最有效和高效的信息传递方式是面对面的沟通。7.衡量项目进度的主要依据是可运行的软件。8.敏捷过程提倡可持续发展，责任人、开发人员和用户要努力保持一个长期的、恒定的开发速度。9.始终专注于卓越的技术和良好的设计以增强敏捷性。10.简单是根本。11.最好的架构、需求和设计来自自组织团队。12.团队定期反思如何才能更有效地工作，然后相应地调整其行为。敏捷组织提出的敏捷开发模型的总体框架主要包括三种敏捷实践：Scrum、XP（eXtremeProgramming）、OpenUP。敏捷开发的原则1.凝聚人的力量，紧密合作。包括业务领导、开发团队、客户和经理之间的关系。所有这些关系都是过去项目危机的原因之一。那么，在敏捷时代，我们需要这些角色紧密配合，让每个角色发挥最大的作用。角色的力量。2、关注客户价值，杜绝浪费（如何关注用户价值，即频繁交付用户友好的软件，快速接收用户反馈）敏捷的团队运作机制1、一个团队有自己的待办事项，并且待办事项清单事情被分解了。2.按客户价值排序，产品经理负责价值排序。3.小而稳定的跨职能团队。4.多个团队松散耦合（相对较低的依赖性），调整迭代时间和战略目标。关键团队角色产品负责人Scrum主管（流程经理）开发团队产品负责人（产品负责人）唯一负责管理产品待办事项（待办事项）的人代表客户/项目作为所有者定义产品的所有功能负责产品输入输出负责最大化产品和开发团队工作的价值。ScrumMaster（流程主管）扮演教练的角色，带领团队完成Scrum实践并体现其价值。消除团队遇到的困难，使团队紧密合作，使团队个人具备在各个职能部门工作的能力。确保您的团队能够胜任工作并保持高效。保护团队免受无缘无故的外部影响。Keyteamactivities每日例会：每天5分钟左右的简单例会，尽可能多的开发人员参与关键问题的讨论。评审会议：需要在迭代周期的最后一天召开，大约1小时就够了，客户需要参加，如果客户不能参加，产品经理需要参加迭代评审会议：theiterationreviewmeeting每次迭代结束时召开，总结工作中的经验教训，时间保持在30-60分钟以内，需要全团队参与（ScrumMaster、ProductOwner、开发团队和客户）。迭代评审将由两部分组成，第一部分是定量分析，第二部分是定性分析。量化分析包括团队是否完成了迭代目标，收集和评审迭代指标（包括速度、迭代燃尽图、迭代计划故事和实际完成故事、计划发布日期和实际发布日期、客户满意度、团队满意度、数量生产环境错误、生产错误解决时间、用户故事等）。定性分析包括什么做得好（应该继续维持）和什么做得不好（应该停止）？可以改进什么（团队选择1-2项在下一次迭代中实施）？
