Scrum 敏捷开发

Posted 2020-06-27 吾将上下而求索……

使用敏捷开发一个月的事件，基本的开发模式跟我遇到的这个文章介绍的基本类似，暂时简单Copy到了这里......

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html
适合码农工作时玩的游戏： Scrum
http://mp.weixin.qq.com/s?__biz=MjM5NTIyNTUyMQ==&mid=200580964&idx=1&sn=206ca28b5c8cd05143fe9d065e27ff73&scene=1&srcid=0127UZwBURBMbjtLW31iugnU#wechat_redirect

* 正如Scrum官方指南所说，“Scrum是易于理解，但难以精通的”；
1. Scrum是游戏规则
1.1 官网的中文版本<Scrum指南>,封面上写下了其最核心原则：游戏规则。
1.2 游戏规则：玩游戏的人为了更好地娱乐而制定的规则。
Scrum规则：为了让大家更开心，更有效地工作，而不是约束大家。
1.3 事实上，Scrum只是一个框架，
所以在实践Scrum时，更多的规则需要团队成员共同制定，
这体现了游戏规则的思想-- 大家自己制定的规则，必定得到大家一致同意的，能让大家舒服工作的规则；
2. Scrum是基于经验的
2.1 Scrum强调经验的重要性，但是经验又是需要不断调整的，
所以Scrum通过迭代增量的开发方式，来每次调整整个团队的经验，从而来优化可预测性。
2.2 例子：
我们在开发猿题库时，在每轮Scrum的结束时，我们会开回顾会议，将大家每天处理待办事项的速度（我们称做日均Story Point）总结在Wiki中，如下图所示。
这样当我们估计一个新一轮的迭代工作是否能够完成时，就可以参考前面几十次的经验，做出更加理性地判断。
日均Story Point图表
3. Scrum的三大支柱
透明性、检视、调整
3.1 透明性： 团队成员要达到对信息的完全共享，以便对观察到的信息有相同的理解；
3.2 检视： 团队成员要不停地检查自己的状态，类似汽车的定期检查一样，通过检视了解当前项目的状态。
3.3 调整： 团队成员发现出现了会影响项目进度的事件后，要及时寻找对策
-- 群体智商常常会出现低于个体智商的现象，这是因为个体之间的信息通常不一致，每个人的信息都是片面的，所以造成了观点的片面，而通常情况下团队领导由于接受到的信息更全面，所以他的决策考虑会更周到一些。
--- 但是Scrum又强调团队需要是“自组织”的，这就需要群体进行决策而不是领导。
为了群体更好的决策，所以Scrum特别强调信息的透明，这样大家的信息都是充分共享的，
而检视是一种保证信息透明的方法，即定期地查看自己和团队的状态，
有了信息的透明，这样团队成员就能共同发现项目执行中的问题，进而一起寻找解决办法，从而达到“自组织”的团队。
4. Scrum的基本游戏规则：
Scrum定义了基础的游戏规则，在基础的游戏规则之上，团队可以依据自己的经验，制定更细致的规则。但更细致的规则不应该违背基础的规则。
4.1 角色定义
产品负责人：产品负责人是管理产品待办列表的唯一责任人，也是产品最终的责任人。
简单来说，最终如果产品没做好，应该扣产品负责人的工资。
开发团队： 开发团队是负责将每轮Scrum迭代中计划的功能（可能是产品稿+美术稿的形式），交付成可发布的产品的各种专业人员。
这里的各种专业人员包括：服务器端开发、javascript前端开发、客户端开发、测试人员等。
开发团队是真正在玩这个Scrum游戏的人，其他人（例如产品负责人都只是部分参与）
Scrum Master： Scrum Master类似于杀人游戏中的法官，即游戏组织者。
Scrum Master并不是团队的领导，他仅仅是做一些组织工作，
而对于一个“自组织”的团队来说，其实真正需要组织的事情也不太多，所以他常常由开发团队中的某一个人兼任。

4.2 没有子团队
在Scrum的官方文档中，这样说道：
** Scrum 不认可开发团队中的所谓“子团队”,无论是测试还是业务分析的成员都不能划分为“子团队”。此规则无一例外。

== Scrum在定义角色的时候，强调开发团队中一个整体，包含把产品发布出来的所有相关的专业技术人员，并且开发团队共同承担开发的责任，只有这样，大家才能形成利益共同体，共同努力把产品做好。

一点也解释了为什么很多大公司玩不好Scrum。团队没有共同的利益，是很难做到“自组织”的。

4.3 强调平等
Scrum中仅定义了“开发团队”这个整体的角色，在“开发团队”内部，大家都是平等的。
因为只有这样，大家才能更加自由的共享信息，共同决策，否则决策权仍然掌握在少部分人手里

Scrum的官方文档中，是这样说的：
** Scrum 不认可开发团队成员的头衔，无论承担哪种工作他们都叫做开发人员。此规则无一例外。

4.4 游戏人数规则
开发团队还有一个不能不说的特点，就是他的规模必须足够小，因为他强调信息的透明，如果人数过大，光沟通的成本就大到无法承受了，
所以官方文档上推荐的人数是 10人以内（不包括产品负责人和Scrum Master，除非他们也参与开发）。

但是在实际执行中，由于业务的增长，团队人数很容易就超过10人。
这个时候，比较好的做法是进行团队的切分，
比如我们试过将服务器端和客户端进行拆分，这样保证每个团队还是在10人以内。
如果以后再增长，可能客户端会再进行拆分成ios团队和android团队。

4.5 游戏时间
Scrum对每一轮的迭代时间并没有严格的规定，但它要求是小于一个月。
对于每一轮的迭代，Scrum把它称作Sprint（冲刺）。

作为创业公司，我们在最近两年都实践着一周一次Sprint的方式来工作。
一周一次Sprint能够保证调整足够快，Sprint执行中是不鼓励需求改动的。
所以一周一次的Sprint能够做到，对于比较急迫的需求改动，在下次Sprint时（下周）就可以执行。

一周一次的Sprint也有不少问题，由于偏离本文主题，所以就不展开介绍了。
现在我们的项目组也在尝试进行2周一次的Sprint。
总之，Sprint多长是由开发团队根据项目的具体特点来决定的，只要不超过一个月即可。

4.6 游戏玩法
Scrum定义了4个事件，分别是：
a. 计划会议
b. 每日站立会议
c. 评审会议
d. 回顾会议

4.6.1 计划会议
计划会议主要通过讨论，完成两件事情：做什么、怎么做。
* 关于“做什么”：
产品负责人会给出一个产品待办列表，然后由团队成员来根据预计的工作量以及以往的表现，来挑选接下来的Sprint需要完成的待办项。
特点：由开发团队成员自己来挑选待办项，而不是由传统意义上的Tech Leader或产品负责人来挑选。
好处：这样保证了开发任务是由团队成员自己决定的，他更有责任心把事情完成。
同时作为产品负责人，有必要非常明确地告诉开发团队每一个待办项的意义和重要性，这样开发团队才能做出有利于产品的挑选工作。
* 关于“怎么做”：开发团队从待办列表中挑选完需要完成的待办项之后，就需要对每个要做的待办项进行评估。
评估的工作就是讨论具体怎么做，这包括技术架构、实现细节的讨论。
只有讨论得非常清楚之后，这项工作的工作量才会比较清楚。
PS：在讨论怎么做之后，一些敏捷公司推荐使用“出牌”的方式来评估工作量，我们也采用了这种方式，我们还专门做了一套Scrum扑克，用于出牌。
出牌的规则是每个人出一张牌，用牌上的数字表示当前工作的工作量。
通常大家还会事先约定好数字2代表的工作量，以保证大家的标准相同。
为了避免相互影响，大家先把要出的牌扣着，然后同时翻开。
之后，出最高分的和出最低分的同学要表达意见，说明为什么自己估计成这样，大家讨论，
这样的过程可以保证大家的信息都是透明的，即没有忽略掉的技术实现难度或细节，在信息充分共享的情况下，通常大家第二次出牌时就可以达成一致了。

4.6.2 每日站立会议
每日站立会议是进行检视的方法。
通常选择固定时间（我们是每天早上10点10分开），以养成团队工作习惯来避免组织成本。
站立会议要尽量的短，通常控制在15分钟以内，选择站着开会，也是让大家有更大的预期快速结束。
* 站立会议主要是为了沟通，以及发现潜在可能的问题，在站立会议上，团队成员每个人要讲3句话：
-- 我昨天做了什么
-- 我今天打算做什么
-- 我遇到了什么问题

通过这3句话来达到高效沟通的目的，对于会上提到的问题，通常是下来相关人员自行解决。
站立会议通常能够发现项目进展的状态是否顺利，从而尽早采取相应的措施。
时间较长的Sprint可以配合燃尽图，更方便地审视项目进展速度。

4.6.3 评审会议
Sprint 评审会议在 Sprint 结束时举行，用于检查计划中的工作，哪些完成了，哪些没有完成。
在我们的实践中，我们会让开发的同事演示自己所做的功能，然后PM会看这个功能是否达到了要求。

4.6.4 回顾会议
a. 回顾会议是开发团队检视自己，发现团队运转中的问题，并且定制游戏规则的过程。
通过对前一个Sprint中的人、关系、过程、工具进行检视，团队成员能够总结出做得好的，和做得不好的。进而制定一个改进的方案。
b. 回顾会议是Scrum创建“自组织”团队的关键，它将团队自我改进变成了一个例行的会议，
在这个会议中，讨论的都是大家对该游戏的感受，包括好的和不好的，最终大家为了玩得更爽，就会发扬好的，努力避免不好的，成为一个能够自我进化的集体。
c. 需要注意的是，回顾会议不应该成为吐槽大会，大家应该本着发现问题，解决问题的态度来讨论。
例如：如果在回顾会议仅仅是抱怨产品老是改需求，或者抱怨时间不够，而不提出解决方案的话，是非常不好的。
d. 提出问题是容易的，麻烦的是提出解决方案。我们的老大提出了一个办法，即我们思考：“如果再来一次，我们能不能做得更好”？如果我们发现，如果再来一次，由于客观原则，我们可能仍然无法避免同样的问题，那么我们就选择坦然接受而不是抱怨。
e. 因为很多时候本来就没有完美的、没有任何问题的解决方案，这就像软件都有Bug一样，如果Bug不可避免，我们就选择发现的时候尽量修复而不是编码的时候避免。

4.7 框架图
a. Executives： [ig‘zekjutivz]
n. 高管们；主管们；执行管理者，执行主管（executive的复数）
b. Team: n. 队；组
c. Stackholders [‘steikhouldeo]
n. 利益相关者；赌金保管者
d. Customers
顾客，客户
e. Users
用户

Product Owner： 产品负责人 ; 产品经理 ; 产品拥有者
Product Backlog： 产品待办事项列表
Product Backlog Item 产品积压工作项 ; 产品积压工作项
Sprint Planning ：迭代计划,计划会议 ；
Sprint Planning Meeting ：会议,迭代计划会,迭代计划会议
Sprint Backlog 冲刺订单
Scrum Master: 敏捷管理员
Sprint end date and team deliverable do not change
1-4 week sprint
Burndown/up Charts 燃尽图 -- Every 24 Hours
Daily Scrum Meeting 站立会议
Sprint Review
Finished Work 完成的工作
Sprint Retrospective Meeting 回顾会议 ; 冲刺回顾会议 ; 迭代回顾会议