一篇文章讲透为什么我们IT行业一定要用Scrum
真实世界是一个复杂而多变的世界
这个世界的规则可以分为四个象限，简单，有序 到 复杂，无序。当我们的IT从业者进入的是复杂无序的领域（混沌），你会发现传统的研发模式已经不能适用于你的业务需要。
传统的瀑布式或者螺旋式模型，源头来自于哪里？
源头来自于工业革命之后兴起的工业生产流水线。每个产线要根据生产计划早早的排定生产任务，按时按量按部就班或者加班加点完成既定任务，部门领导和车间主任将生产过程拆解为简单有序的步骤
形成瀑布形式的计划表和甘特图，这种传统的瀑布式模型是计划驱动的，它的成功有一个前提，就是计划对应的需求，是不变的。
当面临需求的变化时，这种模式就会不适应，规模越大的计划，其变更的成本和所造成的浪费都是巨大的。项目超期、预算超支，最终的产品还不是用户想要的。
放在IT团队，需求的变化使瀑布模型经常遭遇很多问题，譬如：
- 同一个需求变更频繁，还临时加需求，计划又乱了
- 一句话需求，不知道怎么执行
- 已经做了90%，你说需求不用做了
- 不管你们怎么搞，必须在xx日上线，计划反复
- 需求就是这样写的，就这么做，错的也是需求的错
- 都开始开发了，还改需求
- 需求没澄清，开发晚了，又挤占测试的时间
等等还有很多，包括一些貌似是研发或者测试的反馈，其根源也是瀑布模型计划的局限性导致的。
有人说：我们的项目也有这些问题，但是我们还是按期上线了啊，项目很成功啊。
是，有可能是。我们知道，项目管理的铁三角：范围/质量，资源/成本，时间。
如果你的项目保障了范围保障了如期上线，那必定在成本上增加了。
比如996，比如只给象征性的加班费的无偿加班，比如名义上不鼓励加班实际自愿加班
又比如其实并没有保障质量，硬着头皮带病上线，事后找补
又比如根本没有保障范围，只优先做了看得见的功能。
又比如为了上线而上线，并没有使用更合适的方案，只用最快的方案。
怎么才能解决这个问题呢？
20世纪中期的日本汽车产业当时就遇到了这个问题。 大家知道，日本的资源很匮乏，技术也比欧美差，如果用瀑布式大批量生产，是不能及时响应市场变化的，同时造成的浪费对日本来说是毁灭性的。
丰田汽车的大野耐一等人就结合日本的国情，找到了一条丰田生产方式：这是一种多品种，小批量，高质量和低消耗的精益生产方式。精就是追求质量价值，益就是极大的避免浪费，持续改进。
有很多人把这个精益思想，从工业领域，应用到各行各业。比如精益创业，精益软件开发等等。
精益软件开发吸取的就是精益思想中的减少浪费、单件流持续改进的思想，基于这个思想，软件开发行业也形成了很多流派，他们开了一个会，形成了敏捷宣言：
http://agilemanifesto.org/
- 个体和互动胜于流程和工具
- 可工作的软件胜于面面俱到的文档
- 客户合作胜于合同谈判
- 响应变化胜于遵循计划
这个敏捷宣言的敏捷，是Agile。只要是遵循这个宣言的方式方法，都是敏捷的，所以这些流派统一组成了敏捷联盟
小批量短周期的持续交付可工作的软件，它主要并不是说能提高开发的效率，而是响应变化，减少浪费。
在这个联盟中最大的一支，就是Scrum，它是一个价值驱动的轻量级的框架。
看一下原文定义：
Scrum is a framework to address complex adaptive problems,it allows human who work in groups to focus on delivering the highest business value in the shortest time,with an iterative and incremental approach.
我的翻译：Scrum 是一个解决复杂多变问题的框架，以迭代和增量的方式，让一群合作者专注于在最短时间内交付最大商业价值
这个是理论，是道，那么术呢，具体怎么做呢。
可能很多人都知道，
一个Scrum团队有三个角色：Product Owner（产品负责人），Scrum Master（敏捷教练），Developers（开发团队）
产品负责人的责任，就是抉择最有价值的需求
敏捷教练的责任，就是保护团队，工作聚焦，排除障碍，践行Scrum原则
开发团队的责任，就是保持聚焦，完成增量
每次开始一个Sprint，原始需求方会授权产品负责人要从Product Backlog（产品待办列表）里面挑出来本次Sprint要做的事项和优先级，建立统一的Product Goal（产品目标），
然后在Sprint Planning（计划会）上，由Developers对任务进行拆解，形成Sprint Backlog（迭代任务），进行任务评估（故事点）和分工
然后进入研发执行，每天举行Scrum Daily（站会）同步进展、障碍并随时调整工作事项
在Sprint末尾，Developers交付符合完成定义的增量，比如具体的明确的可验收的事先达成一致的功能和交互页面。
然后举行Sprint Review（评审会），确认是否符合完成定义的增量，做检视和调整
最后举行Sprint Retrospective（回顾会），对整个Sprint过程，
最后两个会分别在事和人的维度进行反馈，以便前置风险，打破管理的幻觉。
改进项要遵循smart原则，以期下一个Sprint进行具体改进。
有人可能就说了，你这Scrum还有精益，说了半天，不就是互联网行业常说的“小步快跑”的模式吗？
是，也不是。我在互联网行业干管理一直干了7,8年，小步快跑是真的，但是这只是表象，根没变，还是瀑布。
瀑布基于计划驱动，它在管理上有一个核心本质，就是不需要人进行思考，只需要像机器一样执行，打螺丝，吹灯泡，不要思考，我排计划的时候都思考过了，应该是怎样，新手大概多少时间，老手大概多少时间，你们就照做。这就是为什么你即使在互联网大厂，你也没有发挥出你自己的主动性，而是拧螺丝了。
Scrum的本质是什么，《孙子兵法·谋攻》有云，叫“上下同欲者胜”。敏捷的本质，是要整个研发团队提前对齐目标，拧成一股绳，产品负责人负责做关键的艰难的价值抉择，具体怎么实现怎么做，整个研发团队自己决定，没有人告诉你应该用什么方案；研发工作是脑力劳动，你把他当成体力劳动来使唤，那么必然导致的结果就是，我能摸鱼就摸鱼，最好下班就走，能混着就混着。
本质的区别：
- 计划驱动 变为 价值驱动
- 拒绝变化 变为 避免浪费，不做或者少做无价值的事情，拥抱变化。
- 理论上不需要加班
接下来，我们来实际应用一下Scrum，做一个体验。
我们就拿2022年卡塔尔世界杯来举例，不要小看体育赛事，世界杯的比拼，不仅仅是运动员和教练的比拼，也是科技的比拼。
2009年金州勇士（Golden State Warriors：GSW）队是NBA倒数第二名的球队，6年之后，它是总冠军，创造了常规赛的记录，82场比赛赢了73场。
当时它作为倒数第二的球队，连好的球员都没有，KPCB的一个合伙人联合youtube的创始人一起买下了这个球队，然后对它进行技术改造。
它的技术团队用了2个最常见的技术，一个叫SportUV（数据跟踪），跟踪所有的记录。一个叫MOCAP（数据决策），它跟踪每个人的训练结果和比赛结果，就可以识别出每一个人的优势和劣势，然后分析制定一套方案，什么人打什么位置最合适。像格林就是被系统挖掘出来的,后来格林甚至进入过NBA全明星队。
高尔夫球也是如此。像高尔夫球的职业球员，都是背着可穿戴设备训练的，可以模拟全世界的高尔夫球场地，相当于还没比赛就在赛场训练过，考过驾照的都懂，能提前在考场模拟，对考试会有多大帮助。像tiger woods这样大的年纪，去年还拿高尔夫大师赛的冠军，在过去是不可想象的。
足球也是一样，英超的一些球队，在比赛之后就进行全身肌肉检查，而不是等你受伤了才去看是不是有什么问题，这个肌肉状态是该增加训练还是减少训练。
我们来用Scrum的模式做一个事，大家结合我上面讲的，体会一下异同点：
大老板给Scrum团队提了个需求，要求预测一下2022卡塔尔世界杯的排名
我们先选定Scrum团队里的角色：
ScrumMaster:文和
Product Owner:P总
Developers：D团队
首先，P总针对需求构建Product Backlog和Product Backlog Item:
预测2022卡塔尔世界杯的各球队排名，以便于指导老板做战略投资（狗头）
- 2022卡塔尔世界杯的小组赛预测 （Product Goal)
- 2022卡塔尔世界杯的淘汰赛预测
- 2022卡塔尔世界杯的决赛预测
由于本次Sprint时间有限，资源不足，P总只选了待办清单的第一条，并选取它作为了本次的产品目标。
Sprint Planning：计划会开始，所有人开始对齐和精化任务，确认对完成的定义-本次世界杯小组赛的预测结果图像展示
Sprint backlog：
2022卡塔尔世界杯的小组赛预测
- 数据集的准备-从1870年开始到2022年截止，所有参赛球队的历史交手成绩- 1个故事点 - D架团队-小A
- 模块导入-数据分析和可视化pandas、matplotlib、eaborn，机器学习预测sklearn- 1个故事点 - D团队-小A
- 探索性数据特征-比分特征，比赛当中的比分来判断比赛是谁胜谁负或者是平局-- 1个故事点 - D团队-小B
- 数据集的导入-AI训练- 1个故事点 - D团队-小B
- 2018年俄罗斯世界杯的参赛队伍做数据验证-AI验证- 1个故事点 - D团队-小A
- 逻辑回归算法预测结果-AI预测结果- 1个故事点 - D团队-小B
Scrum Daily每日站会：
每日三问：昨天做了什么，今天准备做什么，有没有什么阻碍。
小A反馈有阻碍，kaggle上的数据集有问题，而且不需要1870年这么久 。
此时，敏捷教练站出来干预，具体技术问题在会后专门讨论，站会不要展开具体技术问题。
小B反馈已经完成3，因为下一步4有依赖，准备协助小A完成1，目前没有阻碍。
把完成的事项从卡片墙上的todo，移到done。
如此几轮之后，D团队得到已定义的完成增量：
卡塔尔 VS 厄瓜多尔 获胜者：厄瓜多尔 卡塔尔准确概率：0.388 平局概率：0.506 厄瓜多尔准确概率：0.106 伊朗 VS 英格兰 获胜者：英格兰 伊朗准确概率：0.645 平局概率：0.290 英格兰准确概率：0.065 塞内加尔 VS 荷兰 获胜者：荷兰 荷兰准确概率：0.732 平局概率：0.163 塞内加尔准确概率：0.105 墨西哥 VS 波兰 获胜者：波兰 墨西哥准确概率：0.422 平局概率：0.331 波兰准确概率：0.247 澳大利亚 VS 法国 获胜者法国 澳大利亚准确概率：0.655 平局概率：0.213 法国准确概率：0.133 摩洛哥 VS 克罗地亚 获胜者：克罗地亚 摩洛哥准确概率：0.531 平局概率：0.313 克罗地亚准确概率：0.156 美国 VS 威尔士 获胜者：威尔士 美国准确概率：0.562 平局概率：0.121 威尔士准确概率：0.317 沙特阿拉伯 VS 阿根廷 获胜者阿根廷 沙特阿拉伯准确概率：0.814 平局概率：0.139 阿根廷准确概率：0.047 突尼斯 VS 丹麦 获胜者：丹麦 突尼斯准确概率：0.623 平局概率：0.242 丹麦准确概率：0.135 日本 VS 德国 获胜者德国 日本准确概率：0.706 平局概率：0.188 德国准确概率：0.107 哥斯达黎加 VS 西班牙 获胜者西班牙 哥斯达黎加准确概率：0.804 平局概率：0.139 西班牙准确概率：0.057 加拿大 VS 比利时 获胜者：比利时 加拿大准确概率：0.806 平局概率：0.120 比利时准确概率：0.074
清单的图形化展示作为增量交付物，满足完成的定义：
Sprint Review：
大老板，P总，文和，D团队一起展示了工作成果。P总验收了大家的工作，满足团队定义的质量。因此，在这次会议期间，团队庆祝了他们的成就，大老板即时反馈了意见和建议。
Sprint Retrospective:
P总，文和，D团队一起选出本次Sprint做的好的3个点，有待改进的3个点，以及具体的可度量的3个改进措施。
这就完成了一次Sprint。
这是比较顺利的情况，真实的情况比这个复杂的多，只是给大家一个基本例子
大家如果在实际工作和管理中有什么问题，欢迎留言或者加微信，微信在左侧
