精益软件度量——实践者的观察与思考读书笔记二

我们不是为了度量而度量,我们要知道度量体系是在什么时候,为谁产生价值,因此我们首先需要回答3个问题:

1. 一个开发组织从来都不可能是独立存在的,其所服务的企业业务目标是什么?对应到对开发组织的期望是什么?

2. 在开发过程中,谁是度量信息的使用者?他们使用度量信息的目的是为了作什么决策?

3. 在梳理清楚上面两个问题之后,最后要回答的才是如何设计一个契合的指标体系来满足这些数据消费的需求?

因此,度量体系是引导团队达成业务目标的一整套策略,包含了业务目标、决策场景和指标体系3个阶段。

我们可以把软件产品的开发分成几个大的阶段:业务策略、项目定义、项目执行、维护支持。

从业务部门期望的及开发组织相关的业务目标可以提取出他们在软件度量角度的诉求:首先是相对竞争对手的响应速度,然后是产能的比较,最后是项目的投入产出--ROI。

业务对开发组织的期望大致分为几类:价值、效率、质量和能力,其中效率又包括对市场的响应速度和单位规模开发组织的产能。

交付价值

相对业务部门,开发组织的优势在于其所拥有关于目标实现方案的知识。交付目标是由一系列的功能性和非功能性需求构成,而交付价值首先体现在优先交付的内容是否是最有价值的。

对于功能性需求,开发组织能够在开发前,将低价值内容从高价值特性上剥离下来,从而提升投资回报(ROI)。

对于非功能性需求,很多情况下,开发组织提出的方案都会影响投入在短期和长期时间轴上的分配,因此,能够使技术方案跟业务模式相吻合,就有可能在相当程度上提升交付的价值。

从事后验证的角度来说,开发部门可以提供技术手段来度量交付后的特性价值。通过识别和清理死亡,休眠特性,减少后续在无用特性上进一步工作的可能性。

响应速度

响应速度意味着先发优势,抢占市场,尽快收集反馈,验证前面的判断,以便能做出调整,提高决策的准确度,享受科技产品生命周期前期的高额溢价,更快地回收成本和投资,取得更长的市场生命周期,当然,总体来说有更高的利润率和投资回报,以创新者、领先者的形象出现在市场上,可能产生巨大的无形资产,营销活动都有时效性,在合适的市场时间窗口退出竞争性产品能够帮助企业在获取市场份额上占得先机。

市场响应速度不仅是指当前一个独立版本的交付速度,还体现在提高差异化和定制版本的发布频率上。

产能

单位规模的组织在单位时间内所能交付的软件规模,即为产能。规模能够对软件开发效率带来2个正面效应:

1. 在以提高生产效率为目的的工具和基础设施上的投入可以被更广泛的共享

2. 产品和项目管理的成本不会直接随着项目规模的增大而增加。

不过经验告诉我们,规模似乎对软件开发效率带来更多的是负面效应:

1. 沟通成本:开发规模大了之后,团队成员之间、团队和团队之间的沟通路径是几何级数增长的

2. 人员投入程度:大团队增加了人员间个性冲突的概率,会造成团队内不良的化学反应,降低团队效率

3. 系统复杂度:更加难以评估引入变更的影响,也意味着系统维护、演进成本的增加。

对于软件开发组织来说,提高单位规模下的产能是从效率的角度提升竞争优势的关键。

质量

这里说的质量包括产品设计、用户体验、功能完善等。质量是个约束性的属性,对于一个特定的产品来说,其质量要求通常是相对稳定的。质量保障是通过系统化的一系列活动,提供足够的证据说明软件产品是适合使用的。

瀑布流程可靠性一方面来自于对开发活动在各个维度的细分,即精细化管理,以期事先能够把事情考虑得面面俱到,并通过流程手段保证该做的事情确实都会发生,另一方面其实就是在计划和流程上引入足够的缓冲空间。此外,还有一种手段就是缩短反馈周期。

提升信息有效性和时效性的关键是缩短信息的反馈周期。

能力

个人、团队、组织的能力是对上述3个因素有直接影响的要素。一个组织唯一可持续的竞争优势是比对手更快的学习能力。这种学习更重要的是从客户、市场、团队学习,从成功和失败中学习。

其实一个公司的差异化能力,有相当程度是受限于研发组织在交付周期、开发效率和质量各方面的能力,而这些能力并不是常量,是可以持续改善的。

大多数的度量都跟项目管理相关,但是项目管理也分不同的层面。首先需要在组织层面考虑各个目标的权衡,诸如交付、创新和能力提升,然后需要考虑本项目在产品或产品线组合中的位置、产品各个版本之间的关系,还要顾及项目目标和相关个人诉求之间的关系。

在达成目标的过程中,组织、团队和个人会遇到各种各样的决策点。

项目定义

问题定义:做正确的事情,第一步是要识别出正确的问题。清晰地定义问题是设定目标、制定计划的前提,我们经常会低估了问题本身的定义对后续方案产生的影响,实际上,仅仅是描述的不同都会对解决方案的方向产生重大的影响。

交付目标:一次交付的目标更可能是为了达成产品路线图上的一系列路标中的一个。这个路标可以是一个新的价值流的端到端的实现,也可以是在现有的价值流上增加不同场景,为用户提供更加丰富的选择。交付目标应该有可度量的开始点和截止点,也就是有清晰的边界。

提升目标:只有真实项目上的挑战才能激发人们学习和创造的潜力。一个组织要分析相关行业和竞争对手的数据,对自身交付竞争力作出评估,有策略地制定提升目标。研发竞争力的提升必须要以项目为载体,在实践中部署实施。

资源配置:资源的投入经常是多个项目、多个产品之间博弈的结果。项目管理人员需要根据项目的目的和里程碑来规划项目,在规划的时候需要覆盖进度、质量、资源和风险各个方面。

进度目标:里程碑提供了一个常规机制来跟踪项目的进展是否跟预期相符。里程碑的定义要有明确的目标。典型里程碑的标志通常是跟某交付物的验收结束相关,确保验证的力度和问题的解决符合预定的阶段性质量目标。

质量目标和手段:不同类型的产品有不同的质量目标。因此使用的测试手段和其他质量保障活动也会有所不同,需要不同的质量保障策略。

资源的规划:项目管理人员就需要用真凭实据,对照过往的历史数据和项目相关信息,提出资源的要求。

项目执行

干预通常主要出自以下两个方面:环境变化和内部变化。

对于项目管理来说,为管理层提供确实的数据,支持管理层决策是至关重要的:

1. 设定管理层对进度和质量的期望

2. 获取更多的资源,以较低的风险达成项目目标或是管理层的期望

3. 提高项目透明度,取得包括管理层在内的各方干系人的信任,以取得决策的权威

4. 预测项目的状态,争取管理层作出对项目有利的干预

5. 识别项目执行当中的瓶颈,做出相应调整,或是说服调动其他有资源、有权利的人作出调整

6. 识别项目执行过程中的浪费,积极采取措施消除浪费

而对于个人来说,一方面需要了解自己团队的进展如何,自己在团队中表现如何,另一方面需要知道项目和自己的风险,这里主要的风险是自己是否需要为项目进入危急状态买单呢,比如加班,还有就是周边团队的情况如何,是否给自己或自己团队拖后腿,最后是个人绩效和提升改进目标是否真的实现。

维护阶段

管理层在这个阶段更关心客户的满意度,主要体现在需求的价值命中率和客户满意度上。

项目管理人员需要再维护阶段管理客户和市场对维护响应的期望,因此需要知道以下内容:

1. 问题的优先级

2. 响应速度:支持团队对客户的响应周期

3. 响应质量

4. 维护成本

作者:Ribbon 出处: http://www.cnblogs.com/Ribbon/ 本文版权归作者和博客园共有,欢迎转载。未经作者同意下,必须在文章页面明显标出原文链接及作者,否则保留追究法律责任的权利。 如果您认为这篇文章还不错或者有所收获,可以点击右下角的【推荐】按钮,因为你的支持是我继续写作,分享的最大动力!
原文地址:https://www.cnblogs.com/Ribbon/p/3633121.html