一、敏捷开发由来
2001年2月11日至13日，美国犹他州瓦萨奇山雪鸟滑雪胜地，17个人聚到一起，试图找到软件开发的共识，最终的成果就是《敏捷软件开发宣言》。参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们。官方网站：http://www.agilemanifesto.org
《敏捷宣言》提出敏捷4条价值观：
1、个人与互动胜过过程与工具
（Individuals and interactions over processes and tools）
2、可用的软件胜过复杂的文件
(Working software over comprehensive documentation)
3、与客户合作胜过合同谈判
(Customer collaboration over contract negotiation)
4、响应变更胜过遵循计划
(Responding to change over following a plan)
《敏捷宣言》提出敏捷12条原则：
1.我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2.欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3.经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期
4.业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5.激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援辅以信任从而达成目标。
6.不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7.可工作的软件是进度的首要度量标准。
8.敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9.坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10.以简洁为本，它是极力减少不必要工作量的艺术。
11.最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
二、Scrum敏捷开发
Scrum敏捷开发定义：Scrum 是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是一至四周。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。Scrum 目前已被用于开发软件、硬件、嵌入式软件、交互功能网络、自动驾驶、学校、政府、市场、管理组织运营，以及几乎我们（作为个体和群体）日常生活中所使用的一切。以下是Scrum敏捷总体流程图：
scrum的基本流程如上图所示：
1.产品负责人负责整理user story，形成左侧的product backlog 。 ---用户故事整理
2.发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表。sprint backlog。 --用户故事确认
3.迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，最终每个任务都有明确的负责人，并完成工时的初估值。--用户故事分解
4.每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。--用户故事实现
5.演示会议：迭代结束后，召开演示会议，相关人员都受到邀请参加，团队负责人向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由PO整理，形成新的story。 --用户故事的二次整理
敏捷开发中用户故事的细化为开发提供了可执行的标准，敏捷开发的特点是快速迭代，一个用户故事的大小和复杂度应该是在一个迭代中开发完毕为宜。如果用户故事过大，可能会导致它的开发横跨几个迭代。此事就应该将这个用户故事分解。每个任务的时间最好不要超过8小时，就是要保证一个工作日内完成，如果做计划时发现有些任务的时间超过了8小时，就说嘛任务的划分有问题，需要进行子任务的分解。
2.1、实施Scrum敏捷开发关键细节点：
1、大项目分成多个迭代（Sprint）,每个迭代都要跟客户交流确认；
2、用户故事不能过大，不要跨多个迭代；
3、每个任务的时间最好不要超过8小时，就是要保证一个工作日内完成；
4、每个团队不要太大，8人左右最好；
5、每天一定要有站例会，每个人2分钟都要说，不会有人摸鱼，注意要控制时间；
6、要有实体看板，把大家聚到一起，仪式感很强，不能用电子看板代替。
2.2、敏捷开发物理看板示例
2.3、Scrum团队组织架构
核心是要保证团队成员稳定，不能老换人，否则会影响敏捷研发效率和质量，PM、PO、UED、SCM等这些角色可以跨团队复用的。
2.4、敏捷开发和瀑布开发的区别
三、Scrum敏捷概念梳理
Scrum框架涉及到多个概念，官方有3个角色、3个工件、5个事件的说法，以下是按照实际的项目开发过程梳理的。
3.1、Scrum敏捷角色有哪些
Scrum Master职责：强调是服务型领导，对内不要太强势，要注意团队融洽
Product Owner 职责：这个角色很关键，懂需求，要处理好与甲方的关系
3.2、Scrum何时做什么事
3.3、Scrum要开哪些会议
3.4、什么是用户故事
用户故事（user story）
用户故事（user story）是个用来确定用户和用户需求的简短描述，用户故事是从用户的角度来描述用户苛求得到的功能。一个好的用户故事包括三个要素：
1.角色：谁要使用这个功能。
2.活动：需要完成什么样的功能。
3.商业价值：为什么需要这个功能，这个功能带来什么样的价值。
模板：作为一个<角色>, 我想要<功能>, 以便于<商业价值>
例子：
“作为招聘网站注册用户，我想要查看最近3天发布的招聘信息，以便于我看到最新的招聘信息”。
作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。
需要注意：用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来表达。
3.5、什么是用户故事地图
用户故事地图 已经成为敏捷需求规划中的一个流行方法。用户故事地图可以将你的backlog变成一张二维地图，而不是传统的简单列表。用户故事地图可以解决以下问题：
- 让你更容易看清backlog的全貌；
- 帮助你更好的进行迭代增量式开发，梳理最小 MVP 最小可运行产品，同时确保早期的发布可以验证整体架构和解决方案；
- 有助于激发讨论和管理项目范围
- 允许你从多个维度进行项目规划，并确保不同的想法都可以得到采纳
用户故事地图模板：
以购书网站为例展现用户故事地图：
3.6、什么是故事点
故事点 是敏捷项目管理和开发中的一种抽象的度量单位，用于估计实现一个或多个用户故事的复杂度，它是对工作量的一种描述方式。一个故事点就是一个数字，透过这个数字告诉整个团队用户故事的复杂度。复杂度包括功能的难易程度、风险和花多大的功夫。
故事点（story point）和预估时间（estimated）不一样，故事点是一种相对的估计，它并不能和类似“人/天”这样的单位画等号，因为每个人完成同样复杂度的工作所需的时间是不同的。故事点方法提倡敏捷团体在一起讨论，为用户故事计数，以此来衡量故事的难度和所需的工作量。
故事点一般用在团队内部，结合燃尽图一起用，故事点度量的最大缺陷就是“缺乏一致性”，不能在多个敏捷团队之间进行横向比较。
四、敏捷开发总结
网上关于scrum的概念很多，让人看后摸不着头脑，实施scrum敏捷开发要注意理解其背后的内涵，其实就是先定规矩、达成共识、简单工作、小步快跑。
比如：
搞一个物理看板，每人日例会站立开会，有仪式感；
日例会每天必开，每人必须参加，迟到给大家发红包；
有问题大家尽快提出来，讨论协商解决，不要隐藏问题；
故事点在团队内部达成共识，比如一个增删改查模块2个故事点；
每个迭代完成后，团体要复盘讨论，分享经验。
云程低代码开发平台产品在研发过程采用了“Scrum敏捷思想+DevOps工具”模式，我们将继续探索。
