敏捷研发（Scrum）
敏捷研发
- 什么是敏捷研发？
敏捷开发（AD：Agile Development ）以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷的构成：敏捷=理念+优秀实践+具体应用
- 敏捷宣言
1）个体和交互胜过过程和工具。
是软件开发中最重要的因素。开发团队成员之间有效的交流、沟通与协作，比单纯的编程能力更为重要。人与人面对面的交流，是最有效、最迅速的交换信息的方式。
2）可以工作的软件胜过面面具到的文档。
过多的文档需要开发人员花费大量时间来维护。文档应该是为程序服务的，因此应当短小精悍、易于维护，而且主题突出。敏捷方法认为最根本的文档就是源码。
3）客户合作胜过合同谈判。
客户对产品的需求是不断变化的，试图在合同中规定项目的细节和进度显然无法应对不断变化的需求。只有开发团队和客户之间真诚的协作，加上及时的与客户交流反馈，才能让项目走向成功。
4）响应变化胜过遵循计划。
客户的需求可能在项目开发过程中不断变化，即使是在合同谈判阶段确定的需求，也可能在客户看见了逐渐成型的产品之后而发生改变。敏捷方法欢迎并且随时准备应对变化。制定计划的时候应该尽量简洁、灵活，使其能适应技术和需求方面的变化。可以说，随时响应变化的能力往往决定着一个项目的成败。
并不是右边的不重要，只是相比而言左边的更重要。在敏捷研发中，左右两边的内容都是相当重要的。
- 敏捷原则
1）我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2）欢迎需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3）经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4）业务人员和开发人员必须相互合作，项目中的每一天都不例外。
Business people and developers must work together daily throughout the project.
5）激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6）不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7）可工作的软件是进度的首要度量标准。
Working software is the primary measure of progress.
8）敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9）坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
Continuous attention to technical excellence and good design enhances agility.
10）以简洁为本，它是极力减少不必要工作量的艺术。
Simplicity--the art of maximizing the amount of work not done--is essential.
11）最好的架构、需求和设计出自自组织团队。
The best architectures, requirements, and designs emerge from self-organizing teams.
12）团队定期地反思如何能提高成效，并依此调整自身的举止表现。
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- 敏捷理念
Value：聚焦客户价值，消除浪费
Team：激发团队潜能，加强协作
Adapting：不能断调整以适应变化
- 敏捷实践
1）IPM(Iteration Plan Meeting)迭代计划会议主要是跟客户保持沟通与信息更新的一个会议。
2）Regular catch up with client跟客户建立信任关系是合作的基础，而让客户保持愉悦，也是项目成功交付的助推剂。
3）Standup是一项成本小收益大的活动，做好它是敏捷的第一步。
4）Story kick-off在一个Story开始前，确保BA, QA, DEV等职能对Story的理解达成一致，并严格按照AC来验收。当然，前提是Story本身是不容置疑的。
5）Pair结对编程的开发速度通常小于简单地将一个人的开发速度乘以2，但它依然能创造价值：知识的共享，代码质量的提高，缺陷率的降低。
6）TDD，测试驱动开发，这项人人都称赞、却很少有人真的去做的活动，不应该只是一个被供奉起来的神。接地气，再接地气一点。
7）Code Review不可否认的一个事实：人人都爱整洁的代码。而一个人单独编码难免会耍一些小聪明，或引入一些自身习惯难以察觉的不良代码。Code Review能让你提高警惕，并改善代码的质量。
8）Showcase不管客户有多忙，也要定期让客户确认自己的期望是否得到满足。在签订合同前，要跟客户达成一致：Showcase的地位不可动摇。
9）CI持续集成.没有CI的项目开发是在耍流氓。CI在Agile中是一项最基础的设施，它通过自动化来提供有效的反馈机制以及高效的部署，大大降低代了码集成和项目交付的风险。
10）Retro即Retrospective的简写，即回顾。团队专注于交付目标，埋头干活的同时，也要懂得停下来总结过去，并更好地抬头看路。
以上仅仅是敏捷实践中的一种，敏捷的实践是多种多样（如极限编程XP、FDD、DDD等等）。
- SCRUM
- 什么是Scrum？
Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程敏捷框架的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。Scrum 是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程。
而Scrum就是这样的一个敏捷框架，运用该框架，你就能看到你团队高效的工作。（敏捷实践中最流行的实践之一）
- Scrum中的角色
Scrum Master（SM）
保护团队不受外界干扰，是团队的领导者及推进者，负责提升 Scrum 团队的工作效率，控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化，他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念。
PS：Scrum Master是Scrum 团队中的贡献者，一般是由Scrum 团队成员担任（专职的Scrum Master比较少，专职的一般是会在敏捷转型初期设立，为了更好的进行敏捷过度）；Scrum团队中任何一个成员都可以担任Scrum Master的，个人建议有比较丰富敏捷经验的研发leader或者架构师担任，不建议项目负责人或项目经理担任Scrum Master。
Team（ST）——由开发人员、测试人员、美工设计、DBA等软件研发流程中各职能人员组成
团队负责交付产品并对其质量负责，团队与所有提出产品需求的人一起工作，包括客户和最终用户，并共同创建 Product Backlog 。团队按照大家的共识来创建功能设计、测试 Backlog 条目交付产品。
PS：软件的实现者，Team运作的好坏直接关系软件产出的质量。Team是具有软件交付能力的特性团队（Team中必须包含开发人员，但不一定包含测试人员、美工设计、DBA、BA\SA等其他职能人员）。对于Team中人员职能类别越多，软件可交付的范围越大、整体管理协调的难度越大；同时Team中人员整体软件水平越高，出现高品质软件的机会也就越大，整体管理协调难度会越小。
Product Owner
从业务角度驱动项目，传播产品的明确愿景，并定义其主要特性。Product Owner 的主要职责是确保团队只开发对于最重要的 Backlog 条目，在 Sprint 中帮助团队完成自己的工作，不干扰团队成员，并迅速提供团队需要的所有信息。
PS：Product Owner是Scrum团队的决策者，它定义整体软件产品的内容及发展方向。一般是由产品负责人、产品经理、运营人员，部分情况由BA\SA担任。
以下个人不建议归纳为角色，下面更像是人员组：
User——最终用户、运营人员、系统使用人员等
很多人都可能成为最终用户，比如市场部人员、真正的最终用户、最好的领域专家，也可能是因其专业知识而被雇佣的资讯顾问。最终用户会根据自己的业务知识定义产品，并告知团队自己的期望，提出请求。
PS:软件的主要受众群体，需求的主要来源。
Manager——管理层、投资人、项目经理
管理层要为 Scrum 团队搭建良好的环境，以确保团队能够出色工作，必要的时候，他们也会与 Scrum Master 一起重新组织结构和指导原则。
PS：组织内部管理者，做出的决定对团队来说影响都是巨大的，是团队的最需警惕和寻求支持的对象。
Customer
为 Scrum 团队提出产品需求的人，会与组织签订合同，以开发产品。一般来说，这些人是高级管理人员，负责从外部软件开发公司购买软件开发能力。在为内部产品的公司中，负责批准项目预算的人就是客户。
- 什么是Sprint
Sprint 本意为“冲刺”，指迭代周期，长度通常是一至六周（建议：迭代节奏保持在2周，刚接触敏捷的Scrum团队采用4周一个迭代，每月逐步递减，直至保持2周一个迭代）。
- Scrum中的产出物
- Product Backlog（PB）
Backlog 待开发项，积压的任务
产品 Backlog 是指产品待办事项的集合，其中事务有优先级判断，先处理优先级高的事项。包括了所有需要交付的内容，其内容根据业务需求的价值顺序排列，每个 Backlog 的优先级是可以调整的，需求是可以增减的，因此产品 Backlog 将根据不断增长来持续驱动维护。
- Product Backlog Items （PBI）
Product Backlog Items 待开发需求的分组。
Product Backlog Items 更多的意义是在于规划，其内容根据业务需求的价值顺序排列；根据公司运作方式，将PB分解成PBI，规划给各个scrum执行或多个Sprint执行。
- Sprint Backlog（SB）
在 Sprint 开始前，定义本次 Sprint 要讨论的“Product Backlog Item”，从中产生本次 Sprint 要完成的 “ Product Backlog”。
Product Backlog是 Sprint 计划会议的产物，它定义了团队所接受的工作量，在整个 Sprint 过程中它将保持不变。
- User Story
1）User Story 来描述了对用户、系统或软件购买者有价值的功能。
2）用户故事通常按照如下的格式来表达：
英文：
As a <Role>, I want to <Activity>, so that <Business Value>.
中文：
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
3）用户故事的六个特性- INVEST
INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable
一个好的用户故事应该遵循INVEST原则。
独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量(这里是按2周的迭代周期计算制定的最大标准，建议一个用户故事的粒度在3人/天左右),至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。
具体用户故事相关内容可以 参考《用户故事地图》、《用户故事与敏捷方法》、《超越需求 敏捷思维模式下的分析》
- Task
Task 是每个用户故事实际需要做的任务。
为了能够及时，高效地完成每个 Story，Scrum 团队会把每个 Story 分解成若干个 Task。
- 障碍 Backlog
障碍 Backlog是问题列表，积压的待处理事务。
列举了所有团队内部和团队相关的和阻碍项目的进度的问题，Scrum Master 需要确保所有的障碍 Backlog 中的问题都已分配并可以得到解决。
- Scrum 工具
- 任务板（看板）
•任务板集合了选择好的 Product Backlog 和 Sprint Backlog，并以可视化方式展示。
•任务板只能由团队维护，使用不同颜色的“即时贴”来区分开发人员，或者在“即时贴”写上接受任务的姓名。
•尽量使用大白板，也可以使用软件。
任务板有4列：
•选择好的 Product Backlog：按照优先级，将团队在当前 Sprint 中要着手的 Product Backlog 条目或是故事放在该列中。
•待完成的任务：要完成一个故事，你得完成一些任务。在 Sprint 规划会议中，或是在进行当前 Sprint 中，收集所有特定 Backlog 条目需要完成的新任务，并将它们放入该列。
•进行中的工作：当团队成员开始某个任务后，他会将该任务对应的卡片放到“进行中的工作”列中。从上个每日 Scrum 例会开始，没有完成的任务都会放在该列中，并在上面做标记（通常是个红点）。如果某个任务在“待完成任务”列中所处时间超过一天，就尽量将该任务分为更小 的部分，然后把新任务放到那一列，移除其所属大任务卡片。如果一个新任务因为某个障碍无法完成，就会得到一个红点标记，Scrum Master 就会记下一个障碍。
•完成：当一个任务卡完成后，完成此任务的成员将其放入“完成”列，并开始选取下一张任务卡
- 燃尽图
•跟踪进度要由团队来完成，燃尽图的横轴表示整个Sprint 的总时间，纵轴表示 Sprint 中所有的任务，其单位可以是小时，人天等。一般来说，燃尽图有”Sprint燃尽图”和”Release燃尽图”之分。
•团队每天更新燃尽图。
•如果燃尽图一直是上升状态，或当 Sprint 进行一段时间之后，Sprint 燃尽图上的Y值仍然与 Sprint 刚开始时相差无几，就说明这个 Sprint 中的 Story 过多，要拿掉一些 Story 以保证这个 Sprint 能顺利完成。 如果Sprint 燃尽图下降得很快，例如 Sprint 刚过半时Y值已经接近0了，则说明这个 Sprint 分配的任务太少，还要多加一些任务进来。在 Sprint 计划会议上，如果团队对即将要做的任务理解和认识不充分，就很可能导致这两种情况的出现。（锻炼团队人员的自我估算时间）
•燃尽图要便于团队更新，没必要让它看起来很炫，也不要过于复杂，难以维护。
Release 燃尽图：记录整个Scurm项目的进度，它的横轴表示这个项目的所有Sprint， 纵轴表示各个Sprint开始前，尚未完成的工作，它的单位可以是个（Story 的数量），人天等。
- 规划扑克牌
规划扑克牌即“计划扑克”（Planning Poker）是一种标有一系列数字的扑克牌。用于敏捷开发的Scrum开发团队估计故事（Story）的故事点（Story Point）。
计划扑克玩法：
- 参加游戏的开发人每人各拿一叠扑克牌，牌上有不同的数字。
- 客户或者产品责任人为大家挑选 1 个 Story（Backlog），并简单解释其功能，以供大家讨论。
- 每个游戏参加者按自己的理解来估计完成这个 Story 所需的时间，从自己手中的牌里选 1 张合适数字的牌，并发展示给大家。
- 游戏参加者各自解释选择这个数字的原因，尤其是数字最大和最小的人。
- 根据每个游戏参加者的解释，重新估计时间并再次出牌，直到大家的估计值比较平均为止。
- 通用会议规则
1）基本要求
•每次会议都要准时开始、准时结束。
•每次会议都采取开放形式，所有人都可以参加。（这是敏捷开放的体现。由于国情及文化等原因，暂时无法达到面向所有人的，建议采用邀请的形式）
2）会前准备
•提前邀请所有必须参会的人，让他们有时间准备。
•发送带有会议目标和意图的会议纲要。
•预订会议所需的全部资源：房间、投影仪、挂图、主持设备，以及此会议需要的其他东西。
•会前24小时发送提醒。
•声明会议纪律
3）会议推进
•展开讨论时，会议的推进人必须在场。他不能参与到具体讨论中，但是他需要注意讨论进程，如果讨论参与者失去重点，他还要将讨论带回正规。
•推进人展示会议的目标和意图。
•有必要时，推进人可以商定由某个撰写会议记录（速记，会议结束时发送）。
•推进人可以记录团队的意见，或是教授团队如何自己记录文档；而且推进人可能会在挂图上进行记录，将对话可视化。
•推进人会对会议进行收尾，并进行非常简短的回顾。
4）会议输出
•使用手写或挂图说明来记录文档，给白板和挂图上的内容拍照。
•必须传达会议记录和大家对会议结果的明确共同认知。
- 团队建设
•Scrum 团队最佳人数控制在“5～9”人。
•特性团队（全职）：开发组（后台开发、前端开发、测试人员——3~8人）、Scrum Master、产品负责人
•兼职团队成员：BA\SA、美工、DBA、运维等
PS：具体团队建设全职和兼职中包含哪些职能，一般都是比较灵活的，但整个Scrum 团队必须保证在5—9 人之间，全职团队必须包含产品及开发人员。
让团队坐在一起！（重点！重点！重点！）
•大家都懒的动，尽量让“产品负责人”和“开发组”都坐在一起！
•互相听到：所有人都可以彼此交谈，不必大声喊，不必离开座位。
•互相看到：所有人都可以看到彼此，都能看到任务板（kanban）——不用非得近到可以看清楚内容，但至少可以看到个大概。
•隔离：如果你们整个团队突然站起来，自发形成一个激烈的设计讨论，团队外的任何人都不会被打扰到，反之亦然。
- 敏捷的重要会议
- 产品计划会（Product Planning Meeting）--非必要
Scrum 框架上并没有相应会议定义，个人认为在产品纳入sping前很有必要开这个会议，特别是体量庞大的产品。
会议目的
•产品代码研发前的动员，宣讲产品理念、产品业务规划。
•Product Backlog 拆解、形成Product Backlog Items。
• Release Planning ，规划发布计划
• 规划人员安排
会议输出
•Product Backlog Items
•发布计划
•规划迭代团队投入量
基本要求
•成员：Scrum Master、项目经理、客户、manager、
•无法出席的团队成员要由同伴代表。
•持续时间：根据产品体量而定，建议控制在2小时以内;在sping开始前
•举办地点：最好是宽敞的会议室。
- 每日立会（Daily Standup Meeting）
会议目的
•团队在会议中作计划，协调其每日活动，还可以报告和讨论遇到的障碍。
•任务板能够帮助团队聚焦于每日活动之上，要在这个时候更新任务板和燃尽图。
构成部分
•任务板、即时贴、马克笔
•提示：ScrumMaster 不要站在团队前面或是任务板旁边，不要营造类似于师生教学的气氛。
基本要求
•成员：团队、Scrum Master
•持续时间/举办地点：每天5~~15分钟，同样时间，同样地点。
PS：站会没有限定在一天中的什么时候开，个人建议在早上开，这样能更好安排协助解决问题。对于移动看板人任务贴纸，个人认为每个成员都应该养成做完任务及时移动任务贴纸。
会议输出
•团队彼此明确知道各自的工作，最新的工作进度图。
•得到最新的“障碍 Backlog”
•得到最新的“Sprint Backlog”
会议过程
•团队聚在看板旁边，面向看板、可以围成环形。
•从一方开始，谁拿到马克笔，谁向团队伙伴发言。
•然后该成员领取或调整任务板（看板）上的任务到正确的列中。(应培养团队人员完成任务后，自觉移动任务的习惯)
•如果该成员遇到问题或障碍，就要将其报告给 Scrum Master。
•每个团队成员重复步骤2到步骤5。
每个人三个问题：
•上次会议时的任务哪些已经完成？：把任务从“正在处理”状态转为“已完成”状态。——今天完成了什么？
•下次会议之前，你计划完成什么任务？：如果任务状态为“待处理”，转为“正在处理”状态。如果任务不在 Sprint Backlog 上，则添加这个任务。如果任务不能在一天成，把这任务细分成多个任务。如果任务可以在一天内完成，把任务状态设为“正在处理”。如果任务状态已经是“正在 处理”，询问是否存在阻碍任务完成得问题。——明天做什么？
•有什么问题阻碍了你的开发？：如果有阻碍你的开发进度的问题，把该障碍加入到障碍 Backlog中。——今天遇到了什么问题？
PS上面三个问题 中的 会议 指的是 每日站会
注意事项
•不要迟到
•不要超出限制时间
•不要讨论技术问题
•不要转变会议话题
•不要在没有准备的情况下参加
•Scrum Master 不要替团队成员移动任务卡片，不要替团队更新燃尽图。
•Scrum Master 不要提出问题，团队成员不要向 Scrum Master 或管理层人员报告。
•如果不能出席会议，需要通知团队，并告知站会需要说的内容。
- Sprint规划会议（Sprint planning meeting）
Sprint规划会议——第一部分（上午）
会议目的
•该会议的工作以分析为主，目的是要详细理解最终用户到底要什么，产品开发团队可以从该会议中详细了解最终用户的真实需要。在会议的结束，团队将会决定他们能够交付哪些东西。
•产品负责人在会前准备：条目化的需求（用户故事），优先级排序，最近1~2个迭代最希望看到的功能。会前准备至关重要，可帮助产品负责人理清头绪，不至于在迭代期内频繁提出变更、增加或删除故事。
基本要求
•迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。
•只有团队成员才能决定团队在当前 Sprint 中能够领取多少个 Backlog 条目的工作。
构成部分：
•经过估算和排序的 Product Backlog。
•挂图、马克笔、剪刀、胶水、即时贴、白板、铅笔和蜡笔。
•假期计划表、重要人员的详细联系信息。
•参会成员：团队成员、Scrum Master、产品负责人
持续时间：在 Sprint 中，每周该会议占用时间为 60 分钟，在早上召开该会议，这样还有可能在同一天召开 Sprint 规划会议的第二部分。
会议输出
•选择好的 Product Backlog 条目。
•各个 Backlog 条目的需求。
•各个 Backlog 条目的用户验收测试。
会议过程
•从第一个 Product Backlog 条目（故事）开始。
•讨论该 Product Backlog 条目，以深入理解。
•分析、明确用户验收测试。
•找到非功能性需求（性能、稳定性...）
•找到验收条件。
•弄清楚需要“完成”到何种水平。
•获得 Backlog 条目各个方面的清晰了解。
•绘制出所需交付物的相关图表，包括流程图、UML图、手绘草图、屏幕 UI 设计等。
•回到步骤1，选取下一个 Backlog 条目。
流程检查：询问团队能否快速回答下列问题，只需要简要回答即可：“我们能在这个 Sprint 中完成第一个 Backlog 条目吗？”如果能得到肯定的回答，那么继续询问下一个 Backlog 条目，一直到已经分析完的最后一个 Backlog 条目。——接下来，休息一下。在休息后，对下一个 Backlog 条目展开上述流程。
结束流程：
•在 Sprint 规划会议第一部分结束前留出 20 分钟。
•再次提问——这次要更加严肃、正式：“你们能否完成第一个 Backlog 条目，...第二个，...？”
•如果团队认为他们不能再接受更多的 Backlog 条目，那就停下来。
•现在是非常重要的一步：送走 Product Owner，除了团队和 Scrum Master 之外的所有人，都得离开。
•当其他人都离开后，再询问团队：“说真的——你们相信自己可以完成这个列表？”
•希望团队现在能短暂讨论一下，看看他们到底认为自己能完成多少工作。
•将结果与 Product Owner 和最终用户沟通。
注意事项：不要改变 Backlog 条目大小，不要估算任务。
Sprint规划会议——第二部分（下午）
会议目的
•该会议的工作以设计为主，产品开发团队可以为他们要实现的解决方案完成设计工作，在会议结束后，团队知道如何构建他们在当前 Sprint 中要开发的功能。
基本要求
•只有产品开发团队才能制定解决方案，架构师或其他团队之外的人只是受邀帮助团队。
构成部分：
•能够帮助团队在该 Sprint 中构建解决方案的人，比如厂商或是来自其他团队的人员。
•选择好的 Product Backlog 条目。
•挂图......
注意事项：不要估算任务，不要分配任务。
会议输出
•应用设计、架构设计图、相关图表
•确保团队知道应该如何完成任务！
会议过程
•从第一个 Backlog 条目开始。
•查看挂图，确定对于客户的需求理解正确。
•围绕该 Backlog 条目进行设计，并基于下列类似问题： •我们需要编写什么样的接口？
•我们需要创建什么样的架构？
•我们需要更新哪些表？
•我们需要更新或是编写哪些组件？
•......
当团队明确知道自己应该如何开发该功能后，就可以转向下一个 Backlog 条目了。在会议的最后 10 分钟，团队成员使用即时贴写出初步的任务。这能帮助团队成员知道接下来的工作从哪里开展，将这些任务放在任务板上。
持续时间：在 Sprint 规划会议第一部分完成后，召开该会议。可以将午餐作为两次会议的一个更长久的休息。但是要在同一天完成 Sprint 规划第一部分，在 Sprint 中，每周该会议占用时间为 60 分钟。
估算会议——根据项目情况合并到Sprint第二部分会议
会议目的
•要做好战略规划，你需要知道 Backlog 中各项的大小，这是版本规划的必要输入；如果想知道团队在一个 Sprint 中能够完成多少工作，这个数据也是必须的。
•团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。
基本要求
•只有团队才能作估算，Product Owner（产品负责人）需要在场，以帮助判定某些用户故事能否拆分为更小的故事。
构成部分：
•Product Owner 根据业务价值排定 Product Backlog 各项顺序。
•需要参加的人员：Team、Product Owner、User、Scrum Master
注意事项：
•不要估算工作量大小——只有团队能这么做。
•Product Owner 不参与估算。
会议过程
•Prodcut Owner 展示她希望得到估算的 Product Backlog 条目。
•团队使用规划扑克来估算 Backlog 条目。
•如果某个 Backlog 条目过大，需要放到下一个或是后续的 Sprint 中，团队就会将该大 Backlog 条目划分为较小的几个 Backlog 条目，并对新的 Backlog 条目使用规划扑克进行估算。
•重新估算 Backlog 中当前没有完成、但是可能会在接下来三个 Sprint 中要完成的条目。
持续时间：该会议时间限制为不超过90分钟。如果 Sprint 持续时间长于一周，那么每个 Sprint 举行两次估算会议比较合适。
会议输出
•经过估算的 Product Backlog。
•更小的 Backlog 条目。
扑克牌估算
具体步骤：
•每个人各自估算后独立出暗牌，听口令一起开牌。
•数值最大者与最小者PK，其他人旁听也可参考。
•讨论结束后重新出牌和开牌。
•重复上述过程，直到结果比较接近。
常见问题
1、为什么任务要分给组而不是个人？
答：因为怕出错了牌又说不出所以然，这样即使日后他不做这个功能，也对这个功能很了解。
2、为什么不让最后领任务的人自己估算？
答：因为他很可能因为不知道某代码可用、不知道某软件不行....而选择了错误的实现方法。
3、为什么不让师傅估算大家采纳，他不是最厉害吗？
答：师傅的想法常常是徒弟们理解不了的，比如为什么不留在女儿国而偏偏去西天取经之类的，共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程。
- Sprint评审会议（Review Meeting）
会议目的
•Scrum 团队在会议中向最终用户展示工作成果，团队成员希望得到反馈，并以之创建或变更 Backlog 条目。
基本要求
•Sprint 复审会议允许所有的参与者尝试由团队展示的新功能。
构成部分
•有可能发布的产品增量，由团队展示。
会议输出
•来自最终用户的反馈。
•障碍 Backlog 的输入。
•团队 Backlog 的输入。
•来自团队的反馈为 Product Backlog 产生输入。
持续时间：60分钟，在 Sprint 结束时进行。（持续时间应与迭代时长成正比；60x迭代周数，建议在30~120分钟之间，不宜过长或过短。）
会议过程
•Product Owner 欢迎大家来参加 Sprint 复审会议。
•Product Owner 提醒大家关于本次 Sprint 的目的：Sprint 目标、Scrum 团队在本次 Sprint 中选定要开发的故事。
•产品开发团队展示新功能，并让最终用户尝试新功能。
•Scrum Master 推进会议进程。
•最终用户的反馈将会由 Product Owner 和/或 Scrum Master 记录在案。
注意事项：
•不要展示不可能发布的产品增量。
•Scrum Master 不要负责展示结果。
•团队不要针对 Product Owner 展示。
- Sprint反思会议（Retrospective Meeting）
会议目的
•该会议的对应隐喻：医疗诊断！其目是：
检视当前这个 Sprint 中关于人、关系、过程和工具的情况如何；
找出并加以排序做得好的和潜在需要改进的主要方面;
制定改进 Scrum 团队工作方式的计划;
构成部分
•参与人员：团队成员、Scrum Master
基本要求
•从过去中学习，指导将来。
•改进团队的生产力。
注意事项
•不要让管理层人员参与会议。
•不要在团队之外讨论找到的东西。
会议输出
•障碍 Backlog 的输入。
•团队 Backlog 的输入。
持续时间：30分钟，在 Sprint 评审会议结束后几分钟开始。
会议过程
•准备一个写着“过去哪些做的不错？”的挂图。
•准备一个写着“哪些应该改进？”的挂图。
•绘制一条带有开始和结束日期的时间线。
•给每个团队成员发放一叠即时贴。
•开始回顾。
•做一个安全练习。
•收集事实：发放即时贴，用之构成一条时间线。每个团队成员（包括 Scrum Master）在每张即时贴上写上一个重要的事件。
•“过去哪些做的不错？”：采取收集事实同样的过程，不过这次要把即时贴放在准备好的挂图上。
•做一个分隔，以区分“过去哪些做的不错”和接下来要产出的东西。
•“哪些应该改进？”：像“过去哪些做的不错”那样进行。
•现在将即时贴分组：
•我们能做什么》团队 Backlog 的输入。
•哪些不在我们掌控之内？》障碍 Backlog 的输入。
•根据团队成员的意见对两个列表排序。
•将这两个列表作为下个 Sprint 的 Sprint 规划会议第一部分和 Sprint 规划会议第二部分的输入，并决定到时候要如何处理这些发现的信息。
- 对于敏捷及Scrum的思考
- 为什么Scrum不行？
《为什么Scrum 不行》作者陈皓在里面加入了自己的分析
Reason 1: Scrum的基石是相信人。创造一个安全的环境，这样每个人都能相互学习，相互直言。但是，这是不行的，这世上有很多人并不关心这些，而且政治和竞争到处都是，办公室里无小事，你和别人交心，你相信他们，最终受伤的你自己。你真的以为那里有空间让你可以去犯错，去冒险吗？
Reason 2: Scrum认为只要给员工足够多的自由员工就能做得最好。这该死的理论是基于什么玩意？不可能，人的天性是懒惰的，他们才不会把事做好的，他们只会做相应报酬的工作量，还可能基本甚至达不到其相应的报酬，大多数人都在混日子。尤其是和经理比起来，谁不想能尽快地成为经理或Team leader啊，因为那样他们就可以即不干活，又挣得多。另外，你给他们自由，你就会发现，他们会只会做他们感兴趣的事，要么聊QQ，要么打游戏，看闲书，反正不干正事。直到你催了，他们才动一动。
Reason 3: 因为前面的原因，所以，我们仍然要把一个PM放在Scrum团队的上面做管理，这样才会有产出。于是，PM给团队分配任何，管得细枝末节，事无巨细，天天让你做进度汇报，等等。直至把团队拖垮。
Reason 4:Scrum只不过是一个流程。这世上有太多的流程，尤其是那那些执行CMMI的公司。几乎所有玩CMMI流程的公司，你都能看到的是员工都是那一副副难看的脸。所以，Scrum的流程同样会这样。因为这些都不是开发团队自发出来的，而是上面管你喜欢不喜欢按给你的。Scrum根本不可能增进你的软件质量和技术，只能是优秀的人才才可能！使用Scrum的公司都是些吝啬鬼，他们不愿花大钱招优秀的人，他们妄图使用Scrum这种东西让现有的这些廉价劳动力发挥更大的生产效率，Scrum成了push程序员最有用的工具。
Reason 5:Scrum delivers ‘business value’。不是这样的，实际上，Scrum不可能。这有很多原因。真正了解业务的那帮人根本不可能加入项目团队，那些人谁TMD愿意和苦逼的技术人员加班啊。 那些人喜欢和我们的用户吃吃喝喝，花天酒地的，根本不会和你们那些奇怪的东西（如：backlog）或是那堆ugly的内向古怪的技术人员打交道，更别说什么技术了。所以，你的团队就像一个客服团队或救火队一样疲于奔命。
Reason 6: 一个敏捷的团队应该是持续进步的。这就是为什么Scrum总是在问什么干得好，什么需要改进，并定义行动方案。你真的以为员工想进步吗？让他们不得不去想想自己和团队怎么进步，然后他们还不得不去执行行动方案。别天真了，人的天性是不喜欢改变的，人的天性是习惯于一些按部就搬的事，也许那样做令人讨厌，但是人家还是能干点东西出来。如果你逼着人家改变，你就是在压迫人家，人家自然会反抗。
Reason 7:Product Owner专注于 ‘what’ 和 ‘why’ 的问题，开发团队决定 ‘how’。很不错的分工，于是可以造就一个即高速有重质量的团队。然而，这根本不行。你的Product Owner马上就想要这个功能，他才不管你的软件开发的技术难题，人家只要快，要你meet deadline，要你给我们重要的客户做出承诺。另外，你千万不要以为你们可以轰走这个初级的product owner，因为他的后台是直接汇报到高层管理。你作为一个程序员可能只是其个小部门的一个小喽啰，或者只是外包公司，你觉得可能吗？你觉得建立信任可能吗？
Reason 8: 软件质量和生产率成正比。也就是说，质量越高，生产率越高。如果质量不高，你开发效率就会低下，但是谁管呢？我们朝九晚五的上班，质量好了也是做8小时，质量差了也是做8小时，无所为嘛。另外，我们的project manager (或者是Scrum master!) 总是会批评我们没有按计划完成。所以，这根本不可能。
Reason 9: “是的，如果我们只做需要的功能，那么我们就会最低的成本，对吗？”，为什么这世上总是会有这些幼稚的人？这种事怎么可能啊。很多很多的银行或保险公司的项目在你还没有启动项目前就谈好了一个价格（可能还会有回扣），为了打单子，销售什么都干得出来，让你去做项目是因为你是廉价劳动力，而且，他们会不断地加需求，因为软件合同谈好的价格时候，连需求都没有，你去做了才有，还是模糊和不确定或根本就是错的，然后需求是越来越多，越改越多。等你精疲力尽的时候，你才意识到，销售早就把你卖了。
上述几点，很多确实是反映了中国软件研发的现状（不管是CMMI、敏捷或者其他模式）：软件生命周期内各个环节的人员各自为政，指标考核不切实际一塌糊涂，盲目追求利益，忽略软件质量……
大部份人认为scrum在中国人的性格特质下，更适合那些凝聚力比较高的、自我驱动能力比较强的、技术水平比较成熟的、具备有号召力的leader（作为组织者、评判者和关系协调者）、已经具备一定沟通条件的技术团队。那么中国哪些拥有高凝聚力、高驱动力、高协调力、高技术水平的团队多么？个人认为，数量是很多的，但比例很低。
那么是不是说我们不适合开展敏捷？
团队素质确实是软件生产能力的表现。高素质的团队不管应用何种模式，都能有比较高的产出。那么我们为什么应用敏捷、CMMI意义呢？直接建立高素质团队不就行了？
- 为什么要敏捷
敏捷要求那么高，Scrum在国内那么水土不服。就如同“没有人喜欢敏捷，但我们不得不敏捷。就像没有人喜欢工作，但你必须工作。”
试想一下，拿到一份完整详尽的需求文档，逐个功能Coding，测试部署上线。不需要再次确认需求，不会有人打断思路。没有需求更改，只要自己不犯错，不存在推倒重来这才是大部分开发人员最舒服的工作方式吧，简直太完美了。但它很像瀑布，一点都不敏捷。
既然我们喜欢的工作方式是传统的、瀑布的，为什么要敏捷？这还不都是市场环境逼的。今天的市场向我们提出了三个问题：
- 如何做出真正满足用户需求的产品？
我不确定这世上是否有人可以做到，他所做出的全部决定都是对的。但绝大多数人是无法一次性做出真正满足用户需求的产品的。我们无法预测未来，我们必须通过一次次的测试，去寻找用户需要的产品是什么？想要更快地获得好的产品，必须迅速将产品推向市场，快速试验，避免走弯路。
- 如何满足不断变化的用户需求？
今天所有的事情的都在快速变化，用户的需求也在变化。毫不夸张地说，我们正在全力开发的一些功能，当它们上线的时候，我们的用户已经不再需要了。我们没有办法让一切不变，我们只能选择去拥抱变化。
- 如何同时满足不同层次用户的需求？
过去我们的产品会遵循产品生命周期，早期追求新奇的尝鲜者，中期普通大众，后期落后者。今天，产品的生命周期变化非常地快，我们可能会同时面对尝鲜者、普通大众、落后者，不同的用户类型的需求是不一样的，你如何满足他们？我们必须快速响应，没法快速响应，就没法留住用户，没有用户就没有一切。
迅速将产品推向市场，拥抱变化、快速响应。今天的市场向所有的从业者提出了一个要求：拥有应对快速变化的需求的软件开发能力。而敏捷就是赋予团队应对快速变化的需求的软件开发能力的方法，而这就是敏捷流行的原因。
- 我们要怎么进行敏捷实践的
- 敏捷是一种信仰
相信信仰的力量，信仰的力量不可估量。若团队对敏捷都不认可，那么开展敏捷几乎就没有什么意义的，敏捷永远都开展不好。
- 信任
要相应敏捷团队的成员利益是一致。所有产出价值，都是团队创造的，自身应该相信团队成员都是为共同利益奋斗的。
- 拥抱变化
敏捷研发是一个渐近明晰的过程，产品需求会应各种因素不断的调整，故在没有明晰前研发任务是会不断的调整。团队应该要有应对调整的原则，团队成员应该积极响应变化。
- 明确
团队成员应形成团队的实践：团队成员应明白自己在敏捷整体流程中，应该明确在各个节点自己的任务和产出；团队应该要有明确的团队原则；团队成员应该对迭代目标有明确的认知。
- 团队素质提升
应注重团队的成员整体素质的提升，不仅仅是团队成员本身技能上的提升，更多是敏捷团队整体的素质提升（如团队成员间的沟通、协作、应变等）。应注重团队内部问题的消化、各职能成员的知识分享和总结、各领域技术的应用、团队资料的传承等等。
- 保护团队
减少对团队人员的干扰：团队成员尽量保持相应稳定，即使是团队成员调整，也应有相应的措施使团队成员互相融合，团队尽快恢复本身素质；各个环节减少干扰，保证各环节团队人员能有相对舒适的环境，以保证产出质量。
- 发挥团队成员的潜力
提倡团队成员在敏捷各个环节参与，发掘团队成员各个职能技术的潜力，给与团队成员跨职能工作的几乎；通过技术分享、应用，让团队成员在参与中有更多的认知。
只要做到由敏捷的理念出发，运用好各种优秀实践，充分结合自身团队情况，随着团队的提升，敏捷会越来越好。
敏捷研发（Scrum）相关推荐
- 互联网周刊2021云办公平台TOP50，leangoo领歌敏捷研发协作入选
这是leangoo领歌的创新优势和综合实力再次得到<互联网周刊>的高度认可,leangoo领歌2015年成立以来,用简单方式打通业务全流程,帮助团队更高效推进项目. 它基于高效协作与敏捷研 ...
- 【第四期】如何用Leangoo领歌快速搭建敏捷研发体系分享会
活动概要 为了助力企业更快地在企业内部搭建高效的敏捷研发体系,快速提升企业研发效能,加速商业价值交付,Leangoo推出了<Leangoo领歌敏捷开发指南>.本活动是围绕<Leang ...
- 【第三期】如何用Leangoo领歌快速搭建敏捷研发体系分享会
概要 为了助力企业更快地在企业内部搭建高效的敏捷研发体系,快速提升企业研发效能,加速商业价值交付,Leangoo推出了<Leangoo领歌敏捷开发指南>.本活动是围绕<Leangoo ...
- 如何用leangoo快速搭建敏捷研发体系分享会
概要 为了助力企业更快地在企业内部搭建高效的敏捷研发体系,快速提升企业研发效能,加速商业价值交付,Leangoo推出了<Leangoo领歌敏捷开发指南>.后期也会推出一系列线上使用指导活动 ...
- 首度揭秘：腾讯敏捷研发和极速交付破局之道
导读 腾讯到底是怎么进行敏捷研发和极速产品交付的呢? 腾讯研发管理部高级产品经理.敏捷教练张贺,受邀在DevOpsDays深圳站中进行了相关分享. 他从"道.法.术.器"四个方 ...
- 为效能而生，企业级敏捷研发管理工具PingCode正式发布！
当「小步快跑」的敏捷开发已成为国内互联网项目主流模式时,海外研发管理工具老牌军Jira集公有云版慢.私有部署贵.产品生态杂.长期维护成本高等弊端,无法良好满足本土需求,中国研发团队,亟需适应国内研发管 ...
- 《天天学敏捷：Scrum团队转型记》读书笔记
读书给人以快乐.给人以光彩.给人以才干. -- 培根 基本信息 作者:杨蕾,郑江著 推荐值:76.7% 微信读书:天天学敏捷:Scrum团队转型记 收获 & 思考 阅读目标:提前明确目标,有助 ...
- 方案详解 | 如何设计和打造敏捷研发组织
目录 为什么要敏捷研发组织 为什么研发转型很挑战 敏捷研发组织的6大关键要素 8大设计原则-敏捷研发组织的成功基础 领航者负责研发战略规划 价值放大者负责研发组合管理 方案交付者负责产品开发 系统整合 ...
- TechExcel混合敏捷研发培训在伦敦举办
Lafayette,Calif. – 2013年11月22日,业内领先的应用生命管理(ALM)解决方案提供商TechExcel举办的"混合敏捷研发培训"在英国伦敦拉开帷幕,此次培训 ...
最新文章
- linux文件属性解析,Linux操作系统的文件属性与目录配置解析
- 多面体体积 matlab,matlab计算多面体体积实现代码
- 幂等问题 vs 如何判断是否是4的幂
- ubuntu 开机黑屏
- 乐视网回击贾跃亭：债务处理没有进展，先拿出57亿再说
- CentOS网络设置 couldn‘t resolve host ‘mirrorlist.centos.org问题解决
- bzoj 1295: [SCOI2009]最长距离（SPFA）
- 协同过滤算法_利用数据分析量化协同过滤算法的两大常见难题
- ajax验证作用,通过正则表达式使用ajax检验注册信息功能
- 儿童计算机编程课程,少儿编程基础课程介绍
- QOpenGLWidget显示图片
- 多级分类查询解决方案
- thinkpadX1C2021充不进去电(去除静电后依旧无效的来看看)
- vue调用手机浏览器打开pdf_在微信中调用外部浏览器实现文件下载之解决
- 手机测试wifi的延迟的软件,六款最佳、免费的网络延迟测试工具
- 黑色星期五移动购物销售额iOS设备占逾80%
- 二极管的三种击穿形式
- Linux下载安装Netcat
- Windows系统下R语言环境搭建及高级图表绘制
- 7.26 2第5篇 无人驾驶带来巨大商机