Epic/Feature/Story/Task要求四层区划是当前一些银行要求管理条例。但已有顾客反馈说，并没感到交货效率提高，还向我咨询，你们有没有一些实例，来验证这样做能够提升研发效能？
做为这一套策略的搭建者，我只想说要求四层区划其实就是当初做出来的一个临时性解决方法，现在看来很别扭，但曾经的那一个场景中，这样做是处理曾经的问题。
临时性解决方法能否做为“标准物质”，就需要复原那时候的画面，看一下公司真的那么来业务需求，是否滥用药方。
Epic/Feature/Story/Task是是怎么来的？
一句话讲清楚：便是融合解决方法和商业部门，专门给客制IT系统开发服务的，这是一个怎么样的情景呢？
某国内公司，是一家以产品为核心竞争力的企业，它内部结构商业服务系统供应商、顾客群，全是的公司。
其顾客A，有着自己的内部系统A’，公司购买了大型厂的商业部门B，做为内部结构IT系统，随后B不完整达到公司自已的内部结构要求，研发了内部系统B’。
伴随着时代的发展演变，IT忽然变成个性化服务，公司对顾客A，在一套解决方法中拥有连通A’B’内部系统以迅速进行产品交付的需要，这个需求也是可以收费服务项目。非常明显，顾客A并不想修改A’，那么问题来了，怎样把顾客A对公司产品的需要，转化成领域关联性解决方案，又怎么将这个解决方法，逐层转化成对B’及终系统软件B的客制开发设计每日任务？怎样在同一个客制系统内分辨内部结构IT需求与外部客户要求？
下面的图灰色区域，意味着开发设计难以控制，绿色区域，意味着个性化服务里的客制开发设计。在公司现行标准解决方案、版本号需求分析文档、设计文档的模式中，节奏感错乱、迟缓。
