一、关于访谈
1、访谈问题类型及回答方法
2、访谈内容关键点
3、什么是过程?
- 目标/目的(Purpose)
- 角色与职责(Role and Responsibility)
- 入口准则(Entry Criteria)
- 出口准则(Exit Criteria)
- 输入(Inputs)
- 输出(Outputs)
- 流程图及活动说明(Activities)
- 度量(Measures)
- 验证(Verification)
4、过程域
⑴、项目管理主要7个过程域
- 审查(Inspection),通常是由经过技术评审培训的项目经理或PPQA主持,规模在3~7人之间为宜,一般在完成了一个工作产品后对其进行的评审
- 轮查(EmailRouting),通常由技术负责人或项目经理召集,一般三人以上参加。目的在于通过对开发人员的工作产品的技术审查,提出改进意见
- 走查(Walkthrough),审查的范围根据需求的优先级通常由管理人员来确定,主要是静态质量分析和编程规则检查。通常是小型讨论会,一般是在工作产品形成的早期进行,作者有一定的想法时,希望从中获得一些帮助或补充一些想法。当然也可以在编制工作产品的任何阶段进行,两三个人参加,由作者主持,主要是评估和提高工作产品的质量
二、准则、依据
1、风险的管理策略:
a. 当风险系数(高)在16~25之间,必须制定应急计划,并且随时监控风险变化情况,一旦风险发生,则立刻启动应急计划。
b. 当风险系数(中)在 9~15之间,可不制定应急计划,定期监控风险变更情况,随时准备启动缓解措施。
c. 当风险系数(低)在 1~8之间,可不制定应急计划,定期监控风险变更情况,必要时启动缓解措施。
注:对于部分低风险,可选择接受。
2、项目QPPO下达:
3、评审通过准则:
4、评审准则(以需求为例):
5、任务分解准则(WBS):
- 项目要求;
- 定义逐步求精;
- 人时(工作量):一般的任务不超过2周,也就是80人时;
- 任务责任到人;
- 团队工作原则:项目经理在制定项目计划过程中,尤其是在任务分解,工期估计对关键过程中一定要与项目成员一起进行。
6、评审员的选择准则:
- 在要评审的领域拥有丰富经验。
- 具备专业技术知识。
- 能够有效识别待评审工作产品中存在的缺陷。
7、评审度量指标
- 评审活动的工时及工作量
- 评审发现的缺陷数(按严重程度及类型)
- 评审产品的规模
8、项目经理技能
- 项目估算的能力
- 有较强的沟通协调能力
- 风险识别、分析、管理的能力
- 项目策划的能力
- 进度及预算编制的能力
- 项目监控与管理的能力
- 具体需求管理的能力
9、基线、版本、存储的定义
- 基线:是由一个或多个配置项组成的逻辑实体,并可以作为进一步开发的基础。组成基线的配置项需要经过正式的评审和批准、正式的变更控制规程。通过评审的文档、开发文档,以及通过测试的,例如:代码、计划(策划阶段)
- 版本:
- 存储:工作记录,例如:会议纪要、报告
11、项目级Car基本改进原则:
- 项目执行中,当前性能目标无法达到现有组织过程性能。
- 项目执行中,出现的缺陷或问题等导致与当前组织过程绩效出现严重偏差,明显影响项目绩效。
- 工作产品与需求出现明显的偏离。
12、确定软件开发生命周期模型的参考规则
- 偏差不大于20%(项目可控)
- 交付产品通过审批或验证
- 里程碑内主要工作完成。
14、软件项目风险管理规则
- 风险类别有:人员、客户、管理、质量、测试、环境等;
- 风险系数有:高、中、低;
- 风险发生概率和风险影响范围分别1~5分。
三、项目策划实践
1、项目策划实践过程简述
2、流程中关键点说明:
- 过程裁剪指南、软件生命周期指南、标准工作环境指南、团队指南等、风险库;
- 开发过程定义(PDP)
- 生产率、估算模型、工作分配比例、人员技能水平。
- 团队水平高于平均水平,包括环境、士气;
- 需求变更范围很小;
- 技术复杂度低。
- 识别项目需要技能、业务知识,例如此项目需要Cordys平台开发技术;
- 根据人员技术,进行差距分析,例如有部分人员缺乏Cordys平台开发技术;
- 根据差异制定培训计划。
- 组织级工作环境提供了标准办公环境,例如工作终端、配置库等;
- 项目特有环境,例如:开发服务器。
3、关键过程举例说明
- 管理项目计划包括渐进明细维护项目计划,与组员及时沟通计划完成情况,以及通过周例会、周报、报工系统收集计划完成情况和进度,并通过挣值分析分析项目的偏差,也通过周例会收集风险、问题,及时跟踪;
- 通过挣值分析管理项目进度、成本偏差;
- 问题管理,识别问题、跟踪问题、关闭问题。
- 组织团队指南;
- 在项目启动时,项目通知中初步提供人员;
- 按项目实施计划模版,制定人力资源计划,对人员进行分工(项目经理、开发人员、QA、CM)。
- 在项目实施计划中干系人管理计划中,干系人沟通记录;
- 在与干系人沟通时,事前通知,事中控制、确认,事后分析。
四、量化管理及监控(QPM)实践
1、度量点、统计技术的选择准则:
2、量化过程
- (RR_Size )需求评审文档正文页数(单位:页);
- (RR_Workload) 需求评审投入工作量(单位:人天);
- (RR_TL) 需求评审高级人员比例
3、量化管理结果达成规则(QPPO冲突)
- 达成概率>95%,接受
- 90—95%,关注风险,有10%-5%的概率达不到
- <90%,协商(降低目标,不降低也只能接受,当风险管理)谈判
4、度量点在什么时候发生变化:
5、过程性能监控
- 不能超过上下限;
- 不能出现连续7个上升;
- 在规格线之间表示有能力。
6、量化项目管理问题记录
7、开发过程量化分析与评审过程量化分析差异
五、原因分析与解决过程实践
1、触发条件(入口准则)
2、过程
3、根因分析实践
4、改进实施方案
- 经过单元测试用例的重新梳理及测试用例评审提高单元测试用例的质量;
- 通过重新测试保证测试的充分性,提高代码质量。
- 重新整理单元测试用例
- 单元测试用例评审
- 对单元测试缺陷移除率低的模块进行重新测试,并对后续模块进行测试
- 跟踪执行效果
- 进行效果评价
- 如上图所示:CAR方案实施后,后续的单元测试模块过程过程能力也得控制,稳定性也得到显著提高。
- 因此判定本次CAR的执行有效。
- 单元测试用例的质量对于单元测试过程至关重要,因此要加强单元测试用例的评审;
- 修改编码与测试过程,删除编码与测试过程中单元测试用例可不进行评审的描述。
六、决策分析过程实践
1、输入:组织级过程体系文件《决策分析过程》、《决策分析指南》
2、决策准则
⑴、入口准则
- 全新标准产品立项时。
- 定制产品立项时。
- 存在多个技术方案选择时。
- 决定全新开发、复用还是采购商用组件时,同时所做出的决定对项目的成败或进度、成本影响大于50%时。
⑵、评估准则
3、评估方法
4、候选方案列表
- 方案一:自主开发消息管理
- 方案二:采用第三方消息中间件(IBM MQ)
5、实施过程与计划
- 决策问题描述:
- 制定决策分析计划:
- 成立决策小组:小组由项目组成员、项目QA、项目经理构成;
- 建立评估准则:根据待决策问题的特征,确定明确的评估准则和评分标准,填写评估准则列表;
- 识别候选方案:寻找潜在的候选解决方案,填写候选方案列表
- 确定评估方法:
- 评选候选方案:
- 完成决策分析:根据评估结果确定最终方案,填写决策分析报告。
6、决策分析结果
七、项目监控实践
1、监控依据
- 过程体系文件《项目监控过程》
- 模版:个人工作周报、项目工作周报、里程碑报告、例会会议纪要、外部干系人管理记录
2、入口准则
- 项目计划已发布。
- 项目组人员已到位,并得到相关培训。
3、监控输入
- 项目实施计划
- 项目进度计划
- 质量保证计划与跟踪表
- 配置管理计划与跟踪表
- 风险管理跟踪表
4、监控输出
- 项目进度计划(已更新)
- 个人工作周报
- 项目工作周报
- 项目度量数据库
- 里程碑报告
- 例会会议纪要
- 里程碑评审会议纪要
- 风险管理跟踪表(已更新)
- 外部干系人管理记录
5、证据举例
- 工作进度及完成工作量,识别项目偏差并分析;
- 识别问题并分析问题;
- 识别风险并跟踪风险,对项目风险进行规避,直至关闭;
- 按进度计划,安排组员的具体任务(TFS),并协调相关任务;
- QA监控过程符合状况;
- 进行干系人计划跟踪,组织干系人参与里程碑会议和其他讨论会。
八、度量实践
1、度量体系简介
- 项目性能度量:监控项目性能,保证项目能够按计划要求完成项目任务
- 产品质量度量:监控项目产品工作质量,保证项目能够高质量地完成
- 需求变更度量:监控项目需求稳定性,保证通过需求管理及需求开发活动,减少需求变更
- 过程质量度量:监控项目过程质量,保证QA人员能够了解项目成员对过程的遵守程度,识别不符合项高的过程加以指导和审计
- 项目规模度量:监控项目的规模,识别估计规模和实际规模的偏差
- 其它度量数据:监控各阶段的评审和测试方式、资源投入、人员水平、各过程的复用率、覆盖率、按期交付率
- PV:计划工作量的预算成本
- EV:已经完成工作量的预算成本
- AC:已经完成工作量的实际成本。
- 进度偏差率(SV%):进度偏差SV(SV=EV-PV)与计划工时的预算成本BCWS(PV)之间的比值
- 成本偏差率(CV%):成本差异CV(CV=EV-AC)与已完成工时的预算成本BCWP(EV)的比值
- 进度性能指标(SPI)
- 成本性能指标(CPI)
2、度量数据收集来源
- 报工系统
- 技术评审报告
- 各类测试报告
- 周例会
3、度量数据记录在度量数据库里
4、度量过程
5、度量分析
九、项目风险管理实践
1、概述(基本概念补充)
- 风险规避:是改变项目计划来消除特定风险事件的威胁。例如,对于开发过程中存在的技术风险,我们可以采用成熟的技术,团队成员熟悉的技术或迭代式的开发过程等方法来规避风险。
- 风险转移:是转移风险的后果给第三方,通过合同的约定,由保证策略或者供应商担保。
- 风险减轻:是减少不利的风险事件的后果和可能性到一个可以接受的范围。通常在项目的早期采取风险减轻策略可以收到更好的效果。
- 风险接受:准备应对风险事件,包括积极的开发应急计划,或者消极的接受风险的后果。对于不可预见的风险,例如不可抗力;或者在风险规避,风险转移或者风险减轻不可行,或者上述活动执行成本超过接受风险的情况下采用。
- 不稳定的需求
- 复杂、不成熟的技术
- 过多的接口
- 客户的配合情况
- 团队技术水平低
2、识别风险与风险分析
- 风险影响范围包括:范围、成本、进度、质量等项,每项分为1~5级(例如成本5级划分如下:小于5%的成本增加、5%~10%的成本增加、11%~20%的成本增加、21%~30%的成本增加、大于30%的成本增加)。
- 风险发生概率也分成5级
3、风险应对措施/计划
- 首先,参考公司资产库中的风险库(风险列表),公司以往最佳实践所提供的应对措施,业界常用的应对措施;
- 接着,是团队的智慧,大家讨论。
4、如何跟踪风险,跟踪哪些?
- 跟踪开放状态风险及其应对措施
- 跟踪重新分析
- 不断识别新风险
5、举例说明本项目风险跟踪情况
- 人力资源不足,资源负载严重,可能影响项目进度、质量,来源是不稳定的团队;
- 不能按进度计划要求完成项目开发各阶段任务,来源是技术不成熟。
十、技术评审与测试
1、技术评审概况
- 评审规模、规模单位(例如页数)
- 预评审工作量(人时)
- 评审人数
- 评审总工作量
- 缺陷数量
3、评审缺陷分类、等级
- 遗漏(M):Missing,工作产品遗漏了必要的内容。
- 错误(W):Wrong,工作产品存在错误。
- 其它(E):Extra,其它不属于以上两类的缺陷。
- 致命缺陷(A):指被评审的工作产品存在结构上或内容上的缺陷,如果不进行修正后续的工作无法开展或造成软件存在功能上的缺陷。
- 严重缺陷(B):指被评审的工作产品存在内容上的缺陷,如果不进行修正后续的工作可能产生更为严重的缺陷。
- 一般缺陷(C):指被评审的工作产品存在内容上的缺陷,如果不进行修正后续的工作基本不受影响,但可能对最终的软件产品质量造成一定影响。
- 轻微缺陷(D):指被评审的工作产品存在文字、规范等方面的缺陷,不会对最终的软件产品质量造成影响。
十一、软件开发过程中的知识点
1、需求跟踪矩阵的两个作用
2、需求变更评价及其影响分析
- 变更申请->变更分析->变更审批->变更执行->变更验证->重新入库与发布
- 变更起止时间、状态(开放、关闭)
3、变更影响值分析规则
十二、过程建议及贡献
1、建议采用商用级代码检查和自动化测试工具
2、项目贡献(对EPG贡献)
- 项目度量数据
- 项目经验教训(包括好的经验、不好的教训)
- 复用代码
- 好的工作产品,例如设计、架构
- CAR的输出
2013年11月1日补充。