https://zh.atomicagility.com 最近的10条笔记 on 原子敏捷性 Quartz -- quartz.jzhao.xyz https://zh.atomicagility.com/ https://zh.atomicagility.com/ 随着敏捷理念从软件开发领域逐渐扩展到各个行业，敏捷的内涵正在经历一场显著的泛化。从最初的敏捷软件开发宣言，到如今应用于制造、金融、医疗等领域，敏捷已经不再仅仅代表一组特定的实践方法，而是成为了一种适应快速变化环境的代名词。各行各业的组织都在借鉴敏捷的思维模式，希望通过快速反应和灵活调整，在复杂多变的市场中保持竞争力。 ... Sun, 12 Apr 2026 01:07:21 GMT https://zh.atomicagility.com/%E5%AE%9E%E8%B7%B5/Dual-Beam-Planning https://zh.atomicagility.com/%E5%AE%9E%E8%B7%B5/Dual-Beam-Planning 上下文 想象你开车行驶在夜间不熟悉的公路上，因为视线与不熟悉路况的关系，汽车的灯光应该主要在远光灯上。而且越是不确定存在风险的状态下，汽车行驶的速度会更更慢一些。远光灯和近光灯会根据情况交替地切换。 这件事是跟风险的承受能力直接相关的。比如你驾驶的是坦克，并且你行驶的道路上无所谓障碍。你绝对有关闭灯光并全速前进的理由。 ... Sun, 12 Apr 2026 01:07:21 GMT https://zh.atomicagility.com/Focus-on-issues-and-pain-points https://zh.atomicagility.com/Focus-on-issues-and-pain-points ... Sun, 12 Apr 2026 01:07:21 GMT https://zh.atomicagility.com/Principles https://zh.atomicagility.com/Principles 原则 更广阔的视角：看到才能产生紧迫感，才会有响应的可能 更强悍的纪律：我们不应该沉浸在不停出现的坏味道之中 更明确的灰度：在完美解决和忽视之间，有其他的选择 关于“更” 之前指导过的团队问我，是否有一个最敏捷的团队。我回答他：不存在一个最敏捷的团队。只存在不停否定自己，让自己更强的团队。这个“更”字是一个无法达到终点的过程，它不是你获得了某个认证，学会了某个技能的过程。反而你获得了某个认证，可能会影响你这种“更”的状态。 ... Sun, 12 Apr 2026 01:07:21 GMT https://zh.atomicagility.com/%E5%AE%9E%E8%B7%B5/Fibo-Lite-Estimation https://zh.atomicagility.com/%E5%AE%9E%E8%B7%B5/Fibo-Lite-Estimation 上下文 设想你和朋友即将出国旅行。你会提前制定详细的行程安排，预订所有的酒店和餐厅吗？还是等到出发当天再试图购买机票？再想象一下，明天你和朋友准备在附近的城市漫步。你会事先制定一份精确的路线计划，还是等到出发前再决定乘坐哪种交通工具？ 这两个情境体现了计划的细致程度与风险的平衡。在国际旅行中，我们通常倾向于制定详细计划，因为未知的因素和风险较高；而在城市漫步中，我们可能更愿意即兴决定，因为风险相对较低。类似地，在研发过程中，是否可以通过直接推进沙子级别的需求来快速前进？这与在黑暗中前行的抉择是相似的。这种不确定性状态，我们称之为潜在风险状态。 ... Fri, 30 Aug 2024 00:00:00 GMT https://zh.atomicagility.com/%E5%AE%9E%E8%B7%B5/Ping-Pong-Splitting https://zh.atomicagility.com/%E5%AE%9E%E8%B7%B5/Ping-Pong-Splitting 上下文 有一个带我入行的软件师父，与他喝酒闲聊的时候跟我说过一个事情。手下人员接手了一个大型项目正在如火如荼的开发。他只给这帮弟兄一个要求，那就是把所有的工作事项拆分到3天的工作单位，并进行管理跟进。我的这个师父根本没有任何敏捷的理论概念与实际操作经验，但他有非常清晰的软件管理者常识。这个常识就是拆分，因为软件行业的特点就是这样的。 ... Mon, 26 Aug 2024 00:00:00 GMT https://zh.atomicagility.com/%E5%AE%9E%E8%B7%B5/Sand-Brick-and-Diamond https://zh.atomicagility.com/%E5%AE%9E%E8%B7%B5/Sand-Brick-and-Diamond 上下文 如果有一个需求澄清过程的话，很可能会有两种声音盘旋在会议室的上空。一种声音：我发的文档你提前看过了吗？你有什么不明白的内容吗？这个倒霉文档实在不想再花太多时间和精力了，我的事情太多了。另一种声音：需求能靠谱一些吗？一堆细节难道这不是该写的需求吗？真希望拍脑袋的想法少一些啊。 在这样的会议背景之中，往往会很容易陷入细节的泥潭。遇到一个问题会牵扯出新的问题，讨论新的问题又会牵扯出新的问题。一直聚焦在新产生的问题之上，毫无整体推进感觉。 ... Wed, 21 Aug 2024 00:00:00 GMT