[原创]软件编码，测试，检查能否流水线化，组件化？

nan309

软件编码，测试，检查能否流水线化，组件化？也许目前的角度来讲，检查的流水线化应该比较容易实现，其他的比较复杂。PL能比较快速地掌握项目的情况。比如现在的情况是A,B,C,D四个人负责4本程序。每个人会出现的错误都是不定的，所以PL抽测一本的结果几乎无效。如果流水作业，PL只要抽测一本比较复杂的就可以基本掌握4本的情况。因人而用，发挥项目组成员各自的特点。流水线的作业以及推广方式，我想借鉴一下钢铁企业推广ERP的模式（从OA向ERP衍化）进行，小规模逐步渗透。Review是最有可能很快实现流水线作业的阶段。从Review阶段向测试阶段推演，反向进行。

nan309

为什么没有人呢？

nan309

BLOG里提到了，“都是很花费工数的”的问题。我想现在很多项目都是预备的时间小于实际操作的时间，我想这样似乎不太对的，有些项目到了中期，甚至后期出现了无法解决的问题都是因为前期构想不足。“习惯性简单”的想法不太可取。

 

REVIEW和TEST的过程容易实现组件的拆分，编码时候的拆分还需要一个统一的构架。

流水线的灵感来源于汽车行业，但我们的程序不是汽车，一条生产线上的汽车是相同的，但一条生产线上的程序是不同的。我们需要找到一种拆分的规律，我问过刘刚，他拿过去的项目做了一个简单的可行性分析，他说那个项目是有拆分可能的。

每个项目去逐个拆分不太合适，我们需要一个模式，一个可以遵循的模式。

 

还有就是说在项目里学习的问题，我想如果在项目里学习的是技术，那说明还没有完成项目的能力，在项目里所能学得应该是流程和一些其他的东西。