读书笔记：《敏捷整洁之道：回归本源》

“ 经常有朋友问有没有学习仿真的相关书籍推荐，于是搜集和阅读了一些，记录在这里，向大家分享。如果大家有觉得好的书籍，也请留言推荐，不胜感激。”

这本不是关于仿真，但是有助于了解仿真测试与软件开发、软件测试的关系。

（美）罗伯特·C. 马丁著；申健，何强，罗涛译. 北京：人民邮电出版社，2020.07

作为“敏捷宣言”的提出者之一的鲍勃大叔，在敏捷开发发展20年后，在本书中重申了敏捷的业务实践、团队实践和技术实践等关键点，以及对敏捷现状的看法。

除最后的总结外，全书共7章，概述如下：

第1章回顾了敏捷开发提出的背景，并对敏捷开发进行了概述。2001年的雪鸟会议上提出《敏捷宣言》：个体和互动高于流程和工具；工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划。

软件项目的质量、项目、成本和完成，只能四选三，不能全部实现，软件项目管理的目标是实现四个属性的平衡，而敏捷是一个帮助开发人员和管理人员进行务实的项目管理的框架。敏捷将项目分为很多次迭代，根据迭代中输出的数据评估下次迭代中能够完成的工作量和最终完成时间，按照业务价值排序确定下次迭代中应开发的任务。尽可能的保持保质量，并主要通过变更范围来管理时间表。

生命之环描述了如何进行极限编程实践，包括三个方面：业务实践，团队实践和技术实践。

第2章说明了为什么要采用敏捷。软件在生活中发挥越来越多的作用，因而其质量至关重要，敏捷高度重视纪律而非形式，敏捷开发就是承诺要拼尽全力，成为专业人士并倡导专业行为，这种专业性有助于保证软件质量。

管理者、用户和客户有很多期望，而敏捷可以满足这些：避免交付糟糕的代码、从技术上随时做好交付准备、稳定的生产率、划算的适应性、持续改进、敢于改善旧代码、QA发现所有需求都正常运行、测试自动化、可互相接手工作、诚实的估算开发周期、及时说“不”（不能完成）、持续主动学习、指导他人。

客户权利和开发人员权利相辅相成，平衡了两者的期望。客户权利条款，客户有权：①制定总体计划，并且知道完成的时间和成本；②在每次迭代得到最多的潜在价值；③在一个真实运行的系统看到进展，所指定的测试都能可重复地成功执行，以证明系统正常工作；④改变主意，要求替换功能或者修改优先级，而且不用付出高昂的成本；⑤在时间表与估算发生变化时得到通知，以便于及时选择如何缩小范围来达到项目日期要求；可以在任何时间取消项目，并留下一个有用且可用的系统，该系统的价值与迄今为止的投资相称。

开发人员权利条款，开发人员有权：①知道明确的需求优先级排序；②保持保质量的工作输出；③向伙伴、经理以及客户提出请求并获得帮助；④决定和更新自己的估算结果；⑤决定是否承接某种职责，而不接受指派。

第3章说明了生命之环中的业务实践，为软件开发团队与业务沟通的方式以及业务和开发团队管理项目的原则提供了框架，包括计划游戏、小布发布、验收测试和完整团队。

计划游戏告诉我们如何将项目分解和完成，具体过程是：①将项目目标转换为多个用户故事（从用户角度对系统功能的简短描述），并为每个故事估算点数（工作量）；②设定第一次迭代可完成的总故事点数，并选择高价值低成本的故事作为这次迭代中要完成的；③迭代中期节点前应编写完所有验收测试并自动化；④迭代的中期检查，将下半期的点数目标调整为上半期以完成的点数，并调整故事（可能增加或减少）；⑤迭代结束进行演示，展示功能的所有验收测试和单元测试都正常运行。注意：通过验收测试的故事才算是完成，因而一个故事中的任务实现了一部分不算完成，不计算点数。

小步发布建议开发团队应尽可能频繁地发布软件，实现持续交付。

验收测试，业务方编写形式化的测试来描述每个用户故事的行为，QA负责将这些测试自动化，而这些测试由开发人员运行并通过。

完整团队是说用开发人员、测试人员、管理人员等所有人是一个朝同一个目标前进的整体，而且物理距离越短，交流就越好，开发就越快、越准确。

第4章说明了生命之环中的团队实践，提供了开发团队内进行沟通和管理的框架和原则，包括隐喻、可持续节奏、代码集体所有和持续集成。

隐喻是为了有效地进行沟通，团队内部的受限制的、有纪律的词汇表，其中包含项目中的术语与概念，这个词汇表不一定是专业词汇，可以用生动形象的词汇代替。隐喻是整个项目各个阶段、所有人员使用的统一语言。

项目过程中要保持可持续的稳定输出节奏，加班、熬夜不是好的方式。

敏捷项目的代码由团队集体所有，任何团队成员可以随时检出代码，并改善项目中的任意模块。开发人员可以有所专长，但同时也必须是通才，保持在专长领域外的工作能力。代码集体所有使知识分散在团队中，极大提高了团队沟通和决策的能力。

持续集成，并持续构建（包含验收测试和单元测试）。持续构建应该永不失败。

站会中由每个开发人员回答三个问题：上次会议之后做了什么、下次会议之前做什么、什么阻碍了我。每人30秒，不要讨论、不要深入解释，经理和其他人可以旁听但不应插话。

第5章说明了生命之环中的技术实践，用以指导和约束程序员，来确保最高的技术质量，包括测试驱动开发、重构、简单设计和结对编程。

测试驱动开发TDD的三规则：①先编写一个需要通过的测试，然后才能开发编写生产代码；②只允许编写一个刚好未通过的测试；③只允许编写一个刚好能使当前失败测试通过的生产代码。通过按照三规则进行测试代码和生产代码的快速切换（可能几秒钟），推进开发过程。遵守三规则可以带来很多好处：更少的调试、高质量的详细文档、有趣、完备的测试、解耦，更重要的是TDD可以给你修改老旧代码的勇气，因为具有完备的测试套件，可以随时查看修改的结果。

重构是一个持续的过程，而不是定期执行的过程，也不会作为一个故事出现在项目计划中。在TDD三规则的基础上再结合重构过程，就成为“红-绿-重构”循环：①创建一个未通过的测试（红）；②聚焦于以粗劣的想法草草地使代码工作起来，测试通过（绿）；③清理代码（重构）；④下一个循环。

简单设计的意思是：仅编写必要的代码，使得程序结构保持最简单、最小和最富表现力。简单设计的目标是，只要有可能，尽量降低代码的设计复杂度和认知负担。

结对编程是两个人共同解决一个编程问题，结对时间通常短暂（常见的是不超过一两个小时，甚至30分钟）、结对伙伴不固定、角色不固定。

第6章讲述了敏捷转型过程中的一些困难。敏捷的价值观：①勇气，就是在合理范围内敢于冒险，坚持正确的信念（质量和纪律会提高速度）也需要勇气；②沟通，重视直接、频繁、跨渠道、面对面、非正式的沟通；③反馈，出现问题时及时反馈，从而及早识别、及时纠正；④简单，代码、沟通和行为都直截了当。

敏捷方法有很多，但是都殊途同归，最强烈的建议就是导入完整的生命之环，特别要包含技术实践，而不仅导入业务实践。

作者认为不存在大规模的敏捷，大型项目中众多项目的管理和协作有成熟的方法，敏捷团队只是在大型项目中需要协调的众多团队之一，敏捷解决的是小型软件团队管理的问题。

要进行敏捷开发，软件开发人员必须掌握一些核心工具，如编程语言、开发环境、数据格式、代码管理、持续集成、沟通工具和测试工具等，精通工具使开发人员能够专注开发本身，而不是一边工作一边操心工具。有很多实施敏捷的工具，但现成的工具不一定支持你团队的特有流程，可以先从简单的工具（如白板、卡片等）开始，先形成与当前特有环境兼容的工作模式。

第7章对软件匠艺进行了介绍。敏捷的发展过程中出现了一些问题，比如只关注流程、而不是完整的生命之环，比如期望实施敏捷流程后期望过高、而忽视了团队需要额外的辅导培训和学习、需要更多纪律和技术技能——敏捷和开发者渐行渐远，采用敏捷前存在的、以为会被敏捷解决的问题依然存在。

为提高软件开发水准，并重新明确敏捷最初的目标，2008年软件匠艺活动被发起，并在敏捷宣言的基础上提出了新的宣言，其价值观是：①不仅要让软件工作起来，更要精雕细琢；②不仅要响应变化，更要稳步增加价值；③不仅要有个体与交互，更要形成专业人员的社区；④不仅要与客户合作，更要建立卓有成效的伙伴关系。