大规模项目中的管理问题
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
了解未改变的代码的需要 考虑使 “部件” vs “特性” 所有者来改变代码
大型项目面临的挑战
• 可能包含新的技术或技术的转化
– 不断增加的功能, 性能及质量上的风险 在接受之前,好测试可移植性及可伸缩性 检测非功能性的特性 (例如: 异常处理) 对于提供者的各种申明保持怀疑
大型项目面临的挑战
• 可能包括多个场所的团队
具
大规模项目中的管理问题
• 大型项目面临的挑战 • 需要考虑的重点 • 项目组织
– 结构 – 角色
• 团队之间的沟通 • 源码控制 • 构造与集成 • 递减测试 • 用户管理
源码控制
• 在代码中可能有很高的重叠部分 • 若想有效地管理，源码控制工具是必不
可少的 • 在 “component-ownership” 和 “line-
• 宣布方法 • 定位团队目标
– 定期举行全体会议 (应该简单明了) – 明确分配职责 / 角色和 扩大沟通途径 – 经常确定里程碑并庆祝其完成
团队间的沟通
• 建立一个“ Team Rooms” (可以是实际的 或虚拟的)
– 信息资源共享
• 指导方向, 需求, 规范, 设计决定, 等等.
– 状态跟踪
大规模项目中的管理问题
• 大型项目面临的挑战 • 需要考虑的重点 • 项目组织
– 结构 – 角色 • 团队之间的沟通 • 源码控制 • 构造与集成 • 递减测试 • 用户管理
团队间的沟通
• 绝对需要 – 不论是正式的还是非正式的 文档和沟通
– 决定开发过程中，方向，记录并采纳（不断 重复）
– 开一个 “动员大会”
– 尽可能地早开始 – 一旦开始, 确定需求的优先级而不断地维护
它的稳定性
构建和集成
• 构建
– 贯穿整个开发过程要定义频率和有效区域 – 必须使其自动化 – 对于代码的检入（check-in)要建立标准的检
测过程 – 对整个效率有很大的影响 – 对于打断“build”过程的后果要保持敏感
构建和集成
• 开发管理人员(Development Managers) – 关注设计、代码和单元测试 – 对资源分配做出决断 – 对负责范围内的技术做出决策 – 具有组件所有者和条款所有者双重身份
项目的组织例子
组织中的角色
• 测试/质量保证管理人员
– 在项目中作为独立的“质量良心” 存在 – 负责质量规划和退出标准 – 应该和开发团队紧密配合以避免重复工作 – 避免开发团队之间的敌对关系
版本团队 (继续)
• 建立并采用 开发指南 — 包括项目中的程 序/过程和开发惯例/协议
• 强制实行相应开发指导方针和程序/过程 • 定位和解决低效率和瓶颈 • 推动团队间的沟通 • 管理其属下 • 负责处理意外 • 警戒: must not be permitted to become
the elitist group
大型项目面临的挑战
• 大量新的或需要修改的代码
– 500,000 + – 重叠的变化 – 代码的稳定性 实施严谨的源码控制 考虑 让“部件” vs “功能/特性” 的所有人来
改变代码 持续的递减测试
大型项目面临的挑战
• 新开发的项目 对比 修改大量已经存在的 代码
– 代码基础的退化(功能,性能) – 必须理解修改的代码 持续不断的递减测试 工作规模评估(Effort sizing)应该包括学习/
小项目
15% 20%
25% 15% 15% 10%
大项目
25% 20%
15% 5% 20% 15%
大规模项目中的管理问题
• 大型项目面临的挑战 • 需要考虑的重点 • 项目组织
– 结构 – 角色
• 团队之间的沟通 • 源码控制 • 构造与集成 • 递减测试 • 用户管理
考虑的重点
• 将大项目分解成许多独立的小项目
• 构建
– 专注项目的最终目标:建立“改变控制”的阶 段
– 逐渐增加实施变化的难度 – Establish a point towards end of project
where the only changes permitted are those for fixing critical defects
项目的组织例子
组织规划
• 主要的能力 / 特定化要基于结构 • 允许更多的并行活动 • 清楚地定义角色 / 职责 • 建立提意见的途径 • 确保每一个成员不走样地理解最终目标
项目的组织例子
组织中的角色
• 项目主管人员
– 组织项目的团队 – 作为项目和用户的最终决策者 – 做出商业上的决定 – 是主要的客户联系人
– 结构 – 角色
• 团队之间的沟通 • 资源控制 • 构造与集成 • 递减测试 • 用户管理
用户管理
• 用户常常坚持编码要尽快地开始 • PM的角色就是只有当需求明确之后再开始开
发
• 在大项目中首先要建造基础部分是至关重要的
• 原型可以与基础部分并行地开始，这样用户可 以看见进展
• 提供尽可能多的实用的Drivers – 演示进展 – 确认需求
– 需要清楚的、有效的、精确的沟通 – 不同时区、网络间的同步和沟通 – 信任 必须为每个开发地点安排本地的PM(项目经
理) 建立每日的检查机制和核查点 定期的交换视察
大型项目面临的挑战
• 值得注意的：更高的失败的可能性和更 大的失败的影响
如果可能, 将交付成果阶段化,避免最后“一 次全部或什么也没有”的结果
• 项目管理应该更多地被视为投入而不是 成本
• 充分利用任何生产效率提高的方法 (多人 的努力实现倍数增长)
– 工具,代码/设计的重用 – 环境 （开发, 测试)
大规模项目中的管理问题
• 大型项目面临的挑战 • 需要考虑的重点 • 项目组织
– 结构 – 角色
• 团队之间的沟通 • 源码控制 • 构造与集成 • 递减测试 • 用户管理
• 确保从用户方安排一个类似的联系人
– 说明成功或可接受的标准
• 避免严格的标准 • 期限 / 功能间的平衡 • 确认不存在一个毫无缺点的方案
项目的组织例子
组织中的角色
• 版本管理人员(Release Manager) – 全面领导项目 – 管理项目经理团队和体系结构 / 技术团队 – 在项目中做出大多数的决定 – 更多关注质量和产品的交付
严格的和不断的风险管理 保证所有“赌金拥有者”了解他们每一个部
件对项目的重要影响
大型项目面临的挑战
• 需求的收集:
– 如果想重复这步将是非常困难的 – 从用户不同的部门可能得到相互矛盾的需求 确保来自用户的在资源投入上的承 确定在用户单位中谁是最终说了算数的人 完善的、可接受的、文档化的需求是非常必
• 支持管理人员
– 提供有效的开发和测试环境 – 负责“构建”和相关的工具 – 负责源码控制 / 库文件
项目的组织例子
版本团队
• 是一个由对项目和技术有很深的理解的 人组成
– 一般由项目经理和技术负责人组成 – 必须要注重实效，避免官僚化 – 有很好地发现和确认实际问题的能力 – 在整个开发过程中要有丰富的经验 – 在项目的不同阶段人员关系可能有变化
须的
大型项目面临的挑战
• 项目大小和成就之间是一个非线形的关 系：
– 500,000行规模的项目付出的努力可能超过 50,000行规模的项目10倍多
在评估中要考虑一些在额外计划,沟通和从 属事件管理中的因素
通常, 虽然个人的生产力可能降低,但会在可 重用性和工具的改进上得到偿还
大型项目面临的挑战
大规模项目中的管理问 题
2021/7/11
大规模项目中的管理问题
• 大型项目面临的挑战 • 需要考虑的重点 • 项目组织
– 结构 – 角色
• 团队之间的沟通 • 源码控制 • 构造与集成 • 递减测试 • 用户管理
大型项目面临的挑战
• 大规模 (超过100人), 多个部门
– 很难找到足够的、有资格的人 – 可用的技能不一致 – 多数人不知道项目的整体 – 团队之间不能有效地沟通 – 用于培训的预算 （时间和金钱） – 减少技能的要求 – “伙伴”（可配对）系统 – 许多的文档 & “有组织的”沟通
• 在详细评估上的增加的难度
增加了依赖历史数据/平均值的需要 如果在内部得不到,就查查行业标准 记住认真记录各种真实数据以备未来之用
大型项目面临的挑战
• 工作分派的区别
增加前端 (结构/设计) 和后端 (集成/系统测 试)的工作
行为
结构/设计 详细设计
代码/调试 单元测试 集成测试 系统测试
工作分派的比较
假设情况（假想） • 在最小的情况下, 投资于自动套件 • 做为构建确认的一部分 • Subsets of this set becomes the “check-in”
regression test buckets • 这些子集应该容易并快速地运行, 否则将被人
们绕过
大规模项目中的管理问题
• 大型项目面临的挑战 • 需要考虑的重点 • 项目组织
大规模项目中的管理问题
• 大型项目面临的挑战 • 需要考虑的重点 • 项目组织
– 结构 – 角色
• 团队之间的沟通 • 源码控制 • 构造与集成 • 递减测试 （Regression Test) • 用户管理
递减测试
• 自动测试工具是基础,但整体测试套件很昂贵 • 定义可以基本覆盖这个“版本（release)”的各种
item-ownership”之间要进行平衡 • 自动构建连接
大规模项目中的管理问题
• 大型项目面临的挑战 • 需要考虑的重点 • 项目组织
– 结构 – 角色
• 团队之间的沟通 • 源码控制 • 构造与集成 • 递减测试 • 用户管理
构建和集成
• 集成
– 尽早规划, 从最后日期逆向计划并工作，是 必须的
• 发展, 构建, 过失等等的跟踪
– 所属人员的状态跟踪 – 可见度
• 全面规划，确定时间表 • 到沟通是缺省的前 提
• “版本团队（release team）”需要一个本 地代表
• 可能需要卫星式的开发和测试环境 • 找到或者搭建一个可以同步源码库的工
大型项目面临的挑战
• 可能包含新的技术或技术的转化
– 不断增加的功能, 性能及质量上的风险 在接受之前,好测试可移植性及可伸缩性 检测非功能性的特性 (例如: 异常处理) 对于提供者的各种申明保持怀疑
大型项目面临的挑战
• 可能包括多个场所的团队
具
大规模项目中的管理问题
• 大型项目面临的挑战 • 需要考虑的重点 • 项目组织
– 结构 – 角色
• 团队之间的沟通 • 源码控制 • 构造与集成 • 递减测试 • 用户管理
源码控制
• 在代码中可能有很高的重叠部分 • 若想有效地管理，源码控制工具是必不
可少的 • 在 “component-ownership” 和 “line-
• 宣布方法 • 定位团队目标
– 定期举行全体会议 (应该简单明了) – 明确分配职责 / 角色和 扩大沟通途径 – 经常确定里程碑并庆祝其完成
团队间的沟通
• 建立一个“ Team Rooms” (可以是实际的 或虚拟的)
– 信息资源共享
• 指导方向, 需求, 规范, 设计决定, 等等.
– 状态跟踪
大规模项目中的管理问题
• 大型项目面临的挑战 • 需要考虑的重点 • 项目组织
– 结构 – 角色 • 团队之间的沟通 • 源码控制 • 构造与集成 • 递减测试 • 用户管理
团队间的沟通
• 绝对需要 – 不论是正式的还是非正式的 文档和沟通
– 决定开发过程中，方向，记录并采纳（不断 重复）
– 开一个 “动员大会”
– 尽可能地早开始 – 一旦开始, 确定需求的优先级而不断地维护
它的稳定性
构建和集成
• 构建
– 贯穿整个开发过程要定义频率和有效区域 – 必须使其自动化 – 对于代码的检入（check-in)要建立标准的检
测过程 – 对整个效率有很大的影响 – 对于打断“build”过程的后果要保持敏感
构建和集成
• 开发管理人员(Development Managers) – 关注设计、代码和单元测试 – 对资源分配做出决断 – 对负责范围内的技术做出决策 – 具有组件所有者和条款所有者双重身份
项目的组织例子
组织中的角色
• 测试/质量保证管理人员
– 在项目中作为独立的“质量良心” 存在 – 负责质量规划和退出标准 – 应该和开发团队紧密配合以避免重复工作 – 避免开发团队之间的敌对关系
版本团队 (继续)
• 建立并采用 开发指南 — 包括项目中的程 序/过程和开发惯例/协议
• 强制实行相应开发指导方针和程序/过程 • 定位和解决低效率和瓶颈 • 推动团队间的沟通 • 管理其属下 • 负责处理意外 • 警戒: must not be permitted to become
the elitist group
大型项目面临的挑战
• 大量新的或需要修改的代码
– 500,000 + – 重叠的变化 – 代码的稳定性 实施严谨的源码控制 考虑 让“部件” vs “功能/特性” 的所有人来
改变代码 持续的递减测试
大型项目面临的挑战
• 新开发的项目 对比 修改大量已经存在的 代码
– 代码基础的退化(功能,性能) – 必须理解修改的代码 持续不断的递减测试 工作规模评估(Effort sizing)应该包括学习/
小项目
15% 20%
25% 15% 15% 10%
大项目
25% 20%
15% 5% 20% 15%
大规模项目中的管理问题
• 大型项目面临的挑战 • 需要考虑的重点 • 项目组织
– 结构 – 角色
• 团队之间的沟通 • 源码控制 • 构造与集成 • 递减测试 • 用户管理
考虑的重点
• 将大项目分解成许多独立的小项目
• 构建
– 专注项目的最终目标:建立“改变控制”的阶 段
– 逐渐增加实施变化的难度 – Establish a point towards end of project
where the only changes permitted are those for fixing critical defects
项目的组织例子
组织规划
• 主要的能力 / 特定化要基于结构 • 允许更多的并行活动 • 清楚地定义角色 / 职责 • 建立提意见的途径 • 确保每一个成员不走样地理解最终目标
项目的组织例子
组织中的角色
• 项目主管人员
– 组织项目的团队 – 作为项目和用户的最终决策者 – 做出商业上的决定 – 是主要的客户联系人
– 结构 – 角色
• 团队之间的沟通 • 资源控制 • 构造与集成 • 递减测试 • 用户管理
用户管理
• 用户常常坚持编码要尽快地开始 • PM的角色就是只有当需求明确之后再开始开
发
• 在大项目中首先要建造基础部分是至关重要的
• 原型可以与基础部分并行地开始，这样用户可 以看见进展
• 提供尽可能多的实用的Drivers – 演示进展 – 确认需求
– 需要清楚的、有效的、精确的沟通 – 不同时区、网络间的同步和沟通 – 信任 必须为每个开发地点安排本地的PM(项目经
理) 建立每日的检查机制和核查点 定期的交换视察
大型项目面临的挑战
• 值得注意的：更高的失败的可能性和更 大的失败的影响
如果可能, 将交付成果阶段化,避免最后“一 次全部或什么也没有”的结果
• 项目管理应该更多地被视为投入而不是 成本
• 充分利用任何生产效率提高的方法 (多人 的努力实现倍数增长)
– 工具,代码/设计的重用 – 环境 （开发, 测试)
大规模项目中的管理问题
• 大型项目面临的挑战 • 需要考虑的重点 • 项目组织
– 结构 – 角色
• 团队之间的沟通 • 源码控制 • 构造与集成 • 递减测试 • 用户管理
• 确保从用户方安排一个类似的联系人
– 说明成功或可接受的标准
• 避免严格的标准 • 期限 / 功能间的平衡 • 确认不存在一个毫无缺点的方案
项目的组织例子
组织中的角色
• 版本管理人员(Release Manager) – 全面领导项目 – 管理项目经理团队和体系结构 / 技术团队 – 在项目中做出大多数的决定 – 更多关注质量和产品的交付
严格的和不断的风险管理 保证所有“赌金拥有者”了解他们每一个部
件对项目的重要影响
大型项目面临的挑战
• 需求的收集:
– 如果想重复这步将是非常困难的 – 从用户不同的部门可能得到相互矛盾的需求 确保来自用户的在资源投入上的承 确定在用户单位中谁是最终说了算数的人 完善的、可接受的、文档化的需求是非常必
• 支持管理人员
– 提供有效的开发和测试环境 – 负责“构建”和相关的工具 – 负责源码控制 / 库文件
项目的组织例子
版本团队
• 是一个由对项目和技术有很深的理解的 人组成
– 一般由项目经理和技术负责人组成 – 必须要注重实效，避免官僚化 – 有很好地发现和确认实际问题的能力 – 在整个开发过程中要有丰富的经验 – 在项目的不同阶段人员关系可能有变化
须的
大型项目面临的挑战
• 项目大小和成就之间是一个非线形的关 系：
– 500,000行规模的项目付出的努力可能超过 50,000行规模的项目10倍多
在评估中要考虑一些在额外计划,沟通和从 属事件管理中的因素
通常, 虽然个人的生产力可能降低,但会在可 重用性和工具的改进上得到偿还
大型项目面临的挑战
大规模项目中的管理问 题
2021/7/11
大规模项目中的管理问题
• 大型项目面临的挑战 • 需要考虑的重点 • 项目组织
– 结构 – 角色
• 团队之间的沟通 • 源码控制 • 构造与集成 • 递减测试 • 用户管理
大型项目面临的挑战
• 大规模 (超过100人), 多个部门
– 很难找到足够的、有资格的人 – 可用的技能不一致 – 多数人不知道项目的整体 – 团队之间不能有效地沟通 – 用于培训的预算 （时间和金钱） – 减少技能的要求 – “伙伴”（可配对）系统 – 许多的文档 & “有组织的”沟通
• 在详细评估上的增加的难度
增加了依赖历史数据/平均值的需要 如果在内部得不到,就查查行业标准 记住认真记录各种真实数据以备未来之用
大型项目面临的挑战
• 工作分派的区别
增加前端 (结构/设计) 和后端 (集成/系统测 试)的工作
行为
结构/设计 详细设计
代码/调试 单元测试 集成测试 系统测试
工作分派的比较
假设情况（假想） • 在最小的情况下, 投资于自动套件 • 做为构建确认的一部分 • Subsets of this set becomes the “check-in”
regression test buckets • 这些子集应该容易并快速地运行, 否则将被人
们绕过
大规模项目中的管理问题
• 大型项目面临的挑战 • 需要考虑的重点 • 项目组织
大规模项目中的管理问题
• 大型项目面临的挑战 • 需要考虑的重点 • 项目组织
– 结构 – 角色
• 团队之间的沟通 • 源码控制 • 构造与集成 • 递减测试 （Regression Test) • 用户管理
递减测试
• 自动测试工具是基础,但整体测试套件很昂贵 • 定义可以基本覆盖这个“版本（release)”的各种
item-ownership”之间要进行平衡 • 自动构建连接
大规模项目中的管理问题
• 大型项目面临的挑战 • 需要考虑的重点 • 项目组织
– 结构 – 角色
• 团队之间的沟通 • 源码控制 • 构造与集成 • 递减测试 • 用户管理
构建和集成
• 集成
– 尽早规划, 从最后日期逆向计划并工作，是 必须的
• 发展, 构建, 过失等等的跟踪
– 所属人员的状态跟踪 – 可见度
• 全面规划，确定时间表 • 到沟通是缺省的前 提
• “版本团队（release team）”需要一个本 地代表
• 可能需要卫星式的开发和测试环境 • 找到或者搭建一个可以同步源码库的工