作者：李文华
注：本文为原创，任何使用必须经得本人同意.
尽可能并行工作
1.1. 各种角色可以协同工作
敏捷的特征就是要是使工作更加高效。很少有公司仔细考虑过项目成员在工作流程上的优化可以为项目提高多大的工作效率。但是，只要我们想一想，项目中的每个成员其实都是一颗能够独立计算并完成任务的CPU，那么我们是否会像IBM的网格计算专家一样去不断优化这些CPU的工作流程以达到一个新的世界记录呢？
千万不要认为必须完成所有的需求后才能够开始开发，完成开发后才能开始测试。软件管理者应该要非常清楚，所有的项目成员都是可供利用的CPU资源，无论在项目的任何阶段，你都不应该让这些CPU资源过分闲置。 项目的工作推进要想CPU的流水线一样，不要形成顺序流程，而要尽可能并发开展，这样才能最大限度利用资源。
需求分析还在进行，开发人员干什么呢？
设计还在进行，需求人员可以干什么呢？测试人员又可以干什么呢？
作者不是善于剥削劳动力的资本家，问这些问题是为了启发大家明白“人力资源”是非常富有弹性的东西，很多时候感觉“资源不足够”并不是真正的不足够，而要问问自己“是否让资源充分发挥了价值”。
下面这张表是作者提供给大家参考的一个敏捷工作计划。在这个计划里，作者要强调几点：
1. 软件项目中存在很多隐性的工作，要尽量在项目立项的时候就考虑到，并排入计划。比如培训，制定规范，组织公用工具开发等
2. 清晰的角色划分，尽量明确每个人的工作职责，会使整个团队工作得更积极、有序。
3. 不要忽略了协调的层次，项目组内，部门内，跨部门都需要良好的沟通渠道和协调资源。
阶段 角色
需求师/人机工程师
架构师/设计师
开发工程师
测试工程师
需求调研
l 与客户沟通
l 编写用例和需求规格说明（功能需求、非功能需求）
l 培训（业务背景）
l 组织需求评审
l 架构设计
l 与需求师确认需求
l 构造原型
l 培训（工具使用指南、编码规范、环境搭建、调试指南、性能问题处理）
l 组织公用工具开发
l 参与需求评审
l 安装并熟悉工具
l 了解业务背景
l 培训和学习
l 开发公用工具
l 参与需求评审
l 列写测试计划
l 编写测试用例
分析/设计
l 持续确认需求
l 细化功能清单
l 细化逻辑检查清单
l 界面需求
l 参与设计评审
l 架构设计精化
l 模块概要和详细设计
l 编写接口文档
l 编写性能测试计划和性能保障计划
l 组织设计评审
l 参与设计评审
l 编写针对接口的单元测试
l 细化测试用例
l 准备测试环境
实现/测试
l 持续确认需求
l 检查功能实现
l 检查界面规范
l 代码走查（代码结构、接口、异常处理、性能瓶颈）
l 难点公关
l 微观性能测试
l 编码实现
l 对照逻辑检查清单编写单元测试
l 修改bug
l 参与技能培训
l 功能测试
l 宏观性能测试
l 集成测试
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等等。
为什么要这样做？我想这是大家想知道的。原因如下：
1. 培养大家的大局观，不要急于钻进一个细节问题
2. 始终把能做的先做，比如分工
3. 先把任务从广度上划分，有利于在某个子任务遇到依赖项时切换到另一个任务去处理
有利于资源共享。任务先在广度上有了一个划分，当出现新的资源时，很容易把其分解的子任务分配出去，从而保证任务始终在并行处理的状态。
