一、背景
我们在项目进展的过程中，是不是还遇到了这些问题：
1、项目有deadline，还没开始讨论需求已经限定死了发布时间，里程碑时间点促使进度往前赶，而往往项目还没有成熟到可以推进的程度
2、为赶进度项目成员之间的沟通会减少和不明确，每个人的理解出入就会越大，返工的隐患就出现了
3、项目人员变更，替换的人员对项目并不是非常了解，理解成本耗费大量项目时间
4、开发过程中的方案变更，没能及时通知到相关合作方
5、需求方中途变更、添加需求
6、遇到的问题，UC的载体修改起来并不是非常便捷导致大家后期不愿意维护UC
7、新老需求纵横交错，一不小心就影响到了其他功能点
当我们疲于应对这些问题的时候，我们是不是就需要这样一个管理方式，它要满足下面几个特性：
1、修改方便，快速记录讨论结果
2、快速理解
3、结构清晰
4、理解上低歧义性
5、沟通方便
6、通过它可以快速生成TC
7、通过它可以快速定位影响点
二、方案概要
简单概述：对业务进行严格的功能点划分，并格式化成相应的结构，方便进行业务管理和维护的一套解决方案。
它的适用范围：
1、业务管理，可以将整块业务整合到一张图里
2、功能点梳理，对即将要进行修改的影响点进行挖掘
优点：
1、快速，可以快速适应复杂的变化
2、便捷，可以非常方便的进行修改
3、清晰，可以对复杂的业务场景进行直观的了解
4、高效，在对功能点的管理规程中，沟通便捷，降低交互成本
5、直接，通过它可以快速生成测试用例
变革：
1、在对业务的梳理上，会更加细化
2、对功能点的格式相对严格
3、在理论的基础上，将可以有一套新的工具，方便进行业务的管理
方案的样例图如下：
<!--[if!vml]-->
方案的发展历程：
第一次提出是在http://www.taobaotest.com/blogs/2181的博客中，半年前。
半年中对这个模型进行了进一步优化和实践，现在它已经不止是一个张图，而是一种管理方案。
这半年中最大的发展是：1、提出了子功能点的概念，让该套体系可以清晰得表述所有功能；2、让业务格式图在项目中进行使用，扩展了业务格式图的适用范围和使用方法，对该种方案进行实战磨砺
三、方案细节介绍
包含的元素：
1、功能点
2、业务
3、实体
4、入口
5、子功能点
6、出口
其中功能点包含部分有业务、实体、入口
子功能点含盖在业务里面，是对复杂业务的补充，子功能点包括业务、实体、入口、出口。
关于功能点和子功能点：
功能点：就是一个业务上，一个具有独立逻辑的功能，整个功能一气呵成，中间没有异步的逻辑。
功能点必须包含下面的属性：
1、具有独立的业务逻辑
2、结果会有实体的存储方式，如果没有存储到实体中，而是存放到内存中，说明并不是一个完整的功能点，只能算是功能点中的一个子功能点
3、入口，即调用入口，没有入口这个功能点将无法被调用也就不称其为功能点了
子功能点：业务逻辑上，子功能点是父功能点中间的一个相对复杂的功能体
子功能点必须包含下面的属性：
1、具有相对独立的业务逻辑，
2、有实体，也可能是非存储方式的实体
3、入口，子功能点的调用入口
4、出口，子功能点完成之后的数据流向
四、方案可行性
1、怎么把实际的业务流程转换为业务格式图呢？
其实我们可以发现，业务流程转换为业务格式图，其实会牺牲一定的流程性，但是对于测试来说，这些牺牲是可以忽略的。我这么解释。
这是一个简单的业务逻辑，我们可以发现里面有A、B、C三个逻辑，有D一个条件判断。
对于测试同学来说，我们在测试的时候，往往会有确定的前置条件和结果，而我们会固定下确定的条件，所以我们会分别进行A、B、C、D四个节点的测试，而这四个节点，就是我们所说的业务逻辑。
上图是一个相对简单的流程图，但是如果像下图这样
我相信大家会经常遇到，其实B节点是比较复杂的，不是一两句逻辑可以讲解清楚的，而且在其中可能会有特有的数据实体生成。
面对这种情况，我相信测试同学会对这个B的分支进行分支流程的详细测试，有别于单元测试，测试入口会是在“开始1”节点进入，从“结束1”节点出来。
但是我们又如何清晰的表示出B的详细业务呢？
所以就提出了子功能点的概念，基于这个概念，我们就可以很清晰得表达出B这个复杂流程的意思。
可以这么说，没有子功能点，业务格式图将不具备可操作性。
2、两点基本理论（下面称之为实体双原则）
有关两点基本理论，这个是对功能影响点的梳理的原理
1）如果两个业务操作的数据载体不会有交集（包括增删查改），这两个业务在系统上不会相互影响
2）如果两个业务操作的代码写在两个完全不同的地方（代码上没有交集），这两个业务不一定不相互影响
五、如何使用
这个是文章的重点，上面哗啦哗啦说了一大堆，只介绍了这个功能，却没有说要怎么使用。
项目业务管理上的使用实践：
在项目（日常）的UC评审阶段，对功能点进行进一步细化，将功能点细节整理到业务格式图中，产出一份项目初期的业务格式图。
在此图基础上扫描影响范围（根据实体双原则），确定影响范围。并产出项目中需要关注的老功能点的影响范围。
进行业务格式图的评审，影响范围的评审，将问题竟可能暴露在开发之前。
进行工时计算，（计算公式见计算工时模块），评估各个功能点所消耗的开发和测试时间，并统筹安排。
在开发过程中，对需求变更，方案变更，进行及时调整，对调整完成得图进行评估和影响点的扫描。
在项目收尾期间，进行功能点的排查，确保没有功能点死角。
整个管理过程中，我们会有几个新的方式
1、初期需要将测试设计的时间，进行更加详细的业务格式图的设计
2、在前期，业务格式图完善之后，可以进行影响点排查，将没有考虑到的功能提前考虑进来
3、更加科学的计算工时，合理安排人员和时间
4、需求变更需要在业务格式图基础上进行修改，并通知到相关人员，同时评估影响点
5、以一种比TC的数量小但是足够变大业务的方式，最快程度得排查功能点死角。
挖掘潜在影响点
根据实体双规则，我们可以根据业务所涉及到的实体，对老功能点的实体进行扫描，如果涉及到的相同实体，我们即对其影响点进行分析，判断其是否存在影响。
具体详情可见我之前的博客http://www.taobaotest.com/blogs/2181
计算工时
工时计算公式是根据近期项目实践结果，统计出来的一个工时，并和实际工时基本上相吻合，可以和大家一起探讨下：
公式如下：项目人时=（业务权重*业务数量+实体权重*实体数量）*协同权数
期中业务权重2，实体权重1.66，协同权数是因为每个点在需求、技术方案、UC、开发、测试、环境部署上均需要耗时。在7-10人的团队（包括PD和投入的运营）协同权数基本上是5左右。人数越多，在协同上的耗时将会增加。
六、方案扩展
该方案需要进一步完善的地方。
1、录入体系。更加科学的录入体系会让体系更加强健，可维护性更高
2、迭代体系。迭代体系的目标，就是为了在项目和项目之间，项目内部迭代之间行成一个高效的管理体系
3、自动扫描、分析体系。自动扫描分析体系在迭代体系的基础之上，自动分析每一个新的迭代的功能影响范围，这块功能需要进一步细分并精确
4、工时管理体系。对工时进行科学的评估，工时计算不再拍脑子
5、实验室功能。功能点执行结果展示，包括对剩余需要的工时，进度的统计