敏捷软件开发管理实践-(三)-—尽可能并行工作

第三部分第三部分 尽可能并行工作尽可能并行工作 1 1 各种角色可以协同工作 敏捷的特征就是要是使工作更加高效 很少有公司仔细考虑过项目成员在工作流程上 的优化可以为项目提高多大的工作效率 但是 只要我们想一想 项目中的每个成员其实 都是一颗能够独立计算并完成任务的 CPU 那么我们是否会像 IBM 的网格计算专家一样 去不断优化这些 CPU 的工作流程以达到一个新的世界记录呢 千万不要认为必须完成所有的需求后才能够开始开发 完成开发后才能开始测试 软 件管理者应该要非常清楚 所有的项目成员都是可供利用的 CPU 资源 无论在项目的任何 阶段 你都不应该让这些 CPU 资源过分闲置 项目的工作推进要想 CPU 的流水线一样 不要形成顺序流程 而要尽可能并发开展 这样才能最大限度利用资源 需求分析还在进行 开发人员干什么呢 设计还在进行 需求人员可以干什么呢 测试人员又可以干什么呢 作者不是善于剥削劳动力的资本家 问这些问题是为了启发大家明白 人力资源 是 非常富有弹性的东西 很多时候感觉 资源不足够 并不是真正的不足够 而要问问自己 是否让资源充分发挥了价值 下面这张表是作者提供给大家参考的一个敏捷工作计划 在这个计划里 作者要强调 几点 1 软件项目中存在很多隐性的工作 要尽量在项目立项的时候就考虑到 并排入计划 比如培训 制定规范 组织公用工具开发等 2 清晰的角色划分 尽量明确每个人的工作职责 会使整个团队工作得更积极 有序 3 不要忽略了协调的层次 项目组内 部门内 跨部门都需要良好的沟通渠道和协调资 源 阶段 角色需求师 人机工程 师 架构师 设计师开发工程师测试工程师 需求调研 与客户沟通 编写用例和 需求规格说明 功能需求 非功能需求 培训 业务 背景 组织需求评 审 架构设计 与需求师 确认需求 构造原型 培训 工 具使用指南 编码规范 环境搭建 调试指南 性能问题处 理 组织公用 工具开发 参与需求 评审 安装并熟 悉工具 了解业务 背景 培训和学 习 开发公用 工具 参与需求 评审 列写测试 计划 编写测试 用例 分析 设计 持续确认需 求 细化功能清 架构设计 精化 模块概要 参与设计 评审 编写针对 细化测试 用例 准备测试 单 细化逻辑检 查清单 界面需求 参与设计评 审 和详细设计 编写接口 文档 编写性能 测试计划和 性能保障计 划 组织设计 评审 接口的单 元测试 环境 实现 测试 持续确认需 求 检查功能实 现 检查界面规 范 代码走查 代码结构 接口 异常 处理 性能 瓶颈 难点公关 微观性能 测试 编码实现 对照逻辑 检查清单 编写单元 测试 修改 bug 参与技能 培训 功能测试 宏观性能 测试 集成测试 1 2 始终做最该做的 让整个团队都可以尽可能地并行工作 这看起来似乎非常理想 但是要在项目管理实践中 做到这一点 并不容易 需要整个团队有统一的价值观 并遵从一个工作原则 那就是 始终做最该做的 这里的 始终做最该做的始终做最该做的 原则包括 1 依赖项优先依赖项优先 2 接口优先接口优先 3 关键路径优先关键路径优先 4 广度优先广度优先 1 1 1 依赖项优先依赖项优先 大家都知道 并行工作的关键就是要让每个任务处理尽可能没有依赖 这样每个任务 就可以单独进行下去 但是 任务之间往往不可避免存在各种依赖项 依赖项使任务的执 行变成了串行 在项目中 每个人每天的任务往往很多 这些任务中有些是独立的 早点完成还是晚 些完成对别人没有影响 有些任务是被依赖的 如果自己不完成 他人也就不能完成 依 赖项优先的原则就是要求整个团队的各成员树立一个意识 始终优先解决他人对自己的依 赖项 一个这样做 还看不出效果 但是如果整个团队都能真正奉行这一原则并落到执行 的实处 那么整个团队的协调工作量就会大为减少 整个团队也就会持续保持在较高的工 作效率状态 案例 测试人员 A 等着需求人员 B 为其提供一个功能检查清单 f 才好对某个模块进行 有效测试 那么 f 是 A 对 B 的一个依赖项 如果 B 手头的其他事都只影响自己的工作 这是时候需求人员 B 应该优先完成 f 以免测试人员 A 无法进行自己的工作 这里也有另外一个问题值得一提 那就是 每个人有应该清楚 如果自己的工作发生 了依赖项 除了协调对方尽快去解决外依赖项外 还应该明白 自己绝对不应该就这么干 巴巴等着 而应该切换去处理其他工作 一旦依赖项被解除 再切换回原来的工作 1 1 2 接口优先接口优先 尽管 接口 一词让面向对象的程序员理解起来更为容易 但是这里把这个概念推广 接口 用来表达两个部分组合到一起的交接部件 可能是代码 也可能是文档 接口优先的原则就是强调要优先把双方的依赖项明确下来 并尽可能使之稳定 有了 接口 双方遵从接口即可并行工作 接口优先是依赖项优先的特殊形式 接口优先要求 A 尽早定接口 B 谨慎定接口 提供方和使用方共同确定接口 并要求接口评审 C 接口变更要受控 从实际项目中看来 围绕接口制定太晚 而导致返工的现象十分突出 一个典型的场 景就是等到项目集成了才发现接口并不符合需要 而这个时候修改接口往往伤筋动骨 重 构的代价很大 另外 就是制定接口需要很丰富的经验 要充分考虑到接口将来存在的变更可能 可 是实际项目中经常看到的一个现象是 接口的使用方往往一开始并不关心接口的具体细节 接口由提供方自行制定 而到了集成阶段 接口的使用方才提出接口无法满足自己的需要 并要求接口提供方进行变更 大家应该非常清楚 这个时候的接口变更不仅要求接口提供 方修改内部逻辑代码 更大的隐患是牵一而动全身 一个接口的变更会引起所有接口使用 者的代码调整 作者比较建议推行 接口评审 制度 评审会上必须要求接口的制定方和使用方共同 派代表参与 明确接口的需求和形式 这样做往往能够形成好的气氛 第一 接口的使用方参与了接口的评审 有助于他仔细考虑自己的需求是否能够满足 第二 接口的形式是经过使用方评审的 使用方要为日后接口的变更负责任 这样可 以促使接口的使用方提前充分理清自己的需求 第三 双方见面进行沟通 明确了相关人 便于日后工作中的协调处理 1 1 3 关键路径优先关键路径优先 学过图论的读者都知道关键路径的概念 项目管理理论也告诉我们 关键路径上的任 何活动的推迟将使整个项目推迟 关键路径要求 1 项目管理团队需要清楚项目的哪些工作是关键路径 2 项目管理团队要制定可行的计划保证这些关键路径的完成 1 1 4 广度优先广度优先 广度优先也是图论中的一个概念 表示在树搜索的时候优先从广度上处理 这里沿 引过来表示始终要要优先分解任务 而不是处理任务 考虑整个团队任务的并行处理效率 如果说任务 A 可以如下图分解为子任务 A1 A2 A3 并且子任务 A1 可能继续分解为子任务 A11 A12 团队中的每个成员应该这样处理 第一 考虑把任务 A 分解为几个子任务 A1 A2 A3 第二 考虑如何处理任务 A1 发现 A1 可以分解为两个子任务 A11 A12 OK 这个时候 不要钻进去处理 A11 或者 A12 而是处理 A2 发现 A2 只需要处理子任务 A21 接下来去 处理 A3 把 A3 分解为 A31 和 A32 第三 这个时候可以处理 A11 了 处理完 A11 就处理 A12 玩了在处理 A21 等等 为什么要这样做