给新朋友的敏捷指向北

最近应邀给公司里刚入职的实习生同学们做了敏捷分享，一共半天的时间，大家反馈不错，睡着的不多，甚至意犹未尽。回想我读大学那会儿，课上一倒一大片的情景，有些唏嘘，也有些感激。

分享过程中自己也有很多灵感和收获，所以写文来总结，以期能影响和帮助更多的新朋友。

准备

老实说，课前我刻意没有做很充足的准备。有几个原因，一是这个话题和与之相关的知识体系我已经非常熟悉，二是我想要自我修炼一下，尽可能摆脱演讲只会照本宣科的困境。三是我所面对的目标群体相对特殊，准备太多反而会让我陷入“卖菜”而非“服务”的状态，所以我的准备几乎是在分享前10分钟完成的。

回想我从学生时代的状态，我的知识体系只够支撑我做题、生活和考试，而我对软件工程行业的理解则停留在：写软件首先是不知道从哪里变出来几张功能明确的设计图，然后某个程序员从不同的地方抄一些代码把功能“弄”出来，最后在本地运行起来，时兴一点可能会用学生权益申请个不要钱的云服务器，关键是一定要把运行截图或者链接发到朋友圈炫耀一番。而这，已经算是实践能力很强的同学了。

所以在我看来，“敏捷”二字对初入行业的新朋友而言，稍微有些遥远。于是我这样规划半天的分享：

1. 自我介绍
2. 分组
3. 设定小组长，小组长自我介绍
4. 小组长安排人介绍团队和团队名称
5. 分小组聊一聊对敏捷的理解和课程期望
6. 整理、澄清、对齐课程期望，后续内容根据期望梳理
7. 敏捷是不是大家理解的敏捷？
8. 软件交付的商业逻辑是什么？软件交付有哪些事情是必须要做好的？
9. 为了做好这些事情，我们实际工作中采取偏向管理的“轻量级方法”——Scrum 中的部分实践
10. 一个可选的话题
11. 偏向工程实践的“轻量级方法”——XP
12. 识别代码坏味道——“码屎”
13. Scrum 沙盘游戏——疯狂动物城

分组

我叫 Leon，花名里昂，做软件交付和工程咨询，平时喜欢读书、写字、打球。今天来这里，是想和新朋友聊聊敏捷，也听听大家对交付这件事的困惑。

人和人的沟通都需要信任来维持，培训也一样，所以花了不少时间在分组这件事情上，尽可能让更多人参与、说话、和置身事中。

• 先把大家分散坐到不同的桌上
• 然后每桌指派一位组长，组长 3 分钟后起来自我介绍，以及介绍自己的团队
• 每个小组讨论一个组名，组长指派一个人自我介绍，同时介绍自己的组名和口号
• 再给大家 10 分钟，聊一聊或者现场搜一搜敏捷。10 分钟后组长指派一个人谈一谈本组对敏捷的认识和对敏捷这个课程的期望

最终得到的结果如下：

组	组名	组长	对敏捷的理解	对课程的期望
Team 1	哎哟，你干嘛？	王xx	可以满足客户（便利用户）的需求；提速；迭代（软件更新）	和瀑布模型的差距；优缺点、利和弊
Team 2	基因重组	林xx	以客户为中心；敏捷宣言；个体和互动高于流程和工具	敏捷是一种项目管理的工具或者方法；传统项目管理的区别
Team 3	无bug	段xx	以用户需求为核心；采用迭代和循序渐进的方法进行软件开发	什么迭代
Team 4	迪士尼的公主们	刘xx	和瀑布式有区别；敏捷：装房子，今年先简装住着，明年再精装	什么情况下使用敏捷的价值观管理；什么情况下使用瀑布
Team 5	闪电飞龙	史xx	敏捷是项目管理和迭代管理的方法；小颗粒度的方式交付软件	优缺点；什么时候进行使用；具体的例子

在对齐期望的过程中，我发现大家关注的问题都非常务实，但对于一些前置概念存在非常多的误解和不当假设，于是我补充了一些依赖性比较高的问题，然后对这些问题进行了简单的排序，由此决定：

Topic1：敏捷是不是大家理解的敏捷？

在听大家讲自己对敏捷的理解的时候，我知道得到的答案一定是千奇百怪，五花八门的，不仅是行业的新朋友，相信很多老朋友也一样满头包，好像一千个人眼中真有一千种“敏捷”：敏捷就是这样，先画个板子，再开几个会，我们照着做了，但是项目还有一堆问题，所以敏捷就是扯淡的。我在前些年也经常有同样的困惑，当我们的知识体系解释不了我们在实践中遇到的问题的时候，我们总是需要给出某些假设以寻求闭环的。谁会轻易承认自己懂得不够多呢？但到最后我还是承认了，当时的我书读得太少，嘴也太硬，当然也不重要了，几年后我也会继续承认今天的我书读的不够多。

话说回来，“敏捷”虽然是一个胜利者，但它本身在二十多年的生命历程里，其实是很谦逊的。我一直很喜欢敏捷宣言的第一句话：“我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观”。

敏捷诞生的逻辑

从二十世纪四十年代祖师爷冯·诺依曼指导第一台通用电子计算机诞生到现在，不过七八十年的时间。而对软件工程的讨论要从二十世纪六十年代的软件危机开始，彼时的资本想必跟今天一样疯狂，整个世界都在为争夺第三次工业革命的科技高地而撒币，计算机软件也因硬件的相对成熟从个人开发为主转变到大规模团队开发。软件系统的规模越来越大，复杂程度越来越高，于是，软件危机爆发了。

为了应对软件危机，当时的大型权威组织借鉴传统工程领域的管理办法，开始定义高度详细的流程：首先，业务分析师采访利益相关者并记录系统需求。接下来，软件架构师将阅读需求文件并创建详细的设计文件，指定系统的每一个组成部分以及它们之间的关系。然后，程序员会将设计文件转换成代码。同时，测试负责人将使用相同的文件来生成测试计划，当编码完成后，大量的 QA 人员将手动遵循这些测试计划，并将差异报告为缺陷。在每个阶段后，一切都将被仔细记录、审查和签署。这些基于阶段的方法后来被称为“瀑布式开发”或“阶段门开发”。

但软件工程这个新兴的工程行业与传统的工程行业有本质的差异，当我们采用从传统工程行业借来的办法管理软件工程问题的时候，仍然有大量的软件项目延期甚至被取消。因此，有几个人创造了更简单、更苗条、更少规定性的软件开发方法。这些方法被称为“轻量级方法”，与大公司使用的重量级方法形成对比。这些新方法的名称是：“适应性软件开发”、“水晶”、“功能驱动开发”、“极限编程”和“Scrum”。

敏捷只有三样东西

那么“敏捷”这个词怎么来的呢，要接上“轻量级方法”的茬。创建“轻量级方法”的十七位先驱，非常注重 Work Life Balance，他们在 2001 年春节后第一个星期的周五到周日，相约到美国犹他州的 Snow Bird 滑雪场“开会”。可想而知其效率应该“非常低下”。果不其然，最终三天的会议只讨论出来了三个结果。

第一个结果是“敏捷”这个词。他们将其定义为“价值观”，用来表示“轻量级方法”背后的抽象。

第二个结果是“敏捷宣言”。宣言全文六句话，第一句我最喜欢，前文已经提过不再赘述。中间四句最广为人知，也最容易被极端者利用以在组织中为自己喜欢的立场谋求利益，比如说：“敏捷宣言说了，可工作的软件胜过面面俱到的文档，而且我们已经这么忙了，所以我们不用花这么多精力维护那么细节的文档。”人就是很复杂的生物，总是会拣选自己喜欢的道理。

第三个结果是“十二条原则”。原则是十七位专家旅行回家之后深思熟虑的产物，是“敏捷宣言”的进一步诠释，对敏捷价值观的落地更具指导意义。回头看时，那些声称“敏捷”的团队遇到的所有问题几乎都能在“原则”中找到建议。我本来是想花一些篇幅来解读“原则”，但我看到已经有朋友做了很详实的解读，就不再画蛇添足了，大家感兴趣可以自行查看：https://zhuanlan.zhihu.com/p/421133013。

Topic2：软件交付的商业逻辑是什么？

从商业层面上看，软件的咨询服务与其它领域的咨询服务并没有太大差别。大致都会分为这样一些阶段：

落到交付上，无外乎是做好这几件必须要事情：

1. 计划：施工方和需求方一起协商好，花多少钱，干多大事，先干啥，后干啥
2. 执行：施工方内部对阶段性的目标达成一致，分工协作达成一致
3. 监控：施工方内部对质量和进度进行把控，在必要时刻与需求方做信息同步
4. 验收：施工方给需求方做产品的演示，需求方对产品结果给出验收反馈
5. 改进：施工方针对给需求方的反馈和自身的复盘，持续改进

Topic3：偏管理的轻量级方法

那么，怎么做好呢，最知名的“轻量级开发方法”之一 Scrum 给我们提供了管理实践上的一些建议：

1. 针对交付服务必须要做的事情
2. 设定必须有的岗位和职责
3. 开且只开必须要开的会
4. 关注必须关注的产出物
5. 通过有节奏的活动建立有工作节奏的团队

我们在实际工作中是这样做的：

对于 Scrum，如果想要有一个比较体系化的学习，可以参考官方网站提供的系列材料：https://scrumguides.org/index.html

至此，我们要回答的问题基本回答完毕了，新朋友们也露出了若有所思的神情。

Topic4：一个可选的话题

还剩下一些时间，我列出了三个 Topic 让新朋友们自己选择：

1. 偏向工程实践的“轻量级方法”——XP
2. 识别代码坏味道——“码屎”
3. Scrum 沙盘游戏——疯狂动物城

最终，新朋友们选择了一个非常务实的 Topic，也是我自己觉得作为一个工程师最应该掌握的基本功之一——识别代码坏味道。篇幅有限，如有必要，下回详聊。