团队动力学
软件开发是知识工作
- 软件开发是一项既复杂又富有创造性的知识工作
- 软件开发是智力劳动
- 处理和讨论极其抽象的概念
- 把不同的部分（不可见）整合成一个可以工作的系统
- 这就要求从事软件开发的工程师
- 必须全身心地参与工作
- 主观意愿上努力追求卓越
- 这就要求管理者激励并且维持激励
知识工作管理
- 管理知识工作的关键规则是：管理者无法管理工作者，知识工作者必须实现并且学会自我管理。
- 要自我管理，知识工作者必须：
- 有积极性
- 能做出准确的估算和计划
- 懂得协商承诺
- 有效跟踪他们的计划
- 持续地按计划交付高质量产物
胶冻状团队
- 知识工作者实现自我管理，可以形成所谓的 胶冻状团队。
- 可理解为：高凝聚力、高信任、高协作的团队。
领导者的激励手段
三种主要激励方式
- 威逼
- 利诱
- 鼓励承诺
交易型领导方式
- 承诺奖励激励
- 威逼和利诱属于交易型领导方式
- 问题：
- 人们通常能找到新的方式来获得奖励，同时少做工作
- 很少能产生成功的、创造性的团队
转变型领导方式
- 用成就激励
- 鼓励承诺属于转变型领导方式
- 转变型领导方式是首选
马斯洛需求层次理论
- 自我实现是最高的层次
- 激励来自为没有满足的需求而努力奋斗
- 低层次需求必须在高层次需求满足之前得到满足
- 满足高层次需求的途径比满足低层次需求的途径更为广泛
承诺形式的激励
- 在个人级别，有很大的差异
- 当满足以下情况，团队承诺比个人承诺的激励作用更大：
- 所有团队成员共同参与作出承诺
- 团队依赖于每一位成员履行自己的承诺
- 一个软件开发团队在制定承诺时，要保证：
- 承诺是自愿的
- 承诺是公开的
- 承诺是可信（行）的
- 向团队承诺
维持激励水平
- 维持激励需要及时的绩效反馈
- 反馈包括：
- 根据一个详细计划衡量进度
- 当前计划不准确时重做计划
- 为漫长而富有挑战性的项目提供中间反馈，即里程碑
其他激励相关理论
海兹伯格的激励理论
- 激励因素（内在因素）
- 成就感
- 责任感
- 晋升
- 被赏识、认可
- 保健因素（外在因素）
- 工作环境
- 薪金
- 工作关系
- 安全等
麦克勒格的 X 理论
- 基本假设偏消极：
- 不喜欢工作并努力逃避工作
- 缺乏进取心，没有解决问题与创造的能力
- 更喜欢经常的指导，避免承担责任，缺乏主动性
- 自我中心，对组织需求反应淡漠，反对变革
- 激励方式：
- 用马斯洛的底层需求，即生理和安全需求进行激励
麦克勒格的 Y 理论
- 基本假设偏积极：
- 如果给予适当的激励和支持性的工作氛围，会达到很高的绩效预期
- 具有创造力、想象力、雄心和信心来实现组织目标
- 能够自我约束、自我导向与控制，渴望承担责任
- 激励方式：
- 用马斯洛的高层需求，即自尊和自我实现需求进行激励
期望理论
- 公式：
- M = V × E
- 含义：
- M：激发力量
- V：目标价值，达到目标对个人需要的价值
- E：期望值，个人判断自己达到目标的可能性
- 核心意思：
- 人们相信努力能够成功，并且成功会带来有价值的回报时，才更容易受到激励
提升成功把握（E）的两种方式
- 现实扭曲立场
- 数据
自主团队
如果整个团队的所有成员都实现了自我管理，也就形成了所谓的自主团队
自主团队的特点
- 自行定义项目的目标
- 自行决定团队组成形式以及成员的角色
- 自行决定项目的开发策略
- 自行定义项目的开发过程
- 自行制定项目的开发计划
- 自行度量、管理和控制项目工作
自主团队的外部环境
项目启动阶段获得管理层支持，项目小组应当：
- 体现出已经尽最大的可能在满足管理层的需求的工作态度
- 在计划中体现定期需要向管理层报告的内容
- 向管理层证明他们所制定的工作计划是合理的
- 在计划中体现为了追求高质量而开展的工作
- 在工作计划中允许必要的项目变更
- 向管理层寻求必要的帮助
项目进展过程中获得管理层支持，项目小组应当：
- 严格遵循定义好的开发过程开展项目开发工作
- 维护和更新项目成员的个人计划和团队计划
- 对产品质量进行管理
- 跟踪项目进展，并定期向管理层报告
- 持续地向管理层展现优异的项目表现
TSP （Team Software Process）
TSP 通过一系列 Launch Meeting 帮助团队建立目标、角色、过程、计划、质量策略和风险管理机制
TSP Launch
Launch Meeting 1
建立产品目标和业务目标
- 产品目标：要做什么？
- 业务目标：要做得怎么样？
Launch Meeting 2
角色分配和小组目标定义
- 角色分配：怎么安排？
- 小组目标：有没有与组织目标冲突？
Launch Meeting 3
开发流程定义与策略选择
- 开发流程：打算使用什么样的过程？
- 开发策略：
- 分为几个迭代？
- 每个迭代做什么？
- 组件如何获取？
Launch Meeting 4
整体计划
- 整体计划：估算 + 计划
- 需要明确：
- 做哪些事情
- 产出物有哪些
- 产出物规模如何
- 需要多少资源
- 团队给出的资源够不够
Launch Meeting 5
质量计划
- 质量计划：
- 有哪些质量实践？
- 做到什么程度？
- 需要投入多少资源？
Launch Meeting 6
个人计划以及计划平衡
- 个人计划：
- 个人要做哪些事情？
- 计划平衡：
- 如何寻求一个最早完成项目的时间？
Launch Meeting 7
风险评估
- 风险评估：
- What if？
Launch Meeting 8
准备向管理层汇报计划
- 向管理层汇报准备：
- 呼应第一次会议要求
- 体现团队诉求
- 体现计划不是粗制滥造
Launch Meeting 9
向管理层汇报计划内容
- 汇报和讨论
Launch Meeting 10
Lauch阶段总结
- 总结：
- 总结得失
典型 TSP 角色
- 项目组长
- 计划经理
- 开发经理
- 质量经理
- 过程经理
- 支持经理
- 开发人员
领导者与经理的区别
| 角色经理 | 团队领导者 |
|---|---|
| 告知 | 倾听 |
| 指导 | 询问 |
| 说服 | 激励 / 挑战 |
| 决定 | 促进达成一致 |
| 控制 | 教练 |
| 监控 | 授权 |
| 设定目标 | 挑战 |
典型 TSP 角色职责
-
项目组长 TL
-
目标和衡量指标
-
建设和维持高效率的团队
-
激励团队成员积极工作
-
合理处理团队成员的问题
-
向管理层提供项目进度相关的完整信息
-
充当合格的会议组织者和协调者
-
-
典型技能
- 天生的领导者
- 有能力识别问题的关键并且做出客观的决策
- 不介意偶尔充当恶人
- 尊敬你的团队成员
-
主要工作内容
-
激励团队成员努力工作
-
主持项目周例会
-
每周汇报项目状态
-
分配工作任务
-
维护项目资料
-
组织项目总结
-
-
-
计划经理
-
目标
-
开发完整的、准确的团队计划和个人计划
-
每周准确地报告项目小组状态
-
-
典型技能
- 做事有条理和逻辑
- 对于过程数据非常感兴趣，期待通过每周输入的数据来了解项目当前情况
-
主要工作内容
-
带领项目小组开发项目计划
-
带领项目小组平衡计划
-
跟踪项目进度
-
参与项目总结
-
-
-
开发经理
-
目标
-
开发优秀的软件产品
-
充分利用团队成员的技能
-
-
技能
- 喜欢创造事物
- 你愿意成为软件工程师，并且喜欢带领团队开展设计和开发工作
- 具备足够的背景可以胜任设计师的工作，并且可以领导设计团队开展工作
- 熟悉主流的设计工具
- 愿意倾听和接受其他人的设计思想
-
主要工作内容
-
带领团队制定开发策略
-
带领团队开展产品规模估算和所需时间资源的估算
-
带领团队开发需求规格说明
-
带领团队开发高层设计
-
带领团队开发设计规格说明
-
带领团队实现软件产品
-
带领团队开展集成测试和系统测试
-
带领团队开发用户支持文档
-
参与项目总结
-
-
-
质量经理
-
目标
-
项目团队严格按照质量计划开展工作，开发出高质量的软件产品
-
所有的小组评审工作都正常开展，并且都形成了评审报告
-
-
技能
- 关注软件产品的质量
- 有评审方面的经验，熟悉各种评审方法
- 有协调组织有效评审的能力
-
主要工作内容
-
带领团队开发和跟踪质量计划
-
向项目组长警示质量问题
-
软件产品提交配置管理之前，对其进行评审，以消除质量问题
-
作为项目小组评审的组织者和协调者
-
参与项目总结
-
-
-
过程经理
-
目标
-
所有团队成员准确地记录、报告和跟踪过程数据
-
所有团队会议都有相应会议记录
-
-
技能
- 对过程定义、过程度量、过程改进感兴趣
-
主要工作内容
-
带领团队定义和记录开发过程并且支持过程改进
-
建立和维护团队的开发标准
-
记录和维护项目的会议记录
-
参与项目总结
-
-
-
支持经理
-
目标
-
项目小组在整个开发过程中都有合适的工具和环境
-
对于基线产品，不存在非授权的变更
-
项目小组的风险和问题得到跟踪
-
项目小组在开发过程中满足复用目标
-
-
技能
- 熟悉本项目相关所有工具，比如开发工具，版本控制工具
-
主要工作内容
-
带领团队识别开发过程中所需要的各类工具和设施
-
主持配置管理委员会，管理配置管理系统
-
维护软件项目的词汇表
-
维护项目风险和问题跟踪系统
-
支持软件开发过程中复用策略的应用
-
参与项目总结
-
-
Scrum中的角色
典型SCRUM小组角色
- 典型 SCRUM 团队由一名产品负责人、开发团队和一名 SCRUM Master 组成
- SCRUM 团队是跨职能的自组织团队
产品负责人职责和工作
- 产品负责人的职责是将开发团队开发的产品价值最大化
- 产品负责人是负责管理产品待办列表的唯一负责人
- 产品待办列表的管理包括：
- 清晰地表述产品待办列表项
- 对产品待办列表项进行排序，使其最好地实现目标和使命
- 优化开发团队所执行工作的价值
- 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作
- 确保开发团队对产品待办列表项有足够深的了解
开发团队职责和工作
- 负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量
- 开发团队由组织组建并得到授权，团队自己组织和管理他们的工作
- 开发团队特点：
- 他们是自组织的，没有人，即使是 Scrum Master，有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量
- 开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能
- Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作，他们都叫开发人员
- Scrum 不认可开发团队中所谓的“子团队”
- 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队
Scrum Master 职责和工作
Scrum Master 的总体职责
- 促进和支持 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 应用的有效性
-
思考题
Q：TSP 和 SCRUM 的团队组成有哪些共性？这些共性对于高效团队有什么帮助？
参考回答：
TSP 和 SCRUM 都强调团队不是简单的人员集合，而是具有明确目标、清晰角色、共同责任和自我管理能力的协作系统。
二者共性：
- 都强调团队目标
- TSP 通过 Launch Meeting 明确产品目标、业务目标和小组目标
- Scrum 通过产品目标、产品待办列表和 Sprint 目标统一团队方向
- 都强调角色分工
- TSP 有项目组长、计划经理、开发经理、质量经理、过程经理、支持经理等角色
- Scrum 有产品负责人、开发团队和 Scrum Master
- 都强调自组织 / 自主性
- TSP 支持团队自行定义目标、角色、过程、计划和度量控制方式
- Scrum 开发团队自己组织和管理工作
- 都强调跨职能协作
- TSP 通过不同角色覆盖计划、开发、质量、过程和支持
- Scrum 开发团队作为整体拥有创建产品增量所需的全部技能
- 都强调反馈和持续改进
- TSP 有周例会、状态报告、过程数据、项目总结
- Scrum 有 Sprint、Scrum 事件、产品增量和持续改进机制
这些共性对高效团队的帮助：
- 明确目标，减少方向偏差
- 明确角色，减少职责模糊
- 强化承诺，提高成员责任感
- 支持自我管理，提高知识工作效率
- 促进协作，减少沟通和移交成本
- 通过反馈和度量持续改进团队表现