敏捷项目管理框架Scrum:对比TSP角色和职责
Author：zhoulujun Date：
软件项目管理（not 软件过程管理）的三大目标：成本、质量、工期，包括估算、计划、跟踪、⻛险管理、范围管理、⼈员管理、沟通管理等等。
软件开发方法/软件开发过程包括：净室（Cleanroom）方法、极限编程方法、SCRUM方法、Gate方法、Kanban（灵活的持续交付，精益制造） 等
如今在神州，普通宣传敏捷开发，具体参看《开发模型的理解：瀑布模型/增量式/迭代/敏捷开发——笔记》
敏捷本质还是一种文化，是整个公司的文化，但中国的公司只有两种文化（Scrum 中式开会化）：
散养文化，每天早上打鸡血，大家相亲相爱一家人。
圈养文化，每天早上不管有没有事先开一个小时会，所有事情流程制度化。
敏捷文化还需要相应的土壤，比如openness， low power distance
scrum团队管理
Scrum 采用最多（自认为）的敏捷项目管理框架，它通过一系列价值观、原则和实践来帮助团队组织和管理他们的工作。
敏捷开发只是一种理念，而Scrum 是完成具体工作的框架。
敏捷开发理念侧重于通过小规模和频繁的发布进行持续的渐进改进。您无法真正“敏捷化”，因为这需要整个团队一致努力才能改变其向客户交付价值的思维方式。但是，您可以使用 Scrum 等框架来协助您开始思考这一方式，并在日常沟通和工作中实践如何构建敏捷开发原则。
scrum是一种轻量级敏捷框架，专注于实现固定时间的迭代，
所以scrum团队的规模通常很小，只有 10 人左右，而这等规模，基本是目前大陆项目开发常规规模——大项目也是拆解成n个这样的小组。
Scrum 团队需要三个特定角色：产品负责人、Scrum 大师和开发团队，典型SCRUM团队由一名产品负责人、开发团队和一名 SCRUM Master 组成
确定团队规模的一种方法是遵循 Amazon 首席执行官 Jeff Bezos 提出的著名“两个披萨原则”，也就是“团队规模不应过大，以便分享两个披萨”。
由于 Scrum 团队跨职能部门，因此“开发团队”除了开发人员之外，还包括测试人员、设计人员、用户体验专员和运维工程师。
Scrum Product Owner（产品负责人）
产品负责人是产品的领航者。他们专注于了解业务、客户和市场要求，然后相应地确定工程团队需要完成的工作的优先顺序。高效的产品负责人应能：
构建和管理产品待办事项。
与企业和团队密切合作，以确保所有人都能了解产品待办事项中的工作项。
明确指导团队接下来提供哪些功能。
确定何时发布产品，且倾向于更频繁地交付产品。
产品负责人并不一定是PM（产品经理）、PO（产品负责人）、BI（系统分析师）。他们专注于确保开发团队为企业带来最大的价值。此外，产品负责人必须是一个人。没有开发团队需要多个产品负责人的混合指导。
PO的主要职责是确保开发团队所开发的产品能够带来最大的价值。为此，产品负责人需要管理产品待办列表（Product Backlog），这是一个按优先级排序的功能需求列表，确保团队始终专注于最重要的任务。
产品待办列表的管理包括：
清晰地表述产品待办列表项；
对产品待办列表项进行排序，使其最好地实现目标和使命；
优化开发团队所执行工作的价值；
确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队 下一步要做的工作；
以及确保开发团队对产品待办列表项有足够深的了解。
产品负责人是负责管理产品待办列表的唯一负责人。
Scrum Master（主管）
Scrum 主管是其团队中 Scrum 方面的领航者、推动者、教练（帮助每个人理解 SCRUM 理论、实践、规则和价值）。
他们负责对团队、产品负责人和企业进行 Scrum 流程方面的培训，并寻找方法精确调整其在此方面的实践。
高效的 Scrum 主管应深入了解团队正在执行的工作，并可协助团队优化其透明度和交付流程。
作为首席推动者，此角色负责安排冲刺规划、每日站会、冲刺审查和冲刺回顾所需的资源（人力和物力）。
其是，Scrum Master 是一位服务型领导。 帮助 SCRUM 团队之外的人了解如何与 SCRUM 团队交互是有益的 改变SCRUM 团队之外的人与 SCRUM 团队的互动方式来最大化 SCRUM 团 队所创造的价值。
Scrum Master 服务于产品负责人，包括：
确保 Scrum 团队中的每个人都尽可能地理解目标、范围和产品域；
找到有效管理产品待办列表的技巧；
帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
理解在经验主义的环境中的产品规划；
确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
理解并实践敏捷性；以及，
当被请求或需要时，引导 Scrum 事件。
Scrum Master 以各种方式服务于开发团队，包括
作为教练在自组织和跨职能方面给予开发团队以指导；
帮助开发团队创造高价值的产品；
移除开发团队工作进展中的障碍；
按被请求或需要时，引导 Scrum 事件；以及，
在 Scrum 还未完全采纳和理解的组织环境中，作为教练指导开发团队。
Scrum Master 以各种方式服务于组织，包括：
带领并作为教练指导组织采纳 Scrum；
在组织范围内规划 Scrum 的实施；
帮助员工和利益攸关者理解并实施 Scrum 和经验导向的产品开发；
引发能够提升 Scrum 团队生产率的改变；以及，
与其他 Scrum Master 一起工作，增强组织中 Scrum 应用的有效性。
Scrum DevTeam（开发团队）
团队成员熟练掌握不同的技能，并且彼此互相锻练，因此没有人会成为交付工作的瓶颈。强大的 Scrum 团队会自我组织，以明确的团队态度来处理项目。团队的所有成员互相帮助，以确保成功完成冲刺。
Scrum 团队可推进每个冲刺的计划。他们将自己的历史速度用作指导，预测他们认为自己在迭代过程中可以完成的工作量。保持迭代长度固定可为开发团队提供有关其预估和交付流程的重要反馈，进而使其能随着时间的推移做出更加准确的预测。
Scrum 团队是自发组织的，尽管职责不同，但每个角色都是平等的。团队以向客户提供价值为目标而聚集到一起。
他们是自组织的。没有人（即使是 Scrum Master）有权告诉开发团队应该 如何把产品待办列表变成潜在可发布的功能增量；
开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全 部技能；
Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作（他们都叫开 发人员）。
Scrum 不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测 试、架构、运维或业务分析；同时， 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。
开发团队只需 负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。
经验主义和精益思维
Scrum 的定义基于经验主义和精益思维。
经验主义：，知识来自经验，决策是根据所观察到的情况做出的。
精益思维：减少浪费，并专注于本质。
经验主义在Scrum中可能指的是基于实际经验来调整流程，也就是透明、检视和适应这三个支柱。而精益思维可能来自制造业的精益生产，比如消除浪费、持续改进这些原则。
以下是对两者的分析及其结合的详细说明：
一、Scrum的经验主义
经验主义强调知识源于实际经验，通过观察和调整来优化流程。Scrum通过以下三个支柱体现这一理念：
透明性：所有工作（如产品待办列表、 Sprint目标）对团队和利益相关者可见，确保信息共享。
检视：定期检查进展（如每日站会、Sprint评审会），识别偏差或问题。
适应：根据检视结果调整流程（如 Sprint回顾会议），持续改进。
关键实践：
迭代开发（Sprint）：每个Sprint交付可用的增量，快速获得反馈。
持续反馈循环：通过评审会与客户互动，确保方向正确。
回顾改进：团队反思流程问题并制定改进措施。
二、精益思维的核心原则
精益思维起源于制造业，目标是以最小资源创造最大价值，核心包括：
消除浪费（Muda）：减少非增值活动（如过度生产、等待、缺陷修复）。
优化流程流动：确保价值流顺畅，避免瓶颈。
持续改进（Kaizen）：不断寻求更高效的方法。
延迟决策：在必要时做决策，保留灵活性。
尊重人员：赋能团队参与改进。
| Scrum | Kanban | |
|---|---|---|
| 起源 | 软件开发 | 精益制造 |
| 原理 | 从经验中学习，自发性复盘来不断迭代改进 | 通过可视化来发现问题、改进工作 |
| 节奏 | 定期、固定周期的迭代工作（一般为两周） | 持续工作 |
| 实践 | 迭代计划会、每日站会、迭代演示会、回顾会 | 可视化工作流程，管理在制品限制，不断循环 |
| 角色 | 产品负责人（Product owner）、敏捷教练（Scrum master）、开发团队 | 不规定角色 |
Scrum与精益思维的交汇点
Scrum的经验主义和精益思维在核心理念上相辅相成，共同推动高效、灵活的产品开发。
减少浪费：
Scrum实践：通过优先级排序（产品待办列表）聚焦高价值任务；限制Sprint范围，避免过度生产。
精益工具：看板限制在制品数量，暴露瓶颈；价值流图分析流程中的浪费。
持续改进：
Scrum的回顾会议与精益的Kaizen理念一致，均强调团队主导的渐进优化。
经验主义的“适应”阶段应用精益方法（如5 Whys分析根因）。
客户价值导向：
Scrum通过频繁交付增量验证假设，精益通过价值流确保客户需求驱动生产。
两者均强调尽早交付最小可行产品（MVP），减少资源浪费。
流程优化：
Scrum的事件（如每日站会）促进沟通效率，减少等待时间（精益中的浪费类型）。
通过透明性快速暴露问题（如任务阻塞），加速问题解决。
结合实践案例
Sprint回顾中的精益改进：团队发现测试阶段存在重复缺陷，引入自动化测试（消除浪费）。
看板与Scrum结合：在Sprint中使用看板可视化任务流，限制并行任务数，优化流程效率。
价值流分析：在项目启动阶段映射端到端流程，识别非增值环节（如冗余审批），并调整Scrum事件以减少延迟。
Scrum 框架是一种基于持续学习和波动因素调整的启发式框架。它承认团队在项目开始时并不了解所有内容，并通过吸取经验教训不断发展。Scrum 的结构旨在帮助团队自然而然地适应不断变化的条件和用户要求，并在流程和较短的发布周期中重新调整优先级，以便您的团队不断学习和改进。
Scrum Story（故事点）
度量实现一个故事（Story）需要付出的工作量
抽象：混合了对于开发特性所要付出的努力、开发复杂度、各种风险以及类似东西
相对：设定标准之后，考虑其他特性（feature）与标准之间的相对大小关系
度量体现着决策者对试图要实现的目标的关切程度
在敏捷开发实践中，团队通常会进行一次“规划扑克”（Planning Poker）会议，利用斐波那契数列来为每个用户故事分配故事点数值。
斐波那契数列
斐波那契数列是1,2,3,5,8,13这样的数列，每个数是前两个数的和。
为什么不用线性增长的数列，比如1,2,3,4,5，或者2的幂次，比如1,2,4,8呢？
斐波那契数列的增长速度符合人类对不确定性的感知。当任务复杂度增加时，准确估计的难度也增加，所以用更大的间隔来反映更大的不确定性。比如，估计一个5和8之间的任务，可能团队觉得不确定是6还是7，这时候直接跳到8，避免陷入细节争论。
人们对复杂度的感知呈非线性，斐波那契数列更贴近这种自然判断模式。
其次，斐波那契数列强制团队进行相对估算，而不是绝对时间估算。使用非线性的数列，让团队更关注任务之间的相对大小，而不是具体的工时。这有助于减少估算的时间，因为不需要精确到小时或天数。
斐波那契数列的间隔变大，迫使团队在更高层次上做决策，加快估算过程。
Team Software Process（团队软件过程）
TSP是计划驱动框架，强调过程纪律，通过严格计划、度量和过程改进确保高质量交付（适用于安全关键系统）。
TSP 的核心角色（6-10个，结构更复杂）
团队领导（Team Leader）
职责：协调团队活动，监督流程执行，对外沟通。
开发经理（Development Manager）
职责：技术决策、设计评审、确保代码质量。
计划经理（Planning Manager）
职责：制定详细计划（任务分解、工时估算），跟踪进度偏差。
质量/过程经理（Quality/Process Manager）
职责：监控过程合规性，分析缺陷数据，推动过程改进。
支持经理（Support Manager）
职责：管理工具、环境和文档支持。
其他角色：可能包括需求经理、测试经理等，视项目复杂度而定。
流程与协作模式
| Scrum | TSP |
|---|---|
| - 迭代周期固定（如2-4周），以Sprint为单位交付增量。 | - 阶段式开发，强调前期计划（需求、设计、实现、测试严格分离）。 |
| - 每日站会聚焦目标进展，而非任务汇报。 | - 每日例会详细汇报个人任务进度、工时消耗与问题。 |
| - 回顾会议驱动过程改进，由团队自主决定调整。 | - 过程改进基于数据度量（如缺陷密度、计划偏差率），由质量经理主导。 |
| - 需求动态调整：每个Sprint可重新定义优先级。 | - 计划刚性：变更需经过正式评审和影响分析。 |
适用场景对比
| Scrum | TSP |
|---|---|
| - 需求不明确或频繁变化的项目（如互联网产品）。 | - 高可靠性要求的系统（如航空航天、医疗设备）。 |
| - 团队追求灵活性和快速响应能力。 | - 需要严格合规性和可审计性的项目。 |
| - 中小型团队（5-9人）。 | - 大型复杂团队（跨职能、多层级协作）。 |
关键差异总结
| 维度 | Scrum | TSP |
|---|---|---|
| 角色分工 | 扁平化，3个核心角色 | 层级化，6-10个专业角色 |
| 过程控制 | 轻量级流程，依赖团队共识 | 严格流程，依赖角色监督 |
| 变更响应 | 快速适应变化（敏捷宣言） | 变更需正式评审（计划驱动） |
| 度量重点 | 速率（Velocity）、价值交付 | 缺陷率、计划偏差、工时精度 |
| 文化导向 | 自组织、信任 | 纪律、规范、可预测性 |
某些团队在TSP中引入Scrum的每日站会，或在Scrum中借鉴TSP的缺陷分析技术
参考文章：
https://www.atlassian.com/zh/agile/scrum/roles
https://syding.njuse.icu/posts/期末复习/24-spring-软件质量与管理期末复习.html
转载本站文章《敏捷项目管理框架Scrum:对比TSP角色和职责》,
请注明出处：https://www.zhoulujun.cn/html/webfront/engineer/Architecture/9490.html