[敏捷/精益以及传统] 项目工程管理方法对比

The Customer (s) type, availability, and the total number of stakeholders drive the management method. The work must meet those demands, based on the goals set.

• Traditional must be efficient in design
• Agile must release early and maximize value with iterative releases
• Lean must be responsive and provide services or products based on client priorities

传统开发方式

• 紧耦合的设计，线性开发

  • 驱动力源于对效率的追求
  • 大量跨组件的重用
  • 系统中有很多依赖关系
  • 任何小的服务变更可都导致Big Costs
  • 在变更很少的情况下，将会非常高效

• 团队: Departmental

  • 为了提高效率，一般采用多部门/多份合同
  • 专业化分工降低交付成本
  • 多专业化团队共同完成项目

• 集成测试: 在结束阶段进行

  • 由于紧耦合，只有在最后阶段进行集成测试
  • 所有的组成部分连接，并可产生相互影响
  • 这延迟了反馈，从而冻结了需求，使得需求难以变更

• 项目结尾: 第三方检验机构验收

  • 一般需要第三方的检验机构对最终产品根据需求进行验收
  • 这样，多方stackholders才能信任结果
  • 这也是一项庞大的工作，需要验证专业知识

Agile

• 松耦合设计 & 迭代开发

  • 允许同一时间开发一个feature
  • This requires additional scope around supporting services to make features independent
  • 降低了变更的成本但是增加了Baseline成本
  • 得以更早的发布新特性或最小化可行产品 (MVP)
  • 每个迭代版本都可以构建在它之前的版本之上

• 团队: Matrixed / Projectized

  • 所有人都在团队内，甚至Customer
  • 所有部门看到和听到同样的设计意图
  • 确保了最大限度的沟通准确性
  • 这提高了速度，减少了交接handoffs 和决策延迟

• 集成测试: 持续进行

  • 通过持续测试，工作可以在每个Release进行关闭
  • 工作是伴随着Owner的节奏完成
  • 这确保当我们为每个版本添加Scope时，新特性不会破坏旧特性

• Closing: 团队内部验收

  • 测试人员在团队中，可以及时告知客户产品质量
  • 客户也在团队内部，可以内部对工作进行验收

Lean

• Designs are Evolutionary & 增量开发

  • 对发布版本进行有限的预先规划和控制
  • 功能的构建基于即时需求，而非细分市场
  • 服务在特性的基础上不断发展，以提高响应能力和效率
  • 设计可能很复杂，以最大限度地提高重用性，需要敏捷并且有限的工程工作
  • 关键是达到“刚刚好”

• Teams: 紧急(临时)(Ad Hoc)

  • 团队只包括每个阶段需要的人
  • 根据当前的工作重点，会有不同的人员参与其中
  • 这可以直接最小化成本支出，但会导致所有权和交接方面的问题

• 集成测试: 可能会

  • 精益项目是按需构建的，没有太多的预先计划
  • This results in an integration "when possible" approach
  • 一旦工作完成，它就会被整合
  • 一些例子：
    • 由研发导入的新的发现
    • 工作系统的修复，如bug修复或替换部件
    • 在当事双方达成协议后，对法律文件进行升级和更新
    • 完成交易阶段一旦客户准备好或响应时间到期

• Closing: 客户接受

  • 仅由客户验收
  • 工作将Open直至客户满意为止
  • 客户同意支付所有费用，直到工作满意或项目取消
  • 甚至测试人员只是简单地通知客户，通常没有权限