“历史的车轮向前滚去，所有人不可避免的参与其中。不同的是有人在车轮的下面，有人在上面；有人在车轮的中间，有人在边缘。”
一、田园式敏捷的来源
已经忘记了从哪年开始，软件开发行业有了“敏捷”的说法，因为是个外来物，通常我们的观念里面认为“洋”字头的总是好东西，于是除了软件行业之外的很多公司也开始流行起了“敏捷”的模式。
很多老板借着网上理解了半吊子的“洋敏捷”的只字片语来实现其一拍脑袋的想法，还美起名曰“快速试错、快速抢占先机”等等，也许正是这样才能配得上现在互联网盲目、投机、轻浮的泡沫。
为啥叫田园式敏捷呢？有些地方或称之为“中华田园敏捷开发”模式，其实是程序猿们对外来的“敏捷”物种进行本土化适应后产生的一个新物种的昵称。
田园式敏捷是借用、套用了“洋敏捷”里的很多名词，然后走自己特色道路、自我摸索出来的一种模式。我认为这个很厉害，总是要达到宗师水平才能自创门派。
敏捷从某些角度看很有点像泰勒提出的科学管理法，特别是理念和实际结果。出发点都是好的，目标是工人和老板双赢，并且理论是自洽完善的，在实际操作中往往变异，因为只提升了员工工作量，工资并没有同步增长，开心的就只是老板了。
为什么田园式敏捷如此应用广泛然而会被群嘲？从基层角度思考一下这个问题。
试想一：工资和职位得不到提升的情况下，我们为什么要多干活？
试想二：我们难道真的全都是蠢货，不知道自己的效率可以提升吗？
试想三：我们为什么不多留点时间和力气陪陪家人？
当然很多心灵鸡汤会跳出来反对，比如稻盛和夫就会说想要成功的人就应该不计较付出，如此这般。
总的来说我觉得他们说的都很对，并且完全没有争论的必要。
所有人都认可的道理，那是定理。定理是可以通过一定时间的实践来论证对错的，但这不是真理。
按照哲学上讲，真理是不能被证明是对的，也不能被证明是错的，并且，真理应该也只属于上帝，我们也只能去发现它而已，当然发现了也不一定知道，因为无法证明，所以只能靠领悟。
这里告诉我们，对任何意见都要保证平和的心态，我们的想法、文章只要有人看、有人发表评论已经证明了价值所在。
二、田园式敏捷的特点
敏捷原本的本质是想通过快速响应、需求分解、进度对齐、持续交付等原则方法来实现产品质量和交付速度的提升。
我们从软件开发行业委婉地看一下田园式敏捷软件开发的特点，委婉的意思是保留一些极端的行为暂且不提。
需求变化快，开发跟不上节奏
常用语1a---我有个想法A，马上开发上线试运行；
常用语1b---明天，不对，A有点问题，应该改成B；
常用语1c---这么简单的东西就不要文档吧，我画个图给你；
常用语1d---这个很难吗，做不了吗？就几个简单的逻辑啊；
以前有个老板觉得从零自研开发一套工业物联网平台要几个月非常不可思议：“必须一周搞出来”，后来多方协商后改为“最晚两周要出第一个版本”，就是这么神奇。
开发者们干活总是不够勤快
常用语2a ---单周迭代，一周出一个版本，每个迭代都叫“冲刺”；
常用语2b ---领导上午10点找，10点半就来问解决方案ppt做好了没有；
常用语2c ---每天的工作时间饱满吗，工时有没有精确到分钟；
常用语2d ---这个功能很简单啊，不行就加个班；
见过一些大厂在工厂车间的生产管理现场都敢用SAAS化软件，还敢每周更新一个版本，幸亏都不是生产很饱和的工厂，所以很侥幸没碰到过宕机发生生产事故的情况，充分证明我的从业经验还不够丰富。
总是有人get不到那个点，总是有两个功能没法实现：这不能做，那不能做
常用语3a ---我们拉个会议对齐一下项目进度；
常用语3b ---谁谁刚加入，重新开会澄清一下需求吧；
常用语3c ---我们来一起开个会，看看这个问题怎么解决；
常用语3d ---那个谁谁把培训搞起来，晚上6点给大家做个培训；
开会可能是所有人的吐槽点，各种所谓的站会、项目启动会、回顾会、评审会，一大群人开几个小时，没有任何重点，也没有任何结论，并且还很喜欢占用吃饭时间、休息时间、下班时间。
要么永远都有下一个版本，要么再也没有了
常用语4a ---需求太多了，放到下一个版本吧；
常用语4b ---实现有点草率了，在下一个版本优化吧；
常用语4c ---代码走查，质量提升，在下一个版本做吧；
常用语4d ---那个产品还在线？有人用吗？
开发人员唯一能感到安慰的可能就是有下一个版本，因为这是一个情怀寄托，将一切不可能的、不科学的、不合理的都可以放入下一个版本，并且有时还可以起到垃圾回收站的功能。可能带来伤感的也是因为下一个版本没了。
时间不够的第一方案永远是加人
常用语5a ---评估一下工作量，来不及就给你加个人；
常用语5b ---大家都对任何功能很熟悉，完全无缝对接上手；
常用语5c ---各个模块要同一时间对接联调，工作量要碎片化到分钟；
常用语5d ---怎么还会出bug呢，不是让你小心了吗
在领导眼里每个人的工作量和工作时间都是excel表格，拉一下就可以对齐了，所以用那些项目管理工具做监工很简单，直接精确到每人每分钟嘛，并且每个人都是万能人才资源，哪里需要去哪里。
三、田园式敏捷对数字化认知的启发
数字化对企业运营的理念作用有点类似敏捷，搞得不好也会怨声载道，变成田园式数字化。
不能因为“天下武功，唯快不破”就把敏捷单单理解为只是快，或者理解为快就是好。一只猫再敏捷也打不过一头熊。
按照我前面的观点，企业是人的延伸，我更愿意将企业数字化功能类比成人体外骨骼，起到辅助增强的作用。
外骨骼目前应该是在一些医疗领域开始使用，但是改造提升人体自身，在未来很长一段时间应该是个很有挑战并值得追求的目标，终极形态也就是如日本动漫里的“强殖装甲”，漫威的“钢铁侠”等。
数字化认知的前提就是要传达实事求是的精神，不能制造误区
数字化首先应该传导稳扎稳打的理念，不能将自己变成万能灵药。
我们听到的一些宣传报道过于失真，经常将数字化的功效无限放大，还将其它领域的功能也大包大揽到数字化里面，所以我们听到的某某公司上了数字化项目后，提升了多少产能，节约了多少能耗，大部分都值得推敲。
可是很多老板会信。
某些实体老板拿着数字化锤子如获至宝：满满一车间的二三十年前老旧设备有救了，产量加倍不是梦，因为数字化可以提升设备效能。
也有些精明的老板觉得数字化可以提供老板和员工之间的不信任问题的解决方案，俗称监工。老板时时刻刻在担心员工是不是故意偷懒，是不是故意搞坏设备，是不是想顺点物料出去，等等。坐办公室里面的同样如此，老板永远在担心员工在上网、去厕所、出去买咖啡等等。
数字化帮助识别出可以标准化的工作交给机器完成
如同外骨骼一样，不能将重量全部依托于人体自身的骨骼负重能力上，而是要分担掉人体承重，让人感觉更轻松。
泰勒的科学管理法一开始掐着秒表给工人动作计时，借着人体极限来提升效率，所以会招致各种抵制，谁都不会喜欢每天绷得紧紧的感觉。
数字化可以在一定程度上提供一些压榨设备、机器的性能的手段，但也要注意设备的适度保养。并且这样的法子用在人身上其实并不恰当，在未来流水线工人会越来越少。
要对复杂度有认识，对技术有敬畏
不能盲目追求快。
在食品行业最有体会。随着肯德基麦当劳的鸡越来越小，越来越没味后，现在的餐馆也都是使用预制菜、高科技狠活，为什么大家会想念家常菜的味道，会去买土鸡吃？
很多软硬件产品从demo到可以实战的路径，比从0到demo要长的多，因为要考虑很多相关因素比如质量、维保等等。
做软件的都很清楚，代码业务流程与处理异常分支、日志跟踪等功能的比例一般都是“二八原则”，其他产品我想也是如此，基本功能占20%，辅助功能占比80%。
复杂度不变的情况下，速度快的方法就是少干，代价就是牺牲质量。
对复杂度和技术的观点具体内容可以查看我前面的文章。
数字化建设需要讲究方式方法
即便数字化能给企业和员工带来双赢，也不可能立竿见影。
正如在初创企业使用敏捷会比较顺畅，中大型企业已经有了比较成熟的流程套路，要改变原有模式走出舒适区，员工必然会有抵触情绪。
并且如果有更好的方式激励员工，也不是一定要用数字化的。
很多人都喜欢将数字化称为一把手工程，这也可以被理解为一种办法。比如销售就最喜欢这样的方案，搞定一个人比搞定一群人要省事。
数字化应该可以减少人的工作量
不用提数字化改造业务流程等等虚无的内容，就很简单的问一个直击灵魂的问题：上了数字化后，有没有减少开会的频次或者人数，最低限度开会内容或者时长应该缩短吧？
数字化如果可以减少开会，那便是功德无量了。
事实上敏捷或者数字化后，所有人会发现开会变多了。
当然现实中的很多开会纯粹是为了炫耀一下权力。
数字化应该凸显人的价值，而不是数字价值
现在数字化有一个误区便是数字驱动业务，觉得企业应该跟空调一样，有个温度传感器，发现低于18度就自动升点温，高于25度就自动降点温。
但是对于人的效应，比如技能如何提升，提升之后可以产生哪些价值，却往往进行选择性忽视，或者说并没有重视起来。
很多数字的来源也是人，并且辅助于不同的人会产生不同的价值，不仅仅是服务于老板。
数字化应该提供的辅助能力是减少盲区、增加主动性选项，就跟“钢铁侠”的盔甲一样：防御我希望是自动的，进攻还是让我自己选择吧。
毕竟这还是一个人类社会。