文章吧手机版
《精益软件度量》经典读后感10篇
日期:2018-08-12 05:59:02 作者:文章吧 阅读:

《精益软件度量》经典读后感10篇

  《精益软件度量》是一本由张松著作人民邮电出版社出版的全彩图书,本书定价:59.00元,页数:244,特精心网络整理的一些读者读后感希望大家能有帮助

  《精益软件度量》读后感(一):度量新传

  软件度量是一个困难话题。对于软件度量的困惑,但凡有过此类经验的人必然深有体会。从事软件度量工作的人,几乎像古希腊神话中的西西弗斯一样,让人敬佩而又同情。然而,随着商用软件的发展,以及快速消费型软件的爆炸增长,缺乏度量的软件开发组织如同缺少导航设备的航海者,只能沿着看得见的海岸线航行,永远不敢深入远洋一步。

  幸运的是,有这样一本书,平实而又从容不迫讲述了软件度量的精巧所在。这就是《精益软件度量》。它不是纸上谈兵的泛泛之作,更不是剪刀协助下的资源浪费,它是一个实践者的感悟行业经验的升华。首先,书中界定了软件度量是什么,以及不是什么,让大家对软件度量有一个合理期待。然后根据精益思想确定了软件的度量框架,从价值效率质量能力等四个方面个子项,对软件度量进行细致的阐述。目的是为了软件组织自身的持续改进实现更大的价值。每个子项中,都有明确的目的、问题、细项说明,逐项说明为何、以及怎样进行该项的度量。既可以对读者有启发性的指导,也可以作为实践者的参考

  本书没有笼统地说“软件”的度量,而是对软件进行了分类,选取了典型互联网软件和电信软件作为两大案例详细地说明其中的差异,包括用户特征产品架构、开发团队、长期演进,以及这些特征在价值、效率、质量、能力方面的映射。从讲述方法上,本书从软件的应用场景开始,到如何建立某种特定类型研发模式,再到如何度量。不是就度量讲度量,而是通过建立与分析软件开发的过程,找出各阶段和各领域目标,然后再度量。涉及软件研发管理的全过程,可以当作一本软件项目如何管理的小型百科全书

  本书行文流畅,充满精巧的比喻,易读性高,读起让人不忍释手。推荐给各位读者,希望各位业界同仁共同推倒软件度量------这个山坡上的巨石

  胡荣亮 ——中兴通信业务技术部长

  《精益软件度量》读后感(二):本书是传统和精益、敏捷之间沟 通的桥梁

  对于敏捷和精益产品开发,度量是一个容易引发争议却无法绕过的话题。讨论它并不容易,需要综合产品的设计、开发、营销,以及项目和组织的管理运营多方面因素考虑。正因为此,我相信由张松来讨论这个话题再合适不过。一方面,张松的实践经验从相对传统的电信和金融行业跨越到互联网前沿等诸多领域,职能也从软件开发跨越到组织运营的诸多方面;另一方面,近年来张松作为Thoughtworks咨询师和团队管理者,在敏捷和精益实施方面进行了持续的探索、实践和总结

  有效的度量体系首先应该是面向价值的。度量目的不是“控制”,而是改进价值交付能力。本书从价值的定义出发构建度量体系,涵盖价值交付的灵活性、速率、质量,以及组织的价值交付能力。软件开发是一个复杂系统,度量同样也不简单作者始终以精益思想和系统思考为指导,为我们呈现了一个端到端的系统的面向价值的度量体系。

  好的度量体系更应该是面向实施的。本书的理论全部提炼自作者的亲身实践,在前两个部分(第1到第12章),作者一梁一柱、一砖一瓦地构建度量体系,虽然系统性强,但多少有枯燥。到了第三部分(最后3章),作者开始讨论度量体系的导入和部署,此时读者会发现,原来所有的理论都将落实到实践,并且有现实案例的支持,一切都是那样自然,仿佛度量本来就应该是这样。

  刚拿到书稿时,我担心它的受众有限一线的实践者,如敏捷开发的实施者往往并不关注度量;而对于还未开始实施敏捷和精益开发的朋友,书中的概念又太过超前。读完书稿,再去反思这个问题,我深知本书的价值所在。对于实践者,本书提供了全新的视角本源去反思相关实践的效用,为进一步改进方向寻求切实的依据;对于正在评估计划实施敏捷和精益开发的朋友,本书是传统和精益、敏捷之间沟通的桥梁,它没有直接推荐具体实践,而是引导大家从价值去反思,我们需要什么样的改进,如何设定改进的目标,评估改进的效果,并为实施的动态计划和调整提供可靠的依据。

  希望你和我一样喜欢这本书,在阅读过程中和作者一起思考、总结,在实践中完善提升

  上海贝尔有限公司软件开发团队负责人 何勉

  《精益软件度量》读后感(三):一本开创性的佳作

  软件项目、软件组织和软件专业人士的度量是一个由来已久难题

  当ISO、CMM等“重量级”管理方法占据言论主导地位时,我们看到管理者们拿出条目繁多的度量方法和KPI,试图量化员工的工作绩效;与此同时员工们却一边抱怨冗杂的报告数据表,一边行之有效地找到了敷衍“上头”使他们不再干扰自己正常工作的妙策,顺便——借由呆伯特漫画——嘲笑高高在上不知民间疾苦的管理者们。

  而当SCRUM、看板之类“敏捷”方法甚嚣尘上,被一句“人和交互重于流程工具激励起来的程序员们高声喊出“我们不要文档/度量/KPI,我们交付可工作的软件”;而——绝非邪恶的——软件组织领导者们则郁结于如何在更大范围、更长周期了解员工和团队的状态和能力水平。毕竟,如果连“全局究竟是什么样子都无法看到,“全局优化”就只能是一句空话

  我无意在此引发又一轮软件方法学之争,只想提醒读者的注意:对于度量这件事,我们这个行业存在着如此明显张力,使得任何一位严肃领导者乃至从业者都无法也不该忽视其中的挑战。一方面,所有人都赞同:“好的”度量对组织以及个人都将大有裨益;另一方面,真正找到“好的”度量方法者寥寥。这个问题的解决,需要丰富的软件、工程、管理乃至商业理论与实践经验的深度结合,并且需要在实际运用中不断改善精炼。

  在所有探索有效软件度量方法的尝试中,这本《精益软件度量》是一本开创性的佳作。从精益软件开发入手,作者首先建立了一个适用于现代软件组织的度量体系。基于这个体系,作者介绍了如何对软件的价值、速度、质量等每个软件组织都高度重视核心要素进行有效度量。

  如果前面这些还是其他著作也有所提及的内容,接下来的部分就是极具开创性——而且极具价值——的思考与经验了。除了软件交付的“业务”本身,作者专章论述了如何对软件组织及从业者个人的能力进行度量,并给出了建设学习型组织、持续提升组织和个人能力的指导。最后,作者还以可观篇幅讲述如何在一个“传统”的软件组织中引入这些精益度量方法,以度量的植入来拉动软件组织的精益转型。这种饱经思辨又与实践紧密结合的“落地指南”,是我在论述同类主题的其他著作中从未见过的。

  整本《精益软件度量》读完,除了丰富的思想与实践,字里行间还渗出一种浓浓的人文关怀。作者在第一章就明确指出:“在理念上,我们希望把度量的重心从‘控制’转向‘改进’。”面对加速变化世界,只有充分发挥员工的主观能动性、帮助员工提升自身能力,企业才能具备长久竞争力。而管理者或领导者更多地需要扮演“导师”和“服务员”的角色:引导、帮助员工成长去达成他们自己向往的目标,而非以度量指标来控制员工的行为。这种管理思路转变,意欲为自己的组织引入度量体系的领导者不可不察。

  有幸作为张松的同事,与他在最近几年紧密合作,使我清楚地知道:讲述这样一个主题,松哥正是最理想的作者。在加入ThoughtWorks之前,松哥就有着MBA背景及在大型IT企业中工作的经验;在ThoughtWorks的6年中,他在大规模离岸交付项目中艰苦奋战过,也在国内超大型IT组织的敏捷转型中舌战群儒过;作为交付总监咨询总监他体会过同时关注十余个项目时的惶恐无力,作为人力资源总监他清楚打造一支持续学习、持续改进的团队对于整个企业而言是何其重要。而且在ThoughtWorks中国区管理团队中,松哥一向扮演着“智库”角色:虽然说话不多、嗓门不大,却总是字字珠玑,每每使我们其他成员受益良多。现在松哥的思想与实践得以付梓,使更多读者得以分享他从若干焦油坑中淬炼的菁华,实在幸事一件。

  更多的阅读乐趣,还是留给读者自己在翻开书之后慢慢体会吧。作为在国内帮助IT组织进行精益转型的实践者之一,我希望这本《精益软件度量》能帮助它的读者在他们的组织中建立一套行之有效的度量体系,并最终帮助这些组织的员工切实地提升自己的能力。如此,善莫大焉

  ThoughtWorks中国 熊节

  《精益软件度量》读后感(四):内容相当全,实际运用需要读者自己多思量

  介绍了很多的度量指标,也旁征博引了很多其他书籍专家们的说法。但很好奇为啥有很多书籍都有中文版,书中在引用时却基本上全部使用的是英文名称,这样不太方便读者搜索进行衍生阅读。

  如下是对文中部分内容要点的摘抄。

  2 Roger Martin在他的著作《The Design of Businesses: Why Design Thinking is the Next Competitive Advantage》把知识的演进用一个知识漏斗生动形象描述了出来。这个漏斗总是从一个问题开始,需要经过谜题(Mystery)、启发(Heuristic)和算法(Algorithm)三个阶段。

  3 Roger在书中提出了两种思考问题的方式:分析性思维和启发性思维。

  5 《大学》第三章:“汤之《盘铭》曰:‘苟日新,日日新,又日新。’”

  6 度量是什么:(1)度量是在一个特定组织上下文中形成的一系列共识;(2)度量是将经验模型向量化模型进行匹配的尝试;(3)度量是包含人、流程、组织和工具的一个动态系统。

  10 度量不是什么:(1)度量不是软件开发固有的活动;(2)度量应该避免跟绩效直接相关;(3)度量不是免费的。

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

  24 我们可以把质量分为当期版本的质量和持续提供高质量软件的成本两个问题,这其实就是产品外部质量和内部质量问题。

  27 Barry Boehm和Richard Turner在“Balancing Agility and Discipline: A Guide for the Perplexed”里提到,5个方面的因素会在很大程度影响开发的组织模型和流程模型:(1)关键性——缺陷带来的影响;(2)参与人员的水平;(3)动态性——需求的变化频率和程度;(4)文化——团队有对混乱秩序偏好;(5)规模——产品和项目规模。

  33 研发竞争力的提升必须要以项目为载体,在实践当中部署实施。

  50 随着时间流逝,流程和指标变得越来越复杂,由于执行贯彻的难度和成本已经使其成为正常运转的枷锁,整套体系形同虚设,最后就没什么人会再关心什么是真实地被落实了。

  - @徐毅:其实就是指标体系设计理念的传承问题。另一方面也是组织到底要一套所谓完整的指标还是要人们认可理解且知道如何执行的一套指标,如果人们不能理解,指标再牛逼也没有用

  51 指标演进所面临的一个明显的挑战是历史数据的保留延续

  - @徐毅:度量数据本身的传承。如果度量标准总是变,那么历史数据的参考价值就会被弱化很多。

  52 我们希望做到的,首先,每个层面的度量信息应该能对本级组织的改进活动提供帮助。

  54 一个开发组织中被度量的对象主要包括两个部分:交付流程、交付对象。

  - @徐毅:就是过程和结果

  57 锚定偏见/基准点偏见(anchoring bias):Tversky & Kahneman,1974

  114 “估”的另一个重要因素——可能性。这个数字是建立在什么样的置信水平(信心度)上的呢?

  114 总的来说,估算有3个主要作用预测、控制、提升。

  118 总的来说,正像Steve McConnell指出的:“不要指望任何单个维度生产力指标能够给你一个关于个体生产效率的完善图景。”

  119 如果把软件开发组织的活动看作是一个动态的系统,提高系统能力的方法主要有3个方面:提高个体的交付能力;优化系统的结构;减少交付活动中的浪费。

  140 业界有试验研究显示,圈复杂度38代码出错的概率达到50%,而圈复杂度在74的代码出错的可能性增加到98%

  - http://www.enerjy.com/blog/?p=198

  140 McCABE指出,如果测试路径数小于复杂度,则有3种情况:(1)需要更多的测试;(2)某些判断点可以去掉;(3)某些判断点可用插入式代码替换。

  141 CheckStyle里用的是类数据的抽象耦合(DAC-Class Data Abstraction Coupling)和类的分散复杂度(ClassFanOutComplexity)。

  141 内聚度的一个指标是缺乏内聚的方法数量(LCOM4 - Lack of Cohesion of Methods)。

  170 Geoff Colvin在《Talent is Overrated》里认为,科学界至今没有发现什么特定的基因是跟某项天赋联系起来的,他认为“刻意练习”才是在任何领域取得世界级水平的关键。他提到的“刻意练习”有这么几个特点:为提升而特意设计;持续得到结果的反馈;不断重复;对精神上的专注有很高的要求。

  182 Watkins和Marsick文章中的DLOQ(Dimensions of the Learning Organization Questionnaire)模型。

  - 在个体的层面,这个模型关注的是:创造持续学习的机会;促进探寻和对话活动;鼓励协作和团队学习;使人们能够寻求共同愿景。

  - 结构这个层面是联系个体学习活动和组织目标和产出的桥梁:连接组织与其所处的环境;建立捕获和共享学习的系统;为持续学习提供战略层面的领导力量。

  197 度量数据是来自一线,第一决策点是在一线,第一目标是帮助一线团队和个人的改进和提升。

  206 度量的作用是引导开发组织根据自身的目标,做到“大处着眼,小处入手,失败趁早,学习赶快”(Think Big, Act Small, Fail Fast, Learn Rapidly,引用自Marry & Tom Poppendieck的《Lean Software Development: An Agile Toolkit, 2003》。)

  228 Everett Rogers的《Diffusion of Innovations》

  233 Marry Poppendieck认为责任(做什么)、知识(怎么做)、行动(完成工作)、反馈(从结果中学习),这些活动的割裂是造成移交(Handover)这种浪费产生的原因。

  【附录 指标和优先级评估示例】

  交付周期:

  - 版本发布周期

  - 特性交付周期(需求-验收)

  - 特性开发周期(设计-功能/集成测试)

  - 特性库存周期

  - 用户故事平均周期

  - 用户故事库存周期

  - 缺陷交付周期(识别-交付)

  - 缺陷修复周期(定位-修复)

  价值和效率:

  - 版本交付价值

  - 迭代交付价值

  - DoD(单元测试/功能测试/联调/集成测试)

  - 迭代产能平均值

  - 迭代产能趋势

  - 团队日均代码合入量

  - 人均日合入次数

  - 团队日均合入次数

  - 待功能测试(特性数/估算工作量)

  - 待联调(特性数/估算工作量)

  - 待集成测试(特性数/估算工作量)

  - 待分析(用户故事数/估算工作量)

  - 待开发(用户故事数/估算工作量)

  - 待测试(用户故事数/估算工作量)

  浪费:

  - 对发布无价值的产物或活动

  - 分析未开发的需求(条数/分析小时数)

  - 开发未测试的代码(KLOC)

  - 未更新的文档(字数)

  - 设计未执行的测试用例

  - 超过n次重复的手工测试用例数

  - 特性平均待功能测试周期

  - 特性平均待联调周期

  - 特性平均待集成测试周期

  - 用户故事平均待分析周期

  - 用户故事平均待开发周期

  - 用户故事平均待测试周期

  - 与迭代目标无关活动的时间

  - 支持活动(团队小时/迭代)

  - 任务切换

  - 等待依赖(设备、环境、系统)

  《精益软件度量》读后感(五):这也是一本关于知识型项目和团队管理的书,读出了精彩哦

  作为一个从未涉足软件开发行业的读者,终于也磕磕绊绊的读完了这本书。

  书名起得不够朴实,读完以后才发现,意思是:为了实现软件开发过程(以及软件开发团队)的持续优化和改进、更快更好地向客户(或用户)交付开发成果,而使用有效度量管理手段的理论、方法和实务。在度量方法的设计和实施中,借鉴了现代制造业精益生产的理念。

  很大程度上,这是一本关于知识型项目管理和团队管理的书。只要是以团队协作模式交付智力成果为目标的部门、企业、机构,比如企业的研发部门、管理咨询公司、知识外包公司、甚至是提供法律财税等专业服务的事务所,许多场景、目标以及方法,都是相通的:采用一些度量指标进行项目管理的首要目标是业务实施过程的改进,当然,附带也是与客户(或用户)有效沟通的手段。

  在制造领域,可以通过人机配置、产线布局的不断优化,每个岗位设置标准作业流程等一系列方法,不断提高生产效率、并且产品缺陷趋近于零。可是,当产品是智力成果而生产工具是一群人的脑力时,一个精准的计划、控制、反馈、再校准的持续改进循环就真的成了谜题。就像书中所说,必须要真正了解一个特定组织中的习惯和内在关系,深入各个层面的工作活动,留心相关的人、事、物,切身体验和研究任何干预行动会对周遭人物的行为产生的影响,才有可能摸索出真正合适的方式和方法。

  即便是谜题,文中还是给出了许多有效、实用的方法,或者说对于知识型项目管理和团队管理非常有借鉴意义的实务解决方案。为了达到“有图有真相”的说服力,作者也算是煞费苦心:(1)对于书中试图建立的一套度量体系,包括度量的目标、“价值、效率、质量、能力”几个度量维度和相应的度量指标时,书中引用了大量目前业界已经非常有影响力的书籍和理论作为其逻辑基础,这也便于有兴趣追根求源或进一步提升理论水平的读者很快找到源头;(2)在具体阐述每个维度的度量方法和指标的评价时,结合了案例、真实项目管理场景的照片、基于业界实践的统计结论和控制管理图表等等;(3) 是把这些方法用在一个大案例上的实务操练,从客户需求、客户心态开始,到业务如何展开、沟通过程,以至于业务内部管理和与客户沟通的工作底稿样本(比如说客户访谈记录、业务关键点分析书等等)都一应俱全。

  特别有价值的是,全篇都贯穿着真实业务场景中作为一个项目管理者对于客户和项目组成员的心态和行为的分析和思考,还专门有一章分享了如何建立学习型组织的心得。这些地方,我一个软件业外人士,都读得津津有味,我猜如果是软件项目管理人员,这种在真实场景下脑力冲浪的感觉应该更明显吧。

  不得不吐槽,这本书使用的文字不太“用户友好”,特别是一些引用外文书的翻译文字,翻译得有些生硬。还有,许多软件行业的术语实在难懂,比如第一章就抛出什么故事点、燃烧图、粒度、特性之类的抽象文字,还不加以解释,我差点在第一章就弃书了。还好坚持下来,才读到了后面的精彩。

  《精益软件度量》读后感(六):只看到一半已经觉得受益匪浅,力荐做为软件开发团队的leader们的必读书籍!

  做为一位为客户提供软件定制开发服务的项目经理,有时遇到客户提出这样的问题和要求,“如何证明你选择了这个开发或管理实践提高了效率,交付了更多价值?” ;“我需要你们在每周的项目报告中提供详细的User Story状态变更情况,Defect数量及原因相关数据”(项目管理软件中已经能得到这些数据,但由于客户的工作习惯,他们仍然希望按照他们的excel表报告格式再提供一些报告)。我理解客户希望通过收集数据来增加他们对项目的把控,然而,做为长期使用敏捷/精益方法的团队,大家对花额外的时间来做这些不对交付提供直接价值的工作多少有些抵触。同时客户的高层和我也都清楚,不恰当的度量可能会使团队为了满足某个指标,而做出其他对项目不利的事情。比如客户担心度量Defect数量会使团队在开发阶段隐瞒Defect。但是在说服客户所有决策人员放弃低价值统计工作,以及如何解决客户提到的度量问题还是没能找到很好的解决办法。

  这本《精准软件度量》很好地解决了我以上的困惑。书里分析了度量存在的误区,明确了度量体系的作用,即“提供信息来帮我们知道我们现在哪里,距离目标到底有多远, 我们是否在向目标前进,以及进展的程度。因此简单地说,度量是通过对目标位置、相对位置、移动方向的描述,更好的帮助组织达成其业务目标。”

  同时书中也列出了度量带来的问题,比如度量不为产品或服务创造直接价值,度量应避免跟绩效直接相关,度量不是免费的观点。对于如何选择度量指标,如何统计数据、如何规避度量指标的缺陷也给出了详细的建议。

  这些内容加深了我对度量价值的理解,提供了跟客户沟通的论据,并对在自己的项目上选择哪些度量指标提供了很多指导。

  力荐做为软件开发团队的leader们的必读书籍。

  《精益软件度量》读后感(七):实施精益软件开发所需要的基本的度量都概括了

  本书大概是目前市面上能找到的比较全的介绍精益软件开发度量方面的书的唯一一本吧。所以说“开创性”的也不为过。作为繁忙的IT人,读大部头的度量书是不切实际的。所以,很需要这样一本概括比较全,内容又不是那种平时用不到的繁杂的度量算法的那种书。从这个角度出发,本书很符合我的需要。

  本书结构也比较清晰,读者对象大概是对精益软件开发经验比较欠缺的组织和个人,所以,介绍精益的理念和做法占了比较大的篇幅,但是也可以理解。 精华在于,对于由“如何更好地进行软件开发”这个谜题引出来的对于精益软件度量的解答:对于一个企业价值,生产效率,质量(内部质量和外部质量)和能力的度量。

  不过看完也是有点小小的失望,也是觉得理论有点过多,基础知识普及有点多了。如果实际的例子和度量指标的关系更多一些,就会有更眼前一亮的感觉了。希望能看到关于这方面讲述更深入的书出现。

  《精益软件度量》读后感(八):你如果无法度量它,就无法管理它

  管理学大师彼得德鲁克曾经说过“你如果无法度量它,就无法管理它”(“It you can’t measure it, you can’t manage it”)。要想有效管理,就难以绕开度量的问题。

  可实际上人们总是倾向于关注容易度量的元素,而忽略难以度量的元素。容易度量的不一定是重要的,难以度量的反而可能是重要的。

  软件开发的过程中就是这样。

  Martin Fowler曾经说过,软件行业至今还没有找到一个可以有效度量软件开发生产效率(Productivity)的方法。想要度量生产效率,首先需要有可以量化的产出物。而软件的产出物是什么呢?人们最直观的结论是一行行的代码。可实际上代码行数的多少并不代表价值的多少,甚至代码产生的功能都不一定是。这些功能运行起来产生的业务价值才是真正的产出,而这又是难以度量的 。 Standish Group Study的一份报告就指出45%的代码在运营当中是从来不会被使用到的。最简单直接地对代码行数进行度量实际上是舍本逐末。

  度量也是一把双刃剑。度量具有极强的牵引性。它会激励你重视并改善能够度量的元素,但也可能使你忽视无法度量的元素并使之恶化。

  我曾经在有些软件开发的组织里看到过对开发人员用代码行数的度量来考核 。结果是产生了很多副作用 ,大量的拷贝复制,不合理的设计,产生了大量冗余的代码,不但难以理解和维护,甚至没有在实际运行中运营起来。这在造成大量的浪费同时, 也造成了软件质量的严重恶化。

  软件开发方法,尤其是敏捷开发方法,正在越来越多地借鉴精益生产中的管理理念,其中主要的核心就是持续改进。要想持续改进,除了对改进方向的经验性认识以外,可以量化的改进目标也是一个无法回避的环节。在大规模实施精益管理的过程中,如何找到合理的度量,并合理利用这些度量,始终是一个难题。

  国内国外的很多企业在实施敏捷精益软件开发方法的过程中,在不同的情况下使用了不同的方法尝试解决这个难题, 也产生了很多有效的和创造性的解决方案。可惜的是,很多优秀的想法只是在很小的范围内产生了影响,并没有被提炼出来,广为人知,

  很高兴终于看到一本书能够提炼汇总这些实践,形成一个比较完整的精益度量体系。

  张松有着国内国外软件行业的从业背景,十几年来一直沉浸在敏捷精益实施的第一线,参与了众多大小企业的转型实践,做为许多CIO和CTO 的专家顾问,在这个领域积累了大量实战经验。我想不出有更合适的人来写这本书了!

  感谢张松在忙碌的工作中抽出时间来完成这项工作,相信所有读到这本书的人都能从精益度量体系和这些实践案例中有所借鉴 。

  ThoughtWorks大中国区董事总经理 郭晓

评价:中立好评差评
【已有2位读者发表了评论】

┃ 《精益软件度量》经典读后感10篇的相关文章

┃ 每日推荐