理解Feature

admin管理员组

文章数量:1633369

2019独角兽企业重金招聘Python工程师标准>>>

定义

特性(Feature)是具有突出的、特定的客户价值的实体(Entity)，是可销售的对象，包括：基本特性和 可选特性。基本特性不单独定价、捆绑在一起销售；可选特性则需要通过License控制销售

四个基本特征

1.        具有客户价值：

特性最重要的特征是具有客户价值，能有效解决客户的某个问题或痛点

2.        客户可感知：

特性是系统的外部表现，是客户可感知的。

3.        能完整使用

特性分两类，业务类、系统能力类。对于业务类特性，要能够代表客户一个完整的使用场景，如摘机不算特性，基本呼叫要包含计费、告警等才能上网应用。但不论是业务类特性，还是系统能力类特性，都要能够包装成为一个吸引客户的独立卖点。

4.        与实现无关：

特性是从客户角度描述的系统的能力，跟系统内部如何实现无关。

特性的重要特征是具有客户价值，是产品卖点，主要从为客户产生价值的角度来描述，通常被作为产品的销售和报价单位

需求分析与分层

• IR与FR是多对多的：

  • 多个IR可能归纳为一个FR（这个还比较常见）；

  • 一个IR也可能分解多个FR

• FR最本质的来源并不是IR，而是客户问题，一个FR，就是一个特性，必须描述包含客户问题/痛点，解决这个问题带来什么价值；

• 一个FR，一般由多个UseCase描述，一个UseCase就是一个SR；（这个UseCase包含由基本场景、扩展场景）

• 一个UseCase的基本场景为一个AR，扩展场景可以为一个或多个AR

  •  多个UseCase的多个操作步骤为相同，可以将此归纳为一个AR

  • 除基本/扩展外其它补充描述也可能是一个AR。

• 根据此分析到的AR，是横切系统的，如果是特性团队完成的，即可结束

  • 如果是模块团队，完成此AR涉及多个项目组，在进一步明确各模块的需求

• SR与IR对照，主要是为跟踪需求，看看需求是否由遗留

Feature的识别需要谨防“转义”，有时候是客户自己在理解你产品的基础上的转义，有时候是市场人员进行的转义，需求分析的时候是要分析清楚的。据说是来源于徐总的例子：可能客户是要在墙上打个洞，他要的是那个洞，但是我们最后提给研发的OR是“我要一台钻孔机”，一个是问题，一个是解，他把这个解给你了。有的客户本身了解你的内部实现，他也会给你提解。关键问题是他说是要钻孔机就是真的要钻孔机么？打个洞，我拿个锤子就行了。如果我们没有识别能力的话，他要一个打孔机，甚至直接要求你研发某个模块这样改一下，为什么要这样改呀，给他带来的好处是什么，没有人再往前追究。

Feature、Function设计与开发

1. Feature和NonFunctional Feature首先要识别，分离清楚。Non Functional Feature就是系统级的Feature，如升级，可靠性，性能。这里是整体性能。单独Feature也有性能要求，每个Feature也要看可靠性

2. 归类Feature Tree，注意是归类特性，而不是分层

3. 完成Feature到Function的提取、抽象

4. Function组成出来的架构是逻辑架构，软硬件形成的是物理架构。开发队伍的组织是按硬件和软件的模块来组织的，这里面是一层一层的分解分配的过程

5. Function跟具体使用的硬件、CPU、操作系统、数据库等解耦，是逻辑架构到物理架构的一个分解、设计过程

Feature与测试

现在的测试一般分成基本功能测试，全量功能测试等等。我们又怎么保证最后做出来的东西呢？只有按Feature的维度去测试，最后去交付才能心里有底，客户在实际场景这么用系统确实是测试过的，没有问题的。

Feature与交付、推广

•  实验局验证

原有的实验局是按功能验证的，与客户交流也大部分是功能的角度。在客户看来是没有重点的。但是如果你跟他谈你要用这个Feature，我们一起来验证这个Feature是好的，给你带来的价值是有用的，他开实验局的动力也就有了。同时开实验局的过程中间，把这个Feature前端的设计得怎么样，实现得怎么样，验证得怎么样，再跟我们在网上真正的使用的怎么样结合起来，一脉相承的去看。关注Feature在客户那如何使用、何时使用，我们就不会有很多东西做了之后没人用。

• Feature随时间的变化

产品的Feature不是一成不变的，与客户交流的粒度也应该是有变化的。从时间上来看，是特性一个一个收编到基本包的过程。比如汽车的例子，10年前的车，气囊是单独报价的，因为没它车也能开嘛，要装个气囊就得打个勾。可是现在谁还打勾呀，都得是标准配置了

Feature与项目管理

• 项目决策

项目归类特性树应该有级别划分，然后以Feature而不是功能的维度去决策什么该做，什么该推迟到后面做，什么不该做

• 上下同欲，自管理

  • 原有的开发过程是一层层分解的过程，开发测试（尤其是开发）一般是以AR的维度去考虑问题，目标被打碎了，团队每个人都只知道自己那一小块是做什么的，他不知道他做这个事情的最终的目的是什么，效率很低

  • 我们把Feature定义清楚之后，以Feature的维度去跟员工讲解说明背景原因和过程、目标是什么样子的，大家都明白了为什么，自己就配合起来了。把在版本的状态报告那几页贴在醒目的位置上，所有的人就都知道这个特性怎么样了，我有没有影响这个特性的进展，我接着该做些什么。这样就会形成一种“自管理”，不需要主管一直在那里盯。

• 项目监控

  • 原来员工的进度报告，开发也好，测试也好，都是有几个功能、几个用例，我已经开发了或测了90%。但是90%意味着什么呢？意味着你的功能好用么？你的特性OK了么？不知道，因为不知道全不全。意味着我的那些最最重要，最最常用的功能都开发完了么，测试完了么？也不知道，很有可能剩下的10%里面还有很重要的没有做，可能会阻塞了。这样的报告里看不出来什么东西。

  • 如果以Feature结果为导向的话，报告就不应该这么写了，就要把Feature离我定义的客户期望的还差多少报告出来。进度也好、质量也好、缺陷趋势也好，最后的结果到底差多少。有了最后这个结果的描述，就会发现每个阶段你都清楚离结果还有多少距离

转载于:https://my.oschina/bigsloth/blog/187204

本文标签： feature