谈到敏捷开发，不得不说敏捷开发的Scrum实践。

Scrum框架包括3个角色、3个工件、5个事件、5个价值观。

3个角色

  1. 产品负责人（Product Owner）

  2. Scrum Master

  3. 开发人员（Developers）

3个工件

  1. 产品Backlog（Product Backlog）

  2. Sprint Backlog

  3. 产品增量（Increment）

5个事件

  1. Sprint（Sprint本身是一个事件，包括了如下4个事件）

  2. Sprint计划会（Sprint Planning）

  3. 每日站会（Daily Scrum）

  4. Sprint评审会（Sprint Review）

  5. Sprint回顾会（Sprint Retrospective）

5个价值观

  1. 承诺 – 愿意对目标做出承诺

  2. 专注– 把你的心思和能力都用到你承诺的工作上去

  3. 开放– Scrum 把项目中的一切开放给每个人看

  4. 尊重– 每个人都有他独特的背景和经验

  5. 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

Scrum不可谓不经典，今天仍有很多企业在践行Scrum的实践。除了流程太重。。。

不过也是因为部分实践者过于照搬Scrum实践，生搬硬套地实施各种迭代会议本身就违背了敏捷“快速响应变化”的初衷。

相信不少人或者开发人员都听说过每日站会，每日站会正是来源于Scrum的实践。每天早上开始上班，团队成员聚集在Scrum Master的工位旁边逐个诉说经典的三个问题：

1、我昨天做了什么

2、今天要做什么

3、有什么困难（哪些问题阻碍了我）

一定要站着开吗？不一定，站着开为了要敏捷，快速沟通发现障碍并解决。但是，站会要简短，15分钟内要开完，6、7人的团队每人不能超过两分钟。

Sprint设置多长比较合适？不少专家推荐2-4周。其实个人觉得过时了，1周就可以，正好和各大厂习惯的周会、周报联动起来。

Sprint计划会议、迭代会议、回顾会议开多久合适？我的答案是，不开合适。这个也是Scrum不够敏捷、被吐槽最严重的点。每周花1-2小时开这个会真的是，让他们干活儿啊，不要一直开会。

感觉一个看板就能对齐了。或者产品自己规划好每个阶段任务，按需组织需求计划会议或者复盘会议即可。

个人觉得，Scrum更适应稳定期的业务，按部就班做计划，完成计划任务，复盘改进。如果当前处于这种业务场景，可以更放心地尝试。如果一会儿插入一个需求，计划赶不上变化，计划白做，Sprint很可能沦为摆设，各种完不成。

敏捷的实践没有银弹，关键是活学活用，Scrum框架依然值得一试。

参考：

[1] https://support.huaweicloud.com/reference-devcloud/devcloud_reference_030203.html

[2] https://www.scrum.cn/scrum/26797.html

[3] https://www.atlassian.com/zh/agile/scrum#continued

[4] https://cloud.tencent.com/developer/article/1554614