第三课软件过程演进 (Software Process Evolution)

标题: 软件过程演进 (Software Process Evolution)

  • (图示演进路径):
    • 瀑布模型 (The Waterfall Model) (预测式过程 Predictive Processes) -> 增量开发 (Incremental Development) -> 集成与配置 (Integration and Configuration) (面向重用的 Reuse-Oriented)
  • (图示时间线与流行度):
    • 预测式过程 (Predicative Process) (1970年代开始流行)
    • 迭代式过程 (Iterative Process) (流行度上升)
    • 敏捷过程 (Agile Process) (当前流行度最高)
  • (列举过程模型):
    • 通用过程模型 (General Process Models now): 瀑布模型, 增量开发, 集成与配置
    • 迭代式过程 (Iterative Processes): 螺旋模型 (Spiral Model), Rational Unified Process (RUP), 特性驱动开发 (Feature-Driven Development - FDD), 开放统一过程 (Open Unified Process - OpenUP)
    • 敏捷过程 (Agile Processes): 极限编程 (eXtreme Programming - XP), Scrum, 看板 (Kanban), 精益 (Lean), 水晶方法 (Crystal Method), Scrumban, 快速应用开发 (Rapid Application Development - RAD), 动态系统开发方法 (Dynamic System Development Method - DSDM), 敏捷统一过程 (Agile Rational Unified Process - Agile RUP)

image

敏捷方法的采用情况 (Adoption of Agile Methods)

  • (图表显示，基于2017年数据):
    • Scrum 是最广泛采用的 (58%)
    • Scrum/XP 混合 (10%)
    • 定制混合 (Custom Hybrid) (8%)
    • Scrumban (7%)
    • 看板 (Kanban) (5%)
    • 迭代开发 (Iterative Development) (4%)
    • 精益 (Lean) (2%)
    • 特性驱动开发 (Feature-Driven Development) (1%)
    • DSDM (1%)
    • 极限编程 (XP) (1%)
    • 敏捷统一过程 (AgileUP) (1%)
    • 其他 (1%)
  • 参考来源: VersionOne 第11次年度敏捷状况报告 (链接)

敏捷软件开发宣言 (Manifesto for Agile Software Development)

  • 来源: http://agilemanifesto.org
  • 核心价值观 (左侧优先于右侧):
    • 个体和互动 (Individuals and interactions) 高于 流程和工具 (process and tools)
    • 可工作的软件 (Working software) 高于 详尽的文档 (comprehensive documentation)
    • 客户合作 (Customer collaboration) 高于 合同谈判 (contract negotiation)
    • 响应变化 (Responding to change) 高于 遵循计划 (following a plan)
  • 说明: 也就是说，虽然右侧的项也有价值，但我们更重视左侧的项。
  • 背景: 2001年，17位专家在盐湖城共同提出。

敏捷方法的原则 (Principles of Agile Methods)

  • 注意: 敏捷开发共有11条原则 (来源链接)
  • (图中列出的五个核心原则):
    • 客户协作 (Customer Collaboration):
      • 用户应与开发团队紧密合作。
      • 用户应就系统提供反馈，并对需求/改进提出建议。
    • 拥抱变化 (Embrace Change):
      • 需求变更可能在开发过程中的任何时候发生。
      • 随着需求的快速变化，计划可能很快变得不准确。
      • 交付软件比遵循计划更重要。
    • 增量交付 (Incremental Delivery):
      • 软件应以增量和迭代的方式开发，每次交付都包含更多功能。
    • 保持简洁 (Maintain Simplicity):
      • 专注于向客户交付有价值的软件，而不是编写详尽的文档。
    • 以人为本，而非过程 (People, not Process):
      • 关注团队中的人。工具和实践是次要的。
      • 应让人们自行发展工作方式，而不是给出规定性的流程。
      • 利用和探索团队成员的技能和知识，并信任他们。
      • 对软件和软件过程都要保持一切简单。

标题: XP 与 Scrum

  • 概述: XP (极限编程) 和 Scrum 都是著名的敏捷软件开发方法论。
  • 实践: 在实践中，一些团队可能会结合 XP 和 Scrum 的元素。例如，一个团队可能遵循 Scrum 框架进行项目管理，同时实施 XP 的工程实践来提高代码质量。

标题: 什么是极限编程 (XP)？ (What is eXtreme Programming (XP)?)

  • 定义 (Beck, 1999): “XP 是一种软件开发风格，专注于卓越地应用编程技术、清晰的沟通和团队合作……”
  • (XP 的三个层次):
    • 价值观 (Values): “一种基于沟通、反馈、简洁、勇气和尊重价值观的软件开发哲学。”
    • 原则 (Principles): “一套互补的原则，是将价值观转化为实践的智力技巧……”
    • 实践 (Practices): “一套被证明有助于改进软件开发的实践方法。”

XP 原则 (1) (XP Principles (1))

  • 1. 人性化 (Humanity):
    • 平衡个人需求与团队需求。
  • 2. 经济性 (Economics):
    • 货币的时间价值。
    • 系统和团队的选择权价值。
    • 引用 (Beck, 1999): “软件开发在能更早赚钱、更晚花钱时更有价值。”
  • 3. 互惠互利 (Mutual Benefit):
    • 每一项活动都应使所有相关方受益。
    • 编写自动化测试，有助于今天更好地设计和实现；将测试留作未来程序员的“文档”。
    • 重构以提高简洁性、清晰度和一致性。
    • 引用 (Beck, 1999): “!!!详尽的软件内部文档是违反互惠互利原则的实践的一个例子。!!!”

XP 原则 (2) (XP Principles (2))

  • 5. 改进 (Improvement):
    • 立即开始一项活动，然后随着时间的推移完善结果。
    • 引用: “……最好（或完美）是足够好（good enough）的敌人” -- 一位明智的意大利人
  • 6. 多样性 (Diversity):
    • 程序员应共同解决问题，所有意见都应受到重视。
  • 7. 反思 (Reflection):
    • 回顾和分析他们成功或失败的原因。
  • 4. 自相似性 (Self-Similarity): (注：原文编号为4，应为8)
    • 将一个解决方案的结构应用于新的情境，即使在不同的尺度上（这是一个好的起点）。

XP 原则 (3) (XP Principles (3))

  • 8. 流动 (Flow): (注：原文编号为8，应为9)
    • 活动的持续流动而不是离散的阶段（小增量，持续集成）。
  • 9. 机遇 (Opportunity): (注：原文编号为9，应为10)
    • 将问题视为变革的机会（个人成长、深化关系和改进软件）。
  • 10. 冗余 (Redundancy): (注：原文编号为10，应为11)
    • 软件开发中的难题应以多种不同方式解决。
  • 11. 失败 (Failure): (注：原文编号为11，应为12)
    • 如果你有3种方法来实现一个用户故事，但不知道该用哪种，那就都试试。

XP 原则 (4) (XP Principles (4))

  • 12. 质量 (Quality): (注：原文编号为12，应为13)
    • 质量可以通过缺陷、设计质量和开发体验来衡量。
    • 引用 (Beck, 1999): “项目不会因为接受较低质量而加快速度。”
  • 13. 小步快跑 (Baby Step): (注：原文编号为13，应为14)
    • 一次进行一个测试，一次集成和测试几个小时的变更。
  • 14. 承担责任 (Accepted Responsibility): (注：原文编号为14，应为15)
    • 责任不能被分配；只能被接受。

XP 工作流程 (XP Workflow)

  • (流程步骤):
    1. 项目开发开始时，产品经理和用户编写故事 (Stories)（程序员也可能参与）。
    2. 程序员估算故事和任务。
      • 如果故事太大，产品经理/用户拆分故事；如果程序员不理解主题，启动一个 Spike。
    3. 产品经理/用户决定季度周期 (Quarterly Cycle) 的“主题”（大方向）。
      • 此过程迭代进行直至项目结束。
    4. 产品经理、用户/程序员为周周期 (Weekly Cycle) 选择合理数量的用户故事，并添加一些缓冲任务 (Slacks)。
      • 此过程迭代进行直至季度周期结束。
  • (相关实践和角色):
    • XP 实践 (XP Practices): 周周期, 季度周期
    • XP 角色 (XP Roles): 产品经理 (Product Manager), 用户 (User), 程序员 (Programmer)
  • 引用 (Beck, 1999 - 关于缓冲任务): “在任何计划中，都包含一些次要任务，如果进度落后可以放弃（缓冲任务）。”
  • 引用 (William C. W., 2000 - 关于Spike): “Spike 是用可丢弃代码实现的精简、最小化的解决方案。Spike 的结果是获得足够的知识来尝试进行估算。”
    image

术语：用户故事 (Terminology: User Story)

  • 描述:
    • 敏捷方法通常没有单独的需求工程活动，而是将其与开发集成。
    • 用户故事通常写在用户故事索引卡上。
    • 它满足用户需求。
    • 可用于规划系统迭代。
    • 用户/产品经理确定故事的实现优先级。
      • 高业务价值
      • 对架构设计有重大影响
  • 结构化模板:
    • 作为一个 <角色> (想要完成某事的人)
    • 我想要 <活动> (做什么)
    • 以便 <价值> (为什么)
    • 它也可能包括验收标准 (Acceptance Criteria) 和评论 (Comments)。
  • 引用 (Sommerville, 2016): “……用户故事是系统用户可能经历的使用场景。”
  • (图片来源): JIRA 生成

XP – 发布规划 (XP – Planning the Release)

  • (流程图):
    • 选择本次发布的用户故事 (Select user stories for this release) -> 规划发布 (Plan release) -> 开发、集成和测试 (Development integrate and test) -> 发布软件 (Release software) -> 评估系统 (Evaluate system) -> (循环回选择用户故事)
    • (从“选择用户故事”分支) -> 将故事分解为任务 (Break down stories to tasks)
  • 核心问题:
    • 每个周期我们应该选择多少用户故事？
      • 取决于用户/产品经理期望一个周期的故事点 (story points) 数量。这个过程通常称为声明速率 (Declare the Velocity)。
    • 谁来决定速率？
      • 通常是负责跟踪迭代、验收测试、代码质量、客户管理等的人。
  • 引用 (Sommerville, 2016 - 关于系统发布): “系统发布是分发给客户的软件系统的一个版本。”
  • XP 角色: 追踪者 (Tracker)

XP 程序员工作流程 (1) (XP Programmer Workflow (1))

  • (日常流程):
    1. 站会 (Standup meeting) (每天早上，10分钟)
      • 识别问题，领取你想做的任务。
    2. 与同事结对 (Pair up) 并做快速设计
      • 所有生产代码都由结对编程 (Pair Programming) 产生。
      • 一人编程，另一人思考；定期切换角色。
    3. 测试 (Test)
      • 一次编写小的单元测试代码。
      • 测试所有可能出错的地方 (测试先行编程 Test-First Programming)。
    4. 编码 (Code)
      • 只编写足够通过单元测试的代码。
      • 使用团队的编码标准。
      • 如果有疑问，向用户寻求反馈。
    5. 重构 (Refactor)
      • 代码应通过所有单元测试，没有重复逻辑，确保良好的编码实践 (重构 Refactoring)。
  • 相关实践和角色:
    • XP 实践: 充沛精力工作 (Energized Work), 重构, 测试先行编程, 增量设计 (Incremental Design), 结对编程
    • XP 角色: 程序员 (Programmer), 项目经理 (Project Manager)
  • 阅读材料 (XP实践): William C. W., Extreme Programming Explored, 2000.

XP 程序员工作流程 (2) (XP Programmer Workflow (2))

  • (日常流程 - 续):
    6. 问答 (Q & A - Question and Answer)
    * 软件系统的用户应该在现场 (On-Site Customer) 回答问题。
    * 用户和产品经理应能做出决策。
    7. 集成 (Integrate)
    * 将代码提交到集成机器，构建系统并运行（通过）所有测试 (持续集成 Continuous Integration, 十分钟构建 Ten-Minute Build)。
    8. 丢弃 (Discard)
    * 如果行不通，就丢弃它们。
    9. 返回“结对与快速设计环节”
    * 如果当天还有足够时间，可以处理另一个任务。
    10. 今日结束 (Finishes today)
  • 相关实践和角色:
    • XP 实践: 持续集成, 现场客户, 十分钟构建
    • XP 角色: 产品经理 (Product Manager), 用户 (User), 测试员 (Tester), 程序员 (Programmer)
  • 阅读材料 (XP实践): William C. W., Extreme Programming Explored, 2000

标题: XP 总结 (XP Summary)

  • 价值观 (Values): 沟通, 简洁, 勇气, 反馈, 尊重
  • 原则 (Principles): 人性化, 经济性, 互惠互利, 自相似性, 改进, 多样性, 反思, 流动, 机遇, 冗余, 失败, 质量, 小步快跑, 承担责任
  • 实践 (Practices): 充沛精力工作, 结对编程, 故事, 周周期, 季度周期, 缓冲任务, 十分钟构建, 持续集成, 测试先行编程, 增量设计, 坐在一起 (Sit Together), 整个团队 (Whole Team), 信息化工作空间 (Informative Workspace)
  • 角色 (Roles): 测试员, 项目经理, 产品经理, 用户, 程序员, 追踪者, 教练 (Coach), 交互设计师 (Interaction Designer), 架构师 (Architect), 执行官 (Executive), 技术文档工程师 (Technical Writer), 人力资源 (Human Resource)

Scrum

  • 定义 (Schwaber & Sutherland, 2011): “一个框架，在此框架内，人们能够解决复杂的自适应问题，同时高效并创造性地交付尽可能高价值的产品。”
  • 经验主义三大支柱 (Empiricism):
    • 透明性 (Transparency): 过程必须对所有团队成员可见。使用通用语言，共享通用定义。
    • 检视 (Inspection): 必须经常检视 Scrum 工件和进展，但不能干扰团队工作。
    • 适应 (Adaptation): 如果过程或开发偏离计划，必须及时调整。使用迭代和增量方法控制风险。基于已知信息做决策。

标题: Scrum 框架的组成部分 (The Components of Scrum Framework)

  • (组成部分):
    • Scrum 价值观 (Values): 承诺 (Commitment), 勇气 (Courage), 专注 (Focus), 开放 (Openness), 尊重 (Respect)。Scrum 团队成员在与 Scrum 角色、事件和工件打交道时学习和探索这些价值观。
    • 团队 (Team): 典型的 Scrum 团队包括一个产品负责人 (Product Owner)、开发团队 (Development Team) 和一个 Scrum Master。
    • 事件 (Events): 所有 Scrum 团队共有的四个正式事件：Sprint 规划会议 (Sprint Planning), 每日 Scrum 会议 (Daily Scrum), Sprint 评审会议 (Sprint Review), Sprint 回顾会议 (Sprint Retrospective)。
    • 工件 (Artifacts): 产品待办列表 (Product Backlog), Sprint 待办列表 (Sprint Backlog), (可能还有) 组合待办列表 (Portfolio Backlog), 项目群待办列表 (Program Backlog)。
    • 规则 (Rules): 将所有组件绑定在一起。

Scrum 工作流程 -- 愿景 (Scrum Workflow -- Vision)

  • (流程图突出显示“愿景”环节)
  • 愿景 (Vision):
    • 参与者 (Who): 用户, 产品负责人, 可能有团队成员, 及相关利益相关者。
    • 解决的问题 (Addresses):
      • 这个软件系统解决什么问题？
      • 它提供什么好处？
      • 为谁提供？
      • 系统的高级特性是什么？
      • 它将支持和遵守哪些平台、法规、标准和约束？
      • 以及其他高级业务目标。
    • 产出 (Outcomes): 特性、功能、需求；需要头脑风暴，并可能封装在一系列用户故事中。image

Scrum 工作流程 – 产品待办列表管理 (Scrum Workflow – Product Backlog Management)

  • (流程图突出显示“产品待办列表管理”环节)
  • 产品待办列表管理 (Product Backlog Management):
    • 负责人 (Who):
      • 产品负责人管理产品待办列表，即列表项、可用性和排序。
      • 开发团队负责所有估算，但所有变更必须由产品负责人进行。
    • 内容 (What are in a Product Backlog?):
      • 所有特性、功能、增强和修复。
      • 建议可能来自用户评审、Sprint 评审或回顾会议。
    • 产出 (Outcomes): 一个产品待办列表，是产品进行任何变更的唯一需求来源。

标题: 产品待办列表 (Product Backlog)

  • 描述:
    • 每个产品待办列表项应包含描述、顺序（优先级）、估算和价值等属性。
    • 每个项应包含验收标准，用于评估其是否“完成 (Done)”。
    • 产品待办列表中的项可以按其属性分组为主题 (themes) 或史诗 (epics)。
    • 排序较高的项通常有更清晰、更详细的描述，因为它们被更好地理解。
  • 引用 (Schwaber & Sutherland, 2011): “产品待办列表是动态的；它不断变化以确定产品需要什么才能变得合适、有竞争力和有用。”

Scrum 工作流程 – Sprint 规划 (Scrum Workflow – Sprint Planning)

  • (流程图突出显示“Sprint 规划”和“为 Sprint 选择项”环节)
  • Sprint 规划 (Sprint Planning):
    • 参与者 (Who):
      • 整个 Scrum 团队共同为一个迭代的工作制定计划。
      • 产品负责人给出本次迭代的目标。
      • 开发团队从产品待办列表中选择项（没有人告诉团队该做什么）。
    • 解决的问题 (Addresses):
      • 本次迭代工作完成后能交付什么？
      • 本次迭代需要什么？
      • Sprint 规划会议有时间盒限制，对于为期一个月的迭代，最长为8小时，对于较短的迭代则相应缩短。
    • 产出 (Outcomes): 一个 Sprint 待办列表，包含所选的项和计划。

标题: Sprint 待办列表 (Sprint Backlog)

  • 定义 (Schwaber & Sutherland, 2011): “Sprint 待办列表是为 Sprint 选择的产品待办列表项的集合，外加交付产品增量和实现 Sprint 目标的计划。”
  • 描述:
    • 选择 Sprint 待办列表中的项是为了实现 Sprint 目标。
    • Sprint 待办列表应至少包含一个在上一次 Sprint 回顾会议中确定的高优先级过程改进项。
    • Sprint 待办列表中的计划应有足够的细节来指导每日 Scrum 会议。
    • Sprint 待办列表中的项可以更改，但只能由开发团队更改。
    • Sprint 待办列表可用于监控 Sprint 进度。

XP VS Scrum

  • 相似之处 (Similarities):
    • 敏捷原则 (Agile Principles): 都基于敏捷价值观和原则。强调客户协作、响应变化、频繁交付可工作软件。例如，客户都全程参与提供反馈和确定需求优先级。
    • 迭代和增量开发 (Iterative and Incremental Development): 都采用迭代和增量方法。将项目分解为小块（Scrum 中叫 Sprint，XP 中也是短迭代）。实现价值的早期和持续交付。
    • 以团队为中心 (Team-Centric): 都非常强调团队。Scrum Team（PO, SM, Dev Team）紧密合作。XP 也提倡紧密协作的团队环境。
  • 不同之处 (Differences):
    • 过程焦点 (Process Focus):
      • Scrum: 更侧重于项目管理和过程框架。定义了特定角色、事件和工件。主要目标是以结构化方式管理项目，确保团队朝着产品目标前进。
      • XP: 更侧重于工程实践。包括结对编程、测试驱动开发(TDD)、持续集成、代码重构等。旨在通过实施这些以工程为中心的实践来提高代码质量和开发过程。
    • 文档 (Documentation):
      • Scrum: 虽然重视可工作软件胜过详尽文档，但仍有一些必要的文档，如待办列表和 Sprint 相关报告。但强调文档要轻量级且对团队管理项目有用。
      • XP: 通常倡导更少的文档。依赖结对编程和持续沟通，减少了对大量书面文档的需求。代码本身常被视作主要文档。
    • 灵活性和适应性 (Flexibility and Adaptability):
      • Scrum: 提供相对固定的框架，有明确定义的规则和仪式。虽然框架内有适应空间，但不轻易鼓励改变核心 Scrum 元素。
      • XP: 在实践方面更灵活。团队可以选择采用最适合其项目和环境的 XP 实践。例如，团队可能根据需要只使用 TDD 和结对编程等部分 XP 实践。

我们一起完成了两件事： (We finish two things together:)

    1. 如何编写用户故事？ (How does to write a user story?)
    1. 如何根据用户故事绘制燃尽图？ (How to draw a burndown chart according to the user stories?)

标题: 用户故事 (User Stories)

  • 前置任务: 在开始 Sprint 2 之前…调查并生成用户故事。
  • 定义: 一系列关于用户可能如何与软件交互的“对话”。
  • 模板: 作为一个 <用户类型>, 我想要 <某个目标> 以便 <某个原因>
  • 示例: 作为一个编辑讲师，我希望能够在没有 moodle 的情况下共享文档，以便我有一种更可靠的方式来分发笔记。
  • 资源: moodle 上有 200 个用户故事示例 (来源链接: Mountain Goat Software)

用户故事 (User Stories)

  • 定义:
    • 用户故事（以及提供满足它们的代码）是敏捷框架中最小的离散工作单元。
    • 从最终用户的角度编写的软件特性的一般性解释。
  • 作用:
    • 被接受为任务的故事需要被“燃尽”。
    • 几个用户故事可以组合成一个更大的工作块。(自下而上开发 Bottom up development)
  • (图示层级): 项目 (Project) -> 子项目1, 子项目2 (Sub-Project 1, Sub-Project 2) -> 用户故事1, 2, 3, 4 (User Story 1, 2, 3, 4)

设置用户故事地图的第一步示例 (Example for the first step of setting up story map)

  • (图示: 横轴为时间/步骤，纵轴为活动/用户任务，下方为具体的用户故事卡片)
  • 参考: 一个关于如何设置用户故事地图的好解释（中文）(链接: 简书)

在 Sprint 待办列表中管理用户故事 (Manage User Stories in Sprint Backlog)

  • (JIRA 截图示例):
    • 第一次迭代 (The first iteration)
    • 4 周 (4 Weeks)
    • 剩余 17 天 (17 Days remaining)
    • 6 个用户故事 (6 User Stories)
    • 28 点 (28 points)

使用燃尽图监控进度 (Monitoring Progress using a Burndown Chart)

  • (JIRA 截图示例 - 燃尽图):
    • 第一次迭代 (The first iteration)
    • 4 周 (4 Weeks)
    • 剩余 17 天 (17 Days remaining)
    • 6 个用户故事 (6 User Stories)
    • 28 Sprint 点数 (28 Sprint points)
  • (图表解释):
    • Y 轴: Sprint 点数 (Sprint Point) (从 28 向下)
    • X 轴: 日期 (Date) (天数)
    • 起点 (the starting point): (0, 28) - 总 Sprint 点数
    • 理想线 (Ideal effort - 未画出但隐含): 从 (0, 28) 到 (约20天, 0) 的直线。
    • 实际线 (Actual effort - 蓝色线): 显示实际完成的点数。
    • 示例点: 第一个用户故事在第 5 天“完成”；我们燃尽了 3 个 Sprint 点数。
  • 分析: 理想情况下，实际工作量应与理想工作量一致。实际上，有些工作会标记在理想线下方（表示团队提前完成），其他工作会标记在线上方（表示团队落后于计划）。

练习 (Practice)

  • 问题: 在 Scrum 中，燃尽图常用于监控 Sprint 内的开发进度。根据下面的燃尽图，为所示的 Sprint 提供适当的解释和分析。（X轴：天数，Y轴：Sprint 点数，第一个点：起点）
  • (图示: 一个示例燃尽图，需要学生分析)

Scrum 工作流程 – Sprint (Scrum Workflow – Sprint)

  • (流程图突出显示“Sprint”和“每日 Scrum”环节)
  • 要素 (Elements):
    • 一个 Sprint 包含 Sprint 规划、每日 Scrum 会议、开发活动、Sprint 评审和 Sprint 回顾。
  • 产出 (Outcomes): Sprint 目标达成；一个可能可交付的产品增量。
  • 规则 (Rules):
    • 作为一个自组织团队一起工作。
    • Sprint 目标不能改变。
    • 目标的质量不能受影响。
    • Sprint 不能缩短。
    • Sprint 不应超过一个月。
    • 只有产品负责人可以取消 Sprint。
      image

Sprint

  • (图示: Sprint 生命周期) Sprint 规划 -> 每日 Scrum 会议 + 开发工作 -> Sprint 评审 -> Sprint 回顾 -> (下一个 Sprint)
  • 描述:
    • 在整个项目中，Sprint 具有一致的持续时间。
    • 新的 Sprint 在上一个 Sprint 的回顾会议结束后立即开始。
    • Sprint 的短持续时间将风险限制在较小的成本内。
  • Sprint 可能被取消的情况:
    • Sprint 目标变得过时。
    • 出现意外情况，例如重要团队成员离职。
    • 出现优先级高得多的任务，并由高级管理层要求。

Scrum 工作流程 – 每日 Scrum 会议 (Scrum Workflow – Daily Scrums)

  • (流程图突出显示“每日 Scrum”环节)
  • 定义 (Schwaber & Sutherland, 2011): “每日 Scrum 是一个为开发团队设定的 15 分钟时间盒事件。”
  • 参与者 (Who):
    • 开发团队成员需要在同一时间和同一地点参加会议。
    • Scrum Master 组织会议。
  • 讨论内容 (Discussion):
    • 我昨天做了什么来帮助团队达成目标？
    • 我今天要做什么？
    • 我是否预见到任何障碍？
  • 目的 (Purpose):
    • 检视实现目标的进展。
    • 规划第二天的工作。
  • 产出 (Outcomes): 第二天的非正式计划。
  • 时长 (How long): 最多 15 分钟。

Scrum 工作流程 – Sprint 评审 (Scrum Workflow – Sprint Review)

  • (流程图突出显示“Sprint 评审”环节)
  • 参与者 (Who):
    • Scrum 团队和相关利益相关者评审已完成的工作。
    • Scrum Master 组织会议。
    • 产品负责人解释哪些已经完成，哪些尚未完成。
  • 要素 (Elements):
    • 评审时间表、预算和潜在能力。
    • 评审下一步最有价值的事情是什么。
    • 讨论产品待办列表的状态。
    • 演示已完成的工作并回答问题。
  • 产出 (Outcomes): 修订后的产品待办列表。
  • 时间 (When): Sprint 结束时。
  • 时长 (How long): 对于为期一个月的 Sprint，最长 4 小时。

标题: Scrum 工作流程 – Sprint 回顾 (Scrum Workflow – Sprint Retrospective)

  • (流程图突出显示“Sprint 回顾”环节)
  • 参与者 (Who):
    • Scrum Master 组织会议。
    • Scrum Master 鼓励团队改进。
    • Scrum 团队成员计划提高产品质量的方法。
  • 目的 (Purpose):
    • 检视上一个 Sprint 在人员、关系、过程和工具方面的情况。
    • 识别潜在的改进点。
    • 制定实施改进的计划。
  • 产出 (Outcomes): 改进计划。
  • 时间 (When): Sprint 评审之后。
  • 时长 (How long): 对于为期一个月的 Sprint，最长 3 小时。

标题: Scrum 总结 (Scrum Summary)

  • 三大支柱 (Pillars): 透明性, 检视, 适应
  • 价值观 (Values): 承诺, 勇气, 专注, 开放, 尊重
  • 角色 (Roles): 产品负责人, Scrum Master, 开发团队
  • 事件 (Events): Sprint 规划, Sprint, 每日 Scrum, Sprint 评审, Sprint 回顾
  • 工件 (Artifacts): 产品待办列表, Sprint 待办列表
  • Scrum Master 职责:
    • 帮助团队理解项目。
    • 引导事件。
    • 指导开发团队实践 Scrum。
    • 移除障碍。
    • 规划 Scrum 的实施。
    • 帮助产品负责人。

标题: DevOps 需求工程 (DevOps Requirements Engineering)

  • 定义: DevOps 指的是开发 (Development) 和运维 (Operations) 的结合。
  • 驱动因素:
    • 减少需求变更。
    • 高度关注测试和质量保证。
    • 实现更快的交付周期。
  • 特点: DevOps 尽可能依赖自动化工具。
  • (图示: DevOps 环)
    • 开发 (Development): 单元测试, 回归测试, 集成测试, 系统测试
    • 构建 (Build): 自动化验证 (verification), 自动化确认 (validation)
    • 运维 (Operations): 故障记录
    • (环中心): CI/CD (持续集成/持续交付)
    • (关联): 测试与 DevOps (Testing and DevOps), CI/CD

标题: 敏捷方法的实际问题 (Practical Issues with Agile Methods)

  • 局限性: 敏捷方法可能不适用于嵌入式系统工程或大型复杂系统的开发。
  • 问题:
    1. 合同问题 (Contractual Issues): 敏捷的非正式性与大型企业常用的法律方法（合同）不兼容。
    2. 维护问题: 敏捷通常用于新软件系统开发，而不是软件维护。
    3. 规模和分布问题: 敏捷方法是为小型、同地协作的团队设计的。对于具有多个地理分布团队的大型项目，管理和协调的复杂性显著增加，因此敏捷方法的有效性值得怀疑。
posted @ 2025-05-01 12:03  糖子哥  阅读(70)  评论(0)    收藏  举报