大规模项目中的管理问题.ppt

《大规模项目中的管理问题.ppt》由会员分享，可在线阅读，更多相关《大规模项目中的管理问题.ppt（42页珍藏版）》请在装配图网上搜索。

1、大规模项目中的管理问题,Centre of e-business Innovation :Vancouver IBM Pacific Development Centre,Jo Hardjasa ,大规模项目中的管理问题,大型项目面临的挑战 需要考虑的重点 项目组织 结构 角色 团队之间的沟通 源码控制 构造与集成 递减测试 用户管理,大型项目面临的挑战,大规模 (超过100人), 多个部门 很难找到足够的、有资格的人 可用的技能不一致 多数人不知道项目的整体 团队之间不能有效地沟通 用于培训的预算 （时间和金钱） 减少技能的要求 “伙伴”（可配对）系统 许多的文档 & “有组织的”沟通,大型

2、项目面临的挑战,大量新的或需要修改的代码 500,000 + 重叠的变化 代码的稳定性 实施严谨的源码控制 考虑 让“部件” vs “功能/特性” 的所有人来改变代码 持续的递减测试,大型项目面临的挑战,新开发的项目 对比 修改大量已经存在的代码 代码基础的退化(功能,性能) 必须理解修改的代码 持续不断的递减测试 工作规模评估(Effort sizing)应该包括学习/了解未改变的代码的需要 考虑使 “部件” vs “特性” 所有者来改变代码,大型项目面临的挑战,可能包含新的技术或技术的转化 不断增加的功能, 性能及质量上的风险 在接受之前,好测试可移植性及可伸缩性 检测非功能性的特性 (例

3、如: 异常处理) 对于提供者的各种申明保持怀疑,大型项目面临的挑战,可能包括多个场所的团队 需要清楚的、有效的、精确的沟通 不同时区、网络间的同步和沟通 信任 必须为每个开发地点安排本地的PM(项目经理) 建立每日的检查机制和核查点 定期的交换视察,大型项目面临的挑战,值得注意的：更高的失败的可能性和更大的失败的影响 如果可能, 将交付成果阶段化,避免最后“一次全部或什么也没有”的结果 严格的和不断的风险管理 保证所有“赌金拥有者”了解他们每一个部件对项目的重要影响,需求的收集: 如果想重复这步将是非常困难的 从用户不同的部门可能得到相互矛盾的需求 确保来自用户的在资源投入上的承 确定在用户单

4、位中谁是最终说了算数的人 完善的、可接受的、文档化的需求是非常必须的,大型项目面临的挑战,大型项目面临的挑战,项目大小和成就之间是一个非线形的关系： 500,000行规模的项目付出的努力可能超过50,000行规模的项目10倍多 在评估中要考虑一些在额外计划,沟通和从属事件管理中的因素 通常, 虽然个人的生产力可能降低,但会在可重用性和工具的改进上得到偿还,大型项目面临的挑战,在详细评估上的增加的难度 增加了依赖历史数据/平均值的需要 如果在内部得不到,就查查行业标准 记住认真记录各种真实数据以备未来之用,大型项目面临的挑战,工作分派的区别 增加前端 (结构/设计) 和后端 (集成/系统测试)的

5、工作,工作分派的比较,大规模项目中的管理问题,大型项目面临的挑战 需要考虑的重点 项目组织 结构 角色 团队之间的沟通 源码控制 构造与集成 递减测试 用户管理,考虑的重点,将大项目分解成许多独立的小项目 项目管理应该更多地被视为投入而不是成本 充分利用任何生产效率提高的方法 (多人的努力实现倍数增长) 工具,代码/设计的重用 环境 （开发, 测试),大规模项目中的管理问题,大型项目面临的挑战 需要考虑的重点 项目组织 结构 角色 团队之间的沟通 源码控制 构造与集成 递减测试 用户管理,项目的组织例子,组织规划,主要的能力 / 特定化要基于结构 允许更多的并行活动 清楚地定义角色 / 职责

6、建立提意见的途径 确保每一个成员不走样地理解最终目标,项目的组织例子,组织中的角色,项目主管人员 组织项目的团队 作为项目和用户的最终决策者 做出商业上的决定 是主要的客户联系人 确保从用户方安排一个类似的联系人 说明成功或可接受的标准 避免严格的标准 期限 / 功能间的平衡 确认不存在一个毫无缺点的方案,项目的组织例子,组织中的角色,版本管理人员(Release Manager) 全面领导项目 管理项目经理团队和体系结构 / 技术团队 在项目中做出大多数的决定 更多关注质量和产品的交付 开发管理人员(Development Managers) 关注设计、代码和单元测试 对资源分配做出决断 对

7、负责范围内的技术做出决策 具有组件所有者和条款所有者双重身份,项目的组织例子,组织中的角色,测试/质量保证管理人员 在项目中作为独立的“质量良心” 存在 负责质量规划和退出标准 应该和开发团队紧密配合以避免重复工作 避免开发团队之间的敌对关系 支持管理人员 提供有效的开发和测试环境 负责“构建”和相关的工具 负责源码控制 / 库文件,项目的组织例子,是一个由对项目和技术有很深的理解的人组成 一般由项目经理和技术负责人组成 必须要注重实效，避免官僚化 有很好地发现和确认实际问题的能力 在整个开发过程中要有丰富的经验 在项目的不同阶段人员关系可能有变化,版本团队,建立并采用 开发指南 包括项目中的

8、程序/过程和开发惯例/协议 强制实行相应开发指导方针和程序/过程 定位和解决低效率和瓶颈 推动团队间的沟通 管理其属下 负责处理意外 警戒: must not be permitted to become the elitist group,版本团队 (继续),大规模项目中的管理问题,大型项目面临的挑战 需要考虑的重点 项目组织 结构 角色 团队之间的沟通 源码控制 构造与集成 递减测试 用户管理,绝对需要 不论是正式的还是非正式的文档和沟通 决定开发过程中，方向，记录并采纳（不断重复） 开一个 “动员大会” 宣布方法 定位团队目标 定期举行全体会议 (应该简单明了) 明确分配职责 / 角色和

9、 扩大沟通途径 经常确定里程碑并庆祝其完成,团队间的沟通,建立一个“ Team Rooms” (可以是实际的或虚拟的) 信息资源共享 指导方向, 需求, 规范, 设计决定, 等等. 状态跟踪 发展, 构建, 过失等等的跟踪 所属人员的状态跟踪 可见度 全面规划，确定时间表 到达的目的 （里程碑）,团队间的沟通,清楚地, 明确地、有效地沟通是缺省的前提 “版本团队（release team）”需要一个本地代表 可能需要卫星式的开发和测试环境 找到或者搭建一个可以同步源码库的工具,多场所的开发,大规模项目中的管理问题,大型项目面临的挑战 需要考虑的重点 项目组织 结构 角色 团队之间的沟通 源码控

10、制 构造与集成 递减测试 用户管理,在代码中可能有很高的重叠部分 若想有效地管理，源码控制工具是必不可少的 在 “component-ownership” 和 “line-item-ownership”之间要进行平衡 自动构建连接,源码控制,大规模项目中的管理问题,大型项目面临的挑战 需要考虑的重点 项目组织 结构 角色 团队之间的沟通 源码控制 构造与集成 递减测试 用户管理,集成 尽早规划, 从最后日期逆向计划并工作，是必须的 尽可能地早开始 一旦开始, 确定需求的优先级而不断地维护它的稳定性,构建和集成,构建 贯穿整个开发过程要定义频率和有效区域 必须使其自动化 对于代码的检入（chec

11、k-in)要建立标准的检测过程 对整个效率有很大的影响 对于打断“build”过程的后果要保持敏感,构建和集成,构建 专注项目的最终目标:建立“改变控制”的阶段 逐渐增加实施变化的难度 Establish a point towards end of project where the only changes permitted are those for fixing critical defects,构建和集成,大规模项目中的管理问题,大型项目面临的挑战 需要考虑的重点 项目组织 结构 角色 团队之间的沟通 源码控制 构造与集成 递减测试 （Regression Test) 用户管理,递

12、减测试,自动测试工具是基础,但整体测试套件很昂贵 定义可以基本覆盖这个“版本（release)”的各种假设情况（假想） 在最小的情况下, 投资于自动套件 做为构建确认的一部分 Subsets of this set becomes the “check-in” regression test buckets 这些子集应该容易并快速地运行, 否则将被人们绕过,大规模项目中的管理问题,大型项目面临的挑战 需要考虑的重点 项目组织 结构 角色 团队之间的沟通 资源控制 构造与集成 递减测试 用户管理,用户管理,用户常常坚持编码要尽快地开始 PM的角色就是只有当需求明确之后再开始开发 在大项目中首先要建造基础部分是至关重要的 原型可以与基础部分并行地开始，这样用户可以看见进展 提供尽可能多的实用的Drivers 演示进展 确认需求,总结,最重要的是规划，并应贯穿整个项目 本能性的动手必将导致失败 沟通，沟通，还是沟通 沟通是大型项目成败的最关键因素 投资正在那些定义正确的另外的投入的一些团队 Remember the leverage factor 保持团队的士气 演示项目的进展 庆祝成果/完工!,