Scrum框架的学习笔记
什么是敏捷开发
相对于传统的瀑布式、迭代式等“非敏捷”的开发模式，敏捷软件开发(Agile software development)更强调以下几点
- 开发团队与业务专家之间的紧密协作
- 开发与业务团队高效的面对面的沟通
- 形成紧凑而自我组织型的团队(见文末)
- 更注重软件开发过程中人的作用
从而获得如下益处：
介绍
Scrum的流程大致如下：
图中展示了Scrum的流程，其中包括Events和Artifacts两大类，前者是活动，后者可以理解为“工件”。
Scrum Events
Scrum Events形成规律性的活动，并尽量减少其他会议；
- Sprint：一个月或更短的周期，在此期间完成工作；Sprint包含所有其他Scrum Events；新的Sprint在前一个Sprint结束后立即开始。
- Sprint Planning：专门用于规划Sprint期间的工作的活动。
- Daily Scrum：每天举行的活动，开发人员检查实现Sprint目标的进展情况，发现可能阻碍他们工作的因素，并作出相应调整。
- Sprint Revie：在Sprint结束时举行的活动，Scrum团队和关键stakeholders回顾在Sprint中完成了什么，在他们的环境中发生了什么变化；接下来，与会者合作讨论下一步该做什么。
- Sprint Retrospective：Scrum 团队在此活动中聚在一起讨论上一个 Sprint 的进展情况，并确定一些有利于提高效率的改变。
Scrum Artifacts
透明且可检查的计划和工作，以便将来进行调整；每个工件都有自己的承诺(Commitment)，这有助于团队了解他们是否正在取得进展；
- Product Backlog：一个不断发展的、有序的、用于改进产品所需的清单；它是Scrum团队开展工作的唯一来源。
Commitment: Product Goal - 团队计划的目标
- Sprint Backlog：一个高度可见的工作清单，它是开发人员的 Sprint 计划，可能会随着他们的学习而不断变化
Commitment: Sprint Goal - Sprint 的单一目标
- Increments：小块的工作，作为实现产品目标的具体垫脚石。在Sprint期间，你可以根据需要随时交付，而不限于每个Sprint只有一个版本。(ps：通常一个increment 可能包含几个user story，但一个user story不会包含多个increment)
Commitment: Definition of Done - 描述一个increment怎样才被视为完成
总结
Scrum是一个经验性的过程，决策是基于观察、经验和实验的。Scrum有三个支柱：透明度、检查和适应。这支持了迭代工作的概念。经验主义可以说是：是通过小的尝试进行工作，从工作中学习，并根据需求调整你正在做的事情和工作方式。
Scrum团队的关键特征是信任。如果信任在Scrum团队中不存在，那么在完成工作的过程中可能会出现紧张和瓶颈。
Scrum价值观包括勇气、专注、承诺、尊重和开放，在上面的图片中可以看到。Scrum价值观对于Scrum团队来说也是至关重要的，因为它们指导了如何开展工作和推动信任。
总的来说，Scrum需要做到以下三点：
- 有价值的工作的增量(Increments of valuable work) 在一个月或更短的短周期内交付，这称为Sprints。在 Sprint 期间会有持续的feedback出现，使得我们可以对工作进程和要交付的东西进行inspection和**adaptation。
- Scrum 团队有一名Scrum Master、一名Product Owner和一些Developers，他们负责在 Sprint 期间将工作的选择转化为价值增量(Increment of value)。
- Scrum 团队及其组织、以及来自业务、用户和客户群体的成员（称为stakeholders）检查 Sprint 的结果并为下一个 Sprint 进行调整。
附：什么是自组织(self-organizing)团队
自组织团队可以自主选择如何最好地完成他们的工作，而不是受团队外其他人(领导、经理等等)的指挥。以下是传统团队和敏捷的自组织团队的对比图。
附：什么是Increments of value
当涉及到大型的、复杂的组织时，组织、团队、内部用户和外部客户的不同需求使得了价值的定义模糊不清。这就是PO和BAs的作用所在——他们通过对不同需求的理解，将工作分解成小的价值增量increments of value，从而带来清晰的认识。
这有助于团队做计划、确定优先级和快速交付。
在评估每个product, feature, or backlog item时，PO和BA在定义increments of value时应该考虑三件事。
- 第一，与客户需求保持一致。PO和BA要确保每个增量都能为用户提供价值，并满足客户的关键需求。一些好的分析问题包括如下内容：它是否为终端用户提供了价值？它是否满足了一个还是多个用户需求？它与任何其他的用户需求有冲突吗？这些问题帮助我们从用户视角考虑问题，而不仅仅是从技术层面。
- 第二，与愿景和战略(vision and strategy)保持一致。PO和BA要确保每个增量都有助于达成战略和产品愿景。一些好的分析问题包括如下内容。这个backlog item是如何提供价值的？这个解决方案是否会改变产品的愿景？这个功能是否支持组织战略，但与用户的需求有冲突？这些问题有助于确保与大局相一致。
- 最后，最大限度地减少没完成的工作。PO和BA的很大一部分作用是除去那些不能提供价值的工作。分析每一个product feature和backlog item，以确定每个组件都能提供切实的价值，剔除那些没有价值的部分。
