- 如何管理团队？
- 在实验中采取了哪些办法？有哪些经验？
- 团队结构有哪⼏种？
- 质量保障有哪些措施？
- 结合实验进⾏说明
- 配置管理有哪些活动？
- 实验中是如何进⾏配置管理的？
团队管理
如何管理团队：
- 建⽴团队章程
- 持续成功
- 和谐沟通
- 避免团队杀⼿
团队结构
主程序员团队
独裁, 效率, 一致性
- 一名技术能力出色的成员被指定为主程序员, 负责领导团队完成任务
- 主程序员完成总体构思和设计, 然后分配任务给其他团队成员, 监督, 验收和整合其他成员的工作情况
适用:
- 完成项目有较大把握
- 时间要求较为紧迫
优点: 如果项目规模较小, 且主程序员能力非常突出, 能很好地独自规划和控制项目工作, 则团队能取得很高的工作效率, 可以最大限度保证产品不同元素的一致性
缺点: 如果项目复杂或主程序员的能力不符, 则主程序员会成为瓶颈
民主团队
民主, 交流, 能动性
没有集中的交流点, 项目经理负责管理, 围绕着项目的计划进行, 没有明确的技术领导.
优点: 每个成员都可以发挥自己的能动性, 能取得更高士气和成就感
缺点: 团队交流过多也有成本, 效率不如主程序员团队, 统一思想和解决冲突的代价较高
开放团队
黑箱, 创新, 不可视
为创新而存在, 使用黑箱管理, 团队内部交流路径对管理者不可见, 管理者无法掌握进展, 不能给定时间表.
优点: 团队自我管理, 激励主动性和创新性
缺点: 项目进展没有可视度.
质量保障措施(结合实验说明)
评审, 测试, 质量度量
评审
又叫同级评审, 是公认的质量保障最佳实践方法, 效果优于测试和质量度量
由作者之外的其他人来检查产品问题, 是静态分析手段
六阶段:
- 规划: 指定审查计划(会议次数, 时间, 人员, 审查内容等)
- 总体部署: 介绍目标, 分发文档(向所有参与审查会议的人员描述待审查材料的内容和审查的目标, 分发文档)
- 准备: 审查人员各自独立执行检查任务, 准备讨论
- 审查会议: 通过会议讨论, 识别, 确认, 分类发现的错误
- 返工: 修改发现的缺陷
- 跟踪: 确认发现的问题都被解决
系统化方法帮助: 检查清单
质量度量
产生自统计控制
测度: 为描述软件产品而提供的定量指标, 是对事实的直接反映
测量: 进行测度的活动
度量: 软件产品在特定属性上的量化测度程度
给软件产品或中间制品建立度量描述, 可以分析确定它们的质量.
配置管理(在实验中如何进行)
配置管理: 将软件开发的重要制品及其变更纳入管理和监控, 保证在不影响开发活动协同的情况下有效处理变更.
概念性的会考(两三分), 后面大头结合项目来考
少量概念, 大量实践
配置管理活动:
- 标识配置项: 确定有哪些配置项(需要进行配置管理的软件开发制品), 给配置项确定标识, 详细说明配置项的特征
- 版本管理: 为每一个刚纳入版本管理的配置项赋予一个初始的版本号, 发生变更时更新版本号. 更新时保留旧记录以便回退, 复杂项目中还要管理分支和多版本情况.
- 变更控制: 已经纳入配置管理的配置项发生变化时, 需要依据变更控制过程进行处理(以可控, 一致的方式进行变更处理,提请变更, 变更评估, 变更决策, 执行变更, 验证变更, 变更控制委员会)
- 配置审计: 确定一个项目满足需求的功能和物理特征的程度, 确保开发工作按照需求规格和设计特征进行, 验证配置项的完整性, 正确性, 一致性和可跟踪性
- 状态报告: 标识, 收集和维持演化中的配置状态的信息, 也就是对在动态演化的配置项信息及其度量取快照
- 软件发布管理: 将软件配置项发布到开发活动之外, 例如发布给客户(即创建和发布可用的产品), 具体工作是标识, 保证和交付产品的元素.
