前言:
本文主要是在讲述精益敏捷外包开发, 为何应舍弃 “过重的文档”, 而应改采 ”视觉化的看板”, 方能有效的整合来自不同企业,位于不同办公区的软件外包人员, 而能共同高效的完成高质量的交付?
本文:
企业的 IT 部门, 将产品的系统, 外包给不同企业, 位于不同办公区的开发与测试人员时, 所面临的一个最大的难题之一便是: 版本交付的质量与效率, 往往无法满足企业内, 业务部门的期望与要求?
之所以会形成这一致命的问题, 其主要的原因便是来自于 “过重的文档”?
企业的 IT 部门与外包人员之间, 或许因各自的立场不同, 或许因外包人员对企业 IT 部门的业务或系统的不熟悉, 而使得企业 IT 部门的需求分析/ 设计人员, 需将一数十页甚至上百页的需求/ 设计规格书, 交与外包的开发与测试人员后, 外包的开发与测试人员, 才会开始进行相关的开发与测试工作?
而这一看似必要且理所当然, 应该由企业 IT 部门的需求分析/ 设计人员, 所交付的需求/ 设计规格书, 往往却是造成企业 IT 部门, 在版本交付效率与质量上, 大幅滑落的最主要原因之一? 其根本的原因便是在于:
1. 数十页甚至上百页的需求/设计规格书,
将造成许多无谓的等待时间:
企业 IT 部门的需求分析/ 设计人员, 编写需求/ 设计规格书时, 往往需耗费 1-3 个月的时间; 有的版本甚至还耗费更久的时间?
而在这段长达一个月甚或数个月的时间, 外包的开发与测试人员也就只有“等待”?
然而, 这段 “等待”, 是绝无可能获得企业内业务部门的理解与谅解的? 版本交付的日期, 并不会因有这段的 “等待”, 而获得延期?
也就是说, 外包人员的开发与测试的时间反而会因为这段的 “等待”, 而被 “压缩”; 举例: 本来在整个版本中, 应有 3 个月的时间进行开发与测试, 却被压缩成只剩下两周?
当外包人员的开发与测试的时间被压缩时, 外包人员将别无选择, 只能把手头上的工作先交付出去, 至于 “质量”…..被逮到了再解决唄?
2. 数十页甚至上百页的需求/设计规格书,
其实可读性与指导性是很差的:
从许许多多的项目中已获得验证, 数十页甚至上百页的需求/ 设计规格书, 只会使不熟悉企业 IT 部门业务或系统的外包人员, 更加的不理解需求, 更加的宛如坠入到五里云雾中?
3. 数十页甚至上百页的需求/设计规格书,
往往会使外包人员被动,过于保护自己:
外包人员只针对需求/ 设计规格书的内容, 来进行开发与测试, 而不愿意再进一步主动的去思考, 该做些什么? 以能真正的满足使用者的要求?
当外包人员已丧失了主动思考的意愿与能力时, 版本交付效率与质量的低落, 便是可以预期的?
所以, 我们应从另一个角度来看待产品软件外包…..
“当面对来自不同企业,位于不同办公区的软件外包开发与测试人员时,首要且最重要的工作,
便是建立起一高效的信息传递机制;而不是文档?”
这一高效的信息传递机制, 需能满足以下的条件:
1.
简单:
在任何的工作环境下, 均可轻易的被建置起来使用?
将复杂, 艰涩难懂的理论隐藏, 封装起来? 而使任何人均可轻易的直接上手?
2. 可视化:
可视化的呈现, 产品软件开发周期内的信息; 包括: 需求分析, 架构设计, 测试用例等的信息?
3. 团队协作:
可使企业 IT 部门与来自不同企业, 位于不同办公区的外包人员充分且直接的协作?
我便是以 “看板”的型式,在精益敏捷外包开发中, 建构一高效的信息传递机制?
我所设计的以特性为纬度的 “看板”, 包括:
1.
需求看板: 使企业 IT 部门与外包团队, 可视觉化的识别特性的基本场景, 扩展场景, 异常场景与质量属性?
2. 架构看板: 将设计Rest Oriented Architecture (ROA) 所需的架构实体类型与架构设计流程, 融入至看板中? 而使企业 IT 部门与外包团队, 可更轻易且直接的协作, 共同设计出特性所需的 Web API?
3. 测试用例看板: 将使特性测试结果产生差异的纬度与各纬度上使测试结果产生差异的变化点, 融入至看板中? 而使企业 IT 部门与外包团队, 可共同且客观的识别特性所需的 测试用例?
结论:
需求看板, 架构看板, 测试用例看板, 已在许多各类型的项目中, 真正使企业 IT 部门与外包团队, 高效的传递信息? 而使项目中的待确认事项, 风险, 最佳的设计与测试方案, 均可及早的被识别出来? 因而, 使项目开发的效率与质量大幅的提升?
后续的文章, 将会再进一步的详细介绍需求看板, 架构看板与测试用例看板?