不应拘泥于现有的敏捷实践，而应抓住「如何缩短反馈周期」这个核心

[EthanLin-TWer]

过去的实践，可能适合过去的时代，可能是对现代软件实践的其中一种解决方案。但不应该拘泥于实践本身。因为时代可能在改变，实践依托的时代假设可能也在变化。能够做到更快地交付软件、更快地在任意阶段获取反馈，就是好的。

[JimmyLv]

最好的用户体验/开发者体验是快。

[EthanLin-TWer]

开发者自身也要有快起来的能力哈。手速、快捷键、常用工具也需要经常练习。

[JimmyLv]

可以以此来发现商业模式，如果某个行业或现有工具效率低下，那创新点就在于如何成数倍或数十倍提高效率。

比如：

• 无人机送快递
• JetBrain 系列
• 人工智能 balaba
• 电动汽车

当然也需要兼顾成本。

[EthanLin-TWer]

最近以为，敏捷的核心在于价值。所有缩短周期，所有快速反馈，所有敏捷实践，都是为了快速验证某个 idea 是否具有价值，有多大的价值。价值的洞见要靠数据埋点和用户反馈产生，快速验证的实现则依托于一系列敏捷实践（比如 CI/CD/TDD/Refactoring）。

当我们谈敏捷实践的时候，常常忽略快速验证这个前提。有时你的业务侧不需要快速上线，那你敏捷实践做不好的后果就不大，其变革动力就不强，追求卓越的程序员们幸福感就不强，所谓皇帝不急太监急。没用。

我们常常忽略的，还有与速度相对的另一侧——稳定。当敏捷实践做的不好的时候，稳定和速度你只能取其中之一。想要稳定，就要降低速度，用更多的人力和手工测试去填质量的坑；想要速度，你就只能让人加班或牺牲稳定性，接受更多 bug 的风险。想要又快又稳地上线，那就要求更高粒度的持续集成，更稳固的质量内建。这需要人员的什么能力呢？做原子提交、做小步提交、写好的单元测试、基于主干开发进行持续集成、有好的测试体系、重构能力。这要求可高了去了，没有迫切的业务需求，没有投入资源的决心，没有自上而下的推动，我看只能自求多福了。

我觉得人是这样的，当你用体制或规则强迫 TA 的时候，事情才能推动。依靠人员自觉或热情的方式注定是理想化的、不能规模化的、基于运气的。如果没有业务侧的强烈需求，也没有技术侧从上至下的强制推动，这个所谓的技术卓越就没法规模化，只能靠运气。或许这就是 TL/TP 的作用。

不要理想化。这是工作三年的小小觉悟。

接下来要看一本敏捷和精益领域最好的书。

[JimmyLv]

技术卓越规模化。 已然不符合二八定律。 maybe

另外我不懂的是，真正的敏捷和精益都应该是直接试验于「产品」，为什么「外包」/「交付」这么需要敏捷和精益呢？

所以真正敏捷的人，是不是已经去了产品公司交付价值？

所以真正精益的人，是不是已经开始了自主创业试验价值？

[EthanLin-TWer]

哈哈哈，对啊，本来「二八定律」和「规模化」就是如此相悖的两个词。

交付只是一种形式嘛，它需不需要敏捷，还是跟你团队有没有办法接触到真正的用户，有没有不敏捷就会死的外部市场环境，有关系。有就需要敏捷，没有就不需要。「有自己的产品」一定程度上还是有这个「外部市场环境」的因素的，至于这个产品你接触的是用户，是产品经理，还是你的上司老板，那就因人而异了。

后两个问题，我觉得确实是这样的。或者可以反过来说，只有需要快速交付价值的产品公司，才会需要真正精益的人。