课程对象
本课程会涉及到以下几种不同角色,并获取相应收益:
●中级管理者(20~50下属),大项目经理、多个项目的经理或部门经理,主要负责部门绩效管理、团队建设。
●基层管理者(1~5下属),小型团队的技术与任务负责人,负责排定微观计划,判断功能点的完成情况,填报跟踪表。
●初级管理者(5~20下属),项目经理级别的负责人,主要负责团队内计划、任务分配、时间协调、跟踪并发现问题,控制进度。
●核心开发与测试人员,理解功能点与代码、测试用例之间的关系,从而理解计划的制定依据、跟踪依据。
课程形式
两种形式均要求现场分组为2~6组,每组5~8人,现场推选一个产品经理。此产品经理应现场能提供一个企业实际产品的需求(或1人年左右工作量的片段)。
●实物教学形式
适合正在使用敏捷开发、看板,希望借助功能点作为敏捷辅助措施情况。
以80*60cm大白纸、粉色/蓝色/黄色纸片为主要载体,在桌上、墙上完成练习。
●电子教学形式
适合希望课后立刻落地,形成以功能点基础的估算、度量、考核体系的情况。
每组至少携带一台电脑,在电脑上各自预装不同实际产品的需求(另需提前准备另一个需求文档给讲师作为讲解依据)。课上会使用此需求,将其改为讲师所用的模板,并使用与之对应的Excel估算工具完成估算。
课程时长
2-3天(6小时/天)
课程大纲
● 预热:什么是功能点和功能点计数项(0.5H)
简单介绍课程目标、功能点的背景知识等等。
学员尽量按实际团队或业务领域分为4~5个小组,每组有自己的需求(实际产品需求,供拆分功能点练习使用)。
功能点的最基本概念
NESMA功能点定义
ILF内部逻辑文件与EIF外部接口文件
EI外部输入,EO外部输出,EQ外部查询
功能点在完整的QAD量化敏捷开发中的位置
● 第一步:准备需求文档(5H2天/5H3天)
● 第一类文档:已经由业务部门写成的现成文档
此类文档的编写者由于没有经过功能点的培训,因此其文档中不存在功能点计数项的清晰条目,还存在大量从字面上看不到的功能点。因此需要对其进行标记、分析后方可计数。
课堂练习:在自己的需求文档中,标识实体(ILF、EIF),并计算早期规模(Indicative Function Point)。在天然的文档中,行为(EI、EO、EQ)遗漏率太高,识别并补充的技巧,需要在下一练习中才能学到。
●第二类文档:需求尚未写成,因此可以按功能点从头编写的文档
特色内容:在实践与教学过程中,讲师发明了一种全新的需求分析法“SEAi需求分析法”,用这种方法可以在写需求的时候就顺便完成功能点的拆分工作,通过简单工具甚至可以自动计算功能点数,是普通功能点计数法速度的20~5000倍左右。此方法还可以把需求遗漏率从30~70%降低到5%左右(初学可至15%左右)。
本章节将使用讲师的“SEAi需求结构”的简化版本,在极短的时间内,即可将Word或人类语言拆分并表达为前三层,其第二层就是ILF和EIF(统称为实体),第三层则是EI、EO、EQ(统称为行为),因此可直接用于计算功能点。
课堂练习:1. 将大型需求拆分为场景;2. 在每个场景描述中识别实体(ILF、EIF);3. 用CRUD方法发现潜在的行为(EI、EO、EQ);4. 计算中期规模(Estimated Function Point)。
●第二步:功能点估算(2.5H2天/3H3天)
课程特色:本课程讲师是世界最大度量咨询美国SPR(生产力研究所)授权的国际标准功能点讲师,也是中国《软件成本定额规范》(成文于2009年,是工信部、北京市标准、国标、国军标的共同前身)编写组组长。国内所有标准所采纳的NESMA体系产生于2003~2004年左右,因此在出现移动开发、敏捷开发后,某些内容已经不适用。以下内容将在标准之外扩展了一些近10年来才出现的新技术如多端开发,以及如何识别和避免标准中存在问题的调整因子如开发语言调整因子。
功能点的历史及定义变化
IFPUG功能点定义五种计数项
复杂的调整因子定义(本课程中弃用)
NESMA两级简化体系
Indicative Function Point
Estimated Function Point
AFP简化体系
Agile Function Point
调整因子
软件因素调整因子
应用类型调整因子
规模调整因子
变更调整因子
二次开发调整因子
维护调整因子
多端开发调整因子
开发因素调整因子
团队经验因子
语言类型因子
实际使用中因子的选择
课堂练习:1. 使用功能点定义重新理解并修订之前的需求拆分;2. 将大型需求拆分为场景;3. 使用调整因子对功能点总量进行调整;4. 使用自动工具从三层需求结构中直接计算功能点
●第三步:造价估算及其标准(2.5H2天/3H3天)
课程特色:本课程讲师是中国《软件成本定额规范》的编写组组长,之后所有国内标准如工信部、北京市标准、国标、国军标均从此标准演化而来。在早期探讨国内标准取舍、优化时,不但继承并发扬了国外的已有标准,也遗留了一些尚未解决的问题。以下内容不仅解释了各种计算公式的依据,也增加了对标准不完善之处的处理。
此外讲师还增加了与研发息息相关的编码、测试估算值,从而使得功能点不再是费时费力而功能单一的技术。
中国的功能点发展历史及标准历史
初期功能点的引入
中国标准时代
行业协会标准:《软件成本低额规范》
北京市地方标准
工信部标准
国标
国军标
其他主要参考体系
韩国标准
澳大利亚SouthernScope
标准估算过程
功能点定义
估算的三个时机
功能点计数
调整因子计算
派生计算项
工作量
成本(不同标准中有两种不同的计算策略)
开发成本计算
总成本计算
工期
讲师增补的数值:
逻辑代码行数,代码混沌指数
测试用例数,测试缺陷数,发布缺陷数
基准比对与五点估算
课堂练习:1. 使用Excel完成早期功能点估算(基于ILF和EIF);2. 使用Excel完成中期功能点估算(基于EI/EO/EQ);3. 计算所有调整因子的数值,完成功能点调整;4. 计算所有派生计算项;5.完成Benchmarking三点计算(部分数据为五点估算);6. 使用标准模板计算非软件成本
●第四步:基于功能点的计划,跟踪,度量,评估(1H2天/2H3天)
整体计划
整体计划包括项目早期的立项、合同等计划。也包括了敏捷开发的整体计划。
新产品开发的功能点计划
二次开发功能点的计算
其他功能点不覆盖的工作量(如数据导入等)
其他估算与计划方法
数学方法(代码行法、类比法)
非数学方法(专家估算法)
迭代计划
课程特色:本课程讲师还是活跃的敏捷开发培训师(场次高达200多次,包括100场金融客户、50场电信客户),根据NESMA的NFP简化公式,讲师推导出了“敏捷功能点AFP”的简化形式,用以取代故事点作为敏捷开发的计划和度量单位;并使用相关的度量项跟踪迭代的进行情况。
迭代计划中使用功能点
使用SEAi需求条目代替用户故事
直接从SEAi条目数计算功能点
维护类任务功能点计算
其他估算方法
故事点
鸡蛋估算法,T恤估算法
迭代跟踪,度量,评估
迭代跟踪产品的进度
量化地跟踪产品的内在质量
使用迭代开发+功能点度量来跟踪,可以有效防止虚假进度。
内在质量的持续跟踪
可以防止在项目结束时发生质量问题而导致看似顺利的进程受阻。
整体跟踪,度量,评估
课程特色:此扩展内容建立了基于功能点的项目评估体系,整体包括6项核心指标,利用基准比对Benchmarking方法进行跨团队/部门/企业/行业的横向对比。
整体跟踪发生在项目完成,或大型里程碑(必须是迭代式而非瀑布式里程碑)处,对计划的执行情况进行评估。
实际完成功能点数据的快速/自动收集
数据库表法,界面计数法,函数反射法,接口反射法
核心指标度量与评估
生产率FP/人天,成本RMB/FP,编码消耗率LLOC/FP
测试密度TC/FP,测试缺陷密度TD/FP,发布缺陷密度RD/FP
QAMMI量化敏捷成熟度模型
基于功能点+Benchmarking的横向比较
课堂练习:1. 为一个已经完成的项目大致度量其功能点;使用Excel完成早期功能点估算(基于ILF和EIF);2. 使用Excel完成中期功能点估算(基于EI/EO/EQ);3. 计算所有调整因子的数值,完成功能点调整;4. 计算所有派生计算项;5.完成Benchmarking五点计算
其他:功能点的扩展应用(详见各个模块的时间)在两天课程中,以下内容会被压缩至0.5~1小时,只做介绍;有要求的除外
课程特色:本课程将功能点应用从报价,扩展到研发管理的全程,从而使得功能点不再是只有管理层关注的数据。
QAC量化敏捷编码(量化敏捷重构)(1H仅培训,或2H含练习)
以下方法并非“重构”特有,对高标准要求的新项目一样适用。
基于功能点的重构决策
基于功能点的重构计划
重构团队人力模型
基于功能点的重构跟踪
重构案例分享
潜在练习:此处可对一个实际的正将、正在重构的项目进行练习
QAT量化敏捷测试(1H仅培训,1.5H含练习)
基于功能点的测试密度计划 TC/FP
基于功能点的测试密度度量
归一化测试密度 RD/FP
基于4个100%的自动化测试策略
潜在练习:此处可现场采集各个项目的度量数据,并按行业计算数据的合理性
QAM量化敏捷度量/绩效管理(0.5H仅培训,1H含额外对一个项目的现场数据收集与计算)
拓展的度量项
技术相关:CCI代码混沌指数
测试相关:测试覆盖率,测试频率,测试效率自动化率
发布相关:发布频率,发测比,线上缺陷次率
基于功能点的敏捷团队绩效管理
与业界基线的比较
基于功能点的个人绩效管理
课程特色
本课程的讲师是中国最早的功能点标准《软件成本定额规范》的编写者(2009年,由讲师的培训大纲改写而来)。在长达一年的标准编写过程中,80多家甲乙方企业参与其中,提出了很多当时悬而未决的问题。加之在之后Scrum、DevOps等敏捷开发逐渐流行起来,逐渐产生了更多的冲突。
本课程的讲师在此后的12年间持续研究这些问题,逐渐找到了答案,其中多数在世界范围内也是独一无二的