# 每日看台是胡说八道(除非他们挣工资) > 每天的站立并非天生的坏 — — 但当它们变成仪式而不是调整时,它们会浪费时间和破坏信任。 这篇文章探讨了为什么仪式是税收,如何衡量其价值,以及让团队在不燃烧精力或时间的情况下保持一致的首选实际的同步选择。 Agile就是适应 — — 而不是坚持。 ## 一. 导言 导言 导言 导言 导言 导言 一,导言 导言 导言 导言 导言 导言 在我将近30年的软件开发过程中, 我参加过比我想数的更多的日常立体活动。有些是电动调整的短暂时刻,清除了阻截器,把我们送过去。另一些则是表演仪式,疲劳的开发者向一个静音摄像机的画廊朗读“和昨天一样”的话。 区别? 一种单立 *赚取税款*另一则只是仪式而已 [TOC] ## 忏悔 我不得不承认:我是一个敏锐的游手好闲者。我经历了PRINCE、瀑布和重力程序框架的WORST,我成为了这样的人。我经历了“单一代码行之前的完整文件”时代。我参加了变革控制委员会的会议,在这些会议上部署一线固定装置需要三周的批准文件。 简单的事实就是: **Agile是建立好软件的最佳方法。** 用丘吉尔的话来说: > *“事实上,有人说,Agile是软件开发过程中最糟糕的形式除了不时尝试过的所有其他形式之外。”* 但事情是这样的: **支持罪并不代表支持罪状**事实上,捍卫无可置疑的仪式就是 *反对* 敏捷。 以下是我学到的: **敏捷是指适应,而不是遵守**然而,大多数团队都继承了斯库姆仪式的批发,认为它们是神圣的而不是实际的。 日常的游行、冲刺计划、回顾这些都是工具,而不是命令。 和任何工具一样,他们应该评估他们是否 *工 工 工 工 工 工 工 工 工 工*. 这篇文章不是关于消除伪装,而是关于质疑你的仪式是否带来与其成本成正比的价值。因为根据我的经验, **你能做的最敏捷的事情 就是调整你的敏捷程序**. ## Scrum 是模板, 不是 Dogma 请允许我明确指出: **Scrum作为一个起点是辉煌的。** 它为我们在瀑布中溺水时提供了团队结构。如果你只是从Agile开始,Scrum就和他们来的时候一样好 它提供了明确的仪式、确定的角色,以及一个为许多团队工作的经过验证的框架。 但是在沿线的某处 我们混淆了 *之后的缩放( Scrum)* 与 *正在敏化*. Scrum 是一个 **工具包工具包**。 Agile 是一个 **心态和心态**. 下面是没有人谈论的部分: **一旦Scrum开始磨擦, 减慢你的速度, 或者提供的价值比它的成本低, 那就是你适应的时候**。这需要经验,但真正敏捷性却是关键。在需要进化过程时,识别能力就是将成熟的灵活团队与这些货物加工仪式区分开来。 这就是不自在的真相: Scrum Masters 只有在你继续使用 Scrum 时才得到报酬。 所以接受他们的建议, 但记住他们的激励与“ 使用最有效方法”并不完全一致。 [《危险宣言》](https://agilemanifesto.org/) 它重视“个人与互动, **"自我组织团队"** 作为核心原则。但我观察了一支9米的突击队 在三个时区横跨3个时区,因为“Scrum是这么说的。”这不是灵活性,这是传统,它被装扮成方法。 我意识到很多人在做“贪婪”时从未真正读过《Agile宣言》。这是2001年17名软件开发者撰写的基本文件,他们厌倦了重力、过程驱动的开发。他们开了三天会,总结了实际有效的四个价值报表。 现为: > **《危险宣言》** > > *我们正在发现开发软件的更好方法,通过这样做和帮助他人这样做。* > > - **个人与互动** 进程和工具 > - **工作软件** 综合文件加综合文件 > - **客户协作** 合同谈判之后的合同谈判 > - **回应变化** 计划之后 > > *也就是说,虽然右侧的物品有价值,但我们对左侧的物品更有价值。* 注意里面没有的东西: 日常的展示, 冲刺计划, 故事点, 回顾。 这些来自Scrum, 用来执行这些价值观的。 但是在某个过程中, 我们开始把Scrum的落实作为目标, 而不是价值观本身。 《宣言》是关于 **原则原则、原则原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、**而不是处方 。 “ 过程和工具的内在和相互作用” 意指如果过程( 观看) 妨碍互动( 实际合作) , 你就会反向这样做 。 **自我组织团队不需要强制他们举行仪式,他们选择可行的做法。** ```mermaid graph TD A[Agile Manifesto] -->|Inspires| B[Scrum Framework] B -->|Provides| C[Ceremonies & Practices] C -->|Should be| D{Adapted to Context} D -->|Teams often skip this| E[Rigid Adherence] D -->|True agility| F[Continuous Optimization] E -->|Results in| G[Process Theatre] F -->|Results in| H[Effective Delivery] style A stroke:#e1f5ff style F stroke:#d4edda style G stroke:#f8d7da style H stroke:#d4edda ``` 以我的经验来看 最快的船队 并不是那些跟随史库伦的队伍 **检查和调整自己的程序** 他们严格检查和修改他们的代码 ## 立体起伏往往衰落成仪式 让我画一幅你可能认出来的照片: 现在是上午九点,你深入地解决了一个古老的货币错误。你的IDE是开放的,调试器是附属的, 心理模型是满载的。然后,ping,在两分钟后开始举行立体会议。 切换上下文。 加入呼叫 。 等三个人解开时 。 然后 : - **爱丽丝:** "和昨天一样,在登录功能上工作" - **鲍勃:** "完成测试,没有阻拦器" - **卡罗尔:** *(相机关闭)* "是啊,仍然在数据库的迁移。" 10分钟后,你回到你的代码, 心理模型不见了,你再花15分钟重建环境。 **那次会议取得了什么成果?** 在我的经验中,失败的政见有共同的症状: ### 仪式衰落检查列表 - [ 多数更新都是"和昨天一样"的变异 - [ 不作决定 - [ 超过50%的参与者有摄像头关闭 - [ 时区扩散力量晚/早出 - [ 会议期间人们的多重任务 - [ 没有人问后续问题 - [ 这次会议本可以是一个黑暗的信息 当这些症状出现时,你的站起来 并没有产生一致。它正在产生 **同步疲劳**. ### 出席情况滚滚问题 坦白地说,在许多工作场所,九点起立是一个出席名单。这是一个验证人们是否“在办公桌”(或至少是醒着)的方法。这不是灵活的,而是监视场。 如果您需要每天站立以了解您的开发者是否在工作, 您就会遇到信任问题, 而不是进程问题 。 **将开发商当作专业人士对待。** 判决他们所表现的,不是判决他们是否按时到会。 ```mermaid graph LR A[Standup Intent] -->|Should produce| B[Alignment] A -->|Should identify| C[Blockers] A -->|Should enable| D[Quick Decisions] E[Ritual Standup] -->|Actually produces| F[Status Updates] E -->|Actually creates| G[Context Switching] E -->|Actually wastes| H[Focus Time] style A stroke:#d4edda style B stroke:#d4edda style C stroke:#d4edda style D stroke:#d4edda style E stroke:#f8d7da style F stroke:#fff3cd style G stroke:#f8d7da style H stroke:#f8d7da ``` ## 所有庆典都是税务 以下是改变了我对灵活做法的看法的框架: **每个仪式都消耗资源:** - **时间 时间 时间 时间 时间 时间 时间 时间 时间 时间 时间** - 15分钟x5个开发商x5天=6.25小时/周 - **认知能** - 环境变换破坏深层工作 - **情感带宽** - "成功的存在"是累累的 - **焦点** - 中断流量状态会增加成本 在民主社会中,我们接受税收 *当它为基本服务提供资金时*道路、学校、医疗保健----这些都证明负担是合理的,因为我们得到回报的价值。 敏捷的仪式同样有效。 ```mermaid graph TD A[Ceremony/Ritual] -->|Consumes| B[Team Resources] B --> C[Time] B --> D[Energy] B --> E[Focus] B --> F[Context] A -->|Must produce| G{Value?} G -->|Yes| H[Justified Tax] G -->|No| I[Process Theatre] H -->|Examples| J[Blocker identified
Alignment achieved
Decision made] I -->|Examples| K[Status updates
Calendar filler
Nobody engaged] style A stroke:#e1f5ff style G stroke:#fff3cd style H stroke:#d4edda style I stroke:#f8d7da ``` ### 税 税 衡 衡 算 任何仪式要证明其存在的理由,都必须如此: **交付价值 > 资源消耗** 以我的经验来看,当球队不衡量这个等式的两面时, 单调就失败了。 他们继承了这个仪式, 永远运行它, 并且从不问: *"这还值得吗?"* ## 更好的,便宜的,更快的替代品 以下是我所看到的工作 跨越不同的团队背景: ### 状态更新 & Async 检查 而非同步会议, 请尝试 : **Slack/Teams Thread(达伊利)** ``` 👋 Good morning! Quick updates: ✅ Yesterday: Completed auth refactor (#234) 🎯 Today: Tackling payment integration (#456) 🚧 Blockers: Need staging DB access (@alice) ``` **时间成本 :** 2分钟对15分钟 **时区影响:** 零 **可搜索历史 :** 是 是 ### 通信乘数效应 以下是一个关键BEYBENEFIT 大部分队错过: **黑报成为与任何对进展感兴趣的人沟通的地方。** 产品经理、利益攸关方、设计师、其他工程团队-他们都可以订阅频道并随时了解情况, **你的任务就是把团队建设成一个特效送货机。通讯是让团队运转的石油。** 当CEO问“团队在工作什么”时, 给他们发送链接。 当产品需要更新时, 他们被订阅。 当其他团队协调时, 他们看到你的实时进展。 这是通信 。 *振动*,而不是 *间接费用*. ### 使它成为真正的阿斯辛 以下是如何在任何时区 进行这项工作: **模式 :** "在早上九点前更新现状" (当地时间) 离开 **细细线中每项任务的详细注释**。 不仅“ 进行验证” , 而且还“ 授权反构件: 完成 JWT 验证, 开始刷新符号流, 阻塞器: 需要在错误状态下进行设计批准 。 澳洲纸币在最适合他们的地方留下纸条--也许在他们一天结束的时候。在9点英国时间(如果是紧急的话),你读了它,然后行动 : “ Dave,你能帮助Joe批准设计吗? ”然后你让TEAM来安排它是如何发生的。 **他们推动这一进程。** 你不是在安排所有的互动,你正在清除阻塞器,让专业人士直接协调。 这是阿盖尔原则 **自我组织小组** 不是“遵循规定程序的团队 ” , 而是围绕工作本身组织团队。 信息是透明的,环境是共享的,团队决定了如何解决。 笔记中的细节意味着你不需要同步的澄清。团队自行组织信息。 ### GitHub + Slack = 文化+地位 将 GitHub 链接到您的 Slack 频道。 现在, 状态更新 BECOMES 公关。 代码审查是可见的 。 您通过 emoji 来庆祝胜利。 这不是轻率的, 而是文化 。 ``` 🎉 @alice opened PR #234: Add JWT refresh token flow 💪 @bob approved PR #234: "Beautiful error handling!" 🚀 @alice merged PR #234 into main ✅ Build passed: 47 tests, 0 failures ``` 你的站立刚刚成为你的GitHub活动饲料 零税,自动可见度,同侪承认 **将通信作为最关键的地方 成为NICE的场所** 如果你的团队频道是工作的地方, 让它成为人们想成为的地方。 庆祝胜利, 欣赏良好的公开工作。 感谢大家的帮助 。 **这是工程文化。** 当主要通讯频道感到积极时,人们就会更多地参与,更快地寻求帮助,并自由分享知识。有毒或无聊的通讯频道?人们会哑口无言。你们的通讯机器崩溃了。 ### 当Async失败(和如何修补) Async - First并不完美。通常的失败模式 : - **人们不看电视频道**: 使其具有价值( GitHub 通知、 决定、 赢 ) 。 Boring = 调出 。 - **封锁4小时,无人注意**@mention, 在两个小时后升级。 跟踪“ 阻塞反应时间” 作为衡量标准 。 - **时区差距=8小时延迟**: 识别2-3小时的重叠窗口。 对于全球团队, 接受交割延迟, 但完整地记录 。 - **小青年不说话**: 指派高级职员明确检查。 庆祝提前问话, 保证“ 我被困住” 的安全 。 **关键词是: Async-first 并不意味着只代表 Async-first 。** 当有东西被卡住时, 跳上电话, 同步会议会解决问题, 而不是报告状况 。 **物理空间的同一航距** 如果你还在办公室里,还有一间工作室... 不错的椅子 体面的咖啡 真正有效的白板 自然光 如果可能的话 当工作室舒适时,人们自然会在那里引力引力。交谈会发生。问题会在白板上解决。有人偷听到阻塞器,跳进来帮忙。这是有机合作,即站立试图(和未能)制造的有机合作。 就是这个 **自我组织小组** 事实上看起来就像。不是站在一个圈子里向Scrum Master报告。而是那些组织工作的专业工作者,因为环境使得工作变得容易。 家具破损和荧光灯照明的令人沮丧的房间? 人们在家里工作或躲在桌子上,你们的通讯机器仍然支离破碎。 **关于同步会议 :** 必要时,您仍然可以预订经常性会议 -- 您不必取消所有会议。 关键是故意。 每周一对一? 保留它。 它保留日历上的空间并显示其重要性。 区别在于它们变成 *可选的同步讨论* 而不是 *强制性强制性状况报告*. 故你们应当记录重犯的经过,你们应当说:如果你们本周没有什么好谈的,那末,你们可以回避它。 **以下是我作为高级/领导的方法:** 我从来没有取消一对一的取消, 从来没有。 但我说清楚了, 他们可以, 它就在那里, 它发出一个信息: “我已经为你保护了这次, 如果你需要, 使用它。如果你不这样做, 不要压力。” 有些星期,他们会跳过它,因为他们是头朝下流的。其他几周,他们会用所有30分钟,因为有什么东西困扰他们,或者他们想通过设计来交谈。 经常性会议 **空间空间空间**非义务。 这对以下方面特别有用: - 一对一(保留关系空间) - 结构讨论(复杂、受益于白板白板) - 利益攸关方的演示(现场互动中的情感/政治价值) 目标不是零会议,而是 **以便有定期的集会,而借计时的计时,**. ### 准确的执行局 以我的经验来看, 保持他们的堪萨斯人董事会的团队 并不需要站得住脚的能见度。 **信号丰富的董事会指标:** - 带有错误栏的语句点( 信任范围) - 带有老化指标的“ 滑” 标记 - 直接在卡片上的公关状况 - 实际与估计时间跟踪 如果你的董事会是可信的, **看着它应该回答 "大家在做什么?"** ### 阻塞器 问题标签 + Async Pings 真正的阻力需要立即关注,而不是第二天的站立。 **更好的模式 :** 1. 标签标签问题 `🚧 blocked` 2. 直接将有关人士 3. 如果2小时后没有解决,升级为铅 4. 音轨阻卡分辨率时间作为公号 ### 聚合团队 每周回溯 + 对等 我经常听到的论点是: *"但站立让我们作为一个团队连在一起!"* 有道理,但每日状况更新是否是 建立连接的最佳方式? 根据我的经验,这些创造 *更强* 债券: - **平间会议** - 实际合作 - **每周复古** - 诚实的反思 - **黑水冷水管道** - 社会非同步社会时间 - **每月小组午餐** - 非工作连接 ```mermaid graph LR A[Team Cohesion Goals] --> B{Choose Method} B -->|Status sharing| C[Async Check-ins
2 min/person] B -->|Problem solving| D[Pairing Sessions
As needed] B -->|Reflection| E[Weekly Retro
1 hour/week] B -->|Social bonding| F[Slack channels
Continuous] G[Daily Standup
15 min × 5 days] -.->|Tries to do all| A style A stroke:#e1f5ff style C stroke:#d4edda style D stroke:#d4edda style E stroke:#d4edda style F stroke:#d4edda style G stroke:#fff3cd ``` ### 背景矩阵 并非所有的团队都应该采取同样的仪式。 团队概况 * 支持价值 * 更好的替代品 * |--------------|---------------|-------------------| | **质、 分布、 合成- 第一次** 低 黑 报到 + 准确板 | **初小重队** * 低指导模式(见下文) | **紧最后期限,高风险** 要看 平衡 : 15 分钟能拖慢你吗? 如果没有阻塞器,为什么你急着报告? | **稳定地特征团队** 低税率更新; 只有在建立复杂的多人特写或关键问题时, 才会扩大到每日 | **开放源,全球时区** Async更新+每周视频摘要 > **另一边:青年开发者神话** > > 常识:"青年需要每天的站立来学习。"现实:常有站立 **增加焦虑** 对于低年级学生,但实际上没有帮助他们成长。 > > **你的团队 让你的犹太人。** 不是站立,而是指导。给老年人分配时间帮助他们。让它们文化化:领导老年人,年长者管理少年。在更新之前,少年可以预知他们的年长者,但他们必须有自己的声音 — — 年长者从来不为他们说话。 > > **专业发展是通过辅导而不是现状报告实现的。** 扶手不会教授估计、建筑或调试。对称是的。代码审查是的。 1对1是的。 以我的经验来说, 错误不是有 站立或没有他们。 **同样的仪式适用于每个背景环境**. ## 一切能适应什么能适应什么 事实是这样的: **一切都能适应你团队最好的方法** 这就是阿盖尔原则 **自我组织小组** 并不是说"精顺史库姆的团队" **不断调整工作程序以服务于工作的团队**. 一些团队为日常的监视活动而生活 — — 能量、连线、快速火力问题解决。 有些人甚至会抗议黑白信息,更愿意专心致志,尽量避免中断。 一个真正的自我组织的团队实验, 测量和选择。你适应了结果。 ### 谁决定改变这一进程? 我说"团队决定"时 是谁打的电话? **铅或高级开发者** 领导才能为改进创造了条件。 **模式 :** 1. 有人建议做一个实验吗? "2周内进行同步检查" 2. 小组讨论权衡取舍 -- -- 关切问题、衡量标准、如何恢复 3. 铅根据买入和可行性决定是否运行 4. 团队衡量结果 - 阻塞时间? 满意度? 5. 小组决定保留、恢复或循环 **透明度是关键。** 依据证据(“我们有数据,这行不通”)而不是意见(“我认为这样更好”)。 如果你的团队不能表达对流程变化的关切, 你没有一个自我组织的团队 - 你有指挥和控制 与更好的嗡嗡声。 ### 斯派克:实验肌肉 这是我爱的图案: **尖尖加**。如果您使用短跑(或只是快速周期反馈),则钉钉就是您的实验预算。 **注意任何“我们应该尝试X科技”的讨论。** 当有人说“我不知道Postgres全文搜索是否比 Elasticsearch 更快,请写下来。不要辩论它。抓住它。 **使用峰值作为重度开发期间的乐趣休息。** 研究一个能把你磨碎的长长的功能? 计划一个钉钉。 “ Alice, 花一天时间尝试你提到的反应服务器组件。 看看它是否解决了我们的水合问题 。 ” **斯派克对Devs很有意思** 他们可以探索 学习 可能失败 这是健康的 **以团队方式追踪他们:** - 这个钉子应该持续多久? (2小时? 1天? 3天? ) - 我们想学习什么? (“这个方法有用吗? ”不是“建造整个功能”) - 我们怎么知道它是否成功? - **期末现有调查结果** - 你不只是在胡闹,你回答 球队的问题 最后一点很关键。 钉钉以“ 以下是我学到的 ” 结尾。 可能是在斯拉克的10分钟, 可能是在白板上的20分钟。 格式并不重要。 重要的是 **你贡献了团队的知识 不只是从中提取**. **这对于初中生来说尤其重要。** 他们正在成为该团队的Redis专家。他们研究、测试了它,现在他们正在教球队。 "你提到想学习关于缓冲的问题。这是2天的峰值:调查Redis和我们的API反应。星期五向团队介绍你的调查结果。" 现在小弟不光是食用 高年级学生的知识 **促进小组的集体理解**这就是你建立信心的方式 初中生不再觉得自己是冒牌货了 ### 斯派克给自己付钱 这里的经济论点是: 他们不只是学习练习, 而是决定加速器。 **道路1:通过** 下一个 dev 循环周期, 您可以使用该技术。 您通过加注而提供更大的价值。 它本身支付。 爱丽丝花了一天时间扑灭反应服务器组件? 两周后, 团队的特色比客户端JavaScript少了80%。 为期一天的投资节省了调试水分问题的日子。 **路径2:消除** 或者你排除一个选择,通过减少路径来让检验更有价值。 “我们尝试了GreagQL Federal, 这对于我们的团队规模来说太复杂了。 现在我们知道: 在接下来的6个月里继续使用REST。 ”这不是一个失败的峰值,而是一个失败的峰值。 **成功决定**你不再浪费时间去想"我们是否应该使用GreagQL?" 答案是否定的,有证据支持。 两种结果都有价值。 要么你获得一个工具,要么你消除分散注意力。 最坏的结果是从未出现过 — — 只是无休止地争论“ 我们应该尝试X吗? ”而没有数据。 **甚至过程也会被钉死** 您可以在团队中担任“ 流程所有人” 并使用流程钉 。 “ 让我们尝试以同步方式检查两周。 这是一个流程钉 。 我们将测量阻塞反应时间, 看看会发生什么 。 ” **原则:改变是由实验驱动的。** 团队玩技术是健康的。玩过程是健康的。选择是停滞 - 同样的工具,同样的仪式,同样的挫折感 多年来。 Spikes 正常实验。 他们保证说"我不知道这行不行" 并尝试它。 问问你自己: **团队需要什么产出?** 1. **现况更新** (至少每天更新) - 所以利害相关者知道发生了什么 2. **用于改变方向的输入** (真正核心是敏捷的) - 但看台并不是真的 反正, 这是一个单独的同步过程, 通过积压的完善,回溯, 和利益攸关方的反馈。 缩略 *最佳结果* 我受够Async 自我组织 Slack 方法了。 您确定什么应该是“ 脱线 ” ( 在利益攸关方的单独会议上) , 或者当您需要小组会议来讨论一些复杂的事情时 。 ### 记住:产品是输出 直到有一个特点可以玩, **您程序的产物是您开发机器的输出**这才是最重要的 若贵公司需要滚动进度更新, 请考虑如何尽可能以CHEAPLY(税制)提供: **创意替代品:** - 查看JIRA已完成故事点的入场票的脚本 - 基于历史任务速度的LLM驱动估计数字 - Git的自动每周摘要摘要承诺 + PR 说明 - 从CI/CD输油管状态提取机板 - 自动从罚单标签上 表面阻塞器的黑机器人 有些选择比强迫人类每天手动报告进展要便宜。 目标不是消除交流,而是 **使机械部件自动化,使人类能够专注于有价值的部件** - 决策,合作,创造性的解决问题。 ## 测量像系统一样的定律 如果你是开发者,您要监视您的系统。 您可以跟踪潜伏、 误差率和资源使用量。 您设置 SLO 并在 SLOs 退化时进行调查 。 **为什么我们不这样做 为我们的过程?** ### 具有实际重要性的度量 在测量仪式之前,请先测量仪式,然后测量 **通信本身的通信本身**以下是我所追踪到的 揭示了真正问题的量度 : **对阻挠者的反应时间** - 从“ 封封”标签到解决方案的平均时间 - 目标:团队重叠时低于2小时 - 如果你一直超过四个小时 你的沟通渠道就失效了 **审查时间到 PR-审查** - 从开放公关到第一次审查还有多久? - 目标:小型公关小功率小于4小时,大型小功率小于24小时,大功率小于24小时 - 如果评论坐着数天, 要么人们不检查Slack,要么你有太多WIP **答 答 答 答 率** - 当有人在团队频道请求帮助时,他们多久能在1小时内得到回应? - 目标: > 80%(重叠时间) - 如果低,你的频道不是通讯中心 **部署频率** - 不只是一个DevOps衡量标准 - 它是一个通信衡量标准 - 如果你每天都在部署,协调就有效了 - 如果在星期四部署组群, 您的进程有瓶颈 **黑频道参与** - 不只是"谁张贴",还有"谁回复了别人" - 3个人携带所有通讯载荷吗? - 一半的球队潜伏着吗? **模式 :** 如果这些测量仪是健康的, 你的通讯基础设施是有效的 如果它们退化了, **任何仪式都无法修补它**您需要解决根本问题(所有权不明确、心理安全低、工具摩擦等)。 ### 健康检查 问你的团队季度: 1. **这个仪式要解决什么问题?** - 如果没人能清楚表达,就杀了它 2. **什么证据表明它起作用了?** - "我们总是这么做"不是证据 3. **有更快的路吗?** - 合成能起作用吗 自动化能帮上忙吗 4. **如果我们跳过它会怎么样?** - 运行实验 暂停两周 测量撞击 5. **我们是否测试过替代品?** - 如果你运行同样的仪式 多年没有改变, 你不灵活。 ### 实际实例:我的最后一个小组 我们每天有18个月的备战,然后我提议一个实验: **假设:** 我们的成熟团队可以保持与 3x每周报到+同步更新一致。 **度量 :** - 块块解解解时间 - 冲印目标实现率 - 小组满意度(匿名调查) - 平均PR 年龄 **4周后结果:** - 屏蔽时间 : **无变化** (我们用黑标签) - 冲刺目标: **+1改进** (更多焦点时间) - 满意程度: **+15% 增加** (没有会议疲劳症) - PR 年龄: **-平均8小时平均8小时** (更多审查时间) 我们让它永久永久存在,不是因为站立是坏的,而是因为 **我们的环境没有证明税收是正当的**. ```mermaid graph TD A[Current Ceremony] -->|Define| B[Success Metrics] B -->|Propose| C[Alternative Approach] C -->|Run| D[Time-boxed Experiment] D -->|Measure| E{Better Results?} E -->|Yes| F[Adopt New Approach] E -->|No| G[Keep Original] E -->|Mixed| H[Iterate & Re-test] F --> I[Document & Share] G --> J[Schedule Next Review] H --> C style A stroke:#e1f5ff style D stroke:#fff3cd style F stroke:#d4edda style I stroke:#d4edda ``` ## 到期和背景问题小组 我想说清楚一点: **我不是说要消除无处不在的僵尸**. 一些环境真正受益于每日同步: ### 当支持赢得税收时 根据我的经验,每天的看台为以下活动提供价值: **新组建小组** - 成员不知道彼此的工作风格 - 隐含知识尚未形成 - 规范制定时需要明确协调 **少年重兵小组** - 学习估算和规划 - 从日常辅导接触点受益 - 建立专业交流技能 **高压力释放窗口** - 协调复杂的综合部署依赖情况 - 迅速识别阻塞器至关重要 - 共同应激反应中的心理安全 **跨功能发现** - 产品、设计和工程共同探索 - 原原型快速迭代 - 紧反馈环必要 **关键原则:** 当你们团队的背景改变时 你们的仪式也应该改变 我和团队合作 在6周的产品发布期间做过立体立体表演 之后改用合成。这不是不一致的 **这是适应**. ## 什么样的好样子 让我分享有效仪式在起作用时的模样: ### 示例:7-减号支持 最优秀的团队之一 我工作与运行的立体 像这样的: **格式 :** 1. 每个人在Slack的更新 *之前* 会 议 会 议 会 议 会 议 会 议 会 议 会 议 会 议 会 议 2. 会议开始:“任何阻拦者或需要的决定?” 3. 仅处理那些项目 4. 如果没有急事: "很好,会议取消,回去工作" **平均持续时间:** 7分钟7分钟 **会议取消:** ~40%的时间 **值 :** 解决高带宽问题,无地位剧院 ### 实例:Async视频更新 分布在9个时区的一个小组: **模式 :** - 每个人在日终记录60秒Lloom视频 - 共享黑线职位 - 其他人观看同步, - 每周同步会议仅限于复杂讨论 **时间成本 :** 60秒记录+3分钟监视 **时区问题:** 已消除 **连接 :** 高一点(看脸,听音音调) ### 示例:信任仪表板 一个团队建立了一个简单的仪表板: 任务 任务 估计 信任 最后一次更新 |------|----------|-----------|-------------| 2小时前 5点 90% = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 5小时前8点 60% 6点 5小时前 DB移民 3点 30% 一天前 置信率低于70%触发的自动“需要帮助?” **结果:** 阻塞器主动浮出水面,不需要开会。 ## 真实的罪恶精神 以下是我对正统的表态感到困扰的原因: 《阿吉勒宣言》说 **"响应变化 而不是遵循一个计划。"** 我们继承了Scrum的立体立体立体 继续运行 即使有证据表明他们不起作用 那不是灵敏度,那是 **传统传统传统**. 以我的经验, 真正灵活的团队 提出棘手的问题: - "去年的仪式有效,还有效吗?" - "我们现在已经分配了 同步模式应该改变吗?" - "我们的团队增加了两倍,是否结构规模相同?" - "我们刚发运了大项目 现在优化什么?" ```mermaid graph TD A[Agile Mindset] -->|Requires| B[Continuous Improvement] B -->|Applied to| C[Product] B -->|Applied to| D[Code] B -->|Should apply to| E[Process] E -->|Questions| F{Is this ceremony
still valuable?} d apply to| E[Process] E -->|Questions| F{Is this ceremony
still valuable?} F -->|Yes + Evidence| G[Keep & Measure] F -->|No + Evidence| H[Change or Remove] F -->|Unsure| I[Run Experiment] G --> J[Schedule Next Review] H --> J I --> F style A stroke:#e1f5ff style E stroke:#fff3cd style G stroke:#d4edda style H stroke:#d4edda style I stroke:#d4edda ``` ## 结论:仪式必须承担其负担 让我用一个简单的原则把这个带回家: > **仪式不灵活, 因为它在 Scrum 指南中有一个名字 。 > 只有当它得到重担时它才灵活** 站起来不是胡说八道 **强制性的、无可置疑的、无背景的政体是。** 以我的经验,最好的团队 对待仪式像代码: - 它们 **复构体** 何时出现模式 - 它们 **优化优化** 业绩受损害 - 它们 **删除删除** 不再需要时 - 它们 **测试替代替代品** 承诺前 - 它们 **度量** 知道什么是有效的,知道什么是有效的, 这是 **实际自组织小组**不是完全按照规定程序行事的团队,而是不断检查和调整自己工作方式的团队。 危险不是保护仪式,而是... **保护清晰、流动和交付**. 如果一个2分钟的黑卡, 达到一个15分钟的站立状态—— 你们的团队船只更快, 感到疲劳更少, 并保持一致—— **即动作的灵敏度**. 这就是我对你们的挑战: **本周,请问您的团队:** 1. 如果我们跳过了一周的斗殴,我们又会失去什么? 2. 我们能得到什么? 3. 我们愿意测试吗? 很好,你现在有证据了,而不是假设了。 或者你可能发现这几个月的税收没有好处了。同样伟大的——现在你可以优化了。 无论哪种方式,你会做 最灵活的事情 尽可能: **适应基于现实,而不是仪式**. --- ## 参考文献和进一步阅读 - [危险宣言](https://agilemanifesto.org/) - 原始原则 - [把船转过来!](https://davidmarquet.com/) L. David Marquet-以本方为主的领导能力减少了仪式需要 - [团队类型](https://teamtopologies.com/) - 团队结构如何影响通信需求 - [远程: 办公室不需要](https://basecamp.com/books/remote) - 基地营的Async第一思维 --- *我很想听听你的团队有什么成功(或没有成功)? [联系](/contact) 或在下文中留下注释。*