当前课程知识点：软件工程 > 第5章 团队开发管理 > 5.1 团队组织与管理 > 讲课视频
《西游记》的故事
可谓是家喻户晓
唐僧师徒的组合非常完美
性格各异的四个人
团结协作 各显其能
历经九九八十一难
终于到达西天取得了真经
现在是一个知识经济的时代
单靠个人的能力
无法应对各种复杂的问题
很难做得又快又好
而依靠团队合作的力量
就可以创造出奇迹
在软件企业
最重要的资产就是一批掌握技术
熟悉业务和懂得管理的人
一个软件项目的好坏
很大程度上
就体现在软件团队的建设与管理
团队的组织与管理
主要包括四个方面
首先 是要识别项目团队中
所需要的人员角色
确定他们的职责和所需要的技能
制定出人员需求计划
根据人员需求计划
选择和获得项目需要的人员
组建项目的团队
然后 通过一系列活动
提高团队成员个人的技能
增强成员之间的信任感
和凝聚力
从而保证更好的协作
和更高的效率
同时
在项目进展过程中
跟踪团队成员的表现
解决问题和管理冲突
优化项目的绩效
软件开发过程
有各种不同的活动
每一个开发人员
可能只擅长软件开发的
某一个特定方面
所以
整个开发需要多种不同角色的
分工协作
对于系统分析员来说
他的主要任务
是要获取和定义用户的需求
在需求分析的基础上
系统设计人员
与分析员一起工作
确定系统的整体结构
接下来
设计人员与编程人员
一起完成代码编写工作
然后开发工作进入测试阶段
程序员 负责单元测试
测试人员
负责集成测试和系统测试
在系统交付时
培训人员负责用户培训工作
系统交付使用后
就会进入维护阶段
各种角色的开发人员
将参与系统的缺陷修复
和新功能开发
在项目初期
首先要做人力资源规划
这里显示的
是某一个项目的人员需求计划
它包括了
团队需要的开发角色和数量
进入和退出项目团队的时间
所需要的基本技能
以及获取相关人员的方式等
在制定了人员需求计划之后
就要开始选择和获得
所需要的团队成员
我们先看这样一个案例描述
某公司需要在原有技术的基础上
开发一个报警系统的新产品
这个产品服务于
独立生活的老年人和残疾人
根据常规的要求
项目团队应该包括
需求分析人员 设计人员
编程人员和测试人员等
我们在选择团队成员的时候
应该注重哪些方面 为什么
从上面的描述我们知道
这个产品
是针对老年人和残疾人的
所以 需求分析人员
必须熟悉老年人和残疾人的生活
善于和他们进行沟通
整个产品
基于公司现有的技术
产品涉及到软件和硬件的开发
所以 开发人员中应该有人
对原有产品的开发比较熟悉
并且具有软硬件产品的开发经验
建立一支优秀的项目团队
是从选择合适的人开始的
在选择人员的时候
需要考虑哪些因素
教育背景
可以显示候选人
应该掌握的基础知识和学习能力
但是 开发人员的经验
也可以在项目实践中学习和获得
所以 这个因素并不是关键性的
往往刚毕业的学生
在进入一个企业时
可能会考察他的教育背景
但是 在工作之后
这个因素就没有太大的作用了
对于项目来说
开发人员对于应用领域
开发平台和编程语言的
知识和经验比较重要
除了技术条件之外
候选人的工作态度 性格和能力
也是非常关键的因素
解决技术难题的能力至关重要
通常会被优先进行考虑
只要有较强的解决问题能力
或许可以弥补其他因素的不足
由于项目成员
经常需要和其他人员
管理者和客户进行口头
和书面的交流
所以 沟通能力是一个
必须要考察的因素
适应性
可以通过候选人的各种经历
进行判断
这个因素反映出一个人的
学习能力
项目成员
应该有积极的工作态度
乐于学习新技术
由于软件开发需要团队的协作
所以
候选人必须与团队成员关系融洽
目前
还没有关于软件工程方面的
特定个性类型
工作态度和个性
这两个因素很重要
但都是比较难以评估的
在平时的工作中
不同性格的人
会表现出不同的工作风格
心理学家荣格
提出了这样一个模型
来描述人的性格类型
其中 横轴表示交流风格
纵轴表示决策风格
一般人的工作风格
可以对应到图中的
四个象限中
第一种 是感性内向的人
他们比较内向敏感
在意周围人对自己的看法
通常 是一个好的倾听者
但是 自己做决策比较困难
大家想一想
《西游记》中的四个人
谁像这种性格
沙僧比较符合这种特质
第二种 是感性外向的人
大部分的决策
是建立在情感反映的基础上
喜欢把自己的想法直接告诉别人
凭直觉做决策
做事有时比较随意而且耐心不足
猪八戒是一个典型的
感性外向的人
第三种 是理性内向的人
遇事深思熟虑 善于思考
注重长远的目标
做事细致 追求完美
但有时应过于谨慎
而变得优柔寡断
唐僧具备这种性格特点
第四种 是理性外向的人
他们依靠逻辑推理进行决策
坚持自己的想法 注重实干
具有很强的执行力和突出的业绩
由于往往偏重关注工作结果
对他人的情感关心不够
显然 孙悟空是这样性格的人
我们在组建团队的时候
应该考虑不同成员的技术
经验和个性
在整体上取得平衡
选择性格互补的成员
可能比单纯选择技术能力的团队
更有活力和效率
在《西游记》团队中
如果没有唐僧
这个团队可能就只是乌合之众
不会有什么远大的前程
如果没有孙悟空
很难想象这个团队
是如何艰难前行的
唐僧的远大抱负
很可能会化为乌有
如果没有猪八戒
这个团队就会显得枯燥无趣
如果没有沙僧
许多事务性的工作就没人去做
团队的和谐和稳定
可能存在一定的问题
可以说这是一个战斗力和执行力
都非常强的团队
团队成员之间互为补充
缺一不可
堪称是一个完美的组合
从《西游记》的故事中
我们可以看出
团队是由若干人组成的一个群体
他们具有互补的技能
对一个共同目的
绩效目标及方法
作出承诺并彼此负责
现实中也有很多团队的例子
团队并不只是简单的
把一组人聚集在一起
我们可以看到
这些团队的共同特点是
具有一致的集体目标
营造出一种互相交流
和协作学习的工作环境
团队成员有自豪感
团队内部有各自的分工
互相依赖 共同协作完成任务
团队工作有正确的绩效评估
软件开发团队
有各种不同的组织形式
适合不同人员和项目的需要
一种比较极端的模式
是民主式的结构
这里 团队成员完全平等
组长只是名义上的
项目工作由全体讨论协商决定
并根据每个人的能力和经验
进行适当分配
这种结构的团队
一般规模比较小
成员之间关系紧密
能够互相学习
同等的项目参与权
可以激发大家的创造力
有利于攻克技术难关
但是 这种结构
缺乏明确的权威领导
很难处理意见分歧的情况
在组内 多数成员技术水平不高
或者缺乏经验的情况下
不适合采用
考虑到多数开发人员
是缺乏经验的
软件开发过程中
还有许多事务性的工作
《人月神话》一书中
提出了一种主程序员的团队模式
他是借鉴
外科手术队伍的组织结构
主程序员就像是主刀医生
负责所有的开发决策
并完成主要模块的设计
和实现工作
后备程序员
作为一个替补
在必要时替代主程序员
其他程序员
完成主程序员分配的编程任务
秘书 负责维护项目文档
并进行初步的测试工作
在这种模式中
所有成员都听从主程序员的安排
只和主程序员进行交流和沟通
降低了项目沟通的复杂性
但是 在现实中
很难找到技术和管理才能兼备的
主程序员
在大型的软件企业中
还有一种层次化的矩阵式结构
在这种结构中
开发人员隶属于不同的职能部门
项目经理可以从不同部门
选择合适的成员
组成开发团队
项目经理负责整个项目的
过程管理和绩效评价
另外还有专门的技术负责人
负责软件开发的技术决策
和方案设计
开发人员
按照不同角色分工
协作完成开发任务
这种结构的好处
是将技术和管理工作进行分离
有效解决了
技术和管理能力无法兼备的问题
但是
由于团队成员受到双重的领导
明确地划分技术负责人
和管理负责人的权限
是十分重要的
团队建设的好坏
对软件项目的成败
具有举足轻重的作用
我们需要通过召开项目会议
明确团队成员的角色分工
形成共同的信念和一致的目标
建立起团队运行的规则
激发团队成员的激情
产生1+1大于2的合力
最终 实现项目的成功
团队建设活动有各种形式
并且贯穿整个开发过程
例如在项目启动时
要建立团队章程
针对开发任务
组织兴趣小组和团队作战史
在每个阶段组织评审
验收和总结活动
对于项目工作
要进行绩效沟通和有效激励
在项目结束时
举行庆功活动等等
绩效评估
是通过对团队成员工作绩效的
考察和评价
反映成员的实际能力和业绩
以及对某种工作职位的适应度
分物质奖励
人员调配和精神激励
提供依据
如果用个人工作量来衡量
比如说代码量是不是合理
代码写得多
并不代表这些代码写得好
而且有价值
过分强调代码量
反而会造成
大量不必要的代码
如果用个人工作时间
比如说
看谁加班多 走得晚
情况又会怎么样
时间并不能反映出
工作成果和效率
磨洋工 可能会更糟糕
大锅饭会使优秀的人走掉
最后 只剩下平庸的人
在过平均主义的日子
应该说 不存在完美的评价方法
但是 完全不评价就会更糟糕
绩效评估应该是多维度的
这里给出的
是一种二维评价体系
个人完成任务维度
主要是由团队成员和直接经理
商量工作目标
直接经理根据任务完成情况
给出好 中 差
三个级别的评价
团队贡献维度
采用团队内部互评的方式
评出团队中最好的20%
中间的70%
和最需要改进的10%
显然
这个体系反映了个人的工作情况
也反映了他对整个团队的贡献
绩效考核做得好
可以有效地激发员工积极性
改进个人的工作绩效
最终实现整体绩效的提升
如果不合理
就会影响人员士气 稳定性
后续合作和产品质量
所以 必须要认真对待 慎重考虑
-1.1 软件无处不在
--讲课视频
-1.2 软件的本质特性
--讲授视频
-1.3 软件工程的产生与发展
--讲授视频
-1.4 软件工程的基本概念
--讲授视频
-1.5 软件质量实现
--讲授视频
-1.6 业界人士谈软件工程
-测验题--作业
-讨论题
--讨论题
-作业题
--第一张 作业题
-2.1 编程过程与规范
--讲课视频
-2.2 良好的编程实践
--讲课视频
-2.3 Python集成开发环境
--讲课视频
-2.4 代码静态检查
--讲课视频
-2.5 代码性能分析
--讲课视频
-2.6 结对编程实践
--讲课视频
-2.7 刘贺谈软件工程
--讲课视频
--讨论
-测验题--作业
-作业题
--第二章 作业题
-3.1 单元测试概述
--讲课视频
-3.2 黑盒测试方法
--黑盒测试方法
-3.3 白盒测试方法
--基本概念
--代码覆盖标准
--基本路径测试
-3.4 单元测试工具
--单元测试工具
--html
-测验题--作业
-作业题
--第三章 作业题
--作业题附件
-4.1 软件过程
--讲课视频
-4.2 软件过程模型
--讲课视频
-4.3 敏捷开发过程
--讲课视频
-4.4 微软公司开发过程
--邹欣经理自我介绍
--微软开发过程之一
--微软开发过程之二
-测验题--作业
-5.1 团队组织与管理
--讲课视频
-5.2 项目沟通管理
--讲课视频
-5.3 软件项目计划
--讲课视频
-5.4 软件项目估算
--讲课视频
-测验题--作业
-讨论题
--讨论
-6.1 敏捷开发之Scrum
-- 敏捷开发之Scrum
--html
-6.2 用户故事与估算
--讲课视频
-6.3 团队协作工具Tower
-6.4 配置管理
--讲课视频
-6.5 配置管理工具Git
--讲课视频
-测验题--作业
-作业题--作业
-7.1 需求工程师
--讲课视频
-7.2 需求定义
--讲课视频
-7.3 需求的类型
--讲课视频
--讲课视频（2）
-7.4 需求工程过程
--讲课视频
-7.5 需求的主要来源
--讲课视频
-7.6 需求获取技术
--讲课视频
--讲课视频二
--讲课视频三
-7.7 撰写需求文档
--讲课视频
-测验题--作业
-讨论题
--讨论
-8.1 用例建模概念
--讲课视频
-8.2 用例建模过程
--讲课视频
-8.3 用例建模精讲
--讲课视频
-8.4 建模工具介绍
--讲课视频
-8.5 微信抢票应用案例
--讲课视频
-测验题--作业
-讨论题
--讨论
-9.1 面向对象分析
--讲课视频
-9.2 CRC卡片分拣法
--讲课视频-1
--讲课视频-2
-9.3 面向对象设计
--讲课视频-1
--讲课视频-2
-9.4 类图建模
--讲课视频-1
--讲课视频-2
-第9章 面向对象分析与设计--测验题
-讨论题
--讨论
-10.1 顺序图概念
--讲课视频
-10.2 顺序图建模
--讲课视频
-10.3 顺序图风格
--讲义视频
-10.4 状态建模
--讲课视频
-10.5 状态图
--讲课视频
-10.6 状态图精讲
--讲义视频
-测验题--作业
-讨论题
--讨论
-11.1 软件体系结构概念
--讲授视频
-11.2 软件设计原则
--讲授视频
-11.3 软件体系结构风格（一）
--讲授视频
-11.4 软件体系结构风格（二）
--讲授视频
-11.5 软件体系结构风格（三）
--讲授视频
-11.6 软件设计过程
--讲授视频
-11.7 Web系统架构设计
--讲授视频
-11.8 数据库选择策略
--讲授视频
-测验题--作业
-作业题
--html
--html
--html
-作业题--作业
-12.1 交互设计概述
--讲授视频
-12.2 交互设计目标
--讲授视频
-12.3 GUI设计原则
--讲课视频
-12.4 KLM效率模型
--Video
-12.5 Fitts定律
--讲授视频
-12.6 交互设计过程
--讲授视频
-测验题--作业
-13.1 软件测试概念
--讲课视频
-13.2 软件测试类型
--讲课视频
-13.3 软件功能测试
--讲课视频
-13.4 软件性能测试
--讲课视频
-测验题--作业
-14.1 软件部署与交付
--讲课视频
-14.2 软件演化与维护
--讲课视频
-测验题--作业
-第一部分：基础知识
-第二部分：编程与测试（选做）
