在传统瀑布式项目管理环境中，由于长周期规划、刚性需求冻结（即不允许随意在中途修改工作内容）等特性，OKRs难以发挥实时反馈与快速调整的优势。此时建议优先构建敏捷基础能力，再逐步引入OKR体系。

OKR的组成部份

OKRs的简洁性也是其广受欢迎的重要原因，主要组成部份为：

O，即”目标”（Objective）

KR，即”关键成果”（Key Results）

“目标”（Objective）定义组织追求的业务成果，”关键成果”（Key Results）则是衡量目标达成进度的可量化指标。每个目标通常对应2-5个关键成果。

使用OKR进行季度工作追踪

OKRs支持持续进度追踪，驱动组织及时采取纠偏或强化成功实践。每个关键成果应具备可分级度量能力（通常以百分比呈现）。鉴于企业战略调整存在滞后效应，建议按季度评估关键成果进展，并通过战略组合评审进行校准。图5展示了季度度量机制。

图5. 季度性关键成果追踪

多维度关键成果的价值在此凸显：单一指标无法完整反映进展全貌。部分成果随工作推进提升，另一些可能出现逆向波动。这种多维视角为计划调整提供决策依据。

OKR的更多经典应用场景

1增强企业的战略穿透力：

通过OKR构建战略主题的量化表达，确保投资方向、团队目标是与企业业务战略同频共振的。

2定义史诗Epic与精简业务用例的商业价值：

将大型举措分解为可衡量的业务成果，例如某Epic为提升客户门店体验提升。

3设定组织转型的改进目标：

用量化指标追踪转型成熟度的演进，如：交付周期从8周压缩至3周。

好的OKR该满足什么标准

精心设计的OKR能够有效对齐个体与团队的可量化目标，而低效的OKR则可能适得其反。常见误区包括：将常规运营活动替代为战略目标、聚焦产出而非成果、将关键成果定义为任务清单等。

优质的目标（Objective）应具备以下特征

激励性，目标应描述重要且有价值的战略方向，具有适度挑战性，能够激发团队突破舒适区。例如：”重塑客户数字体验”而非”完成季度系统升级”。

清晰易记：采用简洁有力的表述，通常设置3-5个目标。避免使用量化指标（这些应体现在关键成果中），例如：”建立行业领先的数据安全体系”。

类型明确，区分承诺型与进取型目标：

承诺型：必须达成的基线要求（如合规性改进）

进取型：突破性创新目标（如市场份额跃升），建议承诺型目标达成率100%，进取型目标60-70%为合理区间。

工作优化导向，识别目标类型差异：

业务交付类：聚焦解决方案开发，关键成果侧重业务指标

流程改进类：关注效能提升，如交付周期、等待时长等

每个目标对应2-5个关键成果（Key Results），优质关键成果应满足

价值导向：聚焦成果而非活动本身。可通过三问实现转化：

该活动的预期影响是什么？
如何量化验证影响效果？
期望达成的可测量结果是什么？

可量化：每个关键成果须包含明确数值目标，混合使用先导指标（如用户参与度）与滞后指标（如营收增长），构建多维评估体系。

可评估，采用渐进式度量方式，避免二元判定。推荐表达格式：

从X提升至Y
从Y降低至X
持续高于X阈值
维持低于Y水平

1. 以用户为中心的创新：对产品的有形影响

通过将我们的用户置于整个交付中心来聚焦，并持续动态重组我们的组织。使用用户的原型角色、影响力地图、用户旅程等技术，为我们持续地洞悉着用户需求的见解。唯有产品与目标受众产生共鸣，方可提高用户的采用率和满意度。

2. 成本优化和投资回报率最大化

产品上的探索发现的一个具体影响，是显著地减少了交付过程中的浪费。通过尽早验证想法，避免了对不必要功能的投资。因此，高效的设计实验显得尤为重要，它是我们提高产品ROI最大化的重要手段。

3. 数据驱动决策：对业务战略的影响

产品探索发现还可以通过用客观的数据取代主观意见，来推动业务上的决策。我们非常重视针对如何收集、分析正确的数据的学习，以支持组织进行明智的产品决策，从而实现更为有效的业务战略和可衡量的结果。

4. 跨职能协同：对组织效率的影响

当我们意识到产品本身并不只是产品团队的事情，这彻底改变了我们对内部人员组织的方式，这是一个将各种利益干系人聚集在一起的协作过程。通过组织跨职能的团队，让大家聚焦在相同的产品探索发现目标上，可以在从营销、设计、开发、运营等各个部门之间创建共享的语言和理解。这种对齐方式使工作执行更顺畅，整体效果更好。

5. 加速产品上市时间：对响应性竞争力的影响

最后我们也发现了，如果产品探索发现应用得当的话，可以显著缩短产品上市时间（TTM）。通过快速验证假设，我们可以快速转向并专注于交付出关键的功能，提高企业整体响应性竞争力。

当团队刚开始接触Scrum时，严格遵守这些规则是非常必要的。比如：

• 每日Scrum会议时长控制在15分钟内
• 每个Sprint都要设定明确的Sprint目标
• 所有的工作内容都要在产品和Sprint待办列表中以条目的形式清晰可见；
• 每个Sprint结束后，都要产出一个潜在的可发布增量；
• 每个Sprint结束后，都要通过回顾会议发掘可操作的改进点。

这些规则有的容易执行，有的则可能比较具有挑战性，但只要坚持遵守规则，团队总能逐步适应并改进。

然而，在与团队持续合作的过程中，在合适的时机允许团队尝试改变部份规则是一件很有意义的事情。（虽然“允许”这个词可能不太准确，但是又有什么理由去否定团队的任何尝试呢？）

Scrum的每一条规则和约束都有其存在的意义。但是如果团队不想继续使用Sprint目标呢？大家觉得实现该目标实在太难了，或者他们觉得Sprint回顾会议是浪费时间，又或者对Sprint工作的意义感到困惑，疑惑为什么无法参与到关注价值的持续产出当中。

我们非常欢迎团队提出这些问题，这说明大家对自己的工作、流程以及合作方式都十分地关心。

作为Scrum Master，我们总是鼓励团队大胆尝试一些小实验。我们可以先制定一个假设，设计一个实验，然后去尝试验证该假设，看看会发生什么。说不定团队能找到更适合自己的工作方式。

当然，也可能一个情况，实验的结果可能是团队不再使用Scrum。严格来说，如果团队不设定产品和Sprint目标，或者一个产品有多个产品负责人，或者不使用Sprint，那就不再是Scrum了。

但若该种方式对团队来说真的确实有效，那也很好！Scrum本身永远都不该是目标。

在我们看来，与其说想要改变Scrum规则，还不如说是，给了我们机会更深入地去了解团队状态：

• 到底发生了什么？
• 我们正试图解决什么问题？
• 我们忽略了什么因素？
• 我们应该进行哪些对话，但目前还没有？
• 我们是否意识到潜在的后果？

和团队一起探讨和观察这些问题。如果最终他们想尝试新事物，Scrum Master将是他们最大的支持者！

指引团队聚焦全新且正确的商业价值

在许多组织中，商业价值的关注点常常被忽视。团队可能被日常任务淹没，专注于流程、技术或个人KPI，而未能充分将其努力与更广泛的商业价值目标对齐。这种脱节可能导致计划错位、浪费精力和表现不佳。

许多组织普遍认为“商业价值”是高层领导的责任，与战略目标的设定相关。实际上，分散式决策对于组织实现敏捷性并释放团队的创造力至关重要。为此，需要在各个层面清晰且具体地理解商业价值，来指导这些决策。而当前的挑战在于商业价值并非一成不变的概念，它是高度情境化以及独特的。对一个组织有价值的东西，对另一个组织可能毫无意义。即使在同一组织内，产品组合、ART或团队在工作情境中对价值的理解也可能大相径庭。因此对于商业价值有全新且正确的理解至关重要。

商业价值发现的四个步骤

商业价值发现是组织各个层面的关键活动，接下来我们深入地介绍这一过程的四个关键步骤。

1、识别和描述价值

在组织的各个层面，商业价值的识别贯穿于SAFe的活动和事件中。在产品组合层面，产品组合的利益干系人和史诗负责人，通过组合看板发起对这些价值的讨论，通常会在组合战略细化阶段甚至更早开始。在ART层面，商业价值识别随着团队评估解决方案、探索使用场景和应用以客户为中心的技术时展开。

2、探索商业价值的维度

要更深入地探索和理解商业价值，必须超越这些价值表达形式，关注这些价值如何实现。它是有形价值（如收入），还是无形价值（如品牌及形象），是面向内部、专注于成本节约，还是面向外部、专注于收益增长的，这些问题有助于更细致、更正确地理解商业价值。

3、识别商业价值理解中的未知因素

记住一个通用原则，除非有确凿的证据和数据支持，否则关于商业价值的每一条陈述都只是假设。这表明了建立有效反馈系统的重要性，基于数据进行有效决策是至关重要的。因此我们需要对商业价值相关的“未知因素”进行分类，制定一些我们认为有效验证该未知因素的观测指标，这有助于有效管理它们的正确方向。

4、确定如何衡量商业价值

了解如何衡量商业价值是发现过程的关键部分。它确保我们商定的方法与我们对有价值东西的理解是一致的。因此需要建立必要的基础设施和方法，以持续收集关于结果的实证数据。

商业价值发现是组织各个层面的关键活动。商业价值文章中描述的四个步骤有助于更好地理解价值，促进对齐，为决策和优先级排序提供信息，并通过产品特性、史诗、战略主题等渠道更好地表达这种价值。

在动态多变的产品开发领域，交付价值对于在每个冲刺（Sprint）结束时创造出有形、可发布的输出至关重要，这能确保产品始终朝着增强可用性和功能的方向稳步前行。

根据《Scrum指南2020》，增量是实现产品目标坚实的基础。每个增量都是所有先前增量的加法且通过彻底验证的，以确保所有增量能够协同工作。为了提供价值，增量必须是可用的。

我们需要考虑几个关键事项：

完成的定义：

可用增量必须满足预定的“完成定义”（DoD），这包括团队为产品增量被视为完成而商定的所有标准。完成定义确保每个增量都符合产品所需的质量指标，并且是有价值的、功能齐全的、随时可用的。它关乎完成工作项目，并满足有效利用增量的所有质量标准和要求。

对客户的价值：

任何改进的一个关键方面是它对最终用户的价值。增量必须包含被认为是有意义的功能或强化。这可能意味着解决问题、添加新功能或改进现有功能，从而使产品更有用或更简单。如果增量没有为客户增加价值，那么其优先级就值得重新考虑。

完全集成：

每个增量都必须与现有产品完全集成，这意味着它应该和其他功能及组件无缝协作。集成确保新增量不会破坏产品的功能或引入新问题。这种无缝集成对于维护客户可以信任的可靠产品至关重要。

潜在可发布

如果有需要，可用增量可能会向最终用户发布，这是可用增量的本质。这确保了产品始终接近可发货状态，从而缩短了新增和强化功能的发布时间。

反馈到位：

可用增量对于收集有价值的反馈至关重要。交付可运作的产品切片使团队能够从真实用户或利益相关者那里收集见解，这些见解可以指导未来的开发工作，以符合用户的需求和偏好。

可持续开发步伐：

1. 创建可用的增量应避免团队倦怠或不可持续的工作实践。开发速度应保持一致和可控，以确保高质量的产出，同时不损害团队的良好状态。这种可持续的方法确保团队能够随着时间的推移保持有价值增量的稳定输出。

可用增量不仅仅是一组完整的工作项；它是产品中精心打造的一部分，能够带来即时价值，并已准备好投入实际应用。它凝聚了团队的协作努力和对为用户带来切实利益的承诺。

从这个视角来看，每个增量都是朝着下一个产品目标迈出的一步，也是朝着创造珍贵且具有影响力的事物迈出的一大步。这种思维方式改变了团队的工作方式，培养了追求卓越和以客户为中心开发的文化。

【学员说-CSP-SM认证课程推荐语】

加入CSP，助你全面理解敏捷本质与提升个人认知。以实践为导向，助你在人生道路上更进一步！

——Jack 程才

前言

在优普丰的CSP认证学习之旅中，我经历了一次深刻的思维和技能的重塑。从最初对CSM的懵懂无知，到A-CSM阶段的一知半解，我开始初步了解引导、教练等概念。如今，我已经能够熟练运用CSP的理念与工具，我的思维模式、行为习惯以及管理技能都经历了显著的转变与提升。接下来，我将从思维模式的转变、行为习惯的改变以及管理技能与LS工具箱三个方面，分享我的心得体会。

思维模式蜕变

在思维模式方面，我从过去单一的思考方式，转变为能够多角度、多层次地分析问题。我学会了批判性思考，不再仅仅满足于问题的表象，而是努力探究其深层次的原因，寻找问题的核心解决方案。在管理认识上，我逐渐从单纯的技术层面——只是关注死板的管理知识——转变为理解和领悟管理背后的深层理念，打开了全新的视野。我开始意识到，管理不仅仅是关于规则和程序，更是关于人与人之间的互动、价值观的塑造和文化的培养。我开始更加注重团队成员的感受和需求，努力营造一个开放、包容的工作氛围，让每个人都能在其中找到归属感和成就感。

行为习惯蜕变

在行为习惯上，我的管理风格从传统的命令与控制，在A-CSM到CSP的学习过程中逐步转变为引导与共创。我开始更多地倾听团队的意见，与他们共同合作解决问题，这种互动更加深入，也更有成效。我学会了如何在保持目标明确的同时，给予团队成员足够的空间去发挥他们的创造力和主动性。这种转变不仅提升了团队的士气，也显著提高了工作效率和成果质量。我开始尝试更多的团队建设活动，通过非正式的聚会和讨论，增强团队成员之间的了解和信任，从而在工作中形成更紧密的合作关系。

管理技能

在管理技能上，我之前仅依靠个人的经验和有限的知识，现在我开始系统地整理和学习各种管理技能，了解它们的应用环境以及自身的不足之处，深入挖掘自我潜能。我开始主动寻求反馈，不断调整自己的管理方法，以适应不断变化的工作环境。我意识到，作为管理者，我需要不断学习和适应，才能带领团队走向成功。我开始更加注重细节，通过定期的项目回顾和绩效评估，确保每个环节都达到预期目标。我也开始学习如何更有效地进行时间管理和资源分配，以确保在紧张的工作节奏中，依然能够保持高效和有序。

LS工具箱

至于LS工具箱，我认识到管理不仅仅是宏观的规划和掌控，更包括对细节的把握。我开始熟悉33种工具，以及它们在不同情况下的应用，从而更好地激发团队的潜能，促进集体智慧的发挥。这些工具成为了我管理工具箱中的宝贵资产，帮助我在面对复杂问题时，能够迅速找到合适的解决方案，确保项目顺利进行。我开始将这些工具融入日常工作中，无论是项目规划、团队协作还是决策制定，都能看到它们的身影。通过这些工具，我能够更加清晰地传达我的想法，也能够更有效地收集和分析团队的反馈，从而做出更加明智的决策。

通过这一系列的学习和实践，我不仅在专业技能上有了显著的提升，更重要的是，我学会了如何成为一个更好的领导者。我期待将这些宝贵的经验和技能应用到未来的工作中，继续推动个人和团队的成长与进步。更重要的是，CSP学习之旅让我深入了解自我、认识自我，与自我和解，向内修炼，探索生命最原始的激情，逐步蜕变为更强大的自己，以更自信、更坚定、更激情的状态面对未来。感谢申导与布老师的教导，我在CSP学习之旅学到的内容将伴随、受用、感悟一生，精进自我，并将能够带领我的团队迎接更多的挑战，实现更多的成就。

A.大模型AI当前在研发领域应用的现状如何？

AI并未给研发工程师带来危机感

智能化研发领域现在发展得特别快，也特别有挑战。在阿里巴巴，他们不仅做了代码补全和代码对话这些基本功能，还特别关注Prompt市场和Extensions这些场景，以支持业务的自定义需求。在外部，除了灵码和快码等产品有进展外，还出现了很多创业公司，比如Cursor和Windsurf。同时，很多创业公司围绕Github生态开发了局部智能化的Agent，比如Gru.ai能生成单测。

现在，研发智能化主要有以下几种形式：

1. 智能研发插件如Github Copilot、通义灵码、Comate，通过JetBrains、VSCode插件提供代码补全服务。

2. AI Native的IDE如Cursor、Windsurf、MarsCode，以独立IDE方式服务开发者，PearAI等公司基于VSCode二次开发。

3. CodeReview智能化领域起步早但效果一般，阿里巴巴项目存在模型能力和工程化不足问题。

4. RAG解决搜索和Summary问题，面临用户问题上下文不足、知识不保鲜、信息不完整、难以评测等挑战。

5. 智能解决代码冲突、自动解决编译问题等已在阿里巴巴内部平台上线，智能诊断、智能监控等也在调研中。

6. 局部智能化的Agent如Gru.ai、readme-ai、RepoAgent，帮助用户生成单元测试、Readme、补充注释，成功率较高。

7. 广泛自动化的Agent如Devin、OpenDevin，利用大模型生成任务plan，并在独立容器内执行，实现简单issue或需求。

目前对大模型能力有清晰界定，常见模型缺陷有应对策略，使用RAG增强模型上下文，降低模型幻觉。尽管模型发展迅速，但除了SWE-Bench榜单分数提高外，并未出现让程序员有危机感的产品，对大模型解决复杂问题的信心减弱。问题究竟出在哪里呢？

这到底是遇到了哪些阻碍问题呢

大模型基于Next-Token原理的局限性会影响其在智能领域的表现，但半年来的发展表明，问题不仅在于模型推理能力，还包括工程能力和数据的不足。即便推理能力强大的gpt o1模型发布已久，复杂系统研发问题上仍未见突破。大模型解决简单问题也面临挑战，并未能达到预期效果。

问题1：即使非常垂直的场景，需求也很难以自动化完成

Aone Copilot 在上半年推出了 Extensions 功能，旨在让专业人士创建插件，实现如 RAG 搜索、业务版本更新和业务代码生成等功能。尽管如此，我们发现特定场景的自动化还是难以实现，用户难以直接使用 Extensions 生成的代码，需要在反复本地调整。
使用者反馈指出，遇到了不同程度的问题，如：
1.定制组件时代码可能返回空值，缺乏定制方法的展示。
2.对字段作用和展示方式不清晰。
3.需要统一的语言输入和背景知识。
4.扩展点选择困难。
5.技术与领域上下文不匹配。
此外，业务上下文不足和需求理解与描述不足也是大模型落地的障碍。尽管积累了丰富的经验，但难以记录和传承，导致模型缺乏知识参考。我们发现，需求理解不足是大模型落地的主要问题，而无需详细描述需求的场景落地则状况较好。

问题2：用户期望过高而场景实际无法落地，给使用者们带来了负面影响

自GPT3.5发布以来，人们期待GPT4和GPT5能解决众多问题。随着简单问题的解决，探索更复杂、富有想象力的领域成为趋势。众多厂商和团队在SWE-Bench上竞争，但一年后，对这些榜单的兴趣减退，公测产品仍在测试中。行业对大模型的前景充满期待，但同时也感到焦虑，导致基础设施和数据建设的基础工作未得到足够关注。此外，许多管理者和企业领导者对人工智能抱有过高期望，但当他们发现辅助工具未显著提高效率时，开始怀疑技术的未来，对智能化研发的进程产生负面影响。

问题3：既没解决工程上下文问题，也没解决业务上下文问题

开发者通常负责维护旧系统、修复问题、开发新功能。如果大模型要开发新需求，它需要学习工程结构，理解项目目录、代码和配置，掌握本地开发、调试、发布、测试和验收流程，以及项目的历史演进，避免常见问题。此外，理解业务上下文也很重要，包括项目目的、业务背景、需求细节和验收标准。没有这些经验，即便是聪明的程序员也难以应对复杂系统。

许多初创企业的产品由于形态限制，难以整合不同平台的数据。同时，人们往往未充分认识到数据在处理复杂任务中的重要性。例如，Aone Copilot通过结合代码库和用户历史修改记录，提高了代码辅助修改的准确性。在代码审查中，引入需求文档和问题报告有助于发现更多潜在的业务逻辑错误。

基础设施的不足也是问题所在，如内部研发生态系统中需求与代码、文档与代码之间的联系微弱，且Commit Message编写不规范，导致数据处理成本高而有价值信息少。尽管阿里内部代码平台强制生成自然语言描述以改善这一状况，但研发基础设施工作仍需继续推进。

问题4：不能忽视“人”才是这其中的决定性要素

现在，很多产品觉得开发者不重要，以为只要写好需求，就能自动生成完整的自动化解决方案。但问题在于，人类才是理解需求和确定验收标准的关键，为什么要把他们排除在生产流程之外呢？不管是Copilot这样的辅助工具还是其他智能代理，人工智能和人类合作才是最好的。模型不确定的时候要找开发者帮忙，完成任务后也要开发者确认。有些知识只有开发者自己知道，改好的代码也需要人工审核。

一些IDE产品，比如Windsurf，已经开始实现这个理念，让模型在对话框里寻求人类确认。这种理念强调人类和AI合作，而不是取代人类。开发者可以通过自然语言和产品互动，随时确认并应用更改。在这种协作模式下，人和IDE的角色变得不那么重要。我们现在看到的是一种新产品形态，就是以IDE为平台，人和AI一起合作，用自然语言为主要交流方式的产品。

问题5：各系统平台间信息孤岛割裂，无法整合用户的操作行为和意图

因为不同平台的信息不统一，所以有时候我们搞不清用户到底想要什么。就像你用阿里Aone平台时，如果能看到和构建问题有关的信息，那AI帮你解决问题的速度就能快多了。还有啊，监控系统的报警如果能告诉我们最近都有什么活动，比如改了什么、发了什么，还有哪些高风险操作，那我们就能更快地找到问题所在。但现在这些重要信息都是孤立的，没有有效地整合在一起。所以啊，把不同平台的数据打通，让它们共享起来，是技术发展的一个重要方向，这样既能提高用户体验，也能更好地提供技术支持。

B. 大模型时代，我们又需要怎样的基础设施?

面向大模型的数据基础设施远远不够， 数据质量的重视仅停留在口号上

大语言模型的能力主要靠模型、数据和推理机制。虽然推理能力和模型性能有所提升，但数据处理还停留在基础阶段，数据迭代和管理的重要性常被忽视。在微调过程中，少量数据也能显著提高模型表现，强调了数据质量的重要性。提升数据质量需要迭代和演进，依赖于有效的版本管理和基础设施。这些基础设施应包括模型版本管理、数据存储、处理工具、审查系统和数据分析功能。当前数据存储基础设施存在不足，尤其是处理非结构化数据方面。在大模型领域，数据处理和使用人员不同，数据质量责任不明确。Aone Copilot 项目通过一年多的努力，开始解决这些问题，构建了可优化、审查和管理的数据基础设施，确保了数据处理的可追踪性和透明度，促进了团队间的高效合作。

人机的AI交互是关键，因此IDE成了最重要的战场

现在这个大模型时代，今年下半年，Cursor 突然火了起来，显示了 IDE 的重要性，它已经不只是个工具了，而是变成了很关键的基础设施。IDE 能把大模型的能力和用户需求结合起来，让协同工作更高效。Cursor 成功了，说明 Copilot 模式还能继续进步。它的亮点包括能一次填好多个地方，还能实时调整光标位置。

它能自动纠正代码中的错误，比如发现错别字并提供修复建议。还能迅速将对话框内容应用到编辑器中。

第一次用这些功能，我特别惊讶它们的性能。它们既不像传统的代码补全那样，又显得特别简洁，用起来也很顺滑。我们带着好奇试了很多，发现它们真的很厉害。Cursor 的关键是“重写”，就是重新写一遍文件或者文本段落，这和传统的方法完全不一样。通过这种方式，可以做到多点的补全和修正错误。比如，我把命名空间里的变量名改了。

Cursor能自动识别代码并重新写，记录模型对代码的改动，然后和本地代码对比，标出不一样的地方。它还能自动修复代码里的错误，更新变量名，保证代码的一致性。Apply功能简化了插入代码的步骤，省去了手动找位置和解决冲突的麻烦，让操作代码对话框更有效率。

用 Apply 功能，Cursor 能把你要改的代码和原来的代码放一起，让语言模型把左边的代码改写一下。IDE 会帮你对比改写后的代码和原来的代码，让你自己选要不要改。不过，还是有点麻烦：得知道改写到哪儿为止，还得赶紧生成好多文本，还得保证不卡。团队已经解决了服务器上的技术难题，让模型推理更快了，但在 VSCode 上，因为 API 的限制，还是有点难。是不是应该开发一个单独的 IDE，给用户提供更好的体验？这是个值得讨论的问题。单独的 IDE 有好多好处，比如可以搞个“影子仓库”机制，还能用 LSP 支持文件操作啥的。

研发平台作为基础设施底座，具有不可估量的潜在知识经验转移场景可应用

咱们聊了聊数据基础设施和集成开发环境（IDE）的重要性，但Aone Copilot的潜力实际上还看研发数据。这些数据展示了研发过程中的复杂信息，帮助AI更高效地完成任务。研发数据包含了必要的知识和经验。比如说，通过分析需求、代码变更和架构设计、代码实现之间的关系，我们能了解项目进展并提出解决方案。像Aone、Code或GitHub这样的研发平台在数据和工具方面有优势，有助于应对大型语言模型的挑战。在大型模型时代，研发基础设施需要提供数据支持和工具能力，但很多团队的研发流程管理不严格，导致有价值的数据积累不足。不过，通过引导和推动规范化，我们可以改进研发的标准化，认识到数据对效率提升的重要性。

C. 每个企业都应重视内部智能化产品的机会

本篇文章谈到了开发智能体遇到的难题，即使智能体智商很高、推理能力也很强，也难以满足所有复杂需求。没有高质量数据支持的智能体是不现实的。同时强调了数据工程和集成开发环境在大规模模型时代的重要性，并解释了人机交互的重要性和工作原理，最后还分析了研发平台的基础建设作用，打通所有数据孤岛的重要意义。

尽管企业内部智能研发工具没有广泛的外部用户基础，但它们能利用内部资源为使用者们提供了更为深层价值，推动标准化文档和研发习惯，促进工程发展。因此，在AI革新研发模式的前夕，我们应该更积极地考虑AI取代人类工作的担忧是否合理，同时更应思考在变革彻底到来之前，我们作为研发领域的资深从业者们，又该如何做好应对准备。

【学员说-CSP-SM认证课程推荐语】

若你想在教练技能和引导技巧上更上一层楼，CSP-SM能让你从“优秀”迈向“卓越”。

——Anson Wu伍伟曦

培训课程设计，闪电演讲 —— 永远不可能完全准备充分，紧抓核心

在我过往的培训或者课程，通常都会事先对演讲课题做充分的准备：充分的演讲台词脚本准备，充裕的演讲时间，清晰已知的课程受众等等，至少在预演当中令我感觉心里踏实的程度。

但第一个练习，导师们就给我出了道难题。三大题目里面选一个，15分钟内和partner协作准备一个15分钟的、符合4C原则的培训课程。一个相当宏大的话题要用15分钟讲完已属实困难，遑论更要15分钟内临时做出准备，虽然觉得有点强人所难，但我还是咬着牙上台讲完。

在自我反思反馈环节，我坦言由于时间仓促导致准备不足，从而还进一步引发了演讲时候的紧张情绪，导致我在本已够复杂的主讲内容中插入了更多的“新名词”，可能让听众感到信息爆炸，堕入雾里。

但接下来，申导的反馈意见无异于给了我一记当头棒喝，把我震醒了：培训课程设计可以有15分钟的，也可以有1个小时，甚至给定时间还有半天、一天的，你也可能准备很多内容。但演讲者需要聚焦，想清楚最想表达给听众的是什么。如果想清楚这点，那么讲一个小时你会知道该围绕什么核心展开；讲15分钟也能讲清楚，内容在哪里倾斜侧重，该一笔带过的也知道怎么带过。

“火把教练”，教练之箭 —— “不识庐山真面目，只缘身在此山中”

在“火把教练”的环节，每人充当教练的角色轮流向案主客户发问。

在教练过程当中，我们更应该关注案主，而不是优先关注案主所描述的案例中人或事细节，毕竟经由案主口中所描述的“客观事实”，已经是带有案主主观的视角和观点。带有“滤镜”的信息，很容易把教练的思绪带偏，无法更客观的帮助案主理清思路和价值。

但第二轮过后，大家都不约而同地深究案主所描述的案情，甚至开始根据“案情”提供各种详细方案。

在反思反馈阶段，导师们跟大家一起回顾了教练之箭的几个要点，总结了适才的练习过程，我回想起每个人问的问题，思索所问问题的角度和思路，发现都过分陷入了案例细节里面，而忽略了本次引导的根本目的，是帮助案主客户理清思路，解决期望目标。

换位思考，自我察觉，内观自变 —— “以人为镜，可以明得失”

在引导师练习中，我在台上不经意的就会代入到现实中的Scrum Master或者Agile Coach角色。现实中这个角色，需要从“引领”到“跟随”，从咨询—培训-导师-引导-教练的各个角色不断游走，在转换中容易迷失自我，导致在引导的过程中变得不够中立客观，给出带有暗示性、偏向性的意见。

而在角色扮演游戏里的收尾阶段，我们每个人则需要不停地转变角色，表达不同的视角和观点。

这两个环节引发了我的深思。在日常实际工作或生活中，我们既要很清晰自己的定位，以及应该聚焦的核心点，避免被其他观点牵着鼻子走；又要多换位思考，尝试从不同视角获得更多更准确的全局信息，避免视野过于狭隘，固执己见。

Scrum Master或者Agile Coach在组织设计或转型中，往往是变革的先驱者。因此变革就应该先从自身开始，随时“吾日三省吾身”，进一步打磨自己的能力。

组织设计，系统思考 —— 敢于突破思维茧房，勇于蜕变

在最后一个沙盘演练中，我们几位准CSP一起讨论探究组织设计的“动”与“静”。我们要在给定的条件中，设计并组建有效的，满足条件的团队。

这个练习并没有所谓的“正确答案”或者“最佳答案”，解题思路更不是唯一，更重要的是过程中的思路。在演练当中，随着给出的难题越来越苛刻，各人在讨论中给出的方案，越容易直接参照自身现实中的情况，甚至放弃一些根本性的原则。

Scrum Master或者Agile Coach作为变革的先驱者，在基于对现状的了解，应该清楚认知到外部的需求和变化是永远不可控的，因为思维必须大胆突破现有的框架，从更高层次、从更广阔的系统思考的角度考虑组织设计，而非单纯为了短期利益成事而安于现状。

LS引导工具箱 —— “工欲善其事，必先利其器”、

我是在A-CSM的课程里首次接触LS释放性结构引导工具箱。我发现很多工具，在日常工作中都用上，并发挥到良好作用，例如协助PO梳理用户故事地图、引导Scrum团队迭代回顾会等。

今次CSP课程中，从一开始的“电梯演讲”，到在“火把教练”练习中的Call-out Question，再到“金鱼缸会谈”的升级版“大型智囊团”，两位导师展示了不少引导工具的实际运用，在课堂引领和交互方面的效果毋庸置疑。

写在最后 —— 醍醐灌顶，易筋洗髓

即使CSP的学习仅有短短两天就结束，但我对教练技巧、引导工具的探索和学习方兴未艾。这让我想起Scrum的其中一个内核精神：以终为始。

临走时，我再看了一眼贴在门口的CSP课程海报，然后心满意足地离开。脑海里仍记得它上面书写着：从“优秀”到“卓越”。乘风而来，满载而归。

在Scrum中，完成的定义（DoD）对确保质量和透明度起着至关重要的作用。但谁来定义这一重要概念？这到底意味着什么？让我们来拆解一下。

完成的定义是什么？

完成的定义是Scrum团队之间对产品待办列表中已完成事项的共同理解。它定义了工作被视为完成所必须满足的标准，也是产品待办列表上每个事项的质量检查清单，确保每个人都知道“完成”的真正含义。

为什么我们需要一个完成的定义？

想象一下，有一个Scrum Cookie公司的两个Scrum团队。Sheila和Bob是各自团队的Scrum Master。两个团队共同努力完成产品待办列表中的cookie订单。条目包括为婚礼提供200个饼干，为家庭团聚提供300个糖饼干等。

然而，有一个问题：Scrum Cookie公司当前局势紧张。Bob的团队遵循严格的流程。他们确保每一批饼干都是依照食谱制作的，按照合准确的时间烘烤、然后包装、然后定价，最后，在考虑把每个产品待办事项列为“完成”之前，他们会清洁厨房。然而，Sheila的团队在烘焙后并没有清理厨房。

这种不一致会导致混乱和沮丧。为了解决这个问题，Scrum Cookie公司引入了“完成”的组织定义：一旦饼干烤好，厨房必须打扫干净，然后才能关闭产品待办列表条目。

Sheila和Bob开会讨论了这一新标准，他们采用组织的“完成的定义”的同时，还同意他们的团队将在关闭各自的产品待办列表事项之前，对每批Cookie进行包装和定价。他们将此添加到其产品的“完成”定义中。

这个示例展示了“完成的定义”如何让团队达成对完成每个产品待办列表事项所需工作的共同理解。这也表明了团队之间保持一致的重要性。

谁创造了完成的定义？

1. 组织：如果有一个现有的组织完成定义，该组织内的所有Scrum团队都必须将其作为最低标准。在我们的Scrum Cookie公司的例子中，该组织决定每个团队在烤完饼干后都必须打扫厨房。这为所有团队的“完成”设定了一个基线。
2. Scrum团队：每个Scrum团队都有完善和扩展组织“完成定义”的自主权。但是，他们不能删除组织设置的任何条件。例如，Sheila和Bob的团队在考虑“完成”所做的工作之前，增加了包装和定价两个额外步骤。
3. 团队之间的协作：当多个Scrum团队在同一产品上协同工作时，他们必须共享相同的完成定义以确保一致性。这避免了一个团队的工作与另一个团队标准不一致的情况，从而避免了未来可能出现的问题。

完成定义的益处

• 灌输质量：通过遵守“完成”的定义，团队可以确保他们始终如一地提供高质量的增量。
• 提高透明度：一个清晰的完成定义为Scrum团队和利益相关者提供了可见性，确保每个人都能理解产品待办列表中的事项何时真正完成。
• 改进计划：对“完成定义“的共同理解，可以让团队更好地计划他们的工作，避免误解或交付不完整。

持续探索（Continuous Discovery）不仅仅是为找到正确的问题，它还帮助团队找到正确的举措、试验和解决方案，这些与组织的产品愿景、战略和路线图一起，为客户提供价值成果。

在持续探索中，我们首先设定一个北极星，我们想要实现的目标。然后尽可能多地学习，以确定这个目标是否能为客户带来价值结果，并且对业务来说是可行的、可实现的。

以下是一个我们可以借鉴的框架，可以帮助Scrum团队进行持续探索，确保战略与价值成果相连，通过提供有意义的解决方案。本文更加以我们某个航空公司客户的案例加以说明，双轨敏捷如何开展应用的。

双轨敏捷（Dual-Track Agile）

由Jeff Patton引入的双轨敏捷是一种强调两个平行的发现和交付轨道的方法，每个轨道都有其特定的重点和目标，学习客户的痛点和价值交付。

探索轨道（Discovery Track）

• 重点：理解客户需求。

• 活动：验证假设和探索潜在解决方案。

• 结果：提供经过验证的学习结果，通知交付轨道开发交付价值结果的功能。

交付轨道（Delivery Track）

• 重点：为客户构建和交付功能。

• 活动：结合发现轨道中经过验证的学习结果，开发符合客户需求和期望的功能。

• 结果：持续为客户交付增量价值，并从反馈中学习。获得的洞察反馈回发现轨道。

双轨并行

这种方法使团队能够根据发现轨道中的经过验证的学习不断迭代和完善他们的产品。通过在探索和交付之间保持平衡，团队可以确保他们正在构建正确的产品功能，满足用户需求并交付业务价值。

案例：某航空公司移动应用开发

在我们某个航空公司的案例当中，在其移动应用团队开发进行了应用。探索轨道*可以用于用户研究，以了解高频使用的航旅用户的需求。这会涉及调查或访谈，以收集关于所需功能的见解，例如如何轻松访问其登机牌、如何实时查看航班信息、如何无缝进行预订体验等。

基于这些见解的下一步是开发原型功能，针对用户进行测试以验证这些产品想法。例如，可以验证一个允许用户数字化地存储他们的登机牌的原型功能，以测试其易用性和便利性。

同时，交付轨道将专注于推出基于探索阶段想法的产品增量更新和功能改进。这可能涉及开发出数字化登机牌功能，并将其作为应用更新发布。用户对这一新功能的使用反馈将反馈到探索轨道，创建一个持续改进循环。

设计冲刺（Design Sprint）

由Jake Knapp在Google Ventures开发的设计冲刺是一种设计思维方法，旨在通过原型制作和与客户测试在五天内验证想法和解决重大挑战。它是商业战略、创新、行为科学和设计思维的融合。

设计冲刺的关键步骤

• 映射Map：理解问题并创建达到目标的路径。

• 草图Sketch：提出各种解决方案来解决已识别的问题。

• **决定Decide **：选择与您的目标一致的最佳解决方案。

• **原型Prototype **：创建一个高保真原型来可视化解决方案。

• **测试Test **：用真实用户验证原型并收集反馈。

案例：航空公司移动应用开发

设计冲刺在开发航空公司移动应用中可以发挥重要作用，确保以用户为中心的解决方案被优先考虑。

• 映射Map：识别关键挑战，如预订效率、用户体验或航班信息准确性。涉及利益相关者，了解业务目标和用户需求。

• 草图Sketch：为高效的预订系统、直观的UI/UX设计或实时航班跟踪功能等解决方案进行头脑风暴。

• 决策Decide：根据可行性、可实现性和可取性评估提出的解决方案。选择增强可用性并与业务目标一致的功能。

• 原型Prototype：开发一个可点击的原型，整合选定的功能，如简化的预订流程或个性化的用户体验。

• 测试Test：从实际用户那里收集关于易用性、功能和整体体验的反馈。根据用户反馈为应用改进做出明智的决策，然后才开始全面开发。

这种结构化方法确保了资源的有效利用，导致开发出满足业务目标并提供增强用户体验的应用。

精益价值树（Lean Value Tree,LVT）

Lean Value Tree（LVT）是由Thoughtworks开发的战略规划工具，使团队能够将产品战略与业务目标对齐。它提供了一种结构化的方法来可视化、优先排序和衡量朝着期望结果的进展。

LVT的关键组成部分：

• 愿景：为所有投资设定最终方向。

• 战略目标：专注于结果的明确清晰的目标。

• 赌注：团队认为将有助于实现目标的价值假设。

• 举措：与赌注相关的小假设，用于衡量成功（验证）。

案例：航空公司移动应用开发

LVT可以有效地用于航空公司移动应用的开发。以下是如何定制每个组成部分：

• 愿景：创建一个用户友好的移动应用，为乘客提供无缝高效的旅行体验。

• 战略目标：

1. 通过应用增加在线预订。
2. 通过应用界面和功能提高用户满意度。
3. 通过吸引新用户来扩大市场覆盖范围。

• 赌注：

1. 在应用中实施新的忠诚度计划，以激励重复预订。
2. 优化预订流程，使其更直观、耗时更少。
3. 引入基于用户偏好的个性化旅行推荐功能。

• 举措：

1. 衡量通过应用增加的在线预订数量。
2. 进行用户满意度调查，以衡量应用界面和功能的改进。
3. 跟踪在实施新功能后吸引到应用的新用户数量。

通过持续监控这些举措并相应调整LVT，开发团队可以确保他们的努力与总体业务目标一致，并为组织提供可衡量的价值。这种方法确保开发的应用程序不仅满足业务目标，还增强了用户体验。

机会解决方案树（Opportunity Solution Tree,OST）

OST框架由Teresa Torres提供，是一种结构化的方法，用于识别客户问题（机会）和潜在解决方案。

• **结果重点 **：树的根是关注传递业务价值的期望结果。结果应该是团队的指导灯塔，确保每个人都朝着与业务目标一致的共同目标工作。

• **机会映射 **：产品团队从进行客户访谈开始，识别他们的问题或需求。这形成了机会空间，确保没有伪需求的解决方案。虽然这个空间可能复杂且混乱，但对于生成潜在解决方案至关重要。

• **解决方案生成与评估 **：对于每个识别的机会，生成多个潜在解决方案。鼓励广泛的创意，不要急于决定追求哪个解决方案。通过假设测试评估这些解决方案，这有助于在投入资源构建它们之前验证这些想法。

• **目标机会选择 **：基于其对期望结果的潜在影响选择目标机会。这个决定应该在不考虑实施潜在解决方案所需的努力的情况下做出。重点应该放在机会的价值和影响上，而不是实施的容易程度。

• 持续迭代：OST是一个随时间演变的活文档。随着团队对客户及其需求的了解越来越多，他们应该更新树。这包括添加新的机会和解决方案，并修剪那些不再相关或已被假设测试否定的机会。这种持续迭代确保OST保持相关并与客户需求和业务目标一致。

案例：航空公司移动应用开发

在航空公司移动应用示例中，团队可能使用OST：

• 结果重点：期望的结果可能是通过移动应用提高客户满意度和增加机票销售。

• 机会映射：与应用用户进行访谈，识别他们的需求和痛点。这可能揭示了需要更用户友好的界面、更快的预订流程或更个性化的航班推荐等机会。

• 解决方案生成与评估：对于每个机会，生成多个潜在解决方案。例如，对于更用户友好的界面的机会，解决方案可能包括重新设计应用布局、简化预订流程或为首次用户添加教程。通过用户测试和反馈评估这些解决方案。

• 目标机会选择：基于其对期望结果的潜在影响选择目标机会。例如，如果用户反馈表明简化的预订流程可以大大提高客户满意度和增加机票销售，那么这可能是被选择的目标机会。

• 持续迭代：随着应用的开发和收集到更多的用户反馈，不断更新OST。这可能涉及添加新的机会和解决方案，如集成额外的支付选项或引入忠诚度计划，并移除已完成或通过用户反馈否定的机会。

这种方法确保航空公司移动应用的开发始终与其用户的需求和航空公司的业务目标保持一致。它还允许随着用户需求和业务目标的演变而具有灵活性和适应性。