SCRUM 革命

Posted 2021-04-25 阿伦阅读

Scrum其实就是一个思维框架，在面对未来一切无法估量的可能中，通过观察和快速改变，去应对一切。其实跟我现在从事的教育行业的概念高度重合，目前的主流教育，其实也是妄图使用陈旧的知识让学生去面对未知的未来，当下的教育并没有以学生如何面对未来为核心，那么如何才是真正的能够帮助孩子更好的面对未来，那就是不断学习，不断调整自己的知识框架，通过适应社会去改变自己。

Scrum方法其实也很简答（应用在项目中）：就是无论你什么时候启动一个项目，一定要经常检查一下自己在做的事情，看看是否朝着正确的方向前进，结果是不是大家真正希望看到的？是否有什么办法能够改善目前正在做的事情？如果才能做得更快更好？存在哪些潜在的障碍？

敏捷的最原始来源其实是来源于戴明的戴明环，也就是PDCA循环。而且结合了，OODA循环（观察-导向-决定-执行）

而人类的生命毕竟是有限的，时间是有限的，如何在有限的时间内让效率最大化？答案就是做最重要的事情，在软件开发领域，有一条根据数十年工作经验总结出来的原则，即在任何一款软件中，80%的价值来之20%的功能。所以说，我们如何识别那带来直接价值的20%，并且优先完成就显得十分重要。 而对于商业或者产品来说，如何寻找那20%？一个关键问题在于你先决定自己要做什么。要在这个问题上作出决定，你要问自己下列几个问题：哪些事项最优商业影响力？哪些事项对顾客最重要？哪些事项最有利可图？哪些事项最容易实现？要知道，清单上有很多事项是你永远不会触及的，但是对那些能在最低风险下创造最多价值的事项，应该一开始就先着手落实。

而在生活或者工作中，这个观点也能够得到很好的验证，把你一天要完成的工作列出来，然后按照重要性排序，从最重要的工作内容开始并且保证专注，那么即便今天的状态不好，只完成了几项工作，但是这几项工作就是最重要的事情。

不得不反复提到的就是jeff的敏捷宣言： 

1. 人胜过流程： 

2. 可以使用的软件胜过面面俱到的文件； 

3. 客户合作胜过合同谈判； 

4. 应对变化胜过遵循计划。

而对于商业，作者的观点与我所认知相同，作者认为失败得快，才能迅速改正。也就是我们常说的快速试错。但是很多公司文化往往更加注重形式、程序和会议，而不是在短期内创造出可供用户检验的价值。无法创造价值的工作是疯狂的愚蠢之举。把项目分解为多个小循环（迭代），可以让早期用户及时提供反馈，就能够避免浪费精力。

而就敏捷而言，最重要的不是敏捷方法，而是人—团队。一个高效并且能够无缝对接外部的团队才能够真正的敏捷。

另外，在站会上作者也说明了站会的意义，我之前理解站会无非就是汇报工作，说一下昨天干了什么，今天打算干什么而已，很硬性甚至让人感觉不自在。但是作者定义站会的目的其实更希望像是打篮球比赛短暂停的时候，大家为了赢球积极的讨论展示，不同位置的球员在说明自己的情况和接下来要做的事情，并且跟其他球员说明一下自己这个位置目前遇到的问题，大家把计划和障碍说出来之后，整个团队就会对不同位置的情况得到了解，并能够调整自身的计划甚至在兼顾自己位置的同时给予其他位置以帮助。目的在于团队渴望获得胜利。这才是站会的核心：团队共同了解情况和解决问题。

对于产品的完成，并不是指需求输出或者开发完成测试完成，一款产品的完成意味着能够被消费者使用，完整的，可交付的产品。所以在一个迭代或冲刺中，交付的是完整可发布的内容。没有做完的工作和无人使用的产品本质上是一样的，你付出了努力，最后却没有收获积极成果。

而对于用户故事，用户故事需要满足INVEST标准： 

1. 独立性（Independent）——尽可能让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得定制计划、确定优先级和工作量评估都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。 

2. 可协商性（Negotiate）——用户故事的内容是要可以协商的，用户故事不是合同。一张用户故事卡片上只是一个简短的描述，不包括太多细节。具体的细节在沟通阶段提出。如果一张用户故事卡片带有太多的细节，实际上会限制和用户的沟通。 

3. 有价值（Valuable）——每个用户故事必须对客户具有价值。一个让用户故事有价值的好方法是让客户来写下它们，一旦一个客户意识到这是一个用户故事，并不是一个契约，而且可以进行协商的时候，他们将非常乐意写下故事。 

4. 可评估（Estimable）——开发团队需要衡量用户故事，以便确定优先级和工作量，并便于安排工作计划。 

5. 规模小（Small，合适的粒度）——一个好的故事要尽量维持小规模，至少要确保在一个冲刺周期能够完成。用户故事越大，在安排计划、工作量评估等方面的风险就会越大。 

6. 可测试（Testable）——一个用户故事要可以测试，以便确定它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它上面时候可以完成。

另外，关于评估点数的使用，原来执行过一次quick start，在分配点数的时候我不是很理解，在这里算是明白了一些，点数主要给项目实际执行人对故事难度进行预估，这里的预估并不是用来预估时间，而是用来预估故事卡片各自的难度。而当在预估难度后，开始每周冲刺后，团队会对难度的预估越来越准确，管理人员也会对团队执行项目的速度越来越清楚。到这里，在未来有新的项目或者卡片，团队就能够很清楚的了解自己在每个冲刺能做多少，管理人员也能够掌握团队大概要用多少个冲刺才能够完成，并给出比较准确的时间。

好的产品有三要素组成：满足需求，商业可持续，技术可实现。 而对于产品负责人来说，产品前景由你能制造的产品，你能卖掉的产品，你充满热情的产品组成。

敏捷革命这本书不是一本敏捷指导工具书，更多的是jeff先生表达敏捷创立的初衷，敏捷不仅可以应用在开发过程，我们日常的生活也可以得到应用，再次强调敏捷是一种思考框架，不是一种方法。