敏捷软件项目开发框架（Scrum框架）

一、产品研发管理的最常用的3种模式的选择

集成产品开发（IPD）、集成能力成熟度模型（CMMI）、敏捷开发（Agile Development）是当前国内外企业产品研发管理的最常用的3种模式。
结合自身特点选择 Scrum敏捷模式。

1 敏捷开发的起源与定义：

其实，在发表《敏捷宣言》之前，很多的敏捷实践都已经存在且使用了，比如：Scrum、XP、KanBan等。之所以发表《敏捷宣言》，
是因为这些实践都是在单打独斗地推进敏捷开发，而不是以一个联合体的形式，且没有一个统一的指导方针。

所以17位敏捷联合创始人决定发表《敏捷宣言》，共同在全世界推进敏捷开发运动。下面是敏捷宣言的4句话，其提出了敏捷开发的核心价值观.

1.个体与互动 高于 流程和工具
2.工作的软件 高于 详尽的文档
3.客户合作     高于 合同谈判
4.响应变化     高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
不管你走了多远，错了就要重新返回。

敏捷开发模式基于以下十二个基本原则：

1. 通过早期和持续交付有价值的软件来满足客户。
2. 欢迎变化的需求，即使在开发后期。
3. 频繁交付可工作的软件，通常每隔几周到几个月一次。
4. 业务人员和开发人员必须每天在项目上共同工作。
5. 围绕有动力的个人构建项目，并给予他们所需的支持和信任。
6. 面对面的交流是团队内部最有效的沟通方式。
7. 工作的软件是进度的主要衡量标准。
8. 敏捷过程促进可持续开发，赞助人、开发者和用户应该能够维持一个恒定的工作速度。
9. 不断追求技术卓越和良好设计以增强敏捷性。
10. 简洁——极力减少不必要的工作，是敏捷开发的精髓。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期反思如何变得更高效，并相应地调整行为。

2  Scrum 敏捷开发

Scrum 最初是为了管理和开发产品而开发的。从上世纪 90 年代初开始，Scrum 在全球范围内已得到了广泛应用，这是两位主要的创始人 Jeff Sutherland与Ken Schwaber。

Scrum框架组成：5项价值观、3种角色、3个工件、5个会议

二、Scrum团队的5个价值观

 承诺、勇气、专注、开放、尊重

当承诺（Commitment）、专注(Focus)、开放(Openness)、尊重(Respect)、和勇气(Courage)五大价值观为 Scrum 团队所践行与内化时，Scrum 的透明、检视和适应三大支柱成为现实，并且在每个人之间构建信任。
Scrum 团队成员通过Scrum 的角色、事件和工件来学习和探索这些价值观。Scrum 的成功应用取决于人们变得更为精通践行五项价值观。

 

 三、Scrum 开发模型

Scrum 是一种敏捷的开发模型，接下来我们来为大家科普 Scrum 中的 “335 ”是什么。

透明、检视和适应是经验过程控制的三大支柱，支撑起每一个经验过程的实施。

两个关键角色

优秀团队需要这两个角色才能取得成功：Product Owner 为团队指出正确的目标；Scrum Master 帮助团队尽可能有效地达到目标。

Scrum组织中项目管理职责的映射

项目管理活动	产品负责人	Scrum Master	开发团队	其他经理
集成	√			√
时间	宏观层面	帮助Scrum团队有效利用时间	冲刺层面
范围	宏观层面		冲刺层面
成本	√		故事/任务评估	√
质量	√	√	√	编队
团队（人力资源）			√	√
沟通	√	√	√	√
风险	√	√	√	√
采购	√

 

四、Scrum 框架(335)：三大角色、三大工件、五/四大会议

三大角色

• 产品负责人（PO）：代表业务方利益，核心职责对产品的成功负责
  • 为产品的愿景规划负责
  • 管理并排序PBL
  • 为产品需求的ROI负责
  • 接受或拒绝迭代交付成果
• 敏捷教练（ Scrum Master）：带领团队，是 Scrum 流程的引领者，为团队排除开发过程中遇到的障碍，核心职责为Scrum的成功实施负责
  • 执行Scrum框架
  • 帮团队消除障碍
  • 保护团队不受外界干扰
  • 带领团队持续改进
• 开发团队：一般由跨职能的 5-9 人自组织组成，包括研发、测试等角色，核心职责对产品功能交付负责
  • 小团队 5-9人
  • 跨职能、无角色
  • 自组织、自管理
  • 为迭代交付给出承诺
  • 为达成承诺可以要求任何事情

三大工件

• 产品待办事项列表(PBL)：由产品负责人不断更新的一份有优先级顺序的需求清单
• 冲刺待办事项列表(SBL)：每一次 Sprint 都会从产品待办事项列表选出部分来组成本次冲刺的任务清单
• 潜在的可交付产品增量(PSPI)：一个可检查的“完成”工作，每一次 Sprint 就会产生一部分成果，随着这些成果的累计，持续丰富产品价值

五大会议

• 产品梳理会(PBL Grooming)：由产品负责人、产品经理对产品需求进行评审、梳理和设置优先级，这个会议会输出产品待办事项列表
• 迭代计划会议(Sprint Planning)：在一个迭代开始前，三大角色对本次迭代需要完成的内容进行规划，输出冲刺待办事项列表
• 每日站会(Daily Scrum)：开发团队和敏捷教练每天固定开的会议，一般15分钟左右，回答三个问题：昨天做了什么，今天要做什么，遇到了什么问题
• 迭代评审会(Sprint Review)：一般在一个迭代快结束的时候所有干系人参与的会议，对本次迭代的成果进行演示和验收，确保是沿着正确的方向在开发
• 迭代回顾会议(Sprint Retrospective)：在迭代结束后，下一次迭代开始前进行，三大角色对本次迭代的过程进行回顾，总结好的经验和不足之处，以便下次迭代可以更好进行

 五、框架实施流程

在SCRUM框架中重点定义了时间盒子（Time-Boxes）。

在整个项目开始，会召开发布计划会议（Release Planning Meeting），这个会议的主要议题是创建计划和最终交付目标，所有关键角色都会参与进来。
甚至是上层领导或者相关的人员都可以被邀请参加。类似于项目启动会议，会议将确定项目主要人员，理解整体目标，时间要求，潜在的风险等等，以求最大限度的让每个人都意识到自己的职责。
每1个月开一次，产品经理主持。其中每个季度的第一个月为发布计划会议（Release Planning Meeting）。季度中的每个月为 产品梳理会(PBL Grooming)。
每个季度完成一个“外发”版本规划，每个月对各个子版本进行评估， 包括需求管理、需求变更、风险管控、质量管理。

接下来就是多个Sprint周期。在每个Sprint开始，需要召开Sprint计划会议（Sprint Planning Meeting）。这个会议将会讨论哪些功能会作为将要开始的Sprint目标，并且会讨论如何来实现该目标。
在进行Sprint会议之前，Product Owner应当已经定义好了所有或者部分产品“待办列表”（Product Backlog），
在会议上，Product Owner会描述产品的路线图，远景目标和发布计划，团队成员则会对每个在产品“待办列表”中的所有项目进行评估，
从产品“待办列表”中选择优先级高的或者大家认为应当先完成的“待办列表”，作为这个Sprint将要实现部分。会议的成果就是团队从产品“待办列表”挑选部分“待办列表”形成一个Sprint “待办列表”（Sprint Backlog）。

Daily Scrum会议则是SCRUM团队每天一次的例会，关键是让项目的进展，遇到的问题对每个成员都是透明的。
这个每日会议会大大提高团队的沟通效率，如此的话其它的会都可以省略了。在这个每天的例会中会发现一切阻碍开发的问题，会促进快速的决策，并且能够提高每个人对项目的参与度和熟知度，增强每个人的参与度。
在这个会议中每位团队成员都需要参与并发言。其中一个人发言时，其他人都应当在旁倾听。会议还应当关注三个问题，其它问题则可以暂时先记录下来，在会后再去解决。

Sprint Review会议则是在当前的Sprint周期将要结束的时候召开。这个会议的主要目的是了解在当前Sprint周期中，哪些功能完成了，哪些部分完成，因为什么原因哪些没有完成。
还存在哪些未解决的问题，等等。其中还有更重要的议题是由Product Owner对已经完成的一些功能模块进行审查，提出反馈意见。如果有需要更改的部分，则可以考虑放入到下一个Sprint中。

Sprint Retrospective会议则是一个回顾和总结大会。在这个会议中，我们可以回顾上一个Sprint的进展，总结做的好的地方，以便下一个Sprint能够做的更好；发现一些需要改进的地方，提出改进建议，希望下一个Sprint能够有所改变。
最好能够对照敏捷开发的4大理念和12大原则进行评估，每个团队成员都应该认真参与进来。不要把回顾和总结会议当作批斗大会，而是欢快而友好的会议，可以准备些零食和饮料，让大家在宽松的气氛中讨论和发言。
这样，每个人都能够从过往的经历中有所学，有所进步。以下是典型的SCRUM流程图。

 

 

5.1 产品梳理会

 

5.2  迭代计划会议

 

参考文献：

Scrum框架: https://segmentfault.com/a/1190000041278260

 

PMI-ACP知识要点：https://blog.csdn.net/chenhu470/article/details/103390694