精益软件度量

2013-5  

人民邮电出版社  

张松  

无  

《精益软件度量:实践者的观察与思考》内容简介：软件度量是当今软件开发行业的热点话题，但同时也是推广实施过程中的难题。一方面软件企业管理存在度量的迫切需求；另一方面，企业在推行软件度量的实践中问题颇多，效果不佳。人们迫切需要破解度量谜题，找到切实可行的软件度量实践方法。
《精益软件度量:实践者的观察与思考》并不试图描述一个完整的软件度量体系，也不会试图解决度量所面临的所有问题，只是从精益理念的角度，尝试重新梳理在中等规模到大规模软件开发中度量体系设计和实施的思路。全书分为3部分，共14章。第一部分包括第1章至第4章，介绍了精益软件开发中度量的理念和体系的设计。第二部分包括第5章至第12章，先阐述了流程建模、需求和功能划分的一些概念，然后分别从交付价值、市场响应速度、交付速率、质量和能力几方面探讨了度量维度的问题。第三部分包括第13章至第15章，介绍度量体系的导入和部署。前两章用案例的方式介绍了度量体系验证阶段的准备和工作，第15章初步探讨了如何在组织范围内部署和推广度量体系。
《精益软件度量:实践者的观察与思考》是作者结合自己在软件开发和项目咨询业界十几年的实践经验，针对软件度量的价值和意义、手段和方法、体系和实践的思考反思之作。《精益软件度量:实践者的观察与思考》对于软件企业和组织管理者、软件产品研发管理者、软件项目管理人员有很好的借鉴意义和启发价值，也可以供高等院校从事软件工程和软件度量研究和教学的老师阅读参考。

张松，应用开发工程师、产品研发工程师、方案架构师、项目经理，甚至售前、销售等各种角色。在过去十几年里，对软件的兴趣，使张松一直在这行当的一线体验着软件从业者所特有的辛劳和喜悦，并乐此不疲。在ThoughtWorks 中国分公司，张松现在承担着咨询总监的职责，负责中国市场的咨询业务。在这之前，他曾是多个交付项目的项目经理，并作为交付总监负责中国区项目组合的交付保障，此外他还为多个知名企业的产品研发机构或IT 组织提供长期的咨询服务。加入ThoughtWorks之前，张松是Aspect Enterprise Solutions Ltd（原OILspace Inc）上海代表处首席代表。张松拥有华中理工大学计算机工程学士学位和英国Warwick 大学MBA学位。

第1章 度量谜题 1.1 精益软件开发的度量体系 1.2 度量是什么 1.3 度量不是什么 第2章 组织目标 2.1 业务目标 2.2 开发组织的目标 2.2.1 交付价值 2.2.2 响应速度 2.2.3 交付速率 2.2.4 质量 2.2.5 能力 2.3 小结 第3章 决策场景 3.1 使用度量的人们 3.2 决策的组织上下文 3.3 项目决策的阶段 3.3.1 项目定义 3.3.2 项目执行 3.3.3 维护阶段 3.4 小结 第4章 指标框架 4.1 支撑决策的数据 4.2 指标 4.3 指标属性 4.4 指标优先级 4.5 指标体系的局限性 4.6 指标体系需要演进 4.7 度量信息的传播和使用 4.8 小结 第5章 度量对象模型 5.1 交付流程模型 5.2 交付对象模型 5.3 度量的边界——DoD（Definition of Done） 第6章 价值 6.1 识别和拆分高价值特性 6.2 反馈提升价值 6.3 减少没发挥价值的特性 6.4 交付价值的度量 6.4.1 发布前——评估待开发特性的价值 6.4.2 发布后——验证价值 6.4.3 尝试的价值 第7章 响应速度 7.1 响应时间的系统因素 7.1.1 WIP（Work In Progress—半成品） 7.1.2 系统资源利用率 7.1.3 需求的差异性 7.2 价值流图分析（VSM） 7.3 累积流图（Cumulative Flow Diagram） 7.4 库存类指标 7.5 小结 第8章 工作量估算 8.1 基于算法模型的估算技术 8.2 基于专家判断的估算技术 8.3 度量单位 8.3.1 功能点（Function Point） 8.3.2 用例点（User Case Point） 8.3.3 故事点（Story Point） 8.4 估算的选择和运用 8.4.1 项目定义 8.4.2 项目执行 8.4.3 估算的沟通 第9章 交付速率 9.1 度量交付速率 9.2 提高系统效率 9.2.1 提高个体的交付能力 9.2.2 优化系统的结构 9.2.3 减少浪费 9.2.4 关于浪费的小结 第10章 内部质量 10.1 技术债 10.1.1 技术债的常见来源 10.1.2 技术债的常见形式 10.2 技术债的度量 10.3 开发节奏 10.4 测试代码中的技术债 10.5 度量呈现 10.6 小结 第11章 外部质量 11.1 度量产品质量 11.1.1 用户满意度 11.1.2 产品可靠性 11.1.3 故障成本 11.2 提升开发过程质量 11.2.1 缺陷防范 11.2.2 更早发现缺陷 11.2.3 减少回归缺陷 11.3 小结 第12章 能力—学习型组织 12.1 个人能力 12.1.1 技术能力 12.1.2 主动能力 12.1.3 社交能力 12.1.4 行为度量 12.2 团队能力 12.3 学习型组织 12.3.1 创造持续学习的机会 12.3.2 促进探寻和对话活动 12.3.3 鼓励协作和团队学习 12.3.4 使人们能够寻求共同愿景 12.3.5 连接组织与其所处的环境 12.3.6 建立捕获和共享学习的系统 12.3.7 为持续学习提供战略层面的领导力量 12.3.8 阻碍因素 第13章 验证导入（准备篇） 13.1 试点 13.2 准备 13.3 评估 13.3.1 业务目标及度量 13.3.2 度量数据的消费者 13.3.3 团队／组织当前度量实践 第14章 验证导入（执行篇） 14.1 基准制定 14.2 目标细分 14.3 指标选择 14.4 数据的收集 14.5 数据的使用 14.5.1 横向比较 14.5.2 数据的呈现 14.6 反馈 第15章 实施推广 15.1 建立愿景 15.2 触发目标 15.3 度量组织 15.3.1 执行组织 15.3.2 能力中心 15.3.3 团队接口人 15.4 度量推广面对的人群 15.5 知识和能力的传播 15.6 实施 15.6.1 系统化VS灵活性 15.6.2 迭代式的实施 15.6.3 目标团队 15.6.4 数据 15.6.5 IT工具和设施 附录 指标和优先级评估示例 交付周期 价值和效率 浪费

版权页： 插图： 我们有时会听到这样的观点，“我们行业的客户不要快，6个月一次的交付已经是他们愿意承受的极限了”，又或是“我们是做企业软件，客户不想总是升级”，还有“我们的客户在招标的时候，他们的功能列表里包含了你能想象出来的所有特性，我们得想办法把所有的条目都打上勾才行”。这些需求似乎都在说，我们应该尽可能快地堆砌功能，单个特性的价值高低或是交付的早晚，其实并没有什么意义。 不过，客户之所以有这样的要求，其实很多情况是其面临某些约束而不得已的做法，并非真正的要求。下面是两个比较常见的约束。 一个是升级的成本和复杂度。如果这种类型的系统升级非常麻烦，成本很高，那么当然客户就不愿意使用新版本。这种现象更多是发生在硬件相关的软件开发领域，而现今在互联网和商用软件领域，一些随持续交付和DevOps兴起的部署和运营手段已经能很大程度上解决这个问题。 还有一个是质量风险。一般在生产环境运行了一段时间的版本都是相对稳定可用的，即使有问题基本也是已知和可控的。如果历史经验说明，新版本总是有较高的质量风险，需要经过一段时间，打上不少补丁才能稳定，而新特性的收益又非常有限，那么在积累的新特性产生的潜在受益远远大于潜在的风险之前，是没人愿意去升级现有产品的。 如果软件开发组织能够突破这两个约束，就可能开启一个全新的市场，将竞争对手远远抛在后面。就好像iPod在MP3市场上做到的，iPhone在智能手机市场上做到的，iPhone上市之前已经有不少智能手机，但大多数人都觉得手机搭载上那些笨拙而又不太实用的软件，意义不大，然而iPhone显然突破了在小屏幕上可用性和实用性的约束，释放出了一个新的巨大市场。 上面的两个约束跟产品形态和部署方式密切相关，业界有不少实践者在尝试各种解决方案，这些技术手段超出了本书的范围，我们现在关注的是管理手段所能够触及的优化空间。任何在软件行当里混过几年的人都知道，通过缩短交付周期来提高市场响应速度并不是一件容易的事情。要完成一个最小的交付单位，可能是一个最基本的端到端的特性，也可能是一个需要紧急修复的缺陷，要真地使其能够为用户产生价值，总有一些障碍是绕不过去的。

张松有着国内外软件行业的从业背景，十几年来一直沉浸在敏捷精益实施的第一线，参与了众多大小企业的转型实践，作为许多CIO 和CTO的专家顾问，在这个领域积累了大量实战经验。我想不出有更合适的人来写这本书了！——郭晓，ThoughtWorks大中国区董事总经理对于实践者，本书提供了全新的视角从本源去反思相关实践的效用，为进一步改进方向寻求切实的依据；对于正在评估和计划实施敏捷和精益开发的朋友，本书是传统和精益、敏捷之间沟通的桥梁。——何勉，上海贝尔有限公司软件开发团队负责人在所有探索有效软件度量方法的尝试中，本书是一本开创性的佳作。——熊节，ThoughtWorks中国本书不是纸上谈兵的泛泛之作，更不是剪刀协助下的资源浪费，它是一个实践者的感悟，行业经验的升华。——胡荣亮，中兴通信业务院技术部部长传统软件研发中的外包行为，显然是一种相对成功的度量，不论是按人头还是按时间，大体是买卖双方能共同接受的。精益软件开发更强调效率，用“外包”的度量方法显然已经不合时宜，作者针对这一难题结合自己多年从业经验进行思考，是值得鼓励的一件事情。——霍泰稳，InfoQ中文站联合创始人我看过很多关于精益软件开发的书籍，但是这本书让人眼前一亮：新的角度和更加务实的内容。过程改进需要数据的支持，如何精益地获得更为有效的数据，帮助高效、切实可行的过程改进，本书不但给出了路线图，而且对于每一个节点都给出了详尽的说明。相信管理者和团队在持续改进的过程中会从这本书获得收益。——袁斌，迅思威尔（AgileDo）资深敏捷教练软件企业和软件开发的管理者一直期望通过合理的技术手段来获取各种度量指标，但指标制定者和考核对象在实践中经常存在脱节的情况，而本书从实践者的角度很好地弥补这部分差距，对指标管理者也有借鉴价值。管理精髓在于实践，期待后续有更多的实战案例。——朱谷，中国惠普企业服务应用管理总监在实际开发工作中，特别是小的开发团队，软件量度常常被忽略。“精益（Lean）”的概念就是去掉浪费，而去掉浪费就首要是软件度量。了解这些，相信读者会不难发现此书的有用之处。——雷剑文（KimManLui） ， AGILE 2012技术评审，《Software Development Rhythms》作者作者在本书中分享了他在软件行业多年的实战经验，也分享了他对软件度量问题的思考。这本书给了我很多启发，我希望我能写出这样一本书。在此特别推荐。——王海鹏，资深软件工程师

《精益软件度量:实践者的观察与思考》为ThoughtWorks中国咨询总监力作，业内众多专家高度推荐、精益软件度量的深度观察和思考。

张松有着国内外软件行业的从业背景，十几年来一直沉浸在敏捷精益实施的第一线，参与了众多大小企业的转型实践，作为许多CIO和CTO的专家顾问，在这个领域积累了大量实战经验。我想不出有更合适的人来写这本书了！——郭晓，ThoughtWorks大中国区董事总经理对于实践者，本书提供了全新的视角从本源去反思相关实践的效用，为进一步改进方向寻求切实的依据；对于正在评估和计划实施敏捷和精益开发的朋友，本书是传统和精益、敏捷之间沟通的桥梁。——何勉，上海贝尔有限公司软件开发团队负责人在所有探索有效软件度量方法的尝试中，本书是一本开创性的佳作。——熊节，ThoughtWorks中国本书不是纸上谈兵的泛泛之作，更不是剪刀协助下的资源浪费，它是一个实践者的感悟，行业经验的升华。——胡荣亮，中兴通信业务院技术部部长传统软件研发中的外包行为，显然是一种相对成功的度量，不论是按人头还是按时间，大体是买卖双方能共同接受的。精益软件开发更强调效率，用“外包”的度量方法显然已经不合时宜，作者针对这一难题结合自己多年从业经验进行思考，是值得鼓励的一件事情。——霍泰稳，InfoQ中文站联合创始人我看过很多关于精益软件开发的书籍，但是这本书让人眼前一亮：新的角度和更加务实的内容。过程改进需要数据的支持，如何精益地获得更为有效的数据，帮助高效、切实可行的过程改进，本书不但给出了路线图，而且对于每一个节点都给出了详尽的说明。相信管理者和团队在持续改进的过程中会从这本书获得收益。——袁斌，迅思威尔（AgileDo）资深敏捷教练软件企业和软件开发的管理者一直期望通过合理的技术手段来获取各种度量指标，但指标制定者和考核对象在实践中经常存在脱节的情况，而本书从实践者的角度很好地弥补这部分差距，对指标管理者也有借鉴价值。管理精髓在于实践，期待后续有更多的实战案例。——朱谷，中国惠普企业服务应用管理总监在实际开发工作中，特别是小的开发团队，软件量度常常被忽略。“精益（Lean）”的概念就是去掉浪费，而去掉浪费就首要是软件度量。了解这些，相信读者会不难发现此书的有用之处。——雷剑文（KimManLui），AGILE 2012技术评审，《Software Development Rhythms》作者作者在本书中分享了他在软件行业多年的实战经验，也分享了他对软件度量问题的思考。这本书给了我很多启发，我希望我能写出这样一本书。在此特别推荐。——王海鹏，资深软件工程师

无

精益软件度量 PDF格式下载

买回来看了一下发现不是我想要的那种书，算了，先放着，以后无聊了再看。

很喜欢，可读性很强。

书中方法和案例来自作者自身实务经验和对业界优秀实践的总结，一些工具和图表很具有启发性。讲述时也不乏思辨精神，值得一读。

这本书在我看来比较适合两类读者群，一是IT和软件研发中高层管理人员，一是在一线实施精益和敏捷的教练，如何度量团队和组织持续改进的进度和质量，这本书旁征博引加上作者多年经验，给出了足够全面和细致的参考。

还行，能看出来作者对软件度量现状非常了解