L114.1 敏捷视频

L114.1 敏捷视频

看板和scrum

​

Scrum 与看板（Kanban）的对比

敏捷开发方法论中的Scrum和看板（Kanban）都是为了以小增量的方式向客户交付价值，并收集客户反馈以改进产品。 它们的核心都是“拉动系统”（pull systems），旨在尽可能缩短工作从产品待办列表（product backlog）到客户手中的时间，并帮助发现流程中的瓶颈。

主要区别

特点	Scrum	看板 (Kanban)
工作节奏	以固定时长的“冲刺”（Sprints）进行，通常为两周。	持续流程，没有固定的冲刺周期。
待办列表管理	每个冲刺前，团队从产品待办列表中选取一部分工作作为“冲刺待办列表”（Sprint Backlog），并承诺在该冲刺内完成。在冲刺期间，除非极特殊情况，新需求需等待下一个冲刺。	没有冲刺待办列表。团队从产品待办列表中持续拉取高优先级任务。
拉动系统实现	通过冲刺规划会议，团队将产品待办列表中的任务“拉入”到冲刺待办列表中。	通过“在制品限制”（Work In Progress Limits）实现。看板上每一列都有在制品数量限制，当一列有空余时，前一列的任务才会被“拉入”。
角色名称	Scrum Master 负责帮助产品负责人和开发团队采纳并保持良好习惯。	敏捷教练（Agile Coach）承担类似角色。
会议/仪式	包括冲刺规划会议、每日Scrum站会、冲刺评审会议和冲刺回顾会议。	也有每日站会、向相关者演示以及回顾会议，但名称可能略有不同。

共同点

• 敏捷核心：两者都遵循敏捷原则，以小增量交付价值并重视客户反馈。
• 拉动系统：都采用拉动系统来优化工作流程和效率。
• 可视化管理：通常都使用某种形式的看板（Scrum Board 或 Kanban Board）来追踪工作进展。
• 持续改进：都包含回顾机制（Retrospectives），旨在让团队不断学习和改进工作方式。
• 角色定位：都有专门的角色（Scrum Master 或 Agile Coach）来支持团队和流程。

何时选择 Scrum 或看板？

文档中并未明确指出在何种情况下应优先选择Scrum或看板。然而，根据它们各自的特点可以推断：

• Scrum 更适用于：

  • 需要固定节奏和明确交付承诺的项目。
  • 团队能够对一定时期内的工作量做出相对准确的估算和承诺。
  • 项目需求在冲刺期间相对稳定。

• 看板更适用于：

  • 工作流程需要高度灵活性和持续流动性的场景。
  • 工作性质难以进行固定时长的规划，例如支持性工作或需求频繁变更的环境。
  • 希望通过限制在制品来暴露瓶颈并优化流程。

何时两者皆不适用及其他敏捷实践方式？

文档中提到，高效的团队会根据自身情况调整和变通Scrum或看板的规则，并没有绝对的“一刀切”。 这暗示了在某些情境下，严格遵循任一框架可能都不是最优解。

当Scrum的固定迭代和看板的持续流程都不能很好地适应团队或项目需求时，可以考虑：

• 混合模式：结合Scrum和看板的元素，例如在Scrum的框架下引入在制品限制，或者在看板流程中加入定期的回顾和规划会议。
• 精益原则 (Lean Principles) ：更广泛地应用精益思想，例如价值流图（Value Stream Mapping）来识别和消除浪费，持续改进，尊重员工等。
• 极限编程 (XP - Extreme Programming) ：引入XP的实践，如测试驱动开发（TDD）、结对编程（Pair Programming）、持续集成（Continuous Integration）等，这些实践可以与Scrum或看板结合使用，也可以作为独立的敏捷实践。
• 自定义敏捷方法：基于敏捷宣言的核心价值观和原则，根据团队的具体情况和项目特点，量身定制一套适合自己的工作方法。重要的是保持灵活性、持续反馈和快速适应变化。

需要强调的是，Scrum和看板都只是实现敏捷的框架，核心在于敏捷的思维方式和原则。

精益和敏捷

精益方法论通常被理解为敏捷思想的一个深化或特定应用方向，它们共享一些核心价值观，例如快速交付价值和持续改进，但也存在显著的关注点和实践差异：

1. 起源与核心焦点:

   • 敏捷 (Agile) ：起源于软件开发行业，其核心在于应对变化、快速迭代、强调个体与互动、可工作的软件、客户协作以及对变化的响应。敏捷更像是一个理念集合和一套指导原则（如敏捷宣言中的四句价值观和十二条原则），旨在使开发过程更灵活和适应性更强。
   • 精益 (Lean) ：起源于丰田的制造业生产实践（丰田生产方式），其核心焦点是消除浪费 (eliminating waste) 、优化流程 (optimizing processes) 和最大化客户价值 (maximizing value to customers) 。精益方法论关注整个价值流的效率。

2. 目标与方法:

   • 敏捷 (Agile) ：目标是灵活地开发产品以更好地满足客户需求，通过短周期的迭代（如Scrum中的Sprints）交付可工作的软件，并持续获取反馈。敏捷强调团队协作和快速响应变化的能力。
   • 精益 (Lean) ：目标是通过持续改进流程，识别并消除所有不为客户增加价值的活动（即“浪费”）来实现可持续的开发过程。精益采用如“构建-衡量-学习”(Build-Measure-Learn) 的循环，并将进展定义为经过验证的学习。它还使用“改善”(Kaizen) 的方法来持续识别和消除浪费。

3. 主要原则与实践差异:

   • 敏捷 (Agile) ：更侧重于通过迭代和增量交付来适应不确定性，常用实践包括用户故事、冲刺（Sprints）、每日站会、回顾会议等。敏捷强调的是交付能工作的软件和满足用户需求。
   • 精益 (Lean) ：更侧重于流程优化和效率提升，强调价值流、流动、拉动系统、追求完美（通过消除浪费）以及尊重员工并鼓励他们参与改进。精益关注的是如何更有效地交付价值，减少流程中的延迟和不必要的环节。

4. 范围与应用:

   • 敏捷 (Agile) ：虽然起源于软件开发，但其原则和实践已被应用于多种项目管理和产品开发领域。
   • 精益 (Lean) ：虽然起源于制造业，其原则（如消除浪费、价值流分析）具有普适性，可以应用于任何行业和流程改进中。

总结来说：

可以将敏捷视为一种更广泛的理念框架，强调适应性、协作和快速交付价值。而精益则可以视为一种更具体的方法论，它通过聚焦于识别和消除浪费来优化整个价值流，从而实现高效和高质量的产出。许多情况下，精益的原则可以被融入到敏捷实践中，形成所谓的“精益敏捷”(Lean-Agile) 方法，结合两者的优点，既保持灵活性，又追求效率和持续改进。例如，敏捷团队可以运用精益中的“改善”(Kaizen) 来持续优化他们的工作流程。

敏捷的曲解

敏捷原则是如何被曲解或颠覆的？请举例。

敏捷原则很容易因为被肤浅地解读或误解而被曲解，从而颠覆其初衷。文档中提到的一些方式和例子包括：

• 曲解“响应变化高于遵循计划” ：

  • 错误解读：认为敏捷意味着不需要计划，或者计划是敏捷的对立面 。
  • 实际含义：敏捷并非摒弃计划，而是强调在有计划的基础上，要乐于接受并适应计划的变更 。制定计划是重要的，但不应陷入过度分析，计划的详细程度可以随着时间的临近而逐步细化 。
  • “半吊子敏捷宣言”中的讽刺性曲解：在遵循计划的前提下响应变化，前提是有一个详细的计划来应对变化，并且该计划被精确地执行 。

• 曲解“客户协作高于合同谈判” ：

  • 错误解读：认为不能或不需要与客户签订合同，只能进行不定期的交流 。
  • 实际含义：可以进行合同谈判，但在敏捷方式下，合同需要体现工作的灵活性，并告知客户团队是持续学习和适应的 。

• 曲解“可工作的软件高于详尽的文档” ：

  • 错误解读：认为不需要任何文档 。
  • 实际含义：可以也应该创建文档，但必须接受软件会变化，文档也需要随之更新 。最好的方式是让文档与代码一起维护（如注释），或者在软件变更时及时更新文档，否则过时的文档毫无价值 。

• 曲解“个体和互动高于流程和工具” ：

  • 错误解读：过于依赖流程和工具，甚至认为遵循特定流程或使用特定工具（如Jira）就是敏捷 。当沟通出现问题时，倾向于增加更多的规则、流程或工具来控制，而不是促进个体间的真实互动 。
  • 实际含义：应重视人与人之间的直接沟通和协作。过多的流程会像“疤痕组织”一样，降低组织的灵活性和敏捷性 。解决沟通问题的方法是移除障碍，让相关人员能够直接、频繁地交流 。例如，每日站会（Daily Scrum）的目的就是提供一个平台，让团队成员沟通需求、寻求帮助和解决问题，而不是简单汇报工作 。

Scrum 能否与瀑布流结合？如何结合？

是的，Scrum可以与瀑布流程（Waterfall process）结合使用，这种混合模式有时被称为“水-Scrum-瀑”（Water-Scrum-Fall） 。

结合方式可能表现为：

• 项目阶段中的“敏捷孤岛” ：在传统的瀑布模型阶段门（Stage Gate Model）之间，团队可能在某个特定阶段（如开发阶段）采用Scrum的迭代方式进行工作。例如，前期进行大量的分析（瀑布），然后在开发阶段采用敏捷迭代（Scrum），最后再进行大量的测试和集成（瀑布）。
• 用Scrum支持项目管理：Scrum的框架（如Sprints、每日站会、Sprint回顾等）可以被用来辅助项目经理追踪团队成员的工作进展和工时消耗 。在这种情况下，Sprints甚至可能提前数月就被规划好，这与敏捷的适应变化原则相悖，更像是用Scrum的外壳来执行预设计划 。

文档作者指出，他曾在一些公司工作，这些公司在阶段门模型中“门内”采用敏捷方式，整体上呈现出“水-Scrum-瀑”的模式 。

究竟是什么让敏捷流程真正敏捷？

仅仅采用Scrum或其他敏捷框架的仪式和工具（如每日站会、Jira）并不意味着一个流程就是真正敏捷的 。文档强调，真正让敏捷流程之所以敏捷的核心在于：

1. 检视与适应 (Inspect and Adapt) ：这是敏捷的核心理念 。团队需要能够：

   • 检视 (Inspect) ：透明地了解工作是如何进行的，例如通过看板展示工作流，通过演示（Demo）向利益相关者展示进展，让管理者了解实际情况（而非仅仅是工时消耗）。
   • 适应 (Adapt) ：能够根据检视到的情况做出反应和调整 。

2. 信任 (Trust) ：

   • 需要管理层的信任，允许团队根据实际情况调整工作。
   • 需要客户的信任，允许团队根据学习和反馈调整最初承诺的功能，以交付更好的产品 。

3. 技术敏捷性 (Technical Agility) ：

   • 没有技术上的敏捷支持，真正的业务敏捷是无法实现的 。
   • 这意味着需要投资于支持敏捷开发的实践，例如持续交付 (Continuous Delivery) 或至少是持续集成 (Continuous Integration) 。
   • 团队需要有勇气去修改软件，而这种勇气来源于技术上的保障，即知道微小的改动不会破坏整个系统 。

4. 遵循敏捷原则和价值观 (Adherence to Agile Principles and Values) ：

   • 不仅仅是遵循某个流程的字面规则，更重要的是理解并实践敏捷宣言背后的12条原则和4项价值观 。例如，重视个体互动、持续交付价值、拥抱变化、与客户协作等。

简而言之，真正的敏捷不仅仅是流程或工具的堆砌，而是一种文化、一种思维模式，它要求透明度、信任、持续学习、快速反馈循环以及能够真正根据反馈进行调整的技术和组织能力 。如果缺乏这些，组织可能只是“名义上的敏捷”（Agile In Name Only - AINO）。

用户故事

用户故事如何帮助需求规约？

用户故事通过以下方式帮助进行需求规约：

• 聚焦用户价值和目标：用户故事的核心是描述用户想要软件做什么，以及他们期望达成的目标和结果，而不是具体的技术实现细节 。它们帮助团队从用户的视角思考，理解用户的真实需求和使用场景 。
• 分离“什么”与“如何做” ：用户故事是一种有效区分“系统需要做什么”（What）和“系统具体如何实现”（How）的技巧或快捷方式 。它们强调描述用户可见的成果，从而让开发团队在后续有更大的自由度去探索不同的解决方案 。
• 促进沟通与理解：用户故事通常采用用户能够理解的自然语言编写，避免技术术语，这使得非技术人员（如产品负责人、客户）更容易理解每个需求的含义和项目进展，从而更好地参与讨论、划分优先级和削减范围 。同时，技术人员也能更深入地理解业务背景和问题本身 。
• 定义用户的心理模型：用户故事帮助定义用户与系统交互时的心理模型，例如：当用户接触系统时他们的目标是什么？系统工作时用户需要注意什么？系统失败时用户需要知道什么以及如何继续？这些都是关于“什么”的问题，而非“如何做” 。
• 保持高层级和灵活性：好的用户故事在捕获目标方面足够准确，同时又保持一定的模糊性，允许通过多种不同方式来实现这个目标，为后续的设计和实现留出空间 。

使用用户故事的优势是什么？

使用用户故事的主要优势包括：

• 更好的设计：从用户视角出发思考，更容易产生更符合用户期望和需求的设计方案 。
• 清晰的沟通：使用用户语言，使得技术和非技术团队成员之间的沟通更有效，减少误解，让每个人对需求的理解更一致 。
• 有效的优先级排序和范围管理：当需求以用户价值的形式表达时，非技术人员更容易判断哪些功能更重要，哪些可以推迟或简化，从而帮助更好地管理项目范围和排定优先级 。
• 增强的灵活性和适应性：由于用户故事关注“什么”而非“如何做”，当需求变化或发现更好的解决方案时，调整实现方式的成本相对较低，系统更具适应性 。
• 提升团队对问题的理解：帮助开发团队随着时间的推移，不断加深对所要解决问题的理解，从而能够做出更明智的技术决策 。
• 简洁明了：相比冗长的技术需求文档，简洁的用户故事是描述软件需求的更佳方式 。

使用用户故事存在哪些劣势或困难？

尽管用户故事有很多优点，但在使用过程中也可能遇到一些劣势或困难：

• 可能不适用于所有场景：在某些极端情况下，用户故事的传统形式可能显得不那么直接适用。例如，文档中提到一个例子，一个持续6小时的复杂硬件校准序列（代表了三年的开发工作）被描述为一个单一的用户交互，这给如何拆分为有意义的用户故事带来了挑战 。不过，作者仍然认为，只要深入挖掘，总能找到合适的故事角度 。
• 容易被误解或肤浅应用：如果团队不理解用户故事的深层含义（即关注用户目标和上下文，而不仅仅是用户界面或功能点），用户故事的价值就会大打折扣 。开发者有时会陷入技术视角，或者仅仅把用户故事看作是对用户界面的描述，而不是真正思考用户的核心需求 。
• “无人真正知道所有需求”的普遍难题：软件开发的一个根本困难在于，除非是处理定义明确的技术接口，否则在一开始没有人能完全、准确地知道所有需求 。需求往往是模糊的愿望，需要通过开发过程逐步探索和明确 。用户故事作为一种需求表达方式，也无法完全规避这种固有的不确定性。用户可能会改变想法，尤其是在看到产品的早期版本之后 。
• 编写高质量用户故事的挑战：编写既能准确捕捉用户目标，又保持适当模糊性以允许不同实现方式的优秀用户故事，本身就是一项需要技巧和经验的工作。需要避免在故事中过早地引入实现细节（如数据库、具体界面元素等） 。
• 开发团队的接受度：有时，特别是经验不足的团队，可能会因为感觉迷失而要求更精确、更细化的需求描述，而不是从用户故事中探索和理解需求 。在一些官僚文化较重的组织中，团队可能更倾向于“照章办事”以规避责任，而不是主动参与需求的探索和定义 。

总结

航空航天领域产品开发复杂、周期长、安全标准极高，但仍可借鉴敏捷与精益原则实现更高效的创新和交付。核心在于将敏捷思维融入现有流程，而非生搬硬套特定框架。参考“臭鼬工厂”（Skunk Works）的某些成功要素，可以为航空航天领域的敏捷实践提供灵感。

1. 核心原则的应用：

• 迭代与增量交付 (Scrum/敏捷核心) ：

  • 对于航空电子、软件系统、或特定子模块（如飞控算法、地面支持软件），可采用短周期迭代开发（类似Scrum的Sprints），尽早进行集成与测试，快速验证原型，降低后期风险。
  • 即使是硬件开发，也可以通过快速原型（包括3D打印、数字孪生仿真）进行迭代验证，小步快跑。

• 持续流程与消除浪费 (Kanban/精益核心) ：

  • 在设计、制造、测试等环节应用精益思想，识别并消除瓶颈和浪费（如等待时间、不必要的返工、过量库存）。
  • 看板可用于可视化和管理复杂工作流，如工程变更请求、零部件供应、测试队列等，通过在制品限制（WIP limits）优化流程效率。

• 聚焦用户价值 (用户故事/敏捷核心) ：

  • 将需求从最终用户（飞行员、乘客、维修人员）或系统内部用户（如其他子系统）的视角进行描述（类似用户故事），明确“做什么”而非“怎么做”。例如：“作为飞行员，我希望能快速获取关键飞行参数，以便在紧急情况下做出正确决策。”
  • 这有助于保持对任务目标和核心价值的关注，避免过早陷入技术细节，并促进跨部门沟通。

• 检视与适应 (敏捷核心) ：

  • 建立规律性的评审和回顾机制，对开发过程、产品原型、测试结果进行“检视”，并根据发现进行“适应性调整”。这对于应对航空航天领域的高不确定性和技术挑战至关重要。
  • 透明化进展和问题，鼓励开放沟通。

• 信任与赋能 (敏捷文化/臭鼬工厂精髓) ：

  • 构建信任文化，赋予小型、跨职能团队（类似臭鼬工厂的模式）更大的自主权来解决问题和进行创新，减少不必要的官僚审批。
  • 管理层提供支持和资源，扫除障碍。

2. 如何在航空航天领域实现“真正的敏捷”：

• 避免“名义敏捷” ：警惕将敏捷原则曲解为“不需要计划”或“不需要文档”。航空航天领域对计划的周密性和文档的严谨性有极高要求，敏捷要做的是让计划更具适应性，文档更侧重于传递有效价值而非冗余信息。
• 警惕“水-Scrum-瀑”模式：避免仅仅在传统的瀑布式阶段门之间嵌入Scrum迭代，而整体流程依旧僵化。真正的敏捷需要流程层面的灵活性和对变化的快速响应能力。
• 技术敏捷性是基础：推动持续集成、自动化测试（包括仿真）、模型驱动的系统工程(MBSE)等实践，以支持快速迭代和变更。没有相应的技术支撑，流程敏捷难以实现。
• 个体与互动高于流程与工具：在强调流程规范的同时，更要促进不同专业领域工程师（气动、结构、航电、软件、制造等）之间的直接沟通与协作。

3. 挑战与考量：

• 安全性与合规性：敏捷的灵活性必须与航空航天极高的安全和适航认证要求相平衡。迭代产出物需满足严格的验证与确认标准。
• 软硬件协同：敏捷起源于软件，应用于硬件及软硬件强耦合系统时，需要调整迭代周期和方式，更侧重模块化设计和接口标准化。
• 组织文化变革：大型航空航天企业通常有深厚的传统工程文化，向敏捷转型需要高层支持和持续的文化建设。

臭鼬工厂的启示：

“臭鼬工厂”的成功并非严格遵循某个敏捷框架，但其运作模式体现了敏捷的核心思想：小型精英团队、高度自治、快速原型、简化流程、目标驱动、勇于创新。这些原则对于在严格管制的航空航天领域内寻求突破和效率提升具有重要的借鉴意义。

总结： 在航空航天领域应用敏捷和精益，关键在于理解其核心价值观和原则——持续交付价值、拥抱变化、消除浪费、赋能团队、快速学习与适应——并将其创造性地融入到现有的工程实践和管理体系中，找到适合自身特点的平衡点。