最近，和客户在聊一个话题，用低代码工具（明道云产品），怎么就体现了敏捷开发？于是有了这篇思考
最近一直在思考、探索，我想试着用下面两个场景，来解释一下我心目中理解的敏捷。
场景一：假设你和朋友一起玩一个猜数字的游戏，你心里面想着一个 1-100 的数字，让你的朋友猜，那么，你的朋友使用什么方法，可以用最少的次数猜中你心中的数字？
答案是，采用二分查找法，好比你心目中的数字是 13，你的朋友只需要问：
到这里，大家心里可以想一想，上面的过程是不是，即使这一步猜错了，但下一步会调整为朝着正确的方向去探索。这是我想说的第一点：只要问题设计的好，实验设计得当，失败会非常有价值，就像一次二分查找。敏捷具有快速试错，快速迭代的内涵。
场景二：假设你着急回家，打了一辆出租车，但是司机根本听不懂你在说什么，可你是会开车的，也熟悉回家的路，这个时候，你会怎么做呢？
现实中不会有这样奇葩的场景，但我们把这个场景换为软件开发中甲乙双方之间的需求沟通呢。
所以，我会选择自己来握住方向盘。这个是我想说的第二点：软件开发过程中，人与人之间的沟通环节越多、越复杂，需求就越容易损失，我们应该让工程师直接与利益相关者沟通，如果条件具备，甚至可以让利益相关者直接作为工程师，自己给自己开发工具，自己解决自己的问题。敏捷需要一个合适的组织，这个组织真正掌握应用开发的所有权。
上面的思考，丢给 AI 后，给出的总结我很满意，分享出来：
- 技术层面（快速迭代）：通过可视化、无代码化能力，把迭代周期从 “天 / 周” 缩短到 “分钟 / 小时”，让快速试错成为可能
- 组织层面（自组织、所有权）：组织上，通过开发所有权的下沉，打破了 “业务和技术的壁垒”，让沟通损耗归零，实现了敏捷所需的 “自组织团队”
