《知行合一： 实现价值驱动的敏捷和精益开发》读后感6
6.1 再议技术债务
>> 技术债务是修复已上线程序中结构质量问题的成本，如果这些问题不解决，组织清楚其带来的后果：后续升级开发失控或用户操作失灵
>> 常见的债务来源有
>> 进度压力逼迫开发团队走“捷径”，如程序中不写注释，造成后期理解的困难；测试不充分，导致产品中存在操作隐患等。
>> 过早地选择了某个通信模式，后期的应
>> 未识别出程序其他需要修改之处，造成软件产品中的不一致。
用户故事没有得到足够的分解。分
>> 没有对复杂的、有依赖关系的技术文档、代码进行互查或评审
>> 缺少必要的系统文档支持
>> 需要整个团队考虑各种因素来确定，一般来讲一定要避免仅仅由团队去假设客户将来的需要！仅由开发预测未来需求，一般意味着麻烦
>> 有开发人员都需要接受重构方法技巧培训，并在开发中不断学习提升。
>> 技术债务的度量
近来业界提出了一些复杂的技术债务度量，这些方法很难真正被团队使用。其实一些简单的度量就可以刻画出债务状况，例如：
上线时发现的缺陷数；
维护中新功能开发的平均时间；
上线后修复缺陷的平均时间。
这些指标的增加，意味着技术债务的增加。
技术债务很难被量化，Israel Gat将其转换成钱。如修复5万行代码需要10万元的话，那么每行代码的代价就是2元。用这个方式和高管沟通技术债务，容易引起他们的关注。
如果使用这种方式度量债务，团队可以设定一个贷款限额（credit limit），当债务超出这个值的时候，也许你就不能再开发新功能了，需要静下心了还债了。
6.2 敏捷中的需求开发及管理
>> 贯穿整个开发过程中的需求澄清：串讲及反串讲
>> 。只有二意的需求，没有二意的程序！
>> 产品线的需求演变过程经历下列的形式：原始需求（Initial Requirement, IR）→特性需求（Feature Requirement, FeR→功能需求（Function Requirement, FuR）→已分配需求（Allocated Requirement, AR）→接口→验收标准。
上述产出物代表了需求逐步细化，向最终代码演进的过程。
6.3 敏捷中的设计和开发
>> 简明设计的以下4条要求（重要性由前到后）
>> 说明还不够简明
>> 所有需要沟通的思路都在系统里面有所体现
>> ）复制的逻辑或结构都会让代码难读难改。
>> 用最少的元素
>> 只发布必须发布的接口
相对于未发布接口——如J
>> 高内聚，低耦合
>> 解耦是降低模块间的依赖、提高复用的一个好办法。
>> 有明确的入口标准
>> 在制订计划时，需要根据评审规模，依据评审速率（如设计页数/小时、代码行数/小时等）安排评审的投入时间，保证必要的评审有效性（发现足够缺陷）
>> 收集评审效率数据并给出结论。评审中收集缺陷、投入时间等效率数据能够帮助我们更好地制订评审计划，也能指出评审短板。
6.4 敏捷中的测试
>> 6.4.1 测试驱动开发的价值及方法
质量意识宣传点
>> 持续集成：提高开发效率的重要保证
>> 持续集成：提高开发效率的重要保证
>> 每次集成都通过自动化的构建（包括编译、发布、自动化测试）来验证，从而第一时间发现集成中的错误，给出实时反馈
>> 持续集成系统应该具备下列能力。
提供统一的代码库。
>> 自动构建并能做到快速构建的能力。
>> 自动测试的能力。这也就是测试完全自动化，开发人员提供自测试的代码，任何人都可以只输入一条命令就运行一套完整的系统测试
>> 每个开发人员可以随时向代码库主干提交代码。这也就是提供主创建，让任何人都可以
>> 每次代码提交后都会在持续集成服务器上触发一次构建
>> 持续集成的关键是完全的自动化：读取源代码、编译、连接、测试，整个创建过程都应该自动完成。
>> 持续集成应该同时遵循下列原则。
（1）所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。
（2）开发人员每天至少向版本控制库中提交一次代码。
（3）开发人员每天至少需要从版本控制库中更新一次代码到本地机器。
（4）需要有专门的集成服务器来执行
>> 修复失败的构建是优先级最高的事情。
>> Humble（Humble et al.,2011）详细描述了持续集成的方法及实施。
>> 敏捷环境下如何执行单元测试、集成测试、验收测试和系统测试？在什么情况下，团队需要做手工测试呢？
>> 单元测试的构架是敏捷测试的关键环节，针对不同编程语言的xUnit构架都是很好的选择。
>> 些测试每日在构建服务器上会跑一到两次，也使用一些如前介绍的集成工具，如Hudson、Jenkins或Anthill等。
验收测试是系统行为驱动测试，在Scrum中由产品经理主导完成，XP则要求客户主导实施。
>> 让发现的缺陷的价值最大化
如何处理评审和各类测试发现的缺陷是软件组织成熟度的一个重要指标，成熟的组织会把每一个缺陷都当成改进的机会。
>> 以是迭代回顾会的一个重要议题。
这部分属于接下来重点改善点
>> 对于客户验收或用户使用中发现的缺陷，建议分析必须能回答下面4个问题。
（1）为什么内部评审、测试未能发现这个缺陷？应该是哪个环节发现？分析结果应该告诉我们哪里的网口太大，导致缺陷漏了过去，我们需要补上这些漏洞。
（2）提交程序的哪些模块可能有类似的缺陷？你应该主动告诉客户这些埋有同样“地雷”的模块，在其引爆之前将其清除。
（3）如何修复这个缺陷？相信你已经做了。
（4）如何保证类似缺陷不再出现？这个是最难做的，主要需要从人、方法过程角度来思考，这是团队效益最明显的改进点！
>> 对于客户验收或用户使用中发现的缺陷，建议分析必须能回答下面4个问题。
（1）为什么内部评审、测试未能发现这个缺陷？应该是哪个环节发现？分析结果应该告诉我们哪里的网口太大，导致缺陷漏了过去，我们需要补上这些漏洞。
（2）提交程序的哪些模块可能有类似的缺陷？你应该主动告诉客户这些埋有同样“地雷”的模块，在其引爆之前将其清除。
（3）如何修复这个缺陷？相信你已经做了。
（4）如何保证类似缺陷不再出现？这个是最难做的，主要需要从人、方法过程角度来思考，这是团队效益最明显的改进点！
