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
image.png
传统开发方式
-
紧耦合的设计，线性开发
- 驱动力源于对效率的追求
- 大量跨组件的重用
- 系统中有很多依赖关系
- 任何小的服务变更可都导致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直至客户满意为止
- 客户同意支付所有费用，直到工作满意或项目取消
- 甚至测试人员只是简单地通知客户，通常没有权限
网友评论