不自觉间，“敏捷”这个词听到的越来越多，之前都是看过一些短视频或者公司的一些类似于讲座性质的介绍，最近一次是有听过一个跟“精益”生产的对比。
引发了好奇，也是无意看到公司发的一封邮件里面，点进去看到有一本书叫“敏捷革命”，看了一下简介，瞬间决定借出来看看，用了一些零碎的时间花了几天看完，不免有一些感想。
“敏捷革命”这本书呢，是杰夫·萨瑟兰所著，他是制定火出圈的“敏捷宣言”的17位参与者中的一位，被誉为“Scrum 之父”，其Scrum是众多敏捷开发方法论其中一种。嘿嘿，这里不免让我联想到了“零缺陷之父”菲利浦·克劳士比。
顺着写写，两个“父亲”还真有些共同点，其方法论都火出了圈子，Scrum 敏捷开发源头是用在软件开发，但现在已被广泛应用于多种场景，书中就介绍了很多成功的场景，如用在教育，解决贫穷，战地新闻报道等等，而零缺陷起源于制造业，也是被推广用到服务业，金融业等等。
“敏捷革命”一书中第五章有个小标题一次性地把事情做好，而这个是“零缺陷思想”的核心之一，我不知道萨瑟兰有没有也看过克劳士比写的书，他在书中没有提及。
聊到这里，其实Scrum思想源头跟质量还有更大的渊源，Scrum的本质核心是PDCA, Plan-Do-Check-Action, 都很熟悉的PDCA循环，其来源于另一位质量大师戴明。而有趣的是来自美国的萨瑟兰建立Scrum理论是出自于日本的大野耐一的“丰田生产方式”及为人熟知的精益生产，而二战后的日本整个制造业的思想都多少来源于美国人戴明，绕了个圈。
回到Scrum本身，我在网上找到了一张图片，来源不详，比较全面地描述了Scrum方法论的全过程。
Scrum方法论用书皮上所讲，用一半的时间做两倍的事情。怎么样？很熟悉吧，中国的一个成语事半功倍不知道莎瑟兰晓得吗，效率如此之高怎么做到的呢？
核心就是PDCA, 成立一个小而精的团队，领了一个任务，拆分并划分优先级，以优先交付可使用的最有价值的用户故事为核心，进行迭代开发，关键来了哦，每个拆分的小故事完成以后，要进行回顾，回顾后不得了，这个小团队已经不是昨天的小团队了，它进化了。
这就是核心，这个小团队是不断通过回顾，克服之前的障碍，不断进化的一个团队，他在完成下一个任务的时候将会比之前更加高效，而且进化后的团队还是服务于这个大的任务，他不是说积累些教训等到给未来未知的项目，他直接就用上了，时效性非常强。
理念非常好，具体还有非常多的一些其他理论，像之前说的“一次就把事情做好”，以及“二八法则”，“重要的事情优先做”，“杜绝浪费”“最佳团队数量为7人满足高饱和沟通”这些耳熟能详的都有在此书中论述，都要运用到Scrum实际执行当中。
对于耳熟能详的一些感想就不单独赘述了，但不是说不重要，其实都非常重要，这里聊一聊有些新感触的点。
聚焦团队，而非个人
这个话题其实非常老，对吧，团队利益高于个人利益。这个要从Scrum的内在来源说起，作者取名Scrum，灵感来源橄榄球即如图示的叫并列争球，一个队的队员前排肩并肩，后面的肩并肩顶着前排人的臀部，这样形成合力来争抢球。
这就是团队的力量，更重要的理念是要想让一个人效率提升10倍和让一个团队效益提升10倍，这之间的难度完全不是一个量级。所以随之带来的任何能提升团队作战能力的行为都值得被鼓励，相反任何带来负面能量的人和行为都需要及时发现和剔除。
所以，如果Scrum团队里面即使有个别英雄能力非常强，但是他无法融入团队甚至于带来负面的能量，这样的英雄也将无法存在于Scrum团队。
短期规划，快速行动
看到文中最初的那张Scrum流程图，有个Sprint，在Scrum里叫冲刺，即1-4周为一个周期进行迭代，短到每1周就完成一个交付物，交付物在Scrum里叫“最简化可行产品”。
Scrum团队也会有规划，但和传统的瀑布法花几个月甚或更久的时间把整个项目按照阶段-节点的方式全部文件化不同，Scrum只做短期的规划，短到甚至只够团队干一个星期，一个星期后就交付一个供客户实实在在能用的产品，而且是客户最想要的那部分。
为什么规划这么短？上图不确定圆锥做了很好的解释，刚开始的规划离最后的目标会偏离很大，两个极差点有16倍之多。
这里其实给我有很多的启示，一个有规划的人往往被认为很靠谱，但如果执着于规划反而可能适得其反，所以适当规划，有个能成型的预判，就立马行动做出来让别人用，这个时候再根据别人给的一些建议和意见，迅速做调整再进行规划。不断循环。
最简化可行产品
慢工出细活，匠人之心，这些常挂在嘴边的话语往往也会有反面的效果，在Scrum里面正如图上所列，能以最快的时间，最少的成本，最单一的功能实现最大的价值就是应该最先完成的。
这个就是“最简化可行产品”的核心。
颠覆，确实颠覆。花的时间少，成本低好理解，往往理解功能多是正面的，其实不然，价值才是最重要的。想一想其实也能想通了，功能齐全但往往其中更多是锦上添花，而不是必须的了，所以其相对于基础功能的价值而言也就更没那么高了。
那么对于敏捷理念而言，越是初期越是资源少应该越聚焦于交付功能单一但价值高的方案。
文中更是列举了实例，非常感触，因为很多情况外部客户需求不是一成不变的，很多时候甚至在Scrum团队进行一轮冲刺后，完成80%的最简单可行产品交付后，客户发现已经足够了，就没有必要再往下开发了。这就是敏捷的最实际价值，随时可根据外部情况变化而做出积极改变。
回顾的细节
上文也提到了，Scrum是把一个完整的拆成很多个客户故事，然后以冲刺的形式挑最有价值的来完成，循环往复，每个冲刺结束和下一个冲刺开始之前都会有一个回顾。
重要的来了，回顾的目的不是为了归因，就是找一个人然后把所有的问题都归结于这个人身上，然后结束。这种方法太令人沮丧了。
回顾的唯一目的，就是找出障碍，然后剔除障碍，提升整体团队效率，直接作用于下一轮冲刺当中，没错就是PDCA循环。
更为重要的是，知道了以上这个大原则后，说出皇帝没穿衣服的那个人应该值得所有人鼓励。这个时候真的需要勇气了。
团队氛围是一方面，但依然需要有勇敢的人，直指团队的最大障碍所在，勇敢的人说出障碍，勇敢的人接受批评并改善，勇敢的团队手拉手优化流程，清除障碍。我都要唱出来了。
更少的工作时间，更高的价值交付
书中有写一个马克斯韦尔曲线，无论是Scrum，还是传统的瀑布，超过一定的工作时长后整体完成的工作量都是下降的，直接可以看出Scrum法每周的最佳工作时间就是40h，划下来每天工作8h，我想着这条是不是让Scrum法火出圈的原因。
这里我为什么对此有感想呢？因为很多公司都提的让员工不加班，多休假，常提的就是工作和生活要平衡，要照顾员工的心理和身体健康，这个当然非常棒，但即使从工作本身的维度讲，到点下班也是更有利的。
一本书又带来了一些新的理念和认识，接下来就是去实行了，其中我最有感触的就是其中两条的结合，简短规划做出最简化可行的产品。那么看了文章的你呢？
,
