作者：程序员罗尼｜发布：2020-11-29 ｜原文：https://mp.weixin.qq.com/s/dxLwBDY_UiMPmwg6Gjqalg

本篇文章为《Clean Agile》第一章的读书笔记

介绍敏捷

自2001年敏捷运动以来，敏捷运动引入了太多的误解和对原始概念的篡改，本书的目的是为了正本清源
多年以前，在软件开发中，是采用科学管理还是敏捷开发，大家也都拿不准该怎么办，科学管理提倡推迟行动，在事前进行详细的分析和设计，产出一个详细的计划；敏捷推崇小步前进，并在其中包含记录和改进
科学管理适合那些变更代价高昂的项目，用于解决定义清晰、目标明确的问题
相反，软件为什么叫 software，我们就是希望它易于更改，相比硬件，我们应该能轻易的通过更改软件来改变机器的行为，所以软件天生就是为了应对变化，而且应该是低成本的应对变化
科学管理带来了瀑布模型，但是多年以后，无数的项目证明瀑布模型在软件开发中行不通，渐渐地，各种不同的新思潮开始浮现
2001年，多位新思想的倡导者开了一个峰会，他们支持不同的开发实践，最终他们求同存异，产出了敏捷宣言，这份宣言的内容，如下

个体和互动高于流程和工具
可工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划

敏捷全貌

铁十字

质量、速度、成本、完成（全部需求），只能选三个，没法四个全要
高质量、快速、低成本，那这样项目就做不完（全部需求）
低成本、快速、完成，那质量就一定不会好

优秀的项目管理是平衡各种属性，推动一个项目变得足够高质量、快速、低成本，尽量按需完成
**重点：**敏捷为这种管理提供数据（真实的数据）
产出的数据汇总成两张关键的图表

一个是团队的速率图，也就是每个迭代能完成的故事点的数量
另一个是燃尽图，也就是每个迭代过后剩余的故事点的数量

戳破幻想

敏捷不等于快，我们将项目拆成小的迭代，就是要真实的，尽快的了解团队的产出速率，戳破幻想，接受现实

面对铁十字

有了项目的数据之后，项目的管理者就要确定项目在这四个方面的取舍程度了
管理者通过变更范围、时间表、人员和质量来调整铁十字，下面来逐个分析一下

一般时间表的确定是出于重要的商业目的，改变起来不太现实
增加人手也不可行，根据布鲁克斯定律，向延迟的项目增加人手，只会使它更延迟，主要原因是培训成本和沟通成本的增加产生的负面影响要强于增加人手带来的产出的增加
牺牲质量？那无异于饮鸩止渴，初期产出了垃圾代码，后期在垃圾代码上做变更，只会痛苦不堪，多年的软件开发经验告诉我们，快速前进的唯一方法就是把每一步都走扎实
最后唯一能做的就是变更范围了，我们对需求的业务价值进行排序，优先实现高价值的需求

敏捷全貌的总结

将项目切分为迭代
每次迭代产生输出，并用测量数据持续的评估时间表
按业务价值对需求排序，优先实施最优价值的东西
尽可能的保持高质量，并主要通过变更范围来管理时间表

此处奉上教员的四个大字：实事求是

生命之环

敏捷由一系列实践组成

外圈是面向业务的实践，为开发团队和业务团队的沟通方式以及业务和开发团队项目管理的原则提供了框架
中圈是面向团队的实践，为开发团队内部的沟通和管理提供了原则和框架
内圈是技术实践，为程序员的开发提供了约束和指导，来确保得到最好的技术质量保证

各实践与敏捷宣言的联系

敏捷包含上面的实践，上面的各种实践又和敏捷宣言相呼应，他们之间有如下的对应关系
个体和互动高于流程和工具

完整团队、隐喻、代码集体所有、结对、可持续节奏

可工作的软件高于详尽的文档

验收测试、测试驱动开发、简单设计、重构、持续集成

客户合作高于合同谈判

小步发布、计划游戏、验收测试、隐喻

响应变化高于遵循计划

小步发布、计划游戏、可持续节奏、测试驱动开发、重构、验收测试

最后，敏捷是帮助小型软件团队管理小型项目的一个小型行为准则，应用敏捷要因地制宜，不要本本主义，照搬照抄