前言
敏捷过程，相信对大家来说并不陌生，在工作中或多或少都会用到敏捷的一些方法，很多概念也都熟悉。但笔者在读完大牛Robert C. Martin（鲍勃大叔）的这本《敏捷整洁之道：回归本源》后，感慨良多。感觉不仅不少概念清晰了，有些想法还得到了纠正，正应了书名，这是一本敏捷“回归本源”的书。
一、敏捷概貌
软件项目的基本原理，被称为管理的“铁十字”：质量、速度、成本、完成。而敏捷是一个框架，它可以帮助开发人员和管理人员进行务实的项目管理。但是，这种管理不是自动的。
软件开发不是一个能够可靠估计的过程，我们程序员在事先是不能准确给出需要多长时间的，是因为在参与和完成任务之前，根本没有办法指导任务的复杂程度。敏捷方法始于分析，并一直贯穿于项目的生命周期，它将整个项目的时间切分为若干个固定长度的时间周期（这些周期被称作迭代或sprint）。
敏捷正是通过不断的迭代来提供必要的数据，是的估算的误差范围不断缩小，预测不断清晰，使得人们不必通过“幻想”来确定是否能在项目结束日期之前成功交付了。
我们知道，管理者是可以通过变更时间表、人员、质量和范围来调整铁十字，但实际很多时候调整是有局限性的。比如，如果在项目开始后，要想改变时间表，这往往是不可能（大家都懂），除非是提前交付。对于增加人手，根据布鲁克斯定律：为延迟的项目增加人手反而会使它更加延迟，这是因为培训新人的成本很高。
关于质量，大家自然是想质量越高越好，但如果遇到项目时间紧张时，放弃编写测试、停止代码审查，只追求拼命编码的作法，无疑是徒劳的。“产生垃圾代码不会使你走得更快，没有快而脏（quick and dirty）这样的事情”，快速前进的唯一方法就是做扎实。
最后一件可以改变的事情，也许是计划中的某些功能实际上并不需要在开始定下的“deadline”前完成，当然这需要比较大的运气，而且还需要利益相关者的同意才可能。
这里就是敏捷的概述，这其中省略了不少细节，而敏捷如鲍勃大叔所说，敏捷是一个框架，有许多不同名称的实际过程。包括极限编程（XP）、Scrum、动态系统开发方法（DSDM）、适应性软件开发（ASD）、水晶方法（Crystal）、特性驱动开发（FDD）等，都是达成同一目标的不同手段。其中极限编程是鲍勃大叔认为定义最好、最完整、最不混乱的一个。
二、大师眼中的敏捷
敏捷是一个支持专业软件开发的记录框架。信奉纪律的人接受和遵守管理者、利益相关者和客户的合理期望，同时也遵守敏捷赋予开发人员和客户的权力。
敏捷不是一个流程，也不是一种时尚，不仅仅是一组规则，还是构成软件开发职业道德基础的权力、期望和纪律的组合体。
敏捷需要和实践相结合，以极限编程为例，对应图中的“生命之环”，敏捷分为几种实践。
- 业务实践——对于业务，软件开发需要遵循的实践有：计划游戏、小步发布、验收测试和完整团队。通过遵循这些实践，业务和开发有一个简单而明确的沟通方式，而这种交流会产生信任。
- 团队实践——隐喻、可持续节奏、代码集体所有和持续集成，这些实践支配着团队成员之间的关系，以及团队成员与他们创建的产品之间的关系。敏捷是一组原则、实践和纪律，有助于团队建立交流语言，使团队成员对彼此、对正在构建的项目期望一致，从而帮助小型团队成功构建小型软件项目。
- 技术实践——没有测试驱动开发、重构、简单设计及结对编程（结对是可选的，也可是间歇的）的敏捷是虚有其表，起不到作用。敏捷的技术实践是任何敏捷工作中最本质的组成部分。
敏捷有其特有的价值观：勇气、沟通、反馈和简单。从非敏捷到敏捷的转型是异常价值观的转变。敏捷开发的价值观包括敢于冒险、快速反馈、热情、人与人之间跨越障碍和指挥结构的频密沟通。这些价值观可能会与一些大型组织的价值观截然相反，比如敏捷专注于直奔目标前进，而不是划地盘、争权夺利，有不少大型组织重金投入的中层管理结构更重视安全性、一致性、命令与控制以及遵循计划。所以转型意味着转变价值观，这是非常困难的，但要“创建”出允许敏捷团队蓬勃发展的大型组织，鲍勃大叔认为是可以的，而且有许多初创公司采用了敏捷，也有不少的大型、非敏捷的公司在雇佣许多敏捷的咨询公司。以后，会有越来越多的大型公司在内部创建新部门，以便采用敏捷方式进行软件开发；大型组织在无法转变现有开发团队的情况下，会越来越多地雇佣采用敏捷方法的咨询公司。
关于大型组织中的敏捷应该怎么办？多年来，有不少人试图回答这个问题，但鲍勃大叔有自己的看法。敏捷是为中小型团队服务的，从来不是为大型团队设计的。大型团队的问题是所有社会、所有文明共同的问题，而且从现在的文明来看，这个问题我们似乎解决的不错，比如建造金字塔、打赢第二次世界大战、把人送上月球并安全带回地球等等。
小型软件团队的问题才是20世纪80年代末敏捷运动开始时尚未解决的问题，如何有效地组织一个相对较小的程序员团队来提高效率，敏捷解决的正是这个问题。而解决的的重点在于，要明白这是一个软件的问题，而不是小团队的问题。敏捷是我们组织小型软件团队的一套纪律。在解决好了小型软件团队的问题后，对于如何组织大型团队的问题，就迎刃而解了：将其拆分成小团队。
此外，鲍勃大叔还谈到了敏捷教练辅导，教练的角色完全是团队内部的，是团队的成员，其职责是捍卫团队中的流程。在看到例如停止重构、忽略持续构建中的失败等现象时，向全团队指出来。另外教练也可能诞生出新的职业，从过程专家成为敏捷专家。如果把敏捷理解为一种算法，它可以找到市场上价值最高的产品特性，然后将它们更快地转化为收入。专门为敏捷专业人士服务的认证教练学校已经成立，敏捷教练的未来是光明的。
三、敏捷与匠艺
为了提高软件开发的水准，并重新明确敏捷最初的目标，一群开发人员在2008年11月聚集到芝加哥，发起了一个新的运动：软件匠艺（Software Craftsmanship），并在《敏捷宣言》的基础上提出了一个新的宣言：
- 不仅要让软件工作起来，更要精雕细琢；
- 不仅要响应变化，更要稳步增加价值；
- 不仅要有个体与交互，更要形成专业人员额社区；
- 不仅要与客户合作，更要建立卓有成效的伙伴关系。
软件匠艺宣言描述了一种思想体系、一种观念。它强调从几个角度来提升职业水准：精雕细琢、稳步增加价值、形成专业人员的社区、建立卓有成效的伙伴关系。不再把工作看做上班打卡，而是提供专业服务，掌控自己的职业生涯，投入自己的时间和金钱来改善自己的工作。这些不仅是专业价值观，也是个人价值观。
思想体系是思想和理想的系统。方法论是方法和实践的系统。敏捷的主要目标是提供业务敏捷性和客户满意度，这是通过紧密协作、迭代开发、短反馈循环和卓越技术来实现的。软件匠艺不包含固定的一组实践。相反，它提倡不断去探索更好的实践和工资方式。如果将特定的实践与软件匠艺相绑定，就会使它变得脆弱和过时，因为总会有更好的实践会被发掘出来。但并不意味着匠艺不倡导任何实践，相反它倡导小步提交改动、小步发布和持续交付；倡导模块化软件设计，以及一切能去除手动重复劳动的自动化措施。匠艺不仅仅包括技术实践、工程实践和自我完善，它还包括职业精神，赋能客户以实现其业务目标。
匠艺对个人的影响——它提倡将软件开发作为一种职业而不是工作。工作是我们要做的事情，但并不是我们自己的一部分，而职业则是我们的一部分。这意味着我们能够找到一种平衡所有承诺和兴趣的方法，使得我们能够过上完整、平衡而幸福的一生。
匠艺对行业的影响——通过匠艺社区，开发人员学习测试驱动开发（TDD）、持续集成、结对编程、简单设计、SOLID原则、整洁代码、重构、微服务系统架构、自动化部署流水线，以及如何将系统迁移到云等等。匠艺社区极为包容，不论他们当前专业水平高低，它都欢迎，且致力于培养下一代专业人士，使加入我们行业的人们可以学习必要的实践，以构建精雕细琢的软件。
匠艺对公司的影响——公司需要可靠的系统（能够快速响应业务需求的系统），公司还需要积极进取、能力合格的技术团队，这样的团队才能做好创建和维护系统的工作。这些正是软件匠艺擅长的领域。
有些开发人员觉得匠艺和敏捷是互相排斥的。参与匠艺运动的人士可能会批评敏捷过分关注过程，缺乏对工程的关注，而敏捷运动的参与者则批评匠艺的关注点太窄，或者缺乏对实际业务和人员问题的关注。大多数的分歧是由于立场不同，而非根本意见分歧。本质上，两个运动的目标非常相似，两种都希望客户满意、渴望紧密合作、希望交付高质量有价值的工作，并且都要求专业性。为了获得业务敏捷性，公司不仅需要协作和迭代过程，还需要良好的工程技能。敏捷和匠艺的结合是实现这一目标的完美方法。
小结
读完鲍勃大师的这本书后，另笔者印象比较深刻的有：敏捷从来是针对管理小团队完成小项目的方法，大团队的问题应该通过拆解为小团队的任务后不断进行迭代。另外还了解到匠艺运动，让我对鲍勃大师去年出版的《匠艺整洁之道：程序员的职业修养》产生浓厚兴趣，有机会再拜读。
Jackson