敏捷开发及scrum
一、敏捷开发
软件市场发展越来越迅速和成熟，传统瀑布式开发模式存在一定的限制，敏捷从而有了更广阔的的平台与机遇。Scrum作为在敏捷中使用最常用的一种方案，受到众多的关注。
1.1、为什么使用敏捷方法
敏捷管理是相对于传统的瀑布模型提出的，传统的瀑布开发模式是这样的：
瀑布开发模式的项目周期往往比较长，一般为3-6个月，甚至更长时间，当项目开发完成后，最后交付成果往往不是产品经理或是客户真正想要的，最后只能重新从项目的需求开始，经过一系列的建设、测试、部署等过程，那样的话，项目周期就会更长，然而又需要尽快投入市场，最后只能是稍微改动一下，差不多接近项目需求就行。
使用瀑布开发模式很容易出现这样的结果，开发周期很长，不可控的因素和风险很大，最终会偏离最初想法。
而敏捷开发流程是这样的：
每一个迭代的开发周期很短，一般为1-4周，它将瀑布开发过程切分为多个短的迭代式的增量开发过程。每一个迭代结束，都会产生最终可用的产品，如果需求有变化，可以在下一个迭代周期进行开发，基本不会出现最终交付产品是用户无法接受的，即使要浪费时间的话，最多就是一个迭代周期的时间。
定义：
理解：
首先，敏捷并不是一门具体的技术，而是一种理念或者说是一种思想。它可以指导我们更加高效的开发。
其次，敏捷开发都具有以下共同的特征：
1. 迭代式开发
2. 增量交付
3. 开发团队和用户反馈推动产品开发
4. 持续集成
5. 开发团队自我管理
最后，相比于“传统”的瀑布开发模式，敏捷开发是一种“现代”的开发模式。
具体方式：
上面说了敏捷是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而具体的开发方式有哪些呢？
Scrum，极限编程（XP），精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。
除了Scrum和XP，对于上面的其他开发方式，我也只是简单了解，大家可以多查查相关的资料。
我们可以简单的对比一下Scrum和XP：
1. 在开发的过程中，你可以采用Scrum方式也可以采用XP方式；
2. Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的。
敏捷宣言：
我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：
- 个体与交互 重于 过程和工具
- 可用的软件 重于 完备的文档
- 客户协作 重于 合同谈判
- 响应变化 重于 遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者
敏捷开发的12准则：
在敏捷开发中，我们遵循以下准则：
1. 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
3. 要不断交付可用的软件，周期从几周到几个月不等，且越短越好
4. 项目过程中，业务人员与开发人员必须在一起工作。
5. 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
6. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7. 可用的软件是衡量进度的主要指标。
8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
10. 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11. 最佳的架构、需求和设计出自于自组织的团队。
12. 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
二、Scrum
2.1 Scrum框架的概念
Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程.。在这个框架中，整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。
在Scrum中，使用Product Backlog来管理产品或项目的需求，product backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为User Story。
Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint中，Scrum开发团队从product Backlog中挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint Plan Meeting上的分析、讨论和估算得到一个Sprint的task列表，我们称它为Sprint backlog 。 在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。下图是Scrum的工作流程图。
2.2 Scrum框架的优势
1 专注于如何在最短的时间内实现最有价值的部分
2 每隔一两周或者一个月，我们就可以看到实实在在的可以上线的产品
3 团队按照商业价值的高低先完成高优先级的产品功能，并自主管理，凝结了团队智慧创造出最好的方法因而提高效率
4 能够在开发进程中不断检查，并作出相应调整，便于快速发现问题，促使团队和组织
2.3 Scrum框架概览
2.4 Scrum中的角色（主要PO/SM/TEAM）
Product Owner（PO）：产品负责人、产品经理、运营人员
职责：---确保Team做正确的事
项目经理更关注deadline（项目截至日期），并以公司为中心；而product owner则聚焦于产品，以最终用户为中心。
🔘清楚知道产品的愿景，分为近期和远期。
清楚愿景才不至于被干扰带偏道路，才可以清楚的区分重要紧急、重要不紧急、不重要紧急、不重要不紧急事件。我们可以集中精力于重要不紧急事件，这样就能减少重要紧急事件的发生。
🔘获取外界的诉求并进行整理成 User Story。
外界：用户、运营部门、其他业务方
User Story：需要实现的功能，以客户的角度，描述「我需要功能A，来达到我的什么目的」。
🔘对整理好的 User Story 所需要的资源进行各方协调并得出「是否可行、什么时候可行」的结论。
一个功能的实现，有时候牵涉各个业务系统，往往各个业务系统所对应的Team排期是不一样的，就需要提前进行沟通。尽最大努力避免在开发的过程中才发现问题，这时候才和其他业务系统沟通影响面就很大，其他业务系统人员很可能拒绝进行协助，业务紧急强行协助导致会打乱了其他团队的开发计划。
🔘根据产品的近期目标，对 User Story 进行优先级排序；期间有更好的 Idea 需要对 User Story 优化，这是一个持续的过程。
注意：Story 的优先级只能有一个1，一个2…一个10。不要把这些功能放得同等重要，这期都得全部实现，全部都是1，这样的做法就失去了优先级的意义。仔细的思考，斟酌，比如问自己「少了这个功能会有什么影响——公司会因此损失100万吗？公司会倒吗？」，有时候并没有想的那么紧急，只是先入为主的思想陷入了局限的泥潭失去了大局观。最后一定是能够得出一个唯一序列的优先级排序的。
🔘需求从外界到 PO 手里的时候，不应该一味地紧缩一线开发人员的时间。PO 的责任不能仅仅是满足外界的诉求，还应该考虑 Team 人员的工作状态和情绪，他们可是实现你「蓝图」的一线人员。（公司所有人都致力于目前公司的蓝图，PO 正是在推动着这张大蓝图中的某个模块。）因此 PO 应该全面考虑团队的目前状态，有时督促团队全速前进，有时应该是 Team 的保护伞，这些都是为了实现公司蓝图更好、更快的前行。
🔘初步决定 Team 每个 Sprint 要完成哪些 Story 任务。
这里只能是初步决定，精确的结果需要在下面的 Plan Metting 中 Team 对其进行时间评估，最后根据该个 Sprint 的任务饱和度，进行 Story 的裁剪或增加。有许多情况并非如此，「这个 Sprint 整理的所有的需求都要实现」，没有考虑过公司现在 Team 所配备的资源情况和完成能力才会有这样的决定，这也往往导致了产品——开发之间的诸多矛盾。心理活动，产品：「这么简单的功能都完成不了」，开发：「你行你来呀」。诸多时候我们以 5000 多年以来的人文素养平息了这场风波，妥协的结果就是质量堪忧甚至完不成任务。
🔘在一个 Sprint 开始后结束前，如果有紧急需求进入，需要站出来保护团队，因为往往很多需求都是认为很紧急而已。
尽量避免 Team 受外界影响，这时候插入紧急需要往往会打乱开发节奏，从而引发各种问题和风险。这个「紧急」需求，如果经过讨论和仔细分析后，大家得出的结论还是是紧急并重要的话，那么这个需求形成的 Story 就需要插入此次 Sprint，优先级列表在这个时候就起作用了，可以在此次 Sprint 的优先级列表中移除一些低优先级 Story。
Scrum Master（SM）：项目负责人、项目经理，敏捷教练，敏捷大师
职责：---确保Team正确地做事
🔘协助 Product Owner 整理需求。
开发是最熟悉每个业务流程以及可能的牵涉方的，要完成列表中的 Story，需要协调哪些资源，以及协助评估现在的资源能否顺利完成这些 Story。
🔘作为 Scrum Team 的带头人，需要确保团队的合理运作，清除 Sprint 开发中的障碍，引导 Team 高效的完成每日工作。
🔘组织团队工作，sprint planning meeting、daily standupo meeting、sprint review、retrospective meeting 组织各项会议的开展（该四个会议在5个活动中会详细介绍）。
🔘帮助大家接收敏捷的理念，推动团队按照敏捷价值观和原则所倡导的方法做出决策。
不要过高估团队的适应能力，当然也不要过低评估团队的适应能力。推行敏捷定是一个长期的过程，Team 人员有着不同的工作经历，不同的公司不同的文化背景，以及现在公司的企业文化影响，推行一套理念都需要专注于明确的目标（Focus）、反馈（Feedback）、纠正（Fix）——简称为3F原则，然后依此循环，长期的反复的过程。
🔘尽量保证团队在每个Sprint中不被打扰。
如果发现有发现影响团队工作的任务来临，要敢于说「NO」，如果确实是重要紧急的需求，而该 Sprint 工作量已经饱和情况，就有必要协商移除之前优先级最低开始的User Story，以保证工作的顺利进行。
ScrumMaster的职责简单的说可以总结为：
确保Team按照Scrum的方式运行。
Team的Coach，帮助team更好的工作。
Process的Owner，能够在team和PO之间平衡。
移除项目进度的障碍，保护团队成员不被过度Commit等。
具体的来说，ScrumMaster的职责到底是什么呢？
1. ScrumMaster的首要职责就是教练，对该怎么踢负责的教练，不是为进几个球负责的教练。
TA帮助PO和团队理解如何应用Scrum开发方式工作。
比如PO如何梳理产品列表、团队如何做故事点的估算、Scrum的5个活动（迭代计划会、迭代回顾会、迭代评审会、每日站会、需求梳理会）该怎么做。
TA是过程上的权威。
工作是否做的下来，TA说不上话，但是工作该如何遵守Scrum的流程，ScrumMaster说了算。
ScrumMaster是教练，并且还是服务型的教练。
TA并不去要求团队们要做到什么（注意我是说的做到什么，而不是依照什么流程做）。TA应该去问团队，我怎样能帮助团队工作得更有效。
2. ScrumMaster要充当团队的保护伞。
TA要代表团队给管理层汇报，TA也会有原则的把管理层的信息传达到团队。
确保团队能集中精力完成冲刺。
经理对团队成员安排额外任务时候，PO想给团队增加Sprint Backlog的时候，ScrumMaster都会充当保护伞，有原则的把这些干扰屏蔽在团队之外。
3. ScrumMaster是清除障碍的人。
TA要确保创造Team能够顺利工作的条件，扫除各种障碍。
比如团队对外部的硬件或者软件依赖；需要其他团队的支持；需要工具的支持等。
4. ScrumMaster是沟通连接的桥梁。
经常说TA是牧羊犬。牧羊犬的作用一是让羊有秩序的行进，不能掉队。牧羊犬还有另一个作用不是和狼打架，通常也是打不赢的，这个作用是叫，如果遇到狼，大叫把人类叫过来打狼。在这点上，ScrumMaster就是团队的代言人，团队遇到问题，ScrumMaster要负责大部分的对外沟通工作。
5. ScrumMaster是变革代言人。
TA要促成组织内部人员转变思维，迎接敏捷开发方式。
TA需要见多识广，引入变革改变组织，让组织运行更加高效。
比如，改变项目经理过去安排任务的习惯；改变团队成员等着分配任务习惯；引进新的测试工具；推进更多的敏捷实践到团队，比如TDD。
ScrumMaster是没有被授予实实在在权利的角色。
这些变革的推动，更多的是靠TA的沟通技巧，比如探索式提问；耐心引导，让团队发现问题；勇敢对外部不合理的安排说不；等等这都对ScrumMaster提出更高的要求。TA是一个服务型的Leader。
职责：---负责产品需求实现
🔘学习和使用敏捷的理念，反馈工作或流程中存在的问题，甚至提出解决方案。
🔘积极去推动任务的进展，提高自我执行力。
🔘高效的沟通，尽量避免通过第三方传达的沟通方式。
🔘高质量的完成 Sprint 开发需求，按期交付。
User——最终用户、运营人员、系统使用人员
很多人都可能成为最终用户，比如市场部人员、真正的最终用户、最好的领域专家，也可能是因其专业知识而被雇佣的资讯顾问。最终用户会根据自己的业务知识定义产品，并告知团队自己的期望，提出请求。
Manager——管理层、投资人
管理层要为 Scrum 团队搭建良好的环境，以确保团队能够出色工作，必要的时候，他们也会与 Scrum Master 一起重新组织结构和指导原则。
Customer——客户、系统使用人员、运营人员
客户是为 Scrum 团队提出产品需求的人，她会与组织签订合同，以开发产品。一般来说，这些人是组织中的高级管理人员，负责从外部软件开发公司购买软件开发能力。在为内部产品的公司中，负责批准项目预算的人就是客户。
2.5 Scrum中的产出物
Product Backlog——Backlog 待开发项，积压的任务。
产品 Backlog 包括了所有需要交付的内容，其内容根据业务需求的价值顺序排列，每个 Backlog 的优先级是可以调整的，需求是可以增减的，因此产品 Backlog 将根据不断增长来持续驱动维护。
Sprint Backlog——Sprint 本意为“冲刺”，指迭代周期，长度通常是一至六周。
在 Sprint 开始前，定义本次 Sprint 要讨论的“Sprint Backlog”，从中产生本次 Sprint 要完成的 “已定 Product Backlog”。
已定 Product Backlog是 Sprint 计划会议的产物，它定义了团队所接受的工作量，在整个 Sprint 过程中它将保持不变。
Burndown chart——燃尽图
燃尽图直观的反映了Sprint过程中，剩余的工作量情况，Y轴表示剩余的工作，X轴表示Sprint的时间。随着时间的消耗工作量逐渐减少，在开始的时候，由于估算上的误差或者遗漏工作量有可能呈上升态势。
User Story、Task——用户故事、任务
用 User Story 来描述 Sprint Backlog 里的项目，User Story 是从用户的角度对系统的某个功能模块所作的简短描述。一个 User Story 描述了项目中的一个小功能，以及这个功能完成之后将会产生什么效果，或者说能为客户创造什么价值。一个 User Story 的大小和复杂度应该以能在一个 Sprint 中完成为宜。如果 User Story 太大，可能会导致对它的开发横跨几个 Sprint，此时就应该将这个 User Story 分解。为了能够及时，高效地完成每个 Story，Scrum 团队会把每个 Story 分解成若干个 Task。每个Task 的时间最好不要超过8小时，保证在1个工作日内完成，如果 Task 的时间超过了8个小时，就说明Task的划分有问题，需要特别注意。
障碍 Backlog——问题列表，积压的待处理事务。
列举了所有团队内部和团队相关的和阻碍项目的进度的问题，Scrum Master 需要确保所有的障碍 Backlog 中的问题都已分配并可以得到解决。
2.6 通用会议规则
基本要求
- 每次会议都要准时开始、准时结束。
- 每次会议都采取开放形式，所有人都可以参加。
会前准备
- 提前邀请所有必须参会的人，让他们有时间准备。
- 发送带有会议目标和意图的会议纲要。
- 预订会议所需的全部资源：房间、投影仪、挂图、主持设备，以及此会议需要的其他东西。
- 会前24小时发送提醒。
- 准备带有会议规则的挂图。
会议推进
- 展开讨论时，会议的推进人必须在场。他不能参与到具体讨论中，但是他需要注意讨论进程，如果讨论参与者失去重点，他还要将讨论带回正规。
- 推进人展示会议的目标和意图。
- 有必要时，推进人可以商定由某个撰写会议记录。
- 推进人可以记录团队的意见，或是教授团队如何自己记录文档；而且推进人可能会在挂图上进行记录，将对话可视化。
- 推进人会对会议进行收尾，并进行非常简短的回顾。
会议输出
- 使用手写或挂图说明来记录文档，给白板和挂图上的内容拍照。
- 必须传达会议记录和大家对会议结果的明确共同认知。
让团队坐在一起！
- 大家都懒的动，尽量让“产品负责人”和“全功能团队”都坐在一起！
- 互相听到：所有人都可以彼此交谈，不必大声喊，不必离开座位。
- 互相看到：所有人都可以看到彼此，都能看到任务板——不用非得近到可以看清楚内容，但至少可以看到个大概。
- 隔离：如果你们整个团队突然站起来，自发形成一个激烈的设计讨论，团队外的任何人都不会被打扰到，反之亦然。
团队建设
- Scrum 团队最佳人数控制在“5～9”人。
- 全职能性团队：开发组（后台开发、前端开发、测试人员——3~8人）、Scrum Master（项目经理）、产品负责人
- 兼职团队成员：美工、DBA、运维
2.7 四个会议
Sprint planning meeting（计划会）、Daily standup meeting（站会）、Sprint review（评审会）、Retrospective meeting（回顾会）
Sprint 计划会：确定本个Sprint需要完成的功能需求。
每日站会：每日站会时间不超过15分钟，主要围绕三个问题展开：我昨天完成了什么？我今天要做什么？我遇到了什么困难？
Sprint评审会：项目团队将已实现的项目结果进行演示，听取利益相关方的反馈，以便在下一个Sprint进行改进。
Sprint回顾会：对本个Sprint进行回顾，哪些是做的好的，哪里需要改进的，并对这些改进的点，提出改进措施，在下一个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 和最终用户沟通。
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、为什么不让师傅估算大家采纳，他不是最厉害吗？
答：师傅的想法常常是徒弟们理解不了的，比如为什么不留在女儿国而偏偏去西天取经之类的，共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程。
Daily standup meeting（站会）
每日站会，一般选在早上，15分钟左右。每个人讲述进展情况（昨天做了什么，今天准备做什么，遇到什么问题），遇到了 Block 的问题，需要 Scrum Master 出面来扫清障碍保证 Team 能够专注的完成任务。这样能够及时的暴露出开发过程遇到的问题，能够的有效的评估风险以及及时讨论解决方案。通过这样透明化的披露，可以将个人和他人的工作结合起来，会更好的考虑自己的工作是否会影响别人。通过每个人进展的汇报，整个 Team 随时可以了解到离完成我们的 Sprint 目标还有多远。
每个人主动在 To do（准备做）一栏中的选取今日要完成的任务放入 InProgress 一栏并且开工，第二天立会继续按此勾兑，同时将已完成的任务放入 Done（完成）一栏，遇到障碍的任务移入 Blocked。Blocked 项 Scrum Master 会负责跟踪，和扫除障碍。
Sprint review（评审会议）
在 Sprint 周期结束，需要进行一次评审会议，向 Product Owner 和利益相关方展示完成的功能。回答利益相关者的问题，并记录期望的更改。评审会议可以让其他人了解团队在做些什么，并得到反馈。
任务板
- 任务板集合了选择好的 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 的数量），人天等。
Sprint评审会议（Review Meeting）
会议目的
- Scrum 团队在会议中向最终用户展示工作成果，团队成员希望得到反馈，并以之创建或变更 Backlog 条目。
基本要求
- Sprint 复审会议允许所有的参与者尝试由团队展示的新功能。
构成部分
- 有可能发布的产品增量，由团队展示。
会议输出
- 来自最终用户的反馈。
- 障碍 Backlog 的输入。
- 团队 Backlog 的输入。
- 来自团队的反馈为 Product Backlog 产生输入。
持续时间：90分钟，在 Sprint 结束时进行。
会议过程
- Product Owner 欢迎大家来参加 Sprint 复审会议。
- Product Owner 提醒大家关于本次 Sprint 的目的：Sprint 目标、Scrum 团队在本次 Sprint 中选定要开发的故事。
- 产品开发团队展示新功能，并让最终用户尝试新功能。
- Scrum Master 推进会议进程。
- 最终用户的反馈将会由 Product Owner 和/或 Scrum Master 记录在案。
注意事项：
- 不要展示不可能发布的产品增量。
- Scrum Master 不要负责展示结果。
- 团队不要针对 Product Owner 展示。
Sprint反思会议（Retrospective Meeting）
会议目的
- 该会议的对应隐喻：医疗诊断！其目的不是为了找到治愈方案，而是要发现哪些方面需要改进。
构成部分
- 参与人员：团队成员、Scrum Master
基本要求
- 从过去中学习，指导将来。
- 改进团队的生产力。
注意事项
- 不要让管理层人员参与会议。
- 不要在团队之外讨论找到的东西。
会议输出
- 障碍 Backlog 的输入。
- 团队 Backlog 的输入。
持续时间：90分钟，在 Sprint 评审会议结束后几分钟开始。
会议过程
- 准备一个写着“过去哪些做的不错？”的挂图。
- 准备一个写着“哪些应该改进？”的挂图。
- 绘制一条带有开始和结束日期的时间线。
- 给每个团队成员发放一叠即时贴。
- 开始回顾。
- 做一个安全练习。
- 收集事实：发放即时贴，用之构成一条时间线。每个团队成员（包括 Scrum Master）在每张即时贴上写上一个重要的事件。
- “过去哪些做的不错？”：采取收集事实同样的过程，不过这次要把即时贴放在准备好的挂图上。
- 做一个分隔，以区分“过去哪些做的不错”和接下来要产出的东西。
- “哪些应该改进？”：像“过去哪些做的不错”那样进行。
- 现在将即时贴分组：
- 我们能做什么》团队 Backlog 的输入。
- 哪些不在我们掌控之内？》障碍 Backlog 的输入。
- 根据团队成员的意见对两个列表排序。
- 将这两个列表作为下个 Sprint 的 Sprint 规划会议第一部分和 Sprint 规划会议第二部分的输入，并决定到时候要如何处理这些发现的信息。
2.8 5个价值观
团队内在的灵魂
01 专注：
只专注于每个 Sprint 要完成的事情，团队和个人的能力和精力都是有限的，在有限的时间内专注于最有价值的事情，以取得好的结果。
02 勇气：
团队完成任务的过程中肯定都会遇到一些棘手问题的情况，要有勇气去挑战和面对。
03 公开：
Sprint 的进展，遇到的问题，阻碍都应该对所有人可视化，透明的。这样的团队才能彼此了解，彼此尊重，同时也能暴露问题。
04 承诺：
团队在 Sprint 开始的时候做出承诺，并在迭代中全力完成，达成功能交付。
05 尊重：
尊重各个团队以及团队的人员。不要越界（超出了自己的范畴）议论，「产品觉得这么简单的功能还要那么久才能完成」、「开发觉得 UI 怎么设计得这么 Low」、「UI 觉得这么简单的效果你们都做不出来」等，我们要相信他人能够在这个岗位上就有胜任的能力，要相信他的专业能力。
