何为敏捷开发？为什么要敏捷开发？...我们带着问题一起来看看吧
开始之前，浅问大家几个问题：
1、个体和交互 和 过程和工具 哪个效率高？
2、可以工作的软件 和 面面俱到的文档 哪个效率高？
3、客户合作 和 合同谈判 哪个效率高？
4、响应变化 和 遵循计划 哪个效率高？
其实就是左边这块和右边这块的比较，先保留自己的答案，待我们了解完敏捷开发之后，看看你的认知是否会发生改变。
一、为什么要采用敏捷开发?
1.1 传统开发模式的弊端（敏捷开发模式与瀑布模式的区别）
瀑布模型是由W.W.Royce在1970年提出的软件开发模型，是一种比较老的计算机软件开发模式，也是典型的预见性 的开发模式。 瀑布模型是一种项目分解为有限的阶段来开发软件的方法。只有在审查并验证其前一阶段时，开发才会应进入下一阶段。在瀑布模型中，阶段不重叠。要等上一阶段完成100%之后再进入下一阶段。 在这种方法中，事件的顺序是这样的:
- 可行性研究和计划
- 需求分析
- 设计
- 实现
- 测试
- 使用和维护
优势：
- 易于准备
使用瀑布式项目管理时，每个阶段都有非常具体的可交付成果和具体的审查过程。因为每个阶段都已经深思熟虑过，你总是知道下一秒要往哪里迈步，所以项目便很容易取得进展。 - 适用于小型、简单的项目
由于瀑布模型基于严格的、既定的步骤，因此它更适合管理具有固定可交付成果的简单项目。这些项目的可交付成果通常不会发生变化，你可以无缝衔接每个阶段。 - 易于使用
基于固定的项目管理原则，让瀑布式项目管理更易于理解和采用。你的团队不需花时间学习并适应它。
劣势 ：
- 不适合大型、灵活的项目
瀑布式项目管理是一种线性管理方式，因此它很难对某个部分的成果进行快速的客户验证。这可能会导致潜在的返工风险。 - 很难在项目过程中发生改变
当项目范围和项目需求非常明确不会改变时，瀑布式项目管理会非常有效。但当你的客户中途提出新的意见，或者需求不够明确，那么就只能回到第一阶段，重头再来。 - 测试过程的风险变高
在瀑布式项目管理中，测试只会在开发完成后开始，由于要等到整个项目开发完毕，因此在测试时可能会发现更多问题。在最严重的情况下，也可能会因为测试出太多问题，而不得不将整个项目推倒重来。
两种方式的区别
-
1、工作流程的差异
在瀑布式项目管理中，只有一个开发周期。你的项目不会分成多个 Sprint或迭代。当你确认客户的需求后，就可以启动整个项目的工作。
在敏捷项目管理中，将开发过程分为多个周期，在你进入下一个 Sprint 之前，每一个 Sprint 都需要完成，并获得客户的批准。
-
2、灵活性的差异
瀑布式项目管理的每个阶段过程都是在开始时精心策划的，非常严格，因此它不能处理不断变化的客户需求，更不能随着项目的推进而拓展。
敏捷项目管理将项目拆分为多个开发周期，由于你不是一次性完成整个项目，因此你在研发过程中可以有多次机会将用户的反馈应用于接下来的开发中。
-
3、测试过程的差异
在瀑布式项目管理中，你只需要在整个开发工作完成后测试产品，这虽然可以让你在不受干扰的情况下开发产品，但最终也可能会导致大规模的问题。
在敏捷项目管理中，每个 Sprint 后都会对项目进行审查和测试，这有助于你微调项目的细节，确保它始终都能满足客户的需求。
-
4、团队协作的差异
在瀑布式项目管理中，团队是一个非常结构化的单位，由项目经理把控整个流程。大多数团队成员都有明确的角色，各司其职做份内的事情。
在敏捷项目管理中，虽然有一个产品负责人和项目经理指导团队，但大多数团队成员都是自给自足并跨职能的，这使他们能快速适应项目变更。
-
5、客户参与的差异
在瀑布式项目管理中，你的客户只参与项目的早期阶段和项目的交付阶段，开发时干预较少。
在敏捷项目管理中，客户的意见将贯穿项目的始终。
如何做出满足用户需求的产品？
- 不断迭代、修改，极限逼近。
如何满足不断变化的用户需求？
- 需要快速应对变化 --> 对开发者的要求提高
and so on...
针对于以上问题，在2001年提出了敏捷开发的概念。
1.2 敏捷开发的优势
- 精确 :瀑布模式通常会在产品起点与最终结果之间规划出一条直线，然后沿着直线不断往前走。然而当项目到达终点时，用户通常会发现那已经不是他们想去的地方。而敏捷方法则采用小步快跑，每走完一步再调整并为下一步确定方向，直到真正的终点。
- 品质 :敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如极限程序设计等，甚至使用测试驱动开发test-driven development)，即在正式开发功能代码之前先开发该功能的测试代码。这些都为敏捷项目的整个开发周期提供了可靠的质量保证。
- 速度 :敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外，较短的迭代周期使团队成员能迅速进入开发状态。
- 投资回报率 :在敏捷开发过程中，最具价值的功能总是被优先开发，这样能给客户带来最大的投资回报率。
- 高效的自我管理团队:敏捷开发要求团队成员必须积极主动，自我管理。在这样的团队中工作，每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。
二、简介
2.1 起源
2001年2月，Martin Fowler，Jim Highsmith等17位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪圣地，举行了一次敏捷方法发起者和实践者的聚会。在这次会议上面，他们正式提出了Agile(敏捷开发)这个概念，并共同签署了《敏捷宣言》。
虽然Agile的概念是在2001年被提出，但这并不等于敏捷开发实践是在2001年才被提出。雪鸟会议是对之前几十年中软件开发实践探索的总结，是水到渠成的一个结果。
2.2 概念
敏捷开发(Agilc Development) 是一种面临迅速变化的需求快速开发软件的能力。为了获取这种敏捷性，我们需要使用一些可以提供必要的纪律和反馈的实践。我们需要使用一些可以保持我们的软件灵活、可维护的设计原则，并且我们需要知道一些已经被证明针对特定的问题可以平衡这些原则的设计模式。
简单的说，敏捷开发以用户的需求进化为核心，通过一个或多个跨职能 的小型团队，分多个迭代 、持续地 、增量地交付价值。
什么是迭代 和增量
- 迭代
- 增量
2.3 敏捷开发宣言
1、个体的交互胜过过程和交互
流程和工具是我们项目当中需要的，将团队的目的聚焦于个体参与和互动。项目是通过人来完成的，而不是通过工具。困难也是由人来解决的，而不是通过流程。同样，项目由人来执行，范围由人来确定，项目成功也是由人来定义的。个体的参与和交互将有利于项目成功。
2、可以工作的软件胜过面面俱到的文档
软件项目以创造有价值、高质量的软件为首要目标。然而很多人经常会过的关注一些临时的可交付成果，比如泛泛的文档，却不太关注项目最终目标的可工作的软件。没有文档描述的软件在技术支持和维护上一定会出现问题及阻碍，但是只要详尽的文档而没有完成软件对于任何一个组织而言都是没有价值的，所以，文档是需要的，但是需要把握其中的度。
3、客户合作胜过合同谈判
本条价值观提醒我们需要做到灵活与包容，而不是死板，类似于"正确的做事"和"做正确的事"。我们可以完全按照最初规定来完成产品，一旦客户改变想法或优先级，最好的做法是通过灵活的方法完成新的目标，而不是用最初的规定来对抗。
4、响应变化胜过遵循计划
遵循计划是按照计划行事，中间可能需要采取纠正措施，目的是为了使预期的未来绩效与项目计划一致而做一切事情。响应变化则是适应的过程，通过卓越构想和不断反馈来采取适当的措施，适当的目的是对实践而非预定计划的回应，是响应而非纠正。
2.4 敏捷开发十二原则
1.我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2.欢迎需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3.经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4.业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5.激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6.不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7.可工作的软件是进度的首要衡量标准。
8.敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9.坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10.以简洁为本，它是极力减少不必要工作量的艺术。
11.最好的架构、需求和设计出自自组织团队。
12.团队定期地反思如何能提高成效，并依此调整自身的举止表现。
十二原则中提到------最好的架构、需求和设计出自自组织团队。什么是的自组织团队？一定是汇集各个行业的大牛？一个优秀的团队成员应该符合什么样的要求呢?
1.自组织团队是敏捷实践的结果我们实施敏捷开发的过程也是我们打造自组织团队的过程
2.明确团队的目标、拥有专业的技能、遵循规则、与他人能实现有效的沟通、愉快的合作；
自组织结构是指系统自动的从无序走向有序，从简单走向复杂，从低级走向高级，甚至具有了自我生长、学习、反馈、进化、更新的能力。团队是否做到自组织是检验敏捷思想是否真正落地的重要判定依据。
最简可行产品(minimum viable product)-mvp。比如说，给客户做一辆汽车，我们交付的最简可行产品是什么？
是组装车子的零件嘛？还是什么别的？ 
我们可以频繁地在软件开发过程中为最核心的需求交付最简可行产品，快速地完成构想到验证的一个循环根据市场的需求，来校正产品的开发方向，避免决策上的失误。
2.5 敏捷开发实践
目前已经有许多的敏捷过程可供选择。包括:SCRUM，Cystal，特征驱动软件开发(Feature Driven Development,简称FDD),自适应软件开发(Adaptive Software Development,简称ADP)，以及最重要的极限编程(eXtreme Programming，简称XP)。
Scrum 用于开发、交付和维持错综复杂产品的敏捷框架 专注于软件管理方面，将软件周期拆分成若干个迭代小周期，每个迭代小周期称为冲刺(sprint)，每个冲刺(sprint)的时间建议是2-4周；冲刺中会挑选优先级高的需求开始开发，每天都会召开简短例会；解释和规划工作。
极限编程(eXtreme Programming，简称XP) 是一种软件工程方法学，是敏捷软件开发的一种方式 独特的地方是对测试的极端重视，将测试作为开发的基础，推荐开发人员在用户故事和初步设计完成后，不要急着编码，而是优先开发出单元测试用例，测试驱动开发的理念。
三、敏捷开发框架介绍-Scrum
Scrum 本意是并列争球，橄榄球运动中一种需要团队合作争球方式。
3.1 简介
Scrum是用于开发、交付和维持错综复杂产品的敏捷框架最初着重于软件开发，之后已被用应用于其他领域包括研究、销售、营销和其他先进技术领域。
敏捷开发的实践按照目的划分,分为敏捷开发管理实践 和敏捷开发工程实践两类。
Scrum以经验过程控制理论作为理论基础利用迭代、增量的方式来实现软件的持续交付与自我改进
预定义过程就是在执行之前先要制定详细的计划，然后严格按照计划执行。工厂的生产线，通常就是预定义的过程控制
经验过程控制理论，又称为经验主义。经验过程控制理论提出对于活动的过程控制应该基于观察和实验，而不是详细的，经过提前规划和定义好的过程。
在Scrum中，经验过程控制的实现依赖于透明度，检验和适应性这三个主要思想。
Scrum框架以经验过程控制理论为理论基础，要求开发人员在软件的开发过程中，根据实际经历的内容做出决策，以事实为基础，以经验为基础，以证据为基础的方式开展工作，强调工作进展是基于对现实的观察，而不是基于大量前期要求的虚构计划。
3.2 工作流程
在这个框架中，整个开发周期包括若干个小的迭代周期，每个小的迭代周期称为一个Sprint(冲刺)，每个Sprint的建议长度2到4周。在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。
用户故事（user story）是从用户的角度来描述用户渴望得到的功能。
三大基石
透明度（Transparency）
透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。
检验（Inspection） 开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。
适应（Adaptation） 如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。
详细工作流程
详述
三大角色：
产品负责人(Product Owner)、开发团队(Dev Team)、Scrum Master
四种会议：
迭代计划会议（Sprint Planning Meeting）
每日站会（Standup Meeting）
Sprint评审会（Retrospective Meeting）
Sprint反思会（Retrospective Meeting）
两大工件
待办列表（Backlog）:Sprint Backlog(Sprint 待办列表)和Product Backlog(产品需求列表)
燃尽图（Burn-down Chart）:分为Sprint燃尽图（Sprint Burn-down Chart）和发布燃尽图（Release Burn-down Chart）
3.3 角色
按照参与程度而言：可分为需要完全投入 和需要部分投入的两大类角色；
-
需要部分投入的角色 1.用户
软件就是为了用户而开发的，因此用户的反馈信息及看法是项目开发过程中需要倾听并考虑的。
2.利益干系人
利益干系人，是指与项目的产出有利益关系的人，比如客户运营等。
-
需要完全投入的角色
1.管理者管理者这个角色比较简单，主要任务就是给工程项目创建良好的工作环境。
2.产品负责人 (Product Owner)
产品负责人代表着客户的意愿，该角色的目的是为了确保Scrum团队能更好地理解业务，在正确的方向上开展工作。
3.开发团队（Dev Team）
他们是自组织的，没有人(即使是Scrum主管都不可以)告诉开发团队如何把产品待办列表变成潜在可发布的功能。
开发团队是跨领域多功能的，团队作为一个整体拥有创造产品增量所需要的全部专业技能。
将传统的职能团队打散，组成一个跨职能的全功能团队，能避免不同职能部门之间无形的沟通障碍，提升沟通协作的效率。
Scrum不认可开发团队中成员的头衔，无论承担哪种工作他们都是开发者，无一例外。成员们在每个冲刺中可以以任何恰当的方式一起工作，来达到他们为自己设置的目标。
开发团队中的每个成员可以有特长和专注领域，但仍需继续学习其他专长。每个人都会有主要的、次要的甚至是第三位的技能，并随时准备 好"到工作所需要的地方去"。
开发团队不包含如系统测试或业务分析等负责特定领域的子团队。
3.4 工件
工件: 指代产品开发过程中的一些产出。
也可以说，他是某些敏捷开发过程中我们要用到的工具。
1、待办列表（Backlog）
待办列表分为产品待办列表以及冲刺待办列表
a.产品待办列表
| 优先级 | 事项 | 细节 | 初始规模估算 |
|---|---|---|---|
| 1 | 作为用户，可以登录进系统主页面 | -- | 3 |
| 2 | 作为用户，可以主页的待办事项以及通知 | -- | 4 |
| 3 | 作为用户，可以修改个人资料 | -- | 2 |
| ... | ... | ... | ... |
产品待办列表中的列表项主要是分为了三种类型
1、技术债 2、缺陷 3、新功能
b.冲刺待办列表 冲刺待办列表定义了开发团队在sprint中的任务清单，也就是说在这个冲刺中需要交付的工作量
2、扩展工具燃尽图
以工作量为y轴，以时间为x轴。
蓝色的线是预测一定时间后的工作量，而橙色的线指的是我们实际的工作量，一般正常情况下，橙色的线是围绕着蓝色的线上下波动的。
上图捏，介绍的是正常的情况，但有的时候会出现如下图所示的情况
大家可以思考一下，是什么原因导致下图这种现象的产生捏？
1.建立的task未及时关闭，导致数据不正确
2.迭代待办列表设计不合理，预估工作量与实际相比误差大，这个时候我们的产品负责人就需要及时纠正过来，将一部分需求留到下一个sprint；
3.在此迭代过程中，客户需求与我们理解的有偏差；
3、可交付产品增量
增量是一个冲刺完成的所有产品待办列表项的总和以及之前所有冲刺所产生的增量的价值总和。
4、用户故事
作为<某个角色>，我希望<实现某项功能>，以便<带来某种价值>
用户故事由以下三个方面组成也就是3C Card -故事卡 Conversation -对坏 Confirmation -验收标准
1、一份书面的故事描述，用于做提示、计划
2、有关故事的对话，用于具体化故事细节
3、验收测试，用于表达和编写故事细节且可用于确定故事怎样才算完成
例子： 以一个简单的购物应用程序为例：
用户故事：作为一个在线购物用户，我希望在商品列表页面上看到每个商品的名称、价格和加入购物车按钮，以便我可以快速地选择喜欢的商品并添加到购物车中。
- 角色（用户）：在线购物用户。
- 动作（需要做什么）：在商品列表页面上看到每个商品的名称、价格和加入购物车按钮。
- 收益（为什么需要）：能够快速地选择喜欢的商品并添加到购物车，方便统一购买。
通过这个用户故事，团队可以更好地理解用户的需求，而不是简单地描述"添加购物车"这个功能。这样的描述有助于确保团队关注用户的需求和价值，从而更好地满足用户期望。
故事点（Story Points，简称SP）是一种用于估算用户故事复杂性和工作量的相对单位，它是敏捷开发中常用的估算方法。
为什么要用相对单位而不是绝对单位？
对于开发团队来说，团员们之间存在技术的参差很正常，对于不同工作年限的程序员，他们一定的时间内完成的工作量不一样。所以，我们应该以基础用户故事为基准。
故事点的计算方式是什么？
- 1.制定基准用户故事；
- 2.相对估算；
- 3.考虑多个因素；
- 4.一致性和讨论；
- 5.不要过于精确
3.5 四大会议
Scrum指南规定的时长
- Sprint Planning：对1个月的sprint来说，8小时为上限。
- Sprint Review：对1个月的sprint来说，4小时为上限。
- Sprint Retro：对1个月的sprint来说，3小时为上限。
- Daily Standup：15分钟。
3.5.1 sprint计划会议
时间：迭代计划会在每个迭代第一天召开；
会议时长：一般是2~3小时，根据迭代周期而言；
参会人员：Scrum Master、PO、开发团队；
主要内容：总的来说是选择本次迭代的Backlog和估算本次迭代的工作量；
产出：sprint待办列表（Sprint Backlog）。
第一部分：这个冲刺要做什么?
1、产品负责人与开发团队就产品待办列表中高优先级的事项进行讲解、讨论，尽可能多的让团队充分理解每一个产品故事背后的需求，以及需求的验收标准；
2、开发团队根据产品待办列表、最新的产品增量以及自身的开发能力，自行选择产品待办列表中的具体条目。
第二部分：选出的工作如何完成?
1、首先，开发团队会将选中的产品待办列表条目移入冲刺待办列表。并对条目逐一进行拆分，将每个待办项细分为多个明确的、能实际操作的开发任务；
2、开发团队需要对每个开发任务进行故事点估算；
3、开发团队的成员自组织地领取冲刺待办列表中的工作。
3.5.2 每日站立会议
时间：每天，一般是在早上；
会议时长：一般是15分钟，根据team的人员数量相关，平均每人两分钟；
参会人员：PO、开发团队；
主要内容：交代三个问题的答案，
- 昨天你做了什么?
- 今天你将要做什么?
- 是否有需要帮助的地方?
注意：
- 1、详细的讨论应该推迟到会议结束之后；
- 2、说话的人在介绍最新情况时不应该被打断；
- 3、Scrum Master应该作为调解人在场，帮助捕捉和解决障碍；
- 4、如果您错过了会议，您必须向团队发送一封电子邮件，其中包含以下内容你今天做的事。你明天打算做什么，任何障碍。
3.5.3 sprint评审会议
时间：交付给可工作软件给客户之前；
会议时长：一般是1~2小时，根据迭代周期而言，如果迭代周期为两周，那么就不超过两小时；
参会人员：Scrum Master、PO、开发团队；
主要内容：对本次sprint完成的可工作软件进行评价。
dev team向产品负责人展示迭代工作结果，产品负责人给出评价和反馈。
以用户故事是否能成功交付来评价任务完成情况。
3.5.4 sprint回顾会议
时间：在Sprint评审会议结束之后，下个Sprint的计划会议之前；
会议时长：一般是1~2小时，根据迭代周期而言，如果迭代周期为两周，那么就不超过两小时；
参会人员：Scrum Master、PO、开发团队；
主要内容：总结哪些事情做得好，哪些事情做得不好。做得好的保留，不好的摒弃；
产出：回顾会议记录表。
重要要素 ：4Ls 包括
- Liked（做得好的） -- things you really liked.
- Learned（学会了的） -- things you have learned.
- Lacked（所缺乏的） -- things you have seen the team doing, but consider that could be done better.
- Longed for（渴望做的） -- something you desired or wished for.
目的：Sprint回顾改善团队沟通，能够持续学习和改进。
还有一个会议是必不可少的
3.5.5 待办事项整理会议（Backlog Grooming Meeting）
时间：迭代计划会议开始之前3天召开；
会议时长：一般是1~2小时，根据迭代周期而言，如果迭代周期为两周，那么就不超过两小时；
参会人员：Scrum Master、PO、开发团队中关键开发者；
主要内容：Product Owner将一批希望团队在下次迭代时实现的用户故事，按照实现顺序描述给在场的团队成员，Scrum Master与在场成员分析用户故事，明确指出团队认为需求不明确的地方。
产出：Backlog
一些问题：
1.为什么用户故事的故事点有的时候会需要设置很大，有的时候又设置很小？
首先，Story Points (SP) 是一种相对度量，是以基础用户故事为参考。选择的基础用户故事的工作量的大小会直接影响到sp的数值。
可以设置很大的原因：
- 表示复杂性巨大的任务： 有些用户故事可能非常复杂，可能需要更多的工作和时间来实现。将这些故事设置为较大的 SP 可以准确地反映它们的复杂性，以便团队在规划和分配工作时更加谨慎。
- 识别风险和不确定性： 一些故事可能涉及未知的领域或技术，可能会伴随更多的风险和不确定性。将这些故事设置为较大的 SP 可以提醒团队在实施时需要更多的关注和准备。
- 支持分解和细化： 如果一个大型任务被标记为大的 SP，团队可以在规划和开发过程中将其分解为更小的任务。这有助于团队更好地理解和管理工作。
可以设置很小的原因：
- 表示相对简单的任务： 有些用户故事可能相对简单，只需要很少的工作和时间。将这些故事设置为较小的 SP 可以更准确地反映它们的相对轻松程度。
- 提高可比性： 将大部分故事设置为较小的 SP 可以更容易地进行相对估算，因为它们之间的差异相对较小。这有助于团队更快地达成共识。
- 支持快速迭代： 将故事设置为较小的 SP 可以鼓励团队在短时间内完成它们，从而实现更快的迭代和交付。
总之，Story Points 的设置是根据团队的共识和经验进行的，目的是更好地估算工作量和复杂性，从而更好地规划和管理项目。无论 SP 大小如何，关键是团队一致性地使用它们，并在实践中逐渐积累对不同 SP 的理解和经验。
2.为什么设定user story不要过于精确？
灵活性和可变性： 用户故事鼓励在开发过程中保持灵活性。它们并不要求在一开始就详尽地定义所有细节，而是鼓励逐步细化和调整，以便根据实际需求进行变化。
用户故事不要求精确地定义每个细节，而是强调与用户价值和需求的直接关联，以及与业务代表的有效沟通。它们为团队提供了一种更灵活、敏捷的方式来管理需求，并在开发过程中根据变化进行适应。
用户故事是简短描述通常只包含关键信息，而不是详尽的技术细节。
敏捷开发就是要拥抱变化。
3.sp讨论的话如果达成一致性？
在敏捷团队中，讨论 Story Points（SP）的目的是为了达成一致性和共识，以便更好地估算用户故事的复杂性和工作量。以下是一些关于如何在讨论中达成一致性的建议：
- 参与全体团队： 确保在讨论 SP 时，所有团队成员都能参与进来，包括开发人员、测试人员、产品经理等。每个人的视角都对于全面理解用户故事的复杂性非常重要。
- 共同讨论： 在估算会议上，团队成员可以一起讨论每个用户故事，分享对复杂性和工作量的看法。讨论可以涉及故事的需求、技术难度、可能的风险等。
- 用相对标准： 使用相对标准（如Fibonacci数列或T-Shirt大小）可以帮助团队更快地达成共识。成员可以将每个故事与其他故事进行比较，以决定其相对大小。
- 开放式讨论： 在估算过程中，鼓励成员自由表达自己的看法，并提出问题、疑虑或建议。开放的讨论有助于深入理解故事，并在团队中建立共识。
- 达成共识： 如果在估算过程中出现分歧，团队可以寻求达成共识。这可能需要进行讨论、澄清需求、更深入地分析等。团队可以通过投票、讨论或其他方式来确定最终的 SP。
- 迭代和调整： 估算是一个逐步迭代的过程。如果团队在后续工作中发现估算不准确，可以在未来的估算会议上进行调整和修正。
- 记录和回顾： 将估算结果记录下来，以便团队可以在以后的项目中查看和回顾。这有助于改进估算的准确性和一致性。
- 尊重经验： 尊重团队成员的经验和专业知识。有些成员可能在某些领域更有经验，他们的见解可以对估算的准确性产生积极影响。
通过开放的讨论、相对标准的使用、共同决策和逐步迭代，团队可以在讨论中达成一致性，从而更准确地估算用户故事的复杂性和工作量。
4.为什么sp的设置会选用Fibonacci数列或T-Shirt大小？
Fibonacci数列（斐波那契数列）或T-Shirt大小是常见的相对标准。在sp的设置过程中，选取一些相对标准，是为了帮助团队更准确地进行相对估算，而不是精确测量时间。