4. 通用原则

　　?? 软件度量本身不要成为一个战略;

　　?? 在软件过程改善的全局战略中整合软件度量，为此应该拥有或者开发一种这样的战略来联合软件度量计划;

　　?? 带着共同目标与课题从点滴做起;

　　?? 设计一种持续的软件度量过程，以使其：

　　? 与组织目标与宗旨相联系

　　? 包括严格的定义

　　? 持续实施;

　　?? 在广泛实施所设计的度量手段和过程之前进行测试;

　　?? 对软件度量手段和度量活动的效果进行度量和监控。

　　弗罗哈克的实用软件度量原则：十大原则

　　弗罗哈克(William A.Florac)、帕克(Robert E.Park)和卡尔顿(Anita D.Carleton)在《实用软件度量：过程管理和改善度量》(Practical Software Measurement：Measuring for Process Management and Improvement)中提出成功的过程度量原则如下。

　　1. 过程度量受商业目标驱动;

　　2. 过程度量手段源自软件过程;

　　3. 有效度量需要明确阐述的可操作性的定义;

　　4. 不同的人拥有不同的度量观点和需求;

　　5. 度量结果必须在产生结果的过程和环境中检验;

　　6. 过程度量应当跨越整个生命周期;

　　7. 保持的数据应当提供分析未来的实际基线;

　　8. 度量是进行客观沟通交流的基础;

　　9. 在项目内部和项目之间对数据进行总计和比较需要细心和规划;

　　10. 结构性的度量过程将强化数据的可靠性。

　　软件度量的要点：来自实战的教训

　　软件度量这一作业本身比较难以在实际的软件开发中顺利操作，也难以在软件开发改善中产生立竿见影的效果，甚至会让人觉得这是枯燥无味的无用功。这往往会形成妨碍实施软件度量的阻力，挫伤软件度量人员的积极性和热情。那么，如何有效地推动软件度量，成为软件度量作业的重点课题。下面是软件度量作业的要点，可以作为推动软件度量作业的参考。

　　1. 从点滴开始。与其采用声势浩大的软件度量运动，还不如从点滴开始：让员工逐渐进入度量状态，避免因为大规模运动带来的不适和阻力。从点滴开始，从小规模的简单的度量项目开始，从能够吸引员工并能让其接纳的度量项目开始，保证软件度量能在避免受挫的情况下得以逐渐推进，同时尽可能提高软件度量的自动化程度。

　　2. 解释为什么。这是消除抵制情绪和消解阻力的重要环节，因为人们不会切实地践行那些他们没有真正理解和接纳的理念和措施。需让员工明白，使用度量将比没有任何度量要好;度量将在一定程度上增进对软件开发的理解、预测、评估、控制和改善;软件度量仅仅针对软件产品、项目和过程，而不针对个人;等等。

　　3. 根据项目实情加以具体实施。不同的项目拥有不同的产品、流程、环境、目标和顾客，顾客、软件开发人员、项目组甚至经营者对项目的需求也不同，必须聚焦于解决该项目在产品、流程等方面的问题，而不是直接套用以前曾经实施或者已经模式化的度量标准。

　　4. 共享数据。度量数据的共享这一行为本身具有四大好处：一则可以让员工感受到度量的切实性，即行动正在按照计划进展;二则可以为员工提供度量的反馈信息，以改进现状;三则可以通过比较，寻找佳实践，实施标杆学习;四则可以通过数据共享增进信任，消除软件度量可能带来的误解。

　　5. 保持简单易懂。简单易懂这一点对于降低度量过程中的理解成本、沟通成本和实施成本都不可或缺。因为软件开发人员没有必要成为软件度量理论、统计方法以及度量技术的专家，他们仅仅需要知道软件度量与解决问题之间的关系，知道如何简单高效地实施度量。

　　6. 塑造度量文化。在软件开发中有意识地塑造一种重视记录、亲近数据、偏好图表、基于度量进行作业的习惯或者说文化，将判断、分析和决策立基于可预测性、可控制性、可改善性之上。

　　软件度量的陷阱：直面铜板的反面

　　像铜板的正反两面，软件度量也具有正反两个方面的影响：正面效用在于通过度量获得定量化的可控过程，负面影响在于其过度滥用带来的危害，比如：

　　1. 软件开发的量化指标替代了开发目标。软件开发管理中定量化极为重要，这当然是指有目的的、毫无浪费的、明确的定量化。如果视软件度量为目的，那么软件度量会陷入可悲的误区：纯粹的量化指标替代了目标，数据淹没了宗旨，任务迷糊了方向，软件度量成为软件开发过程的目标而不是手段，成为应付考核和评价的功利性工具。指标仅仅是个反光镜，而不是行进的指向标。如果不能理解软件度量在商务上的目标，那么会出现这样的情况：收集了错误的数据，以及数据没有被正确使用。要想接近目标，双眼必须注视前方。

　　2. 软件开发的度量方法取代了度量理念。软件度量不仅仅包含着丰富多样的度量方法，更包含着博大精深的度量理念;不仅仅需要理解软件度量的方式方法，更要践行软件度量的理念。如果仅仅拘泥于软件度量的方式方法而忽略更为本质、更为精髓、更为深刻的理念，那么软件度量对于软件开发的意义不再重要，因为这种情况下的软件度量虽然获得了看似完美的躯壳，却丢失了灵魂。

　　3. 软件开发的度量结果成为奖惩的根本依据。软件度量的结果如果成为考核和奖惩的根本依据，那么偏离了软件度量的用途：软件度量只针对项目、产品和过程，用于对软件项目、产品和过程进行理解、分析、预测、评估和改善;软件度量从不针对个人，既不用于评估个人的能力，也不用于评估个人的绩效，更不用于作为个人奖惩的根据，这样才能保持数据的可靠性、客观性和准确性。如果软件度量针对个人，这将从根本上影响个人的态度和行为，并危害团队的绩效。永远不要让软件度量成为软件开发人员心理上的负担。

　　过程影响公司的首席咨询顾问卡尔?威格在其《软件度量的十大陷阱》一文中总结了软件度量应该避免的十大陷阱：

　　1. 缺乏管理承诺;

　　2. 度量得太多太早;

　　3. 度量得太少太晚;

　　4. 度量了错误的事项;

　　5. 度量定义不严密;

　　6. 度量用于评估个人;

　　7. 度量用于激励而非理解;

　　8. 仅仅收集但不使用数据;

　　9. 缺乏沟通和培训;

　　10. 曲解度量数据。

　　软件度量并非神话，从其诞生之日起没有预言过任何神话。软件度量仅仅是增进软件理解、预测、评价、控制和改善的富有助益的路径。如果仅仅寄希望于以统计为基础的软件度量来获取软件开发的所谓“银弹”，需要重温那句富有讽刺意味的名言：谎言有三种，即谎言、该死的谎言、统计数据。