软件匠艺

敏捷的宿醉

从敏捷宣言发布，敏捷如同在雪山顶滚下的一个小雪球，迅速发展并很快席卷了整个软件业。但是如同传话游戏那样，最初的敏捷思想被扭曲和简化，最终到管理者耳朵里变成了是承诺可以更快交付软件的一个流程。

于是浩浩荡荡的敏捷转型开始了，但是一种文化并不容易转型到另一种文化，于是一个岗位出现了巨大的缺口：敏捷教练。令人遗憾的是，许多既没有业务经验也没有技术经验的敏捷教练，在经过短短几天的培训获得认证后就开始辅导各个公司的管理者，并且告诉开发团队该去做什么。

他们告诉管理者：工程部分很简单，只要我们搞定了流程，工程部分自然就搞定了。最终都是人的问题。

估算成为了形式，毕竟上线时间和需要完成的需求已经确定了，无论你怎么估算，反正定期上线即可。这个迭代没能完成的故事点，那就在下个迭代加班加点追回来。

站会成为了汇报会，向管理者汇报进展，保证在什么时候能完成。

自动化测试、TDD 和结对被认为是浪费时间的东西，赶紧停止，大踏步向前走。战略性的技术工作没有任何位置，整个团队不断重复着短视的、战术性的工作，技术债务没人关心但却在疯狂增长。

bug 和运营问题成为了每次回顾会议的主题，说好的频繁发布根本没有看见，每次的手动测试依然没有减少任何时间。

管理者觉得开发人员走得不够快，开发人员责备管理者不允许他们做必要的技术和战略性工作，产品负责人不认为自己是团队的一部分，出现问题时立马把自己摘除出去，大家依旧不是一个团队。

可是公司已经在敏捷转型上投入了时间和资源，以前存在的问题现在依旧存在，最后锅当然只能扣在敏捷头上了。说好的敏捷可以更快交付呢？不就是一直让我加班加班吗，和之前有何区别，甚至比起瀑布要累很多，毕竟每个迭代我根本没有时间休息，我被一直推着往前走？

问题在哪？

technical-debt-pentalog

还是那句话，只关注流程不关注工程技术的敏捷不可能成功，也不能称之为敏捷，大多数公司陷入了“伪敏捷”的陷阱。

实践敏捷大家都有一个很高地期望：新功能开发完成后，或至少每次迭代结束时，开发团队能够交付可部署到生产环境的软件。要将这个期望变成现实，仅仅改变工作流程是绝对不可能实现的，团队必须学习和掌握新的技术实践。

但是在大多数敏捷转型中，几乎没有组织会考虑提升开发人员的技能，他们认为只要改变了工作流程，在工作中更紧密地配合，开发人员就可以工作得更快。

但不可否认的是，经过敏捷转型的公司，哪怕不完整，只从业务角度考虑都会有一些好地改变。比如以更短的迭代工作，和技术部门合作更紧密，问题和风险能够被更早识别等等。不过敏捷流程和工程实践的分离依旧在伤害公司，开发人员的能力跟不上业务迭代，只会被越拖越累，最终只会走上 996 的老路。敏捷和开发者正在互相远离，两者互不认可，敏捷就是加班，敏捷就是快的理念根深蒂固。

公司没有看到问题的本质：技术问题实际上是业务问题，也需要资源和时间来提升和改善。

软件匠艺

software-craftsmanship

诞生

为了提高软件开发的水准，并重新明确敏捷最初的目标，一群开发人员于 2008 年 11 月聚集到芝加哥，发起了一项新的运动：软件匠艺(Software Craftsmanship)。如同 2001 年的敏捷峰会一样，2008 年的会议达成了一套核心价值观，并在《敏捷宣言》的基础上提出了一个新的宣言。

作为有理想的软件工匠，我们一直身体力行提升专业软件开发的标准，并帮助他人学习此技艺。通过这些工作，我们建立了如下价值观：

不仅要让软件工作起来，更要精雕细琢；

不仅要响应变化，更要稳步增加价值；

不仅要有个体与交互，更要形成专业人员的社区；

不仅要与客户合作，更要建立卓有成效的伙伴关系。

在追求左项的过程中，我们发现右项是不可或缺的。

精雕细琢意味着代码经过精心设计和完整测试，同时兼顾灵活性和健壮性。我们不害怕修改这样的代码，这样的代码能允许业务快速做出反应。

稳步增加价值意味着不论我们做什么，都应该始终致力于不断为客户和雇主增加价值。

形成专业人员的社区意味着我们期望彼此共享和学习，从而提高我们行业的水平。我们有责任培养好下一代开发人员。

建立卓有成效的伙伴关系意味着我们将于客户和雇主建立专业的关系。我们将始终秉承职业道德以尊重的态度行事，以最佳方式为客户和雇主提供建议并与他们合作。我们期望相互尊重和职业化的关系，为此我们愿意采取主动，并以身作则。

匠人们努力做到最好，不是因为有人支付工资，而是基于把事情做好地渴望。这是一次开发者的运动，这次运动激励程序员成为并认同自己是技能娴熟的职业人士。

软件匠艺实践

与敏捷不太一样的是，软件匠艺从一开始就没有包含任何一组固定地实践。它提倡不断去探索更好地实践和工作方式。如果将特定的实践与软件匠艺相绑定，那么也就意味着如果这组实践过时了，软件匠艺也就过时了。

如果一类实践是体现了软件匠艺的价值观的，那么就可以说这类实践就是软件匠艺的实践。相反，如果我们的工作方式与其原则和价值观不一致，那么我们就不能声称自己拥有这些原则和价值观。这个道理不光是软件匠艺，敏捷同样适用，只有遵循相关价值观的实践，才能被称为相关实践。

虽然没有固定地实践，但国际软件匠艺社区依然在倡导一些实践。自软件匠艺发起以来，极限编程被认为是当下的最佳敏捷开发实践。测试驱动开发、重构、简单设计、持续集成和结对编程在软件匠艺社区中得到了大力支持，同时 SOLID 原则和整洁代码也同样呼声不小。

软件匠艺还提倡小步提交、小步发布、持续交付。提倡模块化设计，以及一切能去除手动重复劳动的自动化措施。一句话，只要一个实践能够有助于提高生产力、降低风险，有助于做出有价值的、健壮且灵活的软件，匠艺都提倡。

透过现象看本质，敏捷和匠艺之所以提倡这些实践，本质上是因为这些实践能给我们带来价值。敏捷和匠艺都是为了交付高质量、有价值的软件，从而提升客户的满意度。他们都重视以短的反馈循环来提升软件质量，从而提升对业务的快速响应，填补业务和技术的鸿沟。

大多数人停留在表面，只认识到某类实践好像还不错，然后为了实践而实践，忽略了实践的真正目的是什么。这样的情况下你当然说服不了你的经理/同事/团队，因为他们也看不到这样的实践价值在哪里。

所以在讨论某一实践时，有必要先对要实现的目标达成一致。而如果你想要推行某一实践达成某种目的，创造某种价值，请将相关干系人引入讨论并陈诉利弊。

匠艺与你我

匠艺提倡将软件开发作为一份职业而不是一份工作。我们会对职业进行投资，并期望获得长久而充实的职业生涯。但对于工作我们极尽敷衍之事。

你或许会说国内开发人员活不过 35 岁，我不知道，国内的软件行业充其量 30 多年。我始终相信在大环境下依然有能让你实现职业的小环境，至少我身边还有工作了 16 年依然在行业里发光发热的例子，也有海外办公室呆了 10 年总共工作 54 年退休的老人。我也相信软件开发人员也可以成为一名老工匠。

相较于敏捷社区来说，匠艺社区更聚焦与技术方面。通过匠艺社区，测试驱动开发、持续集成、结对编程、简单设计、SOLID 原则、整洁代码和重构等等优秀地实践得以广泛传播。许多编程语言和编程范式也在社区里生根发芽。匠艺社区给开发人员创造了安全而友好的空间，他们彼此分享彼此学习。

而如果你找不到匠艺社区，小波老师最近复活的 CodingStyle 或许可以成为你的第一个匠艺社区。