大规模项目中的管理问题

《大规模项目中的管理问题》由会员分享，可在线阅读，更多相关《大规模项目中的管理问题（42页珍藏版）》请在金锄头文库上搜索。

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

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

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

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

5、设计15%25%详细设计20%20%代码/调试25%15%单元测试15%5%集成测试15%20%系统测试10%15%大规模项目中的管理问题 大型项目面临的挑战 需要考虑的重点 项目组织 结构 角色 团队之间的沟通 源码控制 构造与集成 递减测试 用户管理考虑的重点 将大项目分解成许多独立的小项目 项目管理应该更多地被视为投入而不是 成本 充分利用任何生产效率提高的方法 (多人 的努力实现倍数增长) 工具,代码/设计的重用 环境 （开发, 测试)大规模项目中的管理问题 大型项目面临的挑战 需要考虑的重点 项目组织 结构 角色 团队之间的沟通 源码控制 构造与集成 递减测试 用户管理项目的组织例子

6、组织规划 主要的能力 / 特定化要基于结构 允许更多的并行活动 清楚地定义角色 / 职责 建立提意见的途径 确保每一个成员不走样地理解最终目标项目的组织例子组织中的角色 项目主管人员 组织项目的团队 作为项目和用户的最终决策者 做出商业上的决定 是主要的客户联系人 确保从用户方安排一个类似的联系人 说明成功或可接受的标准 避免严格的标准 期限 / 功能间的平衡 确认不存在一个毫无缺点的方案项目的组织例子组织中的角色 版本管理人员(Release Manager) 全面领导项目 管理项目经理团队和体系结构 / 技术团队 在项目中做出大多数的决定 更多关注质量和产品的交付 开发管理人员(Devel

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

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

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

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

11、 贯穿整个开发过程要定义频率和有效区域 必须使其自动化 对于代码的检入（check-in)要建立标准的检 测过程 对整个效率有很大的影响 对于打断“build”过程的后果要保持敏感构建和集成 构建 专注项目的最终目标:建立“改变控制”的阶 段 逐渐增加实施变化的难度 Establish a point towards end of project where the only changes permitted are those for fixing critical defects构建和集成大规模项目中的管理问题 大型项目面临的挑战 需要考虑的重点 项目组织 结构 角色 团队之间的沟通 源

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