大规模项目中的管理问题

大规模项目中的管理问题 Jo Hardjasa hardjasa@ca.ibm.com Centre of e-business Innovation ::Vancouver IBM Pacific Development Centre

大规模项目中的管理问题 • 大型项目面临的挑战 • 需要考虑的重点 • 项目组织 • 结构 • 角色 • 团队之间的沟通 • 源码控制 • 构造与集成 • 递减测试 • 用户管理

大型项目面临的挑战 • 大规模 (超过100人), 多个部门 • 很难找到足够的、有资格的人 • 可用的技能不一致 • 多数人不知道项目的整体 • 团队之间不能有效地沟通 • 用于培训的预算（时间和金钱） • 减少技能的要求 • “伙伴”（可配对）系统 • 许多的文档 & “有组织的”沟通

大型项目面临的挑战 • 大量新的或需要修改的代码 • 500,000 + • 重叠的变化 • 代码的稳定性 • 实施严谨的源码控制 • 考虑让“部件” vs “功能/特性” 的所有人来改变代码 • 持续的递减测试

大型项目面临的挑战 • 新开发的项目对比修改大量已经存在的代码 • 代码基础的退化(功能,性能) • 必须理解修改的代码 • 持续不断的递减测试 • 工作规模评估(Effort sizing)应该包括学习/了解未改变的代码的需要 • 考虑使 “部件” vs “特性” 所有者来改变代码

大型项目面临的挑战 • 可能包含新的技术或技术的转化 • 不断增加的功能, 性能及质量上的风险 • 在接受之前,好测试可移植性及可伸缩性 • 检测非功能性的特性 (例如:异常处理) • 对于提供者的各种申明保持怀疑

大型项目面临的挑战 • 可能包括多个场所的团队 • 需要清楚的、有效的、精确的沟通 • 不同时区、网络间的同步和沟通 • 信任 • 必须为每个开发地点安排本地的PM(项目经理) • 建立每日的检查机制和核查点 • 定期的交换视察

大型项目面临的挑战 • 值得注意的：更高的失败的可能性和更大的失败的影响 • 如果可能, 将交付成果阶段化,避免最后“一次全部或什么也没有”的结果 • 严格的和不断的风险管理 • 保证所有“赌金拥有者”了解他们每一个部件对项目的重要影响

大型项目面临的挑战 • 需求的收集: • 如果想重复这步将是非常困难的 • 从用户不同的部门可能得到相互矛盾的需求 • 确保来自用户的在资源投入上的承 • 确定在用户单位中谁是最终说了算数的人 • 完善的、可接受的、文档化的需求是非常必须的

大型项目面临的挑战 • 项目大小和成就之间是一个非线形的关系： • 500,000行规模的项目付出的努力可能超过50,000行规模的项目10倍多 • 在评估中要考虑一些在额外计划,沟通和从属事件管理中的因素 • 通常, 虽然个人的生产力可能降低,但会在可重用性和工具的改进上得到偿还

大型项目面临的挑战 • 在详细评估上的增加的难度 • 增加了依赖历史数据/平均值的需要 • 如果在内部得不到,就查查行业标准 • 记住认真记录各种真实数据以备未来之用

大型项目面临的挑战 • 工作分派的区别 增加前端 (结构/设计) 和后端 (集成/系统测试)的工作

工作分派的比较

考虑的重点 • 将大项目分解成许多独立的小项目 • 项目管理应该更多地被视为投入而不是成本 • 充分利用任何生产效率提高的方法 (多人的努力实现倍数增长) • 工具,代码/设计的重用 • 环境（开发, 测试)

项目的组织例子

组织规划 • 主要的能力 / 特定化要基于结构 • 允许更多的并行活动 • 清楚地定义角色 / 职责 • 建立提意见的途径 • 确保每一个成员不走样地理解最终目标

组织中的角色 • 项目主管人员 • 组织项目的团队 • 作为项目和用户的最终决策者 • 做出商业上的决定 • 是主要的客户联系人 • 确保从用户方安排一个类似的联系人 • 说明成功或可接受的标准 • 避免严格的标准 • 期限 / 功能间的平衡 • 确认不存在一个毫无缺点的方案

组织中的角色 • 版本管理人员(Release Manager) • 全面领导项目 • 管理项目经理团队和体系结构 / 技术团队 • 在项目中做出大多数的决定 • 更多关注质量和产品的交付 • 开发管理人员(Development Managers) • 关注设计、代码和单元测试 • 对资源分配做出决断 • 对负责范围内的技术做出决策 • 具有组件所有者和条款所有者双重身份

组织中的角色 • 测试/质量保证管理人员 • 在项目中作为独立的“质量良心” 存在 • 负责质量规划和退出标准 • 应该和开发团队紧密配合以避免重复工作 • 避免开发团队之间的敌对关系 • 支持管理人员 • 提供有效的开发和测试环境 • 负责“构建”和相关的工具 • 负责源码控制 / 库文件

版本团队 • 是一个由对项目和技术有很深的理解的人组成 • 一般由项目经理和技术负责人组成 • 必须要注重实效，避免官僚化 • 有很好地发现和确认实际问题的能力 • 在整个开发过程中要有丰富的经验 • 在项目的不同阶段人员关系可能有变化

版本团队 (继续) • 建立并采用开发指南 —包括项目中的程序/过程和开发惯例/协议 • 强制实行相应开发指导方针和程序/过程 • 定位和解决低效率和瓶颈 • 推动团队间的沟通 • 管理其属下 • 负责处理意外 • 警戒: must not be permitted to become the elitist group

团队间的沟通 • 绝对需要 – 不论是正式的还是非正式的文档和沟通 • 决定开发过程中，方向，记录并采纳（不断重复） • 开一个 “动员大会” • 宣布方法 • 定位团队目标 • 定期举行全体会议 (应该简单明了) • 明确分配职责 / 角色和扩大沟通途径 • 经常确定里程碑并庆祝其完成

团队间的沟通 • 建立一个“ Team Rooms” (可以是实际的或虚拟的) • 信息资源共享 • 指导方向, 需求, 规范, 设计决定, 等等. • 状态跟踪 • 发展, 构建, 过失等等的跟踪 • 所属人员的状态跟踪 • 可见度 • 全面规划，确定时间表 • 到达的目的（里程碑）

多场所的开发 • 清楚地, 明确地、有效地沟通是缺省的前提 • “版本团队（release team）”需要一个本地代表 • 可能需要卫星式的开发和测试环境 • 找到或者搭建一个可以同步源码库的工具

源码控制 • 在代码中可能有很高的重叠部分 • 若想有效地管理，源码控制工具是必不可少的 • 在 “component-ownership” 和 “line-item-ownership”之间要进行平衡 • 自动构建连接

构建和集成 • 集成 • 尽早规划, 从最后日期逆向计划并工作，是必须的 • 尽可能地早开始 • 一旦开始, 确定需求的优先级而不断地维护它的稳定性

构建和集成 • 构建 • 贯穿整个开发过程要定义频率和有效区域 • 必须使其自动化 • 对于代码的检入（check-in)要建立标准的检测过程 • 对整个效率有很大的影响 • 对于打断“build”过程的后果要保持敏感

构建和集成 • 构建 • 专注项目的最终目标:建立“改变控制”的阶段 • 逐渐增加实施变化的难度 • Establish a point towards end of project where the only changes permitted are those for fixing critical defects

大规模项目中的管理问题 • 大型项目面临的挑战 • 需要考虑的重点 • 项目组织 • 结构 • 角色 • 团队之间的沟通 • 源码控制 • 构造与集成 • 递减测试（Regression Test) • 用户管理

递减测试 • 自动测试工具是基础,但整体测试套件很昂贵 • 定义可以基本覆盖这个“版本（release)”的各种假设情况（假想） • 在最小的情况下, 投资于自动套件 • 做为构建确认的一部分 • Subsets of this set becomes the “check-in” regression test buckets • 这些子集应该容易并快速地运行, 否则将被人们绕过

大规模项目中的管理问题 • 大型项目面临的挑战 • 需要考虑的重点 • 项目组织 • 结构 • 角色 • 团队之间的沟通 • 资源控制 • 构造与集成 • 递减测试 • 用户管理

用户管理 • 用户常常坚持编码要尽快地开始 • PM的角色就是只有当需求明确之后再开始开发 • 在大项目中首先要建造基础部分是至关重要的 • 原型可以与基础部分并行地开始，这样用户可以看见进展 • 提供尽可能多的实用的Drivers • 演示进展 • 确认需求

总结 • 最重要的是规划，并应贯穿整个项目  本能性的动手必将导致失败 • 沟通，沟通，还是沟通 • 沟通是大型项目成败的最关键因素 • 投资正在那些定义正确的另外的投入的一些团队 • Remember the leverage factor • 保持团队的士气 • 演示项目的进展 • 庆祝成果/完工!

大规模项目中的管理问题

大规模项目中的管理问题

Presentation Transcript