Phase 2 — 需求与敏捷协作

定量研究与定性研究的方法和工具：

1. 介绍定量研究的方法，例如统计分析、在线问卷调查、以及数据库分析，强调如何通过定量数据进行可靠的数据分析。
2. 讨论定性研究的技术，如深度访谈、焦点小组讨论和案例研究，以及如何通过这些方法获得深入的用户洞察。
3. 探讨选择适当研究方法的重要性，并提供实用的工具和资源以支持研究活动。

用户访谈、问卷调查的设计和实施：

1. 指导如何设计有效的用户访谈指南，包括问题的制定、访谈的安排和实施。
2. 讨论如何设计问卷调查，包括选择合适的问题类型、确保问题的公正性和如何提高响应率。
3. 强调在实施这些研究方法时应考虑的伦理和隐私问题。

用户反馈的收集和分析：

1. 介绍不同的用户反馈收集方法，如在线评论、社交媒体监控和客户支持互动。
2. 讨论如何有效地组织和分析用户反馈，以提取有价值的见解。
3. 强调利用定量和定性分析方法从大量数据中识别模式、趋势和用户需求。

市场趋势的分析和预测：

1. 探讨如何收集和分析市场数据，以识别行业趋势和消费者行为。
2. 强调如何利用历史数据、竞争分析和市场预测模型来预测市场动态。
3. 讨论如何将市场趋势分析转化为实际的业务策略和决策。

需求分析的三个阶段：

1. 定义问题：清晰地识别和描述问题，理解问题的背景和影响。
2. 解决方案探索：探索解决问题的各种可能方法，评估每种解决方案的可行性和影响。
3. 需求落地：将解决方案转化为具体的需求，确保这些需求能够被有效地实施和监控。

探索需求的本质：

1. 隐性：识别和揭露未明确表达的需求。
2. 非解决方案导向：专注于问题和需求本身，而不是预设的解决方案。
3. 不脱离用户和场景：确保需求紧密贴合最终用户的实际使用场景和环境。

需求的 5 个来源：

1. 外部客户：直接从目标市场或特定客户群体收集的需求。
2. 数据报告：通过数据分析和报告揭示的潜在需求。
3. 内部决策：组织内部的战略决策和目标转化成的需求。
4. 内部使用：公司内部用户（如员工）对系统或产品的使用需求。
5. 运营：业务运营中暴露的效率问题或改进机会。

学习需求挖掘三大步骤：

1. 愿景定义
2. 需求挖掘
3. 根因分析

介绍需求挖掘的三个方法：

1. 用户访谈：确定目标用户群
2. Persona：目标用户具象化
3. 用户体验地图：用户使用产品具象化

**了解根因分析的目的：**分解最有价值的痛点

介绍解决方案的组成：

1. 业务解决方案（用户、场景、流程）
2. 技术解决方案
3. 设计方案 （界面、交互）

需求分析完整方法论（120 分钟）。从 stakeholder 口述的模糊想法 → 可执行的功能清单 + 指标定义 + 风险列表。五步拆解法：1) 业务目标澄清；2) 用户画像与使用场景；3) 功能优先级排序（MoSCoW）；4) 成功指标与反指标；5) 边界与约束。

AI 时代新增维度： 数据从哪来、模型选型 trade-off、成本估算、准确率可接受下限、人工 fallback 机制。这五个问题在传统 BA 方法论里是没有的。

User Story 的格式和特点：

1. User Story 应该是具体的、有限的（一个小的功能或需求），并且是独立的，易于理解和实施。

如何收集和整理用户需求生成 User Story：

1. 与用户进行访谈、观察和调研，以深入了解他们的需求和行为。
2. 分析市场数据和用户反馈，以识别需求和改进的机会。
3. 将这些信息整理成具体、可操作的 User Story，确保每个 Story 都明确地描述了一个需求或功能，以及它对用户的价值。

使用 INVEST 原则来确保 User Story 的质量：

1. Independent：每个 Story 都是独立的，可以单独开发和实施。
2. Negotiable：Story 是讨论和协商的起点，细节在开发过程中逐步明确。
3. Valuable：每个 Story 都为用户或客户提供价值。
4. Estimable：可以估计完成 Story 所需的时间。
5. Small：Story 足够小，可以在一个 Sprint 内完成。
6. Testable：Story 的完成标准是清晰的，可以通过测试来验证。

User Story 的组成

1. 固定格式
2. User Story 和AC，Failure Scenarios，以及test case matrix

TDD 测试驱动开发简述

1. 测试驱动开发和User Story / AC的联系

练习：使用Mural Board 书写User Story

介绍 User Story

1. User Story 是敏捷开发中的需求描述，用于传达功能需求。

编写用户故事的目的

1. 提前交付有价值的功能。
2. 减少浪费。
3. 强调用户需求价值。
4. 促进团队沟通。

用户故事的 3C 原则：

1. Card：简洁的文档形式。
2. Conversation：鼓励对话和讨论。
3. Confirmation：明确验收标准，用于验证。

INVEST 原则：

1. Independent：可独立开发和测试。
2. Negotiable：可讨论和调整。
3. Value：提供业务价值。
4. Estimable：能够估算工作量。
5. Scalable：可根据需求扩展。
6. Testable：可被测试，以验证符合要求。

用户故事常见格式：

1. Title：简短标题。
2. Description：详细描述。
3. Narrative：背景和上下文。
4. AC：验证完成情况的标准。
5. Mockup：界面示意图或原型。
6. Others：相关的其他信息。

用户故事的拆分依据：

1. 根据功能、优先级、业务价值、风险、依赖关系等因素进行拆分，确保明确的范围和目标。

为什么要写 AC（Acceptance Criteria）

1. AC 是深入分析用户故事的过程，帮助明确需求和预期结果。

如何写 AC

1. 使用情景、操作和结果描述，以确保清晰和可测性。

好的 AC 包含的元素

1. Happy path first：首先描述正常、顺利的情况。
2. 使用自然语言：使用易懂的日常语言。
3. Start with “I”：以第一人称形式开始句子。
4. Make “When” actionable：将"当"描述为可操作的步骤。
5. Tell a story：通过 AC 讲述用户如何与系统互动。

书写 AC 的注意事项（反模式）：

1. Too many AC and AND：避免过多的条件和"与"操作。
2. Not AC but TC (Test case）：不要将 AC 当作测试用例。
3. 用语不易理解：避免使用难以理解的术语。
4. 格式冗杂：保持 AC 简洁，不要过于冗长。

复杂逻辑下 AC 的书写方式：

1. 使用示例（Examples）来展示复杂逻辑，以更清晰地说明不同情况下的期望行为。

什么是用户故事地图

1. 用户故事地图是一个有方向的图表，通过时间轴和优先度，以时间维度了解产品的所有功能。

用户故事地图的组成元素

1. 时间轴：表示产品开发的时间线。
2. 用户故事：功能需求的描述，按优先级排列。

用户故事地图中用户故事的拆分方法

1. 从核心场景出发，头脑风暴每个用户任务的功能需求。
2. 头脑风暴其他次要场景的用户任务功能需求。
3. 头脑风暴每个功能需求的非功能性需求。
4. 延伸时间线上的下一个流程，重复之前的步骤。
5. 检查和排列优先级。

如何创建用户故事地图

1. 准备核心用户的用户旅程。
2. 从核心场景出发，头脑风暴每个用户任务的功能需求。
3. 头脑风暴其他次要场景的用户任务功能需求。
4. 头脑风暴每个功能需求的非功能性需求。
5. 延伸时间线上的下一个流程，重复之前的步骤。
6. 检查和排列优先级。

为什么需要做用户故事地图

1. 便于发现遗漏和重复的需求。
2. 有助于确定优先级，决定最小可行产品（MVP）。
3. 可视化障碍和问题，促进及时处理。

分享人：Chelsey

内容：

1. 如何写 User Story，Story 如何写，如何读懂 User Story
2. User Story 的书写格式
3. 用户故事的 INVEST 原则
4. 用户故事的拆分
5. 用户故事的相关书籍
6. Developer 如何书写 User Story，如何理解 User Story，如何跟 BA 和 PM 沟通

Bloody facts:

1. 不要害怕表达自己，即使你没有正确答案（有时你可以大声思考）。

User Story:

1. 用户故事是描述功能需求的简短描述，用于敏捷开发中。
2. 通常包括角色、任务和目标。

Jira Card Template (Jira 卡片模板):

1. Jira 是一个项目管理工具，卡片模板用于记录任务和工作项的详细信息。
2. 包括标题、描述、指派人、截止日期等信息。

Backlog (待办事项清单):

1. 待办事项清单是记录需求、任务和功能的列表，通常按优先级排序。
2. 用于规划和跟踪项目工作。

AI 小编剧 Lab：把一句话需求一键变成 3 条符合 INVEST 标准的 User Story。在浏览器内完成，用 few-shot prompting 技巧让 AI 生成可直接进 backlog 的 Story。

交付物： 1) 你选的业务场景（例：外卖 App 订单取消功能）；2) 你写的 few-shot prompt（含 3 个高质量 example）；3) AI 输出的 3 条 User Story + 你的人工修正版。提交到学习群让老师点评。

Agile - Quiz

整理需求：

1. 与利益相关者（包括客户、用户、销售团队等）沟通，以理解他们的需求和期望。
2. 分析市场趋势和竞争对手，以确保产品在市场上的定位是合理的。
3. 识别和澄清业务需求，确保所有需求都是清晰、具体和可测量的。

需求文档：

1. 编写详细的需求文档，包括市场需求文档（MRD）和产品需求文档（PRD）。
2. 确保文档清晰地表达了产品的目标、功能、约束条件以及成功标准。

确定需求：

1. 与利益相关者一起审查需求文档，确保所有人对产品的方向和要求有共同的理解。
2. 管理需求变更，确保变更经过适当的评估并得到记录和沟通。

根据需求画 Wireframe：

1. 创造 Wireframe（线框图）来展示产品的 UI/UX 设计。
2. 确保 Wireframe 反映了用户的需求，并能够指导开发团队理解和实现设计。

Sprint Plan：

1. 与开发团队合作，根据产品的路线图和优先级制定 Sprint 计划。
2. 确保团队清楚每个 Sprint 的目标和期望，以及他们各自的责任。

User Story：

1. 编写用户故事和验收标准，将需求转化为具体的开发任务。
2. 确保用户故事清晰、具体，并且可以衡量，让开发团队可以理解和实现。

Sprint 开发：

1. 在 Sprint 期间与开发团队紧密合作，确保问题及时解决，需求得到正确实现。
2. 参与每日站立会议，以监控进度并提供必要的支持。

测试：

1. 与质量保证（QA）团队合作，确保所有功能都经过测试，并符合用户的需求。
2. 管理用户测试，收集反馈，并确保反馈得到适当的考虑和实施。

产品迭代：

1. 根据用户反馈、市场变化和产品性能数据，对产品进行迭代和改进。
2. 与团队一起评估前一个 Sprint 的表现，确定改进点，为下一个 Sprint 做准备。

传统软件开发流程 vs AI 产品开发流程的系统对比。传统流程：需求 → 设计 → 开发 → 测试 → 上线，各阶段职责清晰。AI 流程加了三件新事：数据准备、模型评估、持续迭代。

关键差异点： 1) 需求阶段多了『能力可行性评估』（这个任务 LLM 能做到什么准确率）；2) 开发阶段多了『Prompt / Pipeline 工程』；3) 测试阶段多了『幻觉检测 / 边界测试』；4) 上线后多了『持续监控 + 成本控制』；5) BA 需要参与评估指标设计，不是只写功能规格。

了解 Agile 本质：一种思维方式

Agile 与 Waterfall 方法的对比：任务分解和并行实施的优势

1. Agile 是一种迭代和增量的方法，允许任务并行执行，快速适应变化。
2. Waterfall 是线性的，任务按顺序执行，变更困难。

项目划分维度：技术复杂度、需求清晰度

1. 项目的性质决定了采用哪种方法。
2. 技术复杂度高或需求不清晰时，Agile 更适合。

Agile 不是终点！

1. Agile 不是目标，而是一种思维方式和方法论。

解读 4 条 Agile Manifesto（敏捷宣言）：

1. 个体和互动 高于 流程和工具
2. 重视人际关系和协作，胜过过于繁琐的流程和工具。
3. 工作的软件 高于 详尽的文档
4. 实际可运行的软件是最重要的产出，胜过过多的文档。
5. 客户合作 高于 合同谈判
6. 与客户紧密合作，灵活适应需求变化，比坚守合同更有价值。
7. 响应变化 高于 遵循计划
8. 能够迅速响应变化的能力比严格遵循计划更重要。

Agile 开发团队组成： Stakeholders & Team

1. 利益相关者（Stakeholders）与团队紧密合作，共同推动项目成功。
2. 团队通常包括开发者、测试人员、产品负责人等角色。

BA 在 reporting line 的定位：Business Team, Technical Team, Trusted Advisors

BA 工作中需考虑的三大要素：Valuable，Feasible，Usable

Sprint Cycle 精简版：Planning, Implementation, Review, Retrospect, Daily Scrum

1. Planning：计划工作。
2. Implementation：实施计划。
3. Review：检查工作。
4. Retrospect：反思进步。
5. Daily Scrum：每日协作。

制定 Sprint 周期

1. Sprint 周期根据项目需求和复杂性而定。

主流辅助工具：Jira, Confluence

1. Jira：项目管理工具。
2. Confluence：协作和文档管理工具。

定义 Done

1. "Done" 是工作完成的标准。

Social Contract（社交契约）

1. 团队一起制定工作规则和期望。

解读 Scrum 仪式：Why, Who, What, Where, When, How

1. Why：Scrum 仪式促进协作和改进，提高透明度。
2. Who：团队成员和利益相关者参与。
3. What：仪式包括 Stand-up、Sprint Planning、Review、Retrospective 等。
4. Where：通常在团队工作环境内进行。
5. When：有明确时间表，如每日 Stand-up。
6. How：有特定的流程和规则。

精讲第一个仪式：Stand-up（站立会议）

1. 特点：每日举行，简洁明了，重点关注问题。
2. 协商时间：BA 确保会议高效，不超过15分钟。

BA 如何成为好的促进者：

1. 明确计划截止日期，鼓励多样性，根据需要增加会议次数。

BA 如何准备 Stand-up：

1. 明确任务，倾听团队，解决问题，灵活调整计划。

Retro 的概念：Apply system thinking

1. Retro（回顾会议）是 Scrum 中的仪式，旨在通过系统思考来改进团队绩效。
2. 它提供了一个平台，让团队反思和讨论问题，以寻找持续改进的机会。

Good Retro practice

1. 只讨论当前 Sprint 的问题：集中关注最新的问题，确保改进具体而实际。
2. 成员积极参与：鼓励每个团队成员分享他们的看法和观点，确保多样性的声音。
3. 提出解决方案：不仅要识别问题，还要一同讨论可能的解决方案，以推动改进。

Retro 进行的注意事项：

1. 避免讨论重复问题：确保之前的问题已经得到解决，不要反复提及。
2. 成员坦诚沟通：鼓励诚实、开放和尊重的沟通，建立信任。
3. 避免互相指责：强调问题是团队的问题，而不是个人责任。

BA 在 Retro 中的 focus

1. Learn：了解团队在 Sprint 中面临的挑战和机会，为改进提供信息。
2. Clarify：澄清问题的原因，确保团队共享一个共同的理解。
3. Support team：支持团队提出和探讨可能的解决方案，促进改进。
4. Listen to all：确保所有团队成员的声音都被听到，不偏袒任何一方。

Showcase（展示）是团队工作展示的过程，旨在展示最新完成的工作，并促进交流和反馈。

深度分析 Showcase 注意事项：

1. 全员参与：确保整个团队参与，每个成员都有机会分享工作。
2. 邀请 Stakeholders：邀请利益相关者参加，以获取他们的反馈和意见。
3. 鼓励面对面交流：展示期间鼓励开放的面对面讨论，以促进理解和互动。
4. 准备 Visual Clue：使用图形、图表或演示文稿等可视化工具，使展示更生动和清晰。

如何成为一个好的 Showcase attendant（展示参与者）：

1. 开放思维（Open-mind）：愿意接受各种反馈和观点，不排斥新思想。
2. 诚实（Honest）：提供真实的反馈，不隐瞒问题或挑战。
3. 把问题视为改进的机会（No-problem is a problem）：鼓励讨论问题，因为它们是改进的机会。

BA 在 Showcase 阶段的工作：

1. 协助 Scrum Master 准备 showcase：帮助整理展示内容，确保准备充分。
2. 记录 Stakeholder 的 feedback：收集和记录利益相关者的反馈和建议。
3. 根据反馈修改待办事项（Make changes to backlog）：根据反馈，可能需要更新待办事项的优先级或内容。

应对 Unfinished Work（未完成的工作）：

1. 如果有未完成的工作，要坦诚地与利益相关者分享，解释原因，并讨论下一步的计划。保持透明度和诚实是关键。

Elaboration（详细阶段）环节的目的：

1. 确保团队所有成员目标一致：在详细阶段，团队需要共同理解和确定下一个 Sprint 的目标和工作内容，以确保一致性。
2. 为下一个 Sprint 做准备：详细阶段的任务包括明确需求、分解任务、制定计划，为下一个 Sprint 的工作做好准备。

确保 Elaboration 环节的效果：

1. 结合 team feedback loop：利用团队反馈循环，确保团队的理解和期望一致。
2. 讨论 user story solution：详细讨论用户故事（User Story）的解决方案，包括设计和实现。
3. 理解团队的 concern：聆听团队的顾虑和问题，并寻找解决方案。
4. Listen to everyone's input：倾听每个团队成员的意见和建议，确保多样性的声音被听到。
5. 解释产品和需求的 background：提供产品和需求的背景信息，帮助团队更好地理解任务的上下文。

准备 elaboration（详细阶段）：

1. Before（会议前）：
2. 准备会议内容。
3. 收集相关材料，如与利益相关者的访谈记录、线框图、用户故事、验收标准等。
4. During（会议中）：
5. 与产品负责人（Product Owner）确认当前任务。
6. 确定任务的优先级。
7. 向团队解释任务的细节和期望。
8. After（会议后）：
9. 根据会议结果更新用户故事。
10. 决定任务的优先级和难度等级。

整理 Backlog（待办事项清单）：

1. 确保待办事项清单（Backlog）保持清晰和有序。
2. 根据需求、优先级和其他因素对待办事项进行排序。
3. 定期回顾和更新待办事项，以反映团队的工作进展和新的需求。

Sprint Planning 的目的：

1. Sprint Planning 的目标是确保团队在下一个 Sprint 期间做出最有价值的工作，以实现产品目标。

Sprint Planning 参与者：

1. Sprint Planning 会议通常由整个核心团队参与，包括开发者、测试人员、产品负责人和 Scrum Master。

如何有效开展 Sprint Planning：

1. Regular Happen：Sprint Planning 是定期举行的，确保持续的规划和方向。
2. 先 Elaboration 再 Planning：在规划之前，进行详细阶段（Elaboration），以明确需求和任务。
3. 确保团队做对产品价值最高的工作：优先选择具有高价值的工作项。
4. 确保 Sprint 方向正确：确保 Sprint 计划与整体产品目标一致。

展开 Sprint Planning：

1. Before（会议前）：
2. 在详细阶段（Elaboration）明确 Sprint 方向。
3. 准备用户故事。
4. 进行能力规划，了解团队的工作容量。
5. During（会议中）：
6. 根据团队成员的工作时间和能力调整任务优先级和数量。
7. 回答团队成员对用户故事的问题。
8. After（会议后）：
9. 更新 Sprint 目标。
10. 细化 Sprint 计划。
11. 确保团队成员的任务理解问题都被解决。

GenAI 的基本特点

1. 介绍 GenAI 的基本概念和特点
2. 讨论 GenAI 在软件开发和交付中的潜在优势和应用场景
3. 分析 GenAI 对软件开发过程的影响和改变

GenAI 在软件交付中的应用

1. 探讨 GenAI 在软件交付过程中的具体应用
2. GenAI 工具如何帮助到 BA
3. 使用基本原则和最佳实践

现场练习：ChatGPT + JIRA

1. 介绍 ChatGPT 的在 BA 工作过程中的使用
2. 设计练习场景：学员将使用 ChatGPT 和 JIRA 进行实际练习，模拟在软件交付过程中的场景
3. 指导学员完成练习：指导学员完成练习任务，并提供实时反馈和指导
4. 分享经验和总结：学员将分享他们的经验和收获，导师强调 GenAI 在软件交付中的潜力和挑战

User Story & Backlog - Quiz