读书笔记

“个体和互动高于流程和工具，可工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划”，敏捷的时代从四个短句开始，但是随着敏捷的流行，各种误解和“蹭热度”的产品也模糊了敏捷的根本思想，书名的clean正透露了作者想要追本溯源的想法——找到干净、整洁和最根本的敏捷思想和实践。

敏捷开发与反馈密不可分，敏捷开发以燃尽图等图表的形式为管理者提供了所需的数据，推动项目达到最佳效果。反馈是相对于乐观主义的一个准则，它可以呈现开发过程中遇到的问题，而且可以在多种时间级别中进行反馈。并且反馈越多，沟通就越容易，所谓“实践出真知”，反馈是一种通过实际状况来沟通的方式。

作者罗列了瀑布模型中分析、设计和实施三个阶段的典型活动，并且用“死亡行军”来形容最后的加班、赶工阶段，以此来代表一个失败的瀑布项目。然而敏捷不同，敏捷以迭代、sprint作为关键词，通过切分为子系统和一个迭代的实际数据来代替估算和预计，从而获得更加真实和准确的数据，打破乐观的幻想，帮助开发者更好地判断何时能够完成项目。

第二章提到：“要把敏捷做对，你需要结对编程、测试先行、重构并致力于简单设计”，这些实践都是为了避免交付糟糕的代码。通过这些敏捷的实践，每次迭代的结果都是技术上可部署、可发布的，团队的开发效率是相对稳定的，项目的结果是可预期的，变化是可以被轻松应对的，从而用户、客户、管理者和开发者对整个项目的期望可以被满足。

业务层面的敏捷实践包括计划游戏、小步发布、验收测试和完整团队。其中，用户故事是一个重要的概念，通过用户故事我们可以获得从用户角度出发的对系统功能的简短描述。用户故事结合卡片工具和迭代的方式，使得估算（故事点）可以更加精确，任务的完成次序更加明确。Git的存在使持续集成、持续部署和小步发布更加轻松，持续集成最大的优点就是避免了“集成地狱”，如果不进行频繁的集成，那么一次大规模的集成绝对会暴露一堆理不清剪还乱的bug。相反，持续集成可以轻松地定位到可能的问题的范围——那一定是最后集成进来的模块引入的问题。

团队层面的敏捷实践注重合作、交流和人以及团队的可持续发展，隐喻和词汇表都是为了让团队成员更好地沟通交流，而长时间的加班和持续的冲刺则是不利于可持续性发展的两个实践。

在技术实践的章节中提到了测试驱动开发，测试驱动开发倡导先写测试程序，然后编码实现其功能而得名。测试、实现、重构、测试等步骤是TDD的主要活动，开发者通过编写单元测试而获得对程序运行的信心，而这种信心又可以成为程序的一部分。同时，通过测试驱动开发，我们可以有效地避免过度设计带来的浪费，也可以在开发过程中拥有更全面的视角。但是，通过测试用例的编码不一定是真正实现了实际需求的，因此，重构就十分必要，结对编程也可以在一定程度上避免这个问题，让我们在关注测试用例的同时注重实际需求的实现。而测试驱动开发需要我们有勇气去放弃原有的代码，有勇气去大刀阔斧地修改原有的设计和实现，从而进行代码的重构，使得代码可以保持整洁有序的状态。

最后，作者指出了现在的组织在向敏捷转型、应用敏捷时遇到的问题，正如一开始提到的那样，敏捷逐渐模糊了最初的目标。软件匠艺就是在这种情况下被提出的，它作为敏捷的补充，关注软件开发的水准，希望可以稳步增加软件的价值，通过形成专业人员的社区和建立卓有成效的伙伴关系增加沟通和交流。