SP 1.1 建立项目的目标:建立并维护项目的质量目标和过程性能目标
(1)项目的QPPO要根据项目的特点、组织级的QPPO、组织级的基线来确定。不应该所有项目的目标都是相同的,因为项目的特点是不同的。
(2)项目的QPPO要满足SMART原则。
(3)项目的QPPO要和历史的过程性能基线进行对比,判断目标达成的概率。
(4)项目的QPPO达成概率也可以通过过程性能模型进行预测。
(5)难以达成的目标,要制定对应的措施。
(6)措施的有效性应该有历史的数据来支持,而不仅仅是靠经验来判断。
(7)项目的QPPO不应该仅仅是某个局部郭晨的目标,要有整体与局部的目标。
(8)项目的QPPO不应该只关注质量一个维度,而应该包括多个维度的,比如还要有进度的目标等等。
(9)项目的QPPO不能到项目结束时才能监督其是否可以达成,而是在项目的初期与过程中可以预测、控制、监督其达成情况。
(10)对于多个QPPO,要划分优先级。
SP1.2 组合已定义过程:使用统计和其他量化技术,组合已定义的过程以确保实现项目的质量和过程性能目标。
(1)组合的动作包括:
a. 可以对工作流程进行最优化选择,以选择出实现目标的最优流程路径;
b. 可以设置每个子流程的投入情况,确定投入的多少,或者是选择不同的方法;
(2)组合的前提包括:
a. 针对实现同一个目的的子过程、方法分别建立了过程性能基线或模型;
b. 如果没有PPB或PPM,应该通过模拟或其他手段建立一个模型,分析如何选择最优的子过程。
(3)最优化决策选择子过程或其投入时,有目标,有限制条件,而不应该仅仅是单一目标的决策。
(4)在组合过程时,一定是采用定量的手段来做,而不应该仅仅是凭经验做选择。
(5)如果公司的过程仅仅定义了一条路径,那么就要确定每个子过程的投入程度。
(6)SP1.1是在基于历史判断目标的可实现性,SP1.2设计未来以确保目标的可实现性,在这两个实践中,都必须基于定量的分析判断目标的可实现性,而不是靠经验来判断。
SP1.3 选择子过程和属性:选择对于评价性能和帮助实现项目质量和过程性能目标的比较关键的子过程和属性。
(1)项目目标是如何实现的?是通过过程的执行实现的!
(2)是否所有的过程都很重要呢?不是,存在80-20现象,关键的过程与子过程影响了80%的目标结果,所以要找到关键的子过程进行管理!所以才有本实践!
(3)选择哪些关键的子过程呢?这些子过程的结果应该影响了项目组QPPO的达成!
(4)怎么证明这些子过程是关键的少数呢?要定量的判断,而不是经验判断!如果定量的判断呢?需要做了相关性分析、敏感性分析等,证明这些子过程的性能是和QPPO相关的。
(5)在判断子过程的性能与QPPO的相关性时,需要具体落实到子过程的某个属性,物理化为某个度量元,通过该度量元历史的数据证明其与QPPO是相关的。
(6)每个项目选中的子过程可能是不一样的!因为每个项目的特点是不同的!
SP1.4 选择度量元和分析技术:选择用以量化管理的度量元和分析技术。
(1)该实践是上一条实践进一步的细化。在选中了关键的子过程及其属性后,需要将这些属性进行定量刻画,就是物理化为某个度量元。
(2)当采集了相应的度量数据后,对该数据的分析方法是什么?这些说的统计技术包括:
统计过程控制,回归分析,数据分布分析等多种手段。
SP2.1 监督选中的子过程的性能:采用统计和其他量化技术监督选中的子过程的性能
(1)本实践提到的子过程就是SP1.3选中的那些影响了项目目标的少数的关键子过程。
(2)本实践关注的是子过程的性能,不是那些总体目标,而是局部的目标,是影响了项目总体目标的那些小目标,子目标。
(3)如何监督的呢?必须是采用了统计手段和其他量化手段。意味着,要监督了目标达成的概率!随着时间的推移,这个概率是变化的!
(4)监督的结果可能是发现了异常点或者发现了过程能力的不足。
(5)如果采用了SPC方法,则应识别了点出界或趋势异常,并计算了Cpk。
(6)如果采用了预测区间的方法,则应识别了点出界。
SP2.2 管理项目性能:运用统计和其他量化技术管理项目以确定项目的质量与过程性能目标是否可以达成。
(1)本实践关注的是项目的总体性能,是要管理总体目标的达成情况。
(2)此处的管理包含了这样几层意思:事先预测,事中控制,事后对比分析。
(3)和上一条实践一样,管理项目性能时,要采用统计的方法和其他量化方法!不能靠经验判断!
(4)判断实际结果是否达成了项目目标时,要看目标是如何定义的?比如你定义的目标是:
项目的代码评审缺陷密度都要大于10个/KLOC,则此时判断目标达成的方法,就是看项目的每次代码评审缺陷密度是否大于了10个/KLOC。
如果你定义的目标是:代码评审的平均缺陷密度大于10个/KLOC,则此时判断目标达成的方法就是统计所有代码评审的平均缺陷密度是否大于了10个/KLOC.
如果你的目标是:代码评审的缺陷密度处在区间10-20/KLOC之间,那么就是判断每次代码评审是否落在这个区间即可。
SP2.3 执行根因分析:对于选中的问题执行根因分析以处理实现项目质量与过程性能目标的偏差。
(1)一定是参照组织级或项目级定义的执行根因分析的触发条件,来选择根因分析的现象的!不能凭感觉,凭经验来判断,要根据规则来判断。
(2)为什么要对这些现象进行根因分析呢?因为他们影响了项目的性能,影响了项目的目标达成!
(3)应该如何做根因分析呢?应该采用了量化的手段。可能有:定量地识别现象、定量地查找原因、定量的预测改进的效果。
(4)分析原因采取措施后,是否见效了,应该执行假设检验!