文档介绍：改善协作
想象一个软件开发组织,它和市场紧密连接,可以随时交付完成的工作或调整方向,对市场做出准确的反应,这样的组织必然会在市场竞争中占据优势。响应能力是所有软件开发组织所期望具备的,但真正能做到的却很少。究竟是什么影响了组织的响应能力。从内部看,主要是堆积的“在制品”,和技术及学****债务”。从外部看主要是和市场的连接程度,也即研发团队和业务人员、用户的协作。以下将分别分析这三个方面对组织响应能力的影响。
“在制品”是响应外部变化的负担
所谓“在制品”(Work In Progress,WIP),是指已经开始但未完成(可以向最终用户交付)的工作。主要包括:未实施的决策、未实现的设计、未集成的编码和未验证的系统。
图1是一个典型的瀑布开发模型,需求阶段产出系统的全部需求规格说明;分析设计阶段产出整个系统的架构和详细设计;测试验证前完成所有的代码。这些都属于不可交付的“在制品”,在整个开发过程中,都无法交付软件以响应客户的需求。另外,在项目开发过程中,任何需求的变更,都意味着对“在制品”的返工,例如在编码结束时需求发生了变化,意味着前期的需求分析、架构和详细设计,以及编码都要进行返工,这引入了需求变更的额外成本。因为这些原因,团队无法在较低额外开销的情况下,随时向客户交付产品或改变方向,其响应能力必然是受限的。
图1 瀑布模型下的在制品及其影响
如图2所示,理想的迭代模式下,“在制品”仅仅存在于迭代之内。团队在迭代开始时,计划一部分需求,迭代结束时产生可交付的软件,清空所有的“在制品”。这样的模式为提升组织的响应能力提供了可能,1)迭代结束时软件是可交付的,可以通过交付它们来响应市场的需要。2)每个迭代开始前,都可以对产品的功能需求和规划做出调整,响应市场、用户及相关各方的反馈。而且因为迭代结束时“在制品”的数量为零,不存在对“在制品”的返工成本。
图2 理想的迭代开发模型
即使是迭代开发,大部分团队并不能做到迭代产出物的直接可交付。如图3所示,在一个典型的迭代开发中,每个迭代产生可运行的软件。但可运行不等于可交付,由于技术手段等的限制,迭代结束时会有遗留未完成工作。随着迭代的进展,未完成工作不断累积,形成迭代开发模式下的“在制品”,它们损害了组织响应能力。首先,可运行的软件加上未完成的工作,才构成可交付的软件。也就是交付软件前必须完成这些工作,组织无法随时交付以响应客户的需求。其次,这些“在制品”也意味着风险,未完成工作的不确定性,使得交付更加不可控,损害响应能力。
图3 现实迭代模型的WIP
技术和学****债务”(debts)加大响应的难度
“债务”是指将来某个时刻要偿还的负担。如图4所示,如果没有适当技术实践的支持,随着迭代的进行,既有代码的单元测试工作增加;功能回归测试工作量变大;代码质量因频繁变更而变差;系统越来越复杂,团队成员却缺乏对系统的理解。这些构成了软件开发中的“债务”,它们加大了将来系统修改、测试的难度,因而降低了系统的响应能力。
图4 技术债务和学****债务的积累
“债务”又可以分为技术“债务”(tech. Debts)和学****债务”(learning Debts)。技术“债务”是指因系统的不良设计、实现和测试,导致系统在需要变更时,难以被理解,难以改变;改变后,难以验证代码的正确性;难以对既有功能进行回归测试。