关键词：
目录
- 前言
- 什么是敏捷开发
- 敏捷软件开发宣言
- 敏捷的项目管理--追求最大价值的成功
- 总结
一、前言
在这瞬息万变的环境里，企业的生存与发展状况取决于其快速响应变化的能力，而敏捷运作是构建该能力的核心。
敏捷和其他创新思想一样，需要时间传播。全世界不少企业都已迈向敏捷的运作模式，也有很多传统企业，还没有尝试敏捷，处于观望评估的阶段。
从2001年敏捷宣言宣布到现在，已经有将近十五年的历史。十五年，在我们这个变化迅速的软件工程行业已经是一个非常悠久的时期了。敏捷并不是什么新玩意，而已经成为我们行业主流的管理运营体系。
那在我们这个行业里面，具体一点说，在我们的项目里面，敏捷开发能为我们解决什么问题呢？
其实不管在哪个项目里面，都会有一些相似的问题出现，比如以下几个难题：
团队目标不一致
团队成员不熟悉
信息发布不流畅
倘若我们任由问题存在，而不在每次项目中进行总结和提炼，就会反复的徘徊于项目当中。
敏捷思想和实践能够为我们提供一种可能性，帮助我们解决在项目交付过程中遇到的具体难题。
二、什么是敏捷开发
敏捷开发，是一种从1990年代开始逐渐引起广泛关注的新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
三、敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。
由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
我们遵循以下原则：我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
四、敏捷的项目管理
我们现在在讲敏捷的项目管理，就得先说说瀑布式开发和迭代式开发的区别。
大家都知道瀑布式开发的特点是大批次、缓慢流动、在每一阶段追求工作完整，但因其缺乏并行迭代的概念，对变化的响应必然很慢。
而迭代式开发则恰恰弥补了这个弱点。在迭代式开发过程中，整个开发工作被组织为一系列短小的、固定长度的小项目，我们将其称为一系列的“迭代”。每一次迭代都包括了需求定义、需求分析、设计、代码实现与测试。
采用这种方法，开发工作可以在需求被完整地确定前启动，并在每次迭代中完成系统的一部分功能开发工作，再通过客户的反馈来细化需求，并开始新一轮的迭代。
敏捷开发是通过逐步细化、迭代前进的方式，分阶段地将需求予以实现。比如说，我们先从整体功能规划中定位出一小部分核心功能，打造能基本运转、对用户有价值的最小可用产品，然后迅速迭代开发，听取用户反馈，及时调整功能规划。
我们可以拿敏捷团队与西游团队来比较，其实是有相似处的。唐僧师徒可以被看作敏捷中的全功能团队：团队有共同的目标——取到真经；他们历经了九九八十一难，好比九九八十一个迭代，每次打怪成功都是完成了一次交付；在不断迭代的过程中，这个团队不断地收集反馈、持续改进，一步步地完成了最后的目标。取到了真经，意味着完成了项目的交付，同时使得团队能力得到质的提升。这是一个美妙的结果。
而项目成果的交付和团队能力的提升，这是项目经理在项目管理中最希望达成的目标。
传统项目管理的定义是：“在有限资源限定的条件下，实现或超过设定的需求和期望”。一句话概括了传统项目管理的铁三角：需求是范围，资源包括时间和成本。
这样的定义正确吗？
传统的定义忽略了“价值”这一重要因素，在追求价值交付过程中，我们越来越多地发现敏捷项目管理中有着至关重要的一环——人，也就是我们的团队。价值是人创造的，是为人服务的，很多敏捷实践都围绕人展开。我们试图找到一种通用的方法来最大限度地发挥人的能量。未来社会最有价值的人，是以创造力、洞察力、对客户的感知力为核心特征的，我们相信这样的团队能创造最大的价值。
那敏捷实践是如何帮助团队实现最大价值的？
用户故事
用户故事(User Story)是敏捷开发的基础，它从用户的角度来对需求进行描述。软件开发是为了实现产品的商业价值，满足用户需求。只要需求足够明确，所有人都了解其具体内容，团队就能简单有效地把需求转化成可实现、可测试、能够发布的代码。为了实现这个目标， 需要找到一种方法来描述需求，让所有人都能对任务的范围有一个共同的认知。这样团队对任务完成会有一个共同的定义，不会出现“你做的不是我所要求的”、 “我忘了告诉你这个需求”等类似的问题。
用户故事体现了用户需求以及产品的商业价值，同时定义了一系列验收标准(Acceptance Criteria AC)。只有团队完成的工作符合这一系列的AC时， 才算真正完成了这个用户故事。一个用户故事通常包括三个要素：
角色：谁要使用这个功能；
活动：需要完成什么样的功能；
商业价值：为什么需要这个功能，这个功能带来什么价值。
用户故事可以有不同的展现形式，以下是其中一种：作为一个<某种类型的用户角色>，我要<达成某些目的>，只有这样我才能够获取<商业价值>。
所以用户故事一旦被确定，那么它所要实现的功能、需求范围、所需工作量也就随之确认了。之后开发人员所要做的就是根据这个用户故事的内容进行开发，只有当所有AC被覆盖到，测试人员完成测试，发现所有功能是可测试的、可运行的，这个用户故事才算完成了。
估算和迭代计划
估算(Estimation)：团队在动手开发一个用户故事功能之前，应当对实现这个用户故事所需要的工作量有清晰的认识。如Martin Fowler所说，”Estimation is valuable when helps you make a significant decision”（当你做出重大决定时，估算是有价值的）。只有当团队对达成一个目标的工作量以及完成它之后的“收益”有明确的认知， 才能做出明智的决定。
当团队在为工作排定优先级、制定迭代计划时，业务分析师需要知道每个用户故事的成本，团队成员需要知道每个用户故事的价值。有很多种估算用户故事工作量的方法，其中一种就是把完成这个用户故事所需要的点数（根据用户故事的复杂度估算）写到对应的故事卡上。估算可以帮助团队以不同的方式，对实现即将开始的用户故事、未来的架构方向和代码库的设计，有更好的理解。一个迭代能完成多少个点数是能估算出来的。也可以使用一些工具统计出过去每个迭代所完成的点数。
在做迭代计划(Iteration Planning)时，团队需要从客户价值维度和技术风险的角度来排定优先级。下图中是常用的工具之一——需求优先级矩阵。
迭代会议和功能演示
敏捷宣言里面有一条：客户协作优于合同谈判。在敏捷团队中有一个角色叫做业务分析师(BA)，其核心职责是确保业务需求的清晰和透明，保证开发团队对业务有足够的理解，并将这些待完成的用户故事按照优先级排列出来，以任务卡的形式来驱动团队的开发。
迭代会议(IPM)通常发生在每个迭代的第一天，团队成员一起制定迭代计划。这个会议由BA主持，大家一起同步几个方面的内容：
下一个迭代的用户故事；
对下一个迭代的期望和计划；
风险的评估和总结。
不同的人对需求有着不同的理解，所有团队成员都要对用户故事所有相关内容、所要实现的功能、满足哪些条件用户故事才算完成达成一致。迭代会议的主要产出是下一个迭代中需要完成的用户故事，这些用户故事即为下一个迭代所要完成的主要目标。
功能演示(Showcase)是敏捷开发流程中的又一个实践，通常发生在每个迭代的最后一天，目的是演示可工作的软件。团队把一个迭代中开发好的功能给相关人员演示，并收集反馈，以便在下一个迭代中可以对变化作出快速响应。
站会和用户故事开卡
简单地说，站会(Standup)是团队在一起快速地开一个会(通常在物理墙前)，成员逐个更新自己的状态。更新包含以下几个方面：
昨天完成的工作；
今天计划做的工作；
面临什么阻碍，需要什么帮助；
自己手头用户故事的进展，是否存在技术风险。
既然是快速的会议，站会的时间就不宜过长，10分钟左右为佳。建议团队成员站着开会，因为研究表明，当人们坐着开会的时候，会议的时间会被无形中拉长。
这里有一些实践原则：
团队成员都要参加站会，轮流主持，谁迟到了都不等——仪式感很重要。
站会的时候，每位团队成员围绕故事卡进行更新。介绍一种有意思的实践——使用Token(也就是使用一个实物作为”令牌”，准备发言的人首先取得”令牌”，发言完成后将“令牌”传给下一个人。令牌要醒目，可以是毛绒玩具，也可以是一顶帽子)。
用户故事开卡(Story kick-off)：在每个用户故事开发之前，要确保BA、DEV和QA对用户故事理解一致。这个沟通活动通常表现为由DEV讲解这个用户故事要完成的功能及AC，一旦发现任何疏漏，BA及时补充。DEV有任何疑惑也需及时提出来，当场确认，使这些功能得以正确实现。在后续开发中如果碰到任何疑惑，也应及时找BA了解清楚。QA会严格按照AC来验收用户故事。
代码审查和回顾
代码审查(Code Review) 开发团队在完成每天代码之后，会聚在一起评审当天的代码，这样做有几个好处：
团队经过一天高强度的思考与编码，适当地停下来，看看其他人写的代码，同时将自己的代码讲解出来，往往能获得一些意外的灵感，或许能解决自己面临的阻碍；
互相了解设计思路，获得更好的建议和进行思路重构，提高代码质量；
及早发现潜在缺陷，降低事故成本：如果这个时候发现代码的坏味道和一些需要改进的地方，代码审查结束后可以花少量时间作出更改；
促进团队内部的知识共享。
回顾(Retrospective)：回顾会议的目的是通过新的沟通形式唤起大家对团队的集体意识，指出团队或个人在一段时间内的不足并列出对应行动。持续而有效的回顾和反馈，可以保证团队关心生产力和效率，了解自身的不足，这将成为团队持续改进的起点。
回顾的关注点也多种多样，除了“项目开发”之外，还可以关注“敏捷成熟度”、“团队角色和职责”、“人员技能提升”等。在坚持回顾的同时，需要做的还有保证回顾的有效性。应根据团队建设目标的发展变化，不断调整回顾的关注点和形式，确保回顾能够有针对性地发现团队的缺陷并转化为实践。长期有效的回顾和正确的回顾产出，还能够不断提升团队内部的安全感和信任度。
最大程度的可视化
看板源于精益生产实践，敏捷将其背后的可视化管理理念借鉴过来，形成了具有自己独特风格的可视化管理工具。
在敏捷项目里，挂在墙上的“人人可见的大图表”是一种普遍的实践，它被用来共享项目的状态并将之可视化。比如表示项目状态的物理墙，这样的物理墙通常包括三个元素：时间、任务和团队。
除了表示项目状态，项目团队还会可视化其他的元素，比如团队应坚持的规则、项目上的经验分享以及项目的里程碑。
一般来说，通过有关联的团队和个人之间相互协商，可以识别出未来一段时间里各自的活动，以及相应的、对成功的衡量方式，然后将其可视化出来，每段时间再回顾和调整一次。有了这样的可视化，团队会更加容易对齐目标，并不断培养和加深责任感。
可视化带来的好处是：
日常工作透明，将迭代过程中所有的故事卡可视化出来，团队成员可以随时知道当前需要完成的工作以及将要完成的工作。由于人对视觉反应更灵敏，可视化的故事墙能立刻聚焦团队的注意力。
将迭代过程中遇到的问题暴露出来，可以促进团队成员在工作中一起积极讨论解决方案。
团队也可以根据现在的进度以及遇到的问题，了解需要哪些帮助，更好的分配资源，减少开发进度被滞后的风险。
沟通计划
敏捷里面的自组织团队其实是敏捷的结果，而不是先决条件。实施敏捷的过程也是打造自组织团队的过程。每个团队成员在面对“做什么、怎么做”的问题时，也会以自组织的方式去解决。每一天，团队中的每一个人都要其他成员保持协调。为了保持同步，我们会创造基于敏捷实践的沟通机会，这个也是实施敏捷的过程之一。
通过集中式、互动式的设计工作坊，帮助客户在最短时间内对项目范围达成一致，快速进入项目交付。
产出沟通计划：比如在这个沟通计划中会讨论：以什么频率、什么形式作项目的更新，比如说每周五以周报的形式作一些主要信息的更新；站会和迭代会议什么时候召开，需要邀请哪些人，比如说业务负责人，技术负责人等等。
团队目标不一致
用电子墙和物理墙展示用户故事、需求全景图、项目进度燃尽图；通过迭代会议和功能演示会议对齐迭代计划，项目进度、识别项目风险。
团队成员不熟悉
基于敏捷实践，创造更多的沟通机会，比如回顾会议、代码审查和站立会议。通过不断地创造这样的沟通机会让团队成员更加默契。
信息发布不顺畅
共享信息，制定沟通计划；
最大程度的可视化。
五、总结
我们刚刚提到了很多类型的敏捷实践，这些实践需要贯穿到团队的日常活动中去，持续的实施和改进。这个过程其实是行为改变思想，再通过思想影响行为的过程，当团队中的人员能力慢慢提升，思想也在随之改变，所有人都能对什么是正确的事作出更好的判断，继而走向持续改进的道路。
行为心理学研究认为：21天以上的重复就会形成习惯。任何一个动作，重复21天就会变成习惯性的动作；任何一种想法，重复21天、或者重复验证21次，就会变成习惯性的思维方式；任何一种信念或者有益的实践，经过团队持续验证，它一定会成为团队的信念和实践。
（PS：有阅读ThoughtWorks洞见里面的博文，内容很棒，感谢分享）
写于2017年10月17日
Anne
关于敏捷开发
一学习心得 简单的说，敏捷开发是一种以人为核心、迭代、循序渐进、小步快走的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就... 查看详情
关于敏捷开发scrum
敏捷开发团队管理 本系列会专门从团队管理的角度，一方面将曾经提到过的内容加以贯穿，另一方面则会提及之外的一些未提及的内容，比如产品团队与开发团队的互动，测试团队与开发团队的关系与工作方式，等等，以供... 查看详情
关于企业推行敏捷文化的思考
问题的背景：在传统银行的软件中心，随着移动互联网的飞速发展，互联网公司给传统银行带了巨大的冲击，很多机会往往转瞬即逝，传统的开发方式难以适应互联网时代的飞速变化。传统银行开始引入敏捷的开发模型，试... 查看详情
关于敏捷开发的一些想法
一、积极。不用等待别人分配任务，在划分任务卡后，按个人实际能力及想法来领取任务，把个人主观能动性发挥至最强。虽然不可避免某些人偷奸耍滑，打鱼晒网，但至少最大程度上的避免了任务超出能力范畴而导致项目... 查看详情
关于敏捷开发，一个菜鸟程序猿有话说
关于敏捷开发，一个菜鸟程序猿有话说 离开学校，已经三年时间了，要说成功远远谈不上，勉强算的上一个合格的程序员，因为十分热爱IT行业，所以很想把工作三年来的一些工作心得与大家分享，希望对刚出道的小伙伴... 查看详情
关于rupxp及敏捷过程
什么是RUP？RUP即Rational统一过程（RationalUnifiedProcess），是一种完整且完美的软件过程。采用佚代开发，在开发过程中能允许在每次佚代过程中有变化的需求，能使用户可以不断的介入和提出反对意见，并且开发人员也因为随时有... 查看详情
软件开发模式之敏捷开发（scrum）
简介这几年关于敏捷开发在互联网企业中越来越广泛被使用到，运用的比较多的当属scrum敏捷开发和xp敏捷开发，人人都在谈论敏捷开发。那什么才是敏捷开发呢？目录什么是敏捷开发？传统的开发模式和敏捷开发模式的对比？... 查看详情
谈谈敏捷开发
我对敏捷开发是源于10多年前看了一本关于迭代开发的书，从而对迭代开发有了一些兴趣。从那时开始有了迭代开发的概念。随着项目经验的增加迭代的重要性也越发觉得明显。随后进入了提倡敏捷开发的公司，被迫式的接触了... 查看详情
软件测试学习敏捷开发
...交付，快速失败，获得反馈，及早向客户提供商业价值，关于人员，协作和互动。敏捷是一种关于透明度，检查和适应的心态。但是，敏捷不包含任何角色，事件或工件。这是一种心态。例如，Scrum是敏捷伞下广泛使用的框架之... 查看详情
谈谈敏捷开发（转）
...179009.html#3762210 我对敏捷开发是源于10多年前看了一本关于迭代开发的书，从而对迭代开发有了一些兴趣。从那时开始有了迭代开发的概念。随着项目经验的增加迭代的重要性也越发觉得明显。随后进入了提倡敏捷开发的公司... 查看详情
关于敏捷测试
来这家公司一直是做敏捷迭代的，在这么长的时间，对敏捷也有一些初步的认识 一个完成的敏捷开发从需求确认到开发到整个迭代结束的一个周期，包括搜集需求，需求方的优先级评审（当然这些不需要我们测试参与），产... 查看详情
敏捷开发——杂记
...外，不得不感慨英语的地位。但前段时间发现一个网站，关于敏捷开发的，对于新手小白来说很值得看看。我暂时没有把网站分享给团队成员，想自己先悄悄学 查看详情
敏捷开发scm
...就是通过每次工作流程的循环实现业务价值的提升；那么关于迭代，其实是两个核心部分，一个时间，在scrum中每个迭代都是称之为一个sprint，即使冲刺的意思，scurm本身是棒球的一个术语，就是"争球"，我理解代表的是一场"比... 查看详情
敏捷软件开发vs传统软件开发
...下面本文就传统软件开发和敏捷软件开发的来探讨一下。关于传统软件开发在软件开发方法出现之前，人们普遍错误的认为开发软件只是编写程序。当时，软件开发活动个体化非常严重，编写程序随心所欲，过分追求编 查看详情
关于敏捷讨论的感想
两种过度讨论的确是必要的，很多时候，只有经过大家详细的讨论，集思广益，才能定出‘最优’的设计方案。但沟通有时也是毫无生产力的，尤其是当我们陷入了对实现细节的争论时。大连和武汉（我们公司的两个分部），在... 查看详情
敏捷软件开发的最佳资源
...读的与敏捷相关的热门文章。小规模Scrum指南Opensource.com关于小规模Scrum的指南（我曾参与合著）由六部分组成，为小型团队提供了关于如何将敏捷引入到他们的工作中的建议。在官方的Scrum指南的概述中，传统的Scrum框架推荐至... 查看详情
web开发敏捷之道-应用rails进行敏捷web开发(第三版)pdf
下载地址：网盘下载这是第一本关于RubyonRails的著作。全书主要内容分为两大部分。在“构建应用程序”部分中，读者将看到一个完整的“在线购书网站”示例。在演示的过程中，作者真实地再现了一个完整的迭代式开发过程，... 查看详情
敏捷1.3敏捷中的项目开发生命周期
...目管理理论中，都会提到一个项目生命周期的概念。关于生命周期其实很好理解，就是一个项目从诞生到消亡的整个过程，在这个过程中，一般会有几个重要的节点是我们需要特别关注的。比如说，我们的人... 查看详情