我写的为什么这么Low

自从开始写这个公众号后，有一些朋友总会问我——你为什么要写这些东西？你写的太基础了，太Low了。

嗯，是的，我承认真的很Low。

但，依然有必要。Low，但不简单。

行业现状

并不是每家公司，都是可以做到BAT、TMDJ 这种巨头级别，也不是每家公司的员工都有机会接触到各位敏捷大牛，更不可能每家公司都充斥着“好好学习、天天向上”的员工。我们不能期盼这些公司可以一夜之间变得如此敏捷，更不可能一夜之间人人都成为敏捷大师。他们所期盼的，很可能就是导入一个敏捷方法，理解一个敏捷理念，然后如履薄冰的在公司内部尝试。哪怕取得了一点点的效果，都足以让他们欢呼雀跃。

听着很悲哀是么？但这就是国内很多中小型，甚至中型民企的现状。低成本甚至零成本试错、“又想马儿跑，又想马儿不吃草”，这对很多人来说是常态。

在这种情况下，各种高大上的内容，他们看不懂，也不想看。他们要看的，就是一些很Low、甚至都不一定完全按照Agile来做的实践。为什么？他们更加需要能“活下去”、能把一些做法“坚持下去”，这就是他们的初衷。而这也就是我觉得有必要写一些这种既为基础、很Low 的内容。

当然，也有另一种极端。部分组织会过分夸大自己的敏捷进程，甚至认为自己在敏捷转型中可以一日千里，今天还在做甘特图，明天全民DevOps ，恨不得每个人开口闭口都是DevOps、价值驱动。这种做法，无异于拔苗助长。偶尔为之，可以静下心来继续打牢地基，那么这种做法可以起到一定的激励人心的作用。但如果沉浸在“敏捷也不难嘛”这种思想中，归根结底，还是我们说的这些很基础、很Low 的东西没有理解到位的前提下，就过早的关注了高大上的内容。这种情况下，对团队的伤害恐怕更甚于前一种情况。

我能做的，恐怕就是在这些基础的知识之外，多说一些Why，希望可以在传播What的同时，也让他们懂一些Why，为后续他们可以走向高端大气上档次之路给予微不足道的帮助。

敏捷天性如此

这句话怕是要得罪很多敏捷从业者，但随着对敏捷、DevOps 的持续深入了解，以及对精益的日益了解后，我不得不承认，Agile 这个名词太不成体系了，内容太松散。能说的理论，真的是太有限了。除了宣言与原则，顶多加上几个框架的说明，从XP的工程实践、到Scrum、Kanban这种框架实践，以及持续交付等实践。绕了一圈，Agile 这个词，总是逃不开“理念”和“实践”两个方面。

理念嘛，我觉得除非人类突然出现较大的物理学突破，否则所有的理念都必须要继续围绕“快速、持续交付对客户有价值的东西”，这玩意估摸着跟那个啥一样，要坚持一百年不动摇。

而实践包含了太多，从工程实践（抱歉，这玩意我是真的不太擅长）到日常工作、再到教练与引导技术等等，这其中自然也包括了我写的内容。而且就当前来看，在可以预见的未来，这种趋势不会有减弱的可能。换言之，怕是我还要继续这么Low 下去。

Low，但不简单

Low 并不代表简单，Low 有的时候甚至会比高大上更费事，因为它包含了很多你想象不到的事情——团队不配合、公司给你挖坑、同事给你挖坑、你的领导给你挖坑、你的能力还给你挖坑。

如何做好这些事情，就成了一个非常麻烦、甚至有时候是无解的事情。你不知道会遇到什么事情，你也不知道下次遇到类似的事情你还能怎么办。你能做的就是使出浑身解数，将理论上没有遇到的事情，通过你的拆分理解，结合你现有的能力、资源去解决掉。而这些你解决的问题，可能都不会在任何一本书上出现，你甚至都找不到任何可以让你直接参考的内容，因为你面临的极有可能是其他人都没有面临过的场景。你甚至还需要时不时违反一下基本的原则，目的就是为了将事情推进下去，而这些也是常规情况下不会遇到的。

而这些，恰好是你的智慧的体现。你会付出更多的努力，但是在实践中，你将会得到更多。

你也可以认为

说了这么多，我想我应该是说清楚了为什么我并不喜欢去写一些很高端的内容，从扩展敏捷到某个最新的理论，这与我的性格和做事方法有关。

当然我依然相信有人会觉得我在zhuangbility，明明就是自己能力不足，写不出来那些高端文字嘛。

嗯，你这么认为，也行。