敏捷整洁之道-读书感悟

敏捷之旅

初识敏捷，是12年在学校时，有幸参加了一次某公司为期两周的开发培训，其中有一门课程是“火星人敏捷开发”，在一堆乐高玩具的workshop中大概了解了“站会”，“story”这些术语的含义。但是，“敏捷有哪些好处，解决了哪些痛点”，没有参加过完整的项目的我，自然无法理解。

工作之后，参与过瀑布模式的大型政府项目，也参与过“伪敏捷”的初创项目。之后加入贯彻敏捷开发的公司之后，也体验了一把基于Scrum和XP的敏捷项目。

随着越来越多的方法论与工具被纳入敏捷的范畴，自己感觉对敏捷的认识有些模糊不清，因此期望能够回归本源，探索敏捷的本质。恰逢其时，Uncle Bob的《敏捷整洁之道》中译版发布，于是赶紧买来阅读，遂了心愿。

---

读书感悟

敏捷整洁之道.jpg

与Bob大叔的其他几本著作《代码整洁之道》、《架构整洁之道》相比，本书内容偏文学性质，读起来比较轻松。前言部分，Bob大叔也特意补充到：

请不要把这本书当视为学术著作，最好将它视作一本回忆录——就像脾气暴躁的老年人满腹牢骚，让时尚新潮的敏捷小年轻们从他家的草坪上滚开。

本书前两章主要讲故事，开篇用了较多篇幅回忆了“雪鸟会议”和“敏捷宣言”的提出。第二章从多维度阐述了使用敏捷的理由，第二章末尾部分，提到了雪鸟会议期间制定的权利条款并对其条目进行了详讨。其中客户权利条款在大多数项目中都得到了保障，开发人员权利条款的落地就值得商榷了。下面列出开发人员的权利条款：

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

其中比较有意思的一点，“开发人员有权保持高质量的工作输出”，乍一看，会感觉这像是要求开发人员应尽的义务，仔细推敲，会发现这其实在说，业务人员无权要求开发人员走捷径或者降低质量，要重视系统的长期利益，保证系统的技术卓越。

中间的三章从业务、团队、和技术三个维度去探索了具体的落地实践方式。该部分内容一部分符合原有教旨，一部分与现代结合。其中印象比较深的一点，书中提到“马拉松”：

软件项目是一场马拉松，不是冲刺，也不是一系列连续冲刺。要保持“可持续节奏”。

这一点感受颇深，所以在日常项目中，我会更多的使用“Iteration”而非“Sprint”，刻意的去淡化冲刺的味道，更多的保证团队以可持续且稳定的节奏进行交付，降低客户不切实际的预期。

第六章介绍成就敏捷，谈的更多的是敏捷中不做什么，而不是做什么。其中有些内容与前文有些重复。

最后一章匠艺站在开发者的角度，鼓励技术人员，不要被项目牵着鼻子走，要坚持本心打磨技艺，同时把精华传递给年轻从业者。

最后，谈一下最近两年结合行业现状的一些感受，极限编程明确将“每周40小时”作为团队实践提出，但目前这项实践受外部因素影响较大。如果团队的加班时间无法控制，敏捷的用户故事，每两周一次上线等实践，就会变成细粒度保证工作强度的手段，反而加重了IT从业人士的劳动强度与工作压力。