Press "Enter" to skip to content

敏捷零部件

cheney 0

玩敏捷的或多或少都知道敏捷(开发)和传统(开发)的区别。敏捷的核心思想是短频快地针对不确定因素提供周期性的确定性反馈。而传统的做法并没有在短频快的周期性交付上做约束。

最近听到一组名词:管道型产品 & 零部件型产品不禁让我对敏捷和传统有了新一轮思考。

零部件产品很容易理解,其产品整体是由多个零部件整合而成。例如电视,电脑,手机等。每个组成的零部件均可追溯其来源。也正因为如此,现如今此类产品的质量已较之前大幅度提高。每个零件的厂商都很清楚这一点,如果希望自己的零部件被广泛采购,运用并被信赖,从而得到长期合作的稳定收益,那厂家必须确保其们个零部件的质量,维持其来源,甚至有必要为此付出大量的沉默成本。这样情况下的社会分工协作是细致的,是高效的,是稳固的。

和零部件型产品不同,管道型产品并没有层层追溯的条件。好比一根管道,从一头入另一头出,我们对其产品有明确的预期,也能在另一端得到产品。但是当产品出现问题时,我们很难去追溯到底是哪个环节出了问题。这类产品多为食品,药品,化妆品。拿牛奶举例,如果出了问题,我们不确定是零售商,还是运输,还是包装盒,还是加工消毒的过程,还是奶源(奶农,奶牛),还是饲料,还是饲料产出的那块地有问题?一罐有问题的牛奶倒进奶罐车里面,我们很难追溯它的出处是哪里了。正是因为这种产品的特性,造成了它们品质检验的难度,要比那些零部件产品大得多。

看到这里,你应该猜到我要拿管道型产品来类比传统开发了。你或许不同意传统开发没有层层追溯这样的说法。传统开发中明明有大量的文档,有报告,甚至有邮件来追溯各个环节的状态和责任人。你可以这样说服你自己,但是真的可以做到吗?当我们把需求,设计,架构,开发,测试,实施,运维等各部门相关人“倒入”了原定计划这条“管道”后,我们真的还能在“管道的另一头”追溯回具体的人,天,事吗?即使重新再来一遍,你有把握问题就真的可以避免吗?假设避免了,别的本来没出问题的地方就一定不会再出错了吗? 我是没有这样的信心啦。

再来看敏捷型项目,迭代周期是短期的,往往是两周。在各个例会(计划,站会,展示,回顾)的高度“曝光”下,每件事的透明度是开放的,责任人是明确的。最重要的是,每个迭代产出的“零件”都是可见可验收的。而团队的每个人都会产生对这可见产出物的责任感。这样情况下的团队分工协作是动态的,高效的,稳固的。

对比“管道”给项目团队提供的周密计划,它带来的“密闭空间”隐藏了太多信息。而暴露的”零部件”或许给项目团队带来压迫的节奏,但一定能换来可信赖的产品。

发表评论

电子邮件地址不会被公开。 必填项已用*标注