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

1、第三局部尽可能并行工作1.1.各种角色可以协同工作敏捷的特征就是要是使工作更加高效。很少有公司仔细考虑过工程成员在工作流程上的优化可以为工程提高多大的工作效率。但是，只要我们想一想，工程中的每个成员其实都是一颗能够独立计算并完成任务的CPU，那么我们是否会像IBM的网格计算专家一样去不断优化这些CPU的工作流程以到达一个新的世界记录呢？千万不要认为必须完成所有的需求后才能够开场开发，完成开发后才能开场测试。软件管理者应该要非常清楚，所有的工程成员都是可供利用的CPU资源，无论在工程的任何阶段，你都不应该让这些 CPU资源过分闲置。工程的工作推进要想 CPU的流水线一样，不要形成顺序流程，而要尽

2、可能并发开展，这样才能最大限度利用资源。需求分析还在进展，开发人员干什么呢？设计还在进展，需求人员可以干什么呢？测试人员又可以干什么呢？作者不是善于剥削劳动力的资本家，问这些问题是为了启发大家明白“人力资源是非常富有弹性的东西， 很多时候感觉“资源缺乏够"并不是真正的缺乏够，而要问问自己“是否让资源充分发挥了价值。下面这张表是作者提供应大家参考的一个敏捷工作方案。在这个方案里，作者要强调几占：八、1 软件工程中存在很多隐性的工作，要尽量在工程立项的时候就考虑到，并排入方案。 比方培训，制定标准，组织公用工具开发等2 清晰的角色划分，尽量明确每个人的工作职责，会使整个团队工作得更积极、

3、有序。3 不要忽略了协调的层次，工程组内，部门内，跨部门都需要良好的沟通渠道和协调资 源。'阶段、.角色需求师/人机工程 师架构师/设计师开发工程师测试工程师需求调研与客户沟通 编写用例和需 求规格说明功能需求、 非功能需求 培训业务背 景组织需求评审架构设计 与需求师 确认需求构造原型 培训工具 使用指南、 编码标准、 环境搭建、 调试指南、 性能问题处 理组织公用 工具开发参与需求 评审安装并熟 悉工具了解业务 背景培训和学 习开发公用 工具参与需求评审列写测试 方案编写测试用例分析/设计持续确认需求 细化功能清单 细化逻辑检查架构设计 精化模块概要参与设计 评审编写针对细化测试

4、用例准备测试清单界面需求参与设计评审和详细设计编写接口 文档编写性能 测试方案和 性能保障方 案组织设计 评审接口的单元测试环境实现/测试持续确认需求检查功能实现检查界面标准代码走查代码构 造、接口、 异常处理、 性能瓶颈 难点公关 微观性能 测试编码实现 对照逻辑 检查清单 编写单元 测试修改bug 参与技能 培训功能测试 宏观性能 测试集成测试1.2.始终做最该做的让整个团队都可以尽可能地并行工作，这看起来似乎非常理想。但是要在工程管理实践中做到这一点，并不容易，需要整个团队有统一的价值观，并遵从一个工作原那么，那就是“始 终做最该做的"。这里的“始终做最该做的"原那么

5、包括：1依赖项优先2接口优先3关键路径优先4广度优先.依赖项优先大家都知道，并行工作的关键就是要让每个任务处理尽可能没有依赖， 这样每个任务就 可以单独进展下去。 但是，任务之间往往不可防止存在各种依赖项， 依赖项使任务的执行变 成了串行。在工程中，每个人每天的任务往往很多， 这些任务中有些是独立的， 早点完成还是晚些 完成对别人没有影响。有些任务是被依赖的，如果自己不完成，他人也就不能完成。依赖项优先的原那么就是要求整个团队的各成员树立一个意识：始终优先解决他人对自己的依赖 项。一个这样做，还看不出效果；但是如果整个团队都能真正奉行这一原那么并落到执行的 实处，那么整个团队的协调工作量就会大

6、为减少，整个团队也就会持续保持在较高的工作效率状态。案例：测试人员 A等着需求人员B为其提供一个功能检查清单 f才好对某个模块进展 有效测试。那么f是A对B的一个依赖项。如果 B手头的其他事都只影响自己的工作，这 是时候需求人员 B应该优先完成f，以免测试人员 A无法进展自己的工作。这里也有另外一个问题值得一提， 那就是， 每个人有应该清楚， 如果自己的工作发生了 依赖项， 除了协调对方尽快去解决外依赖项外， 还应该明白， 自己绝对不应该就这么干巴巴 等着。而应该切换去处理其他工作，一旦依赖项被解除，再切换回原来的工作。.接口优先尽管“接口一词让面向对象的程序员理解起来更为容易，但是这里把这个

7、概念推广。 “接口用来表达两个局部组合到一起的交接部件，可能是代码，也可能是文档。接口优先的原那么就是强调要优先把双方的依赖项明确下来， 并尽可能使之稳定。 有了 接口，双方遵从接口即可并行工作。接口优先是依赖项优先的特殊形式。接口优先要求：A 尽早定接口B 慎重定接口，提供方和使用方共同确定接口，并要求接口评审C 接口变更要受控从实际工程中看来， 围绕接口制定太晚， 就是等到工程集成了才发现接口并不符合需要， 代价很大。而导致返工的现象十分突出。 一个典型的场景而这个时候修改接口往往伤筋动骨， 重构的另外， 就是制定接口需要很丰富的经历， 要充分考虑到接口将来存在的变更可能。 可是 实际工程

8、中经常看到的一个现象是： 接口的使用方往往一开场并不关心接口的具体细节，接口由提供方自行制定， 而到了集成阶段， 接口的使用方才提出接口无法满足自己的需要，并要求接口提供方进展变更。 大家应该非常清楚， 这个时候的接口变更不仅要求接口提供方修 改内部逻辑代码， 更大的隐患是牵一而动全身， 一个接口的变更会引起所有接口使用者的代 码调整。作者比拟建议推行 “接口评审制度， 评审会上必须要求接口的制定方和使用方共同派 代表参与，明确接口的需求和形式。这样做往往能够形成好的气氛：第一，接口的使用方参与了接口的评审，有助于他仔细考虑自己的需求是否能够满足。第二， 接口的形式是经过使用方评审的， 使用方

9、要为日后接口的变更负责任。 这样可以 促使接口的使用方提前充分理清自己的需求。第三，双方见面进展沟通，明确了相关人，便于日后工作中的协调处理。.关键路径优先 学过图论的读者都知道关键路径的概念， 工程管理理论也告诉我们， 关键路径上的任何 活动的推迟将使整个工程推迟。关键路径要求：1 工程管理团队需要清楚工程的哪些工作是关键路径2 工程管理团队要制定可行的方案保证这些关键路径的完成。.广度优先 广度优先也是图论中的一个概念，表示在树搜索的时候优先从广度上处理。这里沿 引过来表示始终要要优先分解任务，而不是处理任务。考虑整个团队任务的并行处理效率，如果说任务 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等等。为什么要这样做？我想这是大家