一、敏捷起源
2001年2月,Martin Fowler,Jim Highsmith等17位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪圣地,举行了一次敏捷方法发起者和实践者的聚会。在这次会议上面,他们正式提出了Agile(敏捷开发)这个概念,并共同签署了《敏捷宣言》。 我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观:
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说,尽管右项有其价值,我们更重视左项的价值。
(1) 预定义型过程控制(发射火箭) (2) 经验性过程控制(开车)
软件研发的主要效率来源于团队协作和互动
文档作用: (1) 沟通 (2)知识回溯
效率: 单个步骤的开发的时间 → 响应力: 达到目标所需要的时间
邓巴数理论(150):社交网络给了我们联系,却未必给了我们交流;拉近了我们的距离,却未必增加我们的亲密;激发了我们社交的天性,却可能磨平了我们沟通的能力。社交的幸福感来自社交的质量而不是数量,来自于沟通的深度而不是频率。
二、敏捷12条原则
1、我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。
2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。
3、要不断交付可用的软件,周期从几周到几个月不等,且越短越好。
4、项目过程中,业务人员与开发人员必须在一起工作。
5、要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
6、无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
7、可用的软件是衡量进度的主要指标。
8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
9、对技术的精益求精以及对设计的不断完善将提升敏捷性。
10、要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
11、最佳的架构、需求和设计出自于自组织的团队。
12、团队要定期反省如何能够做到更有效,并相应地调整团队的行为。
三、Scrum的3355理论(3个角色,3个工件,5个价值观,5个仪式/事件)
![图片替换文本](https://i-blog.csdnimg.cn/blog_migrate/bd6c1ebb30a83122832de9d56f48e60b.png)
(1) 3个角色
1.1.Product Owner
产品所有人,简称PO,主要职责是负责Product Backlog和Sprint Backlog。PO不仅要决定选择做什么,还要能从商业价值的角度解释为什么做这些。PO的日常工作主要有:
- 在产品团队中扮演业务的发言人,是项目的客户或者代表
- 有充足的知识和授权
- 定义业务需求,定义产品的最高优先级的特征和功能
- 根据需求的商业价值对其进行优先级排序
- 确定发布日期和发布内容
- 根据需要调整每个Sprint的需求和优先级
- 在Sprint交界处可以变更功能和优先级
- 定义验收标准
- 接受或者推翻工作成果
- 对于每个敏捷团队做的所有工作的价值、优先级和细节拥有最终的权威
- 对于业务目标和期望的最终结果的深层的了解使得其拥有此权威
- 与团队一起更紧密地工作
1.2.Scrum Master
Scrum教练或者Scrum大师,简称SM,主要职责是传播敏捷的思想,保证Scrum的流程。日常工作主要有:
- 促进团队的工作
- 精心组织Scrum的各种仪式
- 负责设定Scrum的价值和实践
- 确保团队的组件完整性且保证效率高产
- 促成所有角色和职能之间的紧密协作
- 排除障碍
- 保护团队不受外界干扰
1.3.The Team
研发团队,是任务执行团队,一般是一个跨职能团队(一般包括前后台研发、测试等),能够切实提供一个可用产品的团队。团队主要有以下特征:
- 典型团队通常为5-9个人
- 跨职能团队,囊括了开发人员、测试人员、业务分析师等开发最终软件所必需的角色
- 团队成员应该是全职的。也可能有特殊情况 (例如, 数据库管理员DBA等兼职)
- 保持纪律,遵守承诺,按时交付软件成果
- 自组织、自管理的团队
(2) 3个工件
2.1.Product Backlog
产品待办事项集合,整个产品的用户故事集合,这些用户故事可以来自甲方客户、终端用户、PO自己对产品的理解、研发团队等。它具有以下特点:
- 是项目的需求列表
- 以用户故事的形式表示
- 包含功能性以及非功能性需求
- 每项需求应该描述其商业价值
- PO负责进行对Product Backlog Item(产品待办事项)优先级排序
- 每个Sprint开始之前要重新进行排序,以确定最重要的事项
- 随着项目的进行,可能新增、变更或减少条目
2.2.Sprint Backlog
冲刺待办事项列表,一个冲刺目标阶段内的用户故事列表。
这些用户故事来自Product Backlog,每次冲刺前,PO根据交付价值,将优先级最高的用户故事放入迭代。它具有如下特点:
- 从产品Backlog中取出前面若干项,在当前Sprint中被实现
- 每个用户故事应该能够在当前Sprint中被实现
- 每一个用户故事都会被分解并关联到若干个子任务(Task)
- 团队成员自愿挑选任务
- 每日更新任务剩余时间
- 团队成员均可按需在Sprint Backlog中增加、修改、删除任务
- 如果Sprint工作不清晰,创建Sprint Backlog时先估算一个比较大的时间段,在后续阶段再做进一步的缩短
- 伴随着任务的逐步清晰化,及时更新剩余时间
- 对于用户故事的完成,团队一起定义“完成”的标准(DoD)
- DoD代表了各种用于确保sprint backlog中质量、准确性、业务关联性活动
2.3.Increment
增量是一个 Sprint 完成的所有产品待办列表项的总和,以及之前所有 Sprint 所产生的增量的价值总和。在 Sprint 的最后,新的增量必须是“完成”的,这意味着它必须可用并且达到了 Scrum 团队“完成”的定义的标准。增量是在 Sprint 结束时支持经验主义的、可检