软件质量管理-03-团队动力学

本文主要内容来自 SpriCoder 的博客，更换了更清晰的图片并根据新的课程设计做了补充和修正。

【2014】自主团队

【2013】【2015A】【2016】软件开发是知识工作

软件开发是一项既复杂又富有创造性的知识工作

软件开发——智力劳动：

1. 处理和讨论极其抽象的概念：件和传统行业的不同：不可重复性
2. 把不同的部分（不可见）整合成一个可以工作的系统

这就要求从事软件开发的工程师：

1. 必须全身心地参与工作
   1. 知识工作必须是全身心投入的
   2. 任务切换一般需要 30 分钟才能全身心的投入：《人件》
2. 主观意愿上努力追求卓越

这就要求管理者激励并且维持激励：

1. 激励手段
2. 维持激励手段

知识工作管理

管理知识工作的关键规则是：管理者无法管理工作者，知识工作者必须实现并且学会自我管理。

要自我管理，知识工作者必须（如下是自我管理的前提条件）：

1. 有积极性：不然可能会被其他人替代
2. 能做出准确的估算和计划
3. 懂得协商承诺
4. 有效跟踪他们的计划
5. 持续地按计划交付高质量产物

带来的改变

1. 需要什么样的团队协作？
2. 什么样的领导者适合软件项目？如何激励？
3. 估算、计划和跟踪中的心理因素
4. 敏捷开发中的心理因素
5. UML 技术隐含的心理因素

知识工作者实现自我管理：胶冻状团队

团队中到处蔓延着一些神奇的东西，体现着独特的伦理，态度和力量。团队成员相互支持，他们凭直觉就知道何时以及如何帮助彼此。每一个团队成员都深深感觉到是共同力量的一部分，有一种强烈的归属感和一种互助友爱的感觉。

——DeMarco & Lister 《人件》

领导者

1. 知识工作者的管理需要的是领导者，而不是经理。
2. 简单讨论知识工作的领导者具有什么特点？

【2014】马斯洛的需求理论

1. 自我实现是最高的层次
2. 激励来自为没有满足的需求而努力奋斗
3. 低层次的需求必须在高层次需求满足之前得到满足
4. 满足高层次的需求的途径比满足低层次的途径更为广泛

领导者的激励手段

有 3 种主要的激励方式：

1. 威逼
2. 利诱
3. 鼓励承诺：位于马斯洛需求理论的 4 级以上，应当是主要的方式，并且最好以团队为单位做承诺

上面哪种激励效果最好

被以上这 3 种方式激励的团队各有什么特点？

交易型领导方式：

1. 承诺奖励激励
2. 人们通常能找到新的方式来获得奖励，同时少做工作。
3. 威逼和利诱属于交易型领导方式。

转变型领导方式：

1. 用成就激励
2. 鼓励承诺属于转变型领导方式。

由于交易型领导方式很少能产生成功的并且有创造性的团队，因此转变型领导方式是首选。

承诺形式的奖励

在个人级别，有很大的差异：有些人对待承诺十分认真；有些人对待承诺十分轻率。

当满足以下情况，团队承诺比个人承诺的激励作用更大：

1. 所有团队成员共同参与作出承诺；
2. 团队依赖于每一位成员履行自己的承诺；
3. 如果有计划在支撑承诺，那么就更为可信。

一个软件开发团队在制定承诺时，要保证：

1. 承诺是自愿的；
2. 承诺是公开的；
3. 承诺是可信（行）的；
4. 向团队承诺。

维持激励水平

维持激励需要及时的绩效反馈。

这些反馈包括：

1. 根据一个详细计划衡量进度
2. 当前计划不准确时重做计划，想想为什么？
3. 为漫长而富有挑战性的项目提供中间反馈，即里程碑，想想为什么？

编写代码时：执行单元测试前，阅读代码查找错误，可以保证错误更少，总体消除缺陷的代价更低。

有反馈的更容易愿意加班。

激励水平的重要影响因素：

1. 回报：回报越大，激励水平越高
2. 期望：完成这件事情的把握多大，把握越大，激励水平越高

其他激励相关理论

1. 海兹伯格的激励理论 Herzberg's Motivational and Hygiene Factors
2. 麦克勒格的 X-理论 和 Y -理论 McGregor's Theory X and Y
3. 期望理论 Expectancy Theory

海兹伯格的激励理论

1. 激励因素（内在因素）：成就感，责任感，晋升，被赏识、认可
2. 保健因素（外在因素）：工作环境，薪金，工作关系，安全等

麦克勒格的 X-理论

1. 不喜欢他们的工作并努力逃避工作
2. 缺乏进取心，没有解决问题与创造的能力
3. 更喜欢经常的指导，避免承担责任，缺乏主动性
4. 自我中心，对组织需求反应淡漠，反对变革
5. 用马斯洛的底层需求（生理和安全）进行激励

麦克勒格的 Y-理论

1. 如果给予适当的激励和支持性的工作氛围，会达到很高的绩效预期
2. 具有创造力，想象力，雄心和信心来实现组织目标
3. 能够自我约束，自我导向与控制，渴望承担责任
4. 用马斯洛的高层需求（自尊和自我实现）进行激励

期望理论 Expectancy Theory

人们在下列情况下能够受到激励并且出大量成果 \(M = V \times E\)

1. 相信他们的努力很可能会产生成功的结果（V）
2. 他们也相信自己会因为成功得到相应的回报（E）

Motivation = Valence \(\times\) Expectancy(Instrumentality)，即激发力量 = 效价 \(\times\) 期望值

1. M 表示激发力量，是指调动一个人的积极性，激发人内部潜力的强度。
2. V 表示目标价值（效价），这是一个心理学概念，是指达到目标对于满足他个人需要的价值。同一目标，由于各个人所处的环境不同，需求不同，其需要的目标价值也就不同。同一个目标对每一个人可能有三种效价：正、零、负。效价越高，激励力量就越大
3. E 是期望值，是人们根据过去经验判断自己达到某种目标的可能性是大还是小，即能够达到目标的概率。目标价值大小直接反映人的需要动机强弱，期望概率反映人实现需要和动机的信心强弱。

提高成功把握的两种方式

1. 现实扭曲立场！（乔布斯传）
2. 数据！
3. 问题：美国基金会每年提交申请书数量太多，没有足够的评审人员，怎么才能解决这个问题？
   1. 和课程有关
   2. 取消申请的最后期限

团队软件过程（TSP）对自主团队的实现

自主团队

团队的定义：

1. 2 个人以上
2. 有不同的角色和职责
3. 通过协作来完成目标

自主团队具备如下的特点：

1. 自行定义项目的目标
2. 自行决定团队组成形式以及成员的角色
3. 自行决定项目的开发策略
4. 自行定义项目的开发过程
5. 自行制定项目的开发计划
6. 自行度量、管理和控制项目工作

自主团队的外部环境

项目启动阶段获得管理层的支持：

1. 项目小组应当体现出已经尽最大的可能在满足管理层的需求的工作态度。
2. 项目小组应当在计划中体现定期需要向管理层报告的内容。
3. 项目小组应当向管理层证明他们所制定的工作计划是合理的。
4. 项目小组应当在计划中体现为了追求高质量而开展的工作。
5. 项目小组应当在工作计划中允许必要的项目变更。
6. 项目小组应当向管理层寻求必要的帮助。

在管理层视角，在项目还没有开始的阶段，如何判断项目团队已经很努力？

1. 前提是团队已经明确 3 个月内没有办法完成，但是团队会给出相应的替代方案。
2. 自主团队能够给出一些修正内容。

在项目进展过程中获得管理层的支持

1. 项目小组应当严格遵循定义好的开发过程开展项目开发工作。
2. 项目小组应当维护和更新项目成员的个人计划和团队计划。
3. 项目小组应当对产品质量进行管理。
4. 项目小组应当跟踪项目进展，并定期向管理层报告。
5. 项目小组应当持续地向管理层展现优异的项目表现。
6. 高成熟度的质量管理和低成熟度的质量管理有什么区别？差别在于认定偏差的方式不一样：
   1. 2 级、3 级是基于当前已经发生的事实来认定偏差
   2. 4 级、5 级是基于模型来预测最终结果，最后根据这个结果来纠正偏差。

TSP 对自主团队的支持

TSP Launch

• 分为 4 天完成
• 管理层的期望和小组的期望的完成的对立冲突：
  • 996 加班
  • 希望你的功能能尽快上线
• 第一次和第二次会议由项目经理主持
• 第三次会议：
  • TSP 灵活：自定义的流程让人相信项目可以成功
  • 开发策略：打算进行几个迭代周期。
• 几个认识：
  • 错误的认识：软件开发阶段理解为注入缺陷的阶段，软件测试阶段理解为消除缺陷的阶段。
  • 正确的认识：开发和测试都是既有可能引入缺陷，也有可能消除缺陷的阶段
• 项目完成的实际时间由什么决定？最晚完成的工作的人决定的
• 经过平衡的计划和没有平衡的计划有什么不一样？更有把握去成功。
• 准备 PPT，其中准备实现哪些东西？

承诺文化的建立与团队激励

通常用以激励团队成员的方式有三种：“威逼”、“利诱”以及鼓励承诺。

按照马斯洛关于人的需求层次的理论，人的需求大致分成五个不同的层次。

1. 第一层：生理需求
2. 第二次：安全感
3. 第三层：爱和归属感
4. 第四层：获得尊敬
5. 第五层：自我实现

【2021Fall】典型 TSP 角色

1. 项目组长
2. 计划经理：开发完整的、准确的团队计划和个人计划；每周准确的报告项目小组状态
3. 开发经理：开发优秀的软件产品；充分利用团队成员的技能
4. 质量经理：项目团队严格按照质量计划开展工作，开发出高质量的软件产品；所有的小组评审工作都正常开展，并且都形成了评审报告
5. 过程经理：所有团队成员准确的记录、报告和跟踪过程数据；所有的团队会议都有相应会议记录。
6. 支持经理：项目小组在整个开发过程中都有合适的工具和环境；对于基线产品，不存在非授权的变更；项目小组的风险和问题得到跟踪；项目小组在开发过程中满足复用目标
7. 开发人员

领导者与经理的区别

角色经理	团队领导者
告知	倾听
指导	询问
说服	激励/挑战
决定	促进达成一致
控制	教练
监控	授权
设定目标	挑战

【2022Fall】典型 TSP 角色-Team Leader

项目组长的目标和衡量指标：

1. 项目组长应当建设和维持高效率的团队。
2. 项目组长应当激励团队成员积极工作。
3. 项目组长应当合理处理团队成员的问题。
4. 项目组长应当向管理层提供项目进度相关的完整信息。
5. 项目组长应当充当合格的会议组织者和协调者。

典型 TL 技能

1. 你是天生的领导者
2. 你有能力识别问题的关键并且做出客观的决策
3. 你不介意偶尔充当“恶人”
4. 你尊敬你的团队成员

TL 的工作内容

1. 激励团队成员努力工作
2. 主持项目周例会
3. 每周汇报项目状态
4. 分配工作任务
5. 维护项目资料
6. 组织项目总结

计划经理

1. 开发完整的、准确的团队计划和个人计划
2. 每周准确的报告项目小组状态

计划经理典型技能

1. 最为重要的一点是，你做事有条理和逻辑
2. 你对于过程数据非常感兴趣，期待通过每周输入的数据来了解项目当前状况
3. 你认为计划非常重要，也愿意要求团队成员跟踪和度量他们的工作

计划经理的主要工作内容

1. 带领项目小组开发项目计划
2. 带领项目小组平衡计划
3. 跟踪项目进度
4. 参与项目总结

开发经理

1. 开发优秀的软件产品
2. 充分利用团队成员的技能

有助于开发经理的技能

1. 你喜欢创造事物
2. 你愿意成为软件工程师，并且喜欢带领团队开展设计和开发工作
3. 你具备足够的背景可以胜任设计师的工作，并且可以领导设计团队开展工作
4. 你熟悉主流的设计工具
5. 你愿意倾听和接受其他人的设计思想

开发经理的主要工作内容

1. 带领团队制定开发策略。
2. 带领团队开展产品规模估算和所需时间资源的估算。
3. 带领团队开发需求规格说明。
4. 带领团队开发高层设计。
5. 带领团队开发设计规格说明。
6. 带领团队实现软件产品。
7. 带领团队开展集成测试和系统测试。
8. 带领团队开发用户支持文档。
9. 参与项目总结

质量经理

1. 项目团队严格按照质量计划开展工作，开发出高质量的软件产品
2. 所有的小组评审工作都正常开展，并且都形成了评审报告

有助于质量经理的技能

1. 你关注软件产品的质量
2. 你有评审方面的经验，熟悉各种评审方法
3. 你有协调组织有效评审的能力

质量经理的主要工作内容

1. 带领团队开发和跟踪质量计划
2. 向项目组长警示质量问题
3. 软件产品提交配置管理之前，对其进行评审，以消除质量问题
4. 项目小组评审的组织者和协调者
5. 参与项目总结

过程经理

1. 所有团队成员准确的记录、报告和跟踪过程数据。
2. 所有的团队会议都有相应会议记录。

有助于过程经理的技能

1. 你对过程定义、过程度量非常感兴趣
2. 你对过程改进非常感兴趣

过程经理的主要工作内容

1. 带领团队定义和记录开发过程并且支持过程改进。
2. 建立和维护团队的开发标准。
3. 记录和维护项目的会议记录。
4. 参与项目总结。

支持经理

1. 项目小组在整个开发过程中都有合适的工具和环境
2. 对于基线产品，不存在非授权的变更
3. 项目小组的风险和问题得到跟踪
4. 项目小组在开发过程中满足复用目标

有助于支持经理的技能

1. 你对于各种开发工具很感兴趣，熟悉各类工具的适用场合。
2. 你对版本控制工具很熟悉，也熟悉配置管理流程。
3. 对于本项目所有工具而言，你都是专家。

支持经理的主要工作内容

1. 带领团队识别开发过程中所需要的各类工具和设施。
2. 主持配置管理委员会，管理配置管理系统。
3. 维护软件项目的词汇表。
4. 维护项目风险和问题跟踪系统。
5. 支持软件开发过程中复用策略的应用。
6. 参与项目总结。

SCRUM 中的角色

SCRUM

迭代式增量软件开发过程：

Scrum 中的文档：

1. 产品订单（product backlog）：整个项目的概要文档，包含了已划分优先等级的、项目要开发的系统或产品的需求清单，是动态的。
2. 冲刺订单（sprint backlog）：细化了的文档，包含了团队如何实现下一个冲刺的需求信息。
   1. 哪些产品订单会加入一次冲刺由冲刺计划会议决定。会议中，产品负责人告诉开发团队他们需要完成产品订单中的哪些订单项，开发团队决定在下一次冲刺中承诺完成多少订单项。
   2. 在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog），这意味着在一个冲刺中需求是被冻结的。

燃尽图（burn down chart）

典型 SCRUM 小组角色

1. 典型 SCRUM 团队由一名产品负责人、开发团队和一名 SCRUM Master 组成
2. SCRUM 团队是跨职能的自组织团队

产品负责人职责和工作

产品负责人，代表利益所有者。

产品负责人的职责是将开发团队开发的产品价值最大化。

产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括： 1. 清晰地表述产品待办列表项； 2. 对产品待办列表项进行排序，使其最好地实现目标和使命； 3. 优化开发团队所执行工作的价值； 4. 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作；以及 5. 确保开发团队对产品待办列表项有足够深的了解。

开发团队职责和工作

1. 负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。
2. 开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。开发团队具有下列特点：
   1. 他们是自组织的。没有人（即使是 Scrum Master）有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量；
   2. 开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能；
   3. Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作（他们都叫开发人员）。
   4. Scrum 不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架构、运维或业务分析；同时，
   5. 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。

Scrum Master 职责和工作

促进和支持 SCRUM，帮助每个人理解 SCRUM 理论、实践、规则和价值

SCRUM Master 是一位服务型领导

1. 帮助 SCRUM 团队之外的人了解如何与 SCRUM 团队交互是有益的
2. 改变 SCRUM 团队之外的人与 SCRUM 团队的互动方式来最大化 SCRUM 团队所创造的价值。

Scrum Master 服务于产品负责人

1. 确保 Scrum 团队中的每个人都尽可能地理解目标、范围和产品域；
2. 找到有效管理产品待办列表的技巧；
3. 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
4. 理解在经验主义的环境中的产品规划；
5. 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
6. 理解并实践敏捷性；以及，
7. 当被请求或需要时，引导 Scrum 事件。

Scrum Master 以各种方式服务于开发团队

1. 作为教练在自组织和跨职能方面给予开发团队以指导；
2. 帮助开发团队创造高价值的产品；
3. 移除开发团队工作进展中的障碍；
4. 按被请求或需要时，引导 Scrum 事件；以及，
5. 在 Scrum 还未完全采纳和理解的组织环境中，作为教练指导开发团队。

Scrum Master 以各种方式服务于组织

1. 带领并作为教练指导组织采纳 Scrum；
2. 在组织范围内规划 Scrum 的实施；
3. 帮助员工和利益攸关者理解并实施 Scrum 和经验导向的产品开发；
4. 引发能够提升 Scrum 团队生产率的改变；以及，
5. 与其他 Scrum Master 一起工作，增强组织中 Scrum 应用的有效性。

Scrum 常见活动

1. Sprint Planning Meeting
2. Daily standup meeting
3. review meeting
4. retrospective meeting
5. sprint

Empirical Process Control VS. Statistical Process Control

不同于统计过程控制方法（也叫预测式、计划式）不能解决不可预见的需求变化问题，Scrum 采用的实证过程控制承认问题无法完全理解或定义，即用户可以在项目过程中变更需求，关注于如何使开发团队快速推出和响应需求变化的能力最大化

Scrum VS. XP

1. 迭代周期不同。XP 迭代周期为 1~2 周，而 Scrum 迭代周期为 2~4 周
2. 迭代中是否允许需求变更。XP 中只要变更需求与原需求所需时间资源相等即可变更，而 Scrum 在迭代中需求被冻结
3. 迭代中，需求是否严格按照优先级来实现。XP 中务必遵守优先级别，Scrum 中则比较灵活，原因是可能有需求依赖问题
4. 过程工程化。Scrum 开发过程并未工程化，要求开发者自觉保证，但 XP 则对开发流程定义严格，例如 TDD，结对编程，重构等