过去的2019年有很多事情值得总结，做得好的事情，涉及商业秘密，不宜宣扬。疫情肆虐，封闭在家，闲得无聊，总结些失败的案例，以儆效尤。

记得19世纪末，有位叫开尔文的物理学家说：“物理学的大厦已经建成，晴朗天空中只剩下了两朵小乌云…”。100多年后的某一天，有个程序员也有了类似的感觉。公元2019年初，我觉得有了新的Python后台加入，我们的开发团队已经组建得比较完整了，意气风发，当然晴朗天空中也只剩下了两朵小乌云，一是团队的需求分析工作比较薄弱；二是团队技术栈太多，各司其职，缺乏沟通。为了提高团队凝聚力、战斗力，提高团队管理水平，我兴冲冲的报名参加了Scrum培训。

那么多培训，为什么要选择Scrum呢？我也有过一番深思熟虑：

1. 团队管理需要专业技能。我一直认为我没有做管理的本领，本来的职责就是技术负责人，恰好我比大多数人多一些经验、悟性和机遇，于是奉命组建开发团队，兼负一些管理工作。但我深知这种管理能力不具有行业普遍性，不能支撑我在行业内长期发展。软件行业是技术密集型行业，很多岗位，需要很专业的技能，然而很多人实际上是靠本能在工作，尤其是某些管理角色。
2. 团队的需求分析能力比较薄弱。早期很长一段时间，需求文档是我自己写的，那段时间身兼数职，写需求、写代码的同时，还要协调开发和测试。我的需求写得很不专业，大家都很有意见。开发人员我还能压一压，测试就很不爽了，但是碍于面子不好意思当面怼我。需求写得很随意，测试也就没有依据，产品质量也就无从提起了嘛。那么引入Scrum对需求分析有什么帮助呢？其实没有帮助，但是Scrum能从另一个角度解决需求问题。
3. 团队需要拧成一股绳。并不是说团队人心不齐，而是受制于一些刻观原因。团队人数不多，但是存在IOS、Android、Web前端、后台、PC端等多个开发岗位，基本上每个岗位都是一个人，相互之间缺少沟通，各忙各的，互不关心。有的岗位技术栈一样，但是做的项目不同，毫无关联；有的是同一个大项目，但是分属不同的端，老死不相往来（从这一点看，真不该引入Python的，凭空又搞出个技术栈）。这种状态很不健康，难以管理。而Scrum特别擅长处理团队问题，Scrum几乎就是为团队协作而生的。

这些个原因，其实总结一下就是要避免管理混乱、提高产品质量、提高团队凝聚力。再简要点说，就是要让软件开发又快又好，这是软件开发永恒的追求。

我参加的Scrum培训非常棒，记得当时培训完，一起培训的朋友们都很兴奋，组建微信群，经常探讨Scrum实施的问题。过了一段时间，有人一脸哀怨，说Scrum在公司推进不了，没人听他的。我当时心想，我们团队肯定不会有这个问题吧，团队是我组建的，我要推进个啥，应该还好吧！再后来，群里就没人再讨论Scrum了，那个群仿佛从来没有出现过，消失在了人山人海。。现在我也不得不承认了这个事实，虽然没有人来和我讨论这件事的成败，但我内心很清楚，辛苦推进了一年的Scrum，事实上已经失败了。只有每天早上的站会，证明我们曾经Scrum过。。

我们需要Scrum吗？

这两天做总结翻出来18年写的文章，看得我哭笑不得，字里行间都散发着心中的怨气，隔着屏幕看到了当时的我，现在看来还挺搞笑的。这篇文章其实一定程度上体现了研发过程野蛮生长的无序状态，当时团队里每个人都干得很不爽，团队不应该是这样的状态，我想改变一下。

如果只是为了改变混乱状态，让研发过程可控，那么有很多项目管理方法可供选择，哪怕就是最古老的瀑布，项目各阶段清晰可控，操作最简单，为什么要舍近求远，选择Scrum呢？

这和我的执念有关。我是从电子政务行业出来的，我很清楚瀑布模式、矩阵管理有哪些优点和缺点。电子政务行业的严肃性要求软件开发必须要严格按照标准执行，说到底就是为了严格控制工期和质量。那么瀑布模式是怎么保证工期的呢？答案：加班，deadline画在那，不加也得加；瀑布模式是怎么保证质量的呢？答案：一起加班，一群小姑娘做人肉测试，和开发小哥一起加班。其实瀑布模式即保证不了工期，也保证不了质量，保证工期和质量的，依然是开发和测试人员的本能。可喜的是，现在也有不少甲方明确要求使用Scrum交付软件了，因为他们觉得Scrum分阶段发布产品，可以随时看到成果，比较放心。

我到现在都记得老东家的svn模版，新项目立项申请svn后，就会默认初始化一个很复杂的空目录树，目录文件夹有很多：产品策划、需求开发、交互设计、软件设计、软件测试、系统验收等等，我刚入职时就在想，这个管理好专业呀，不愧是大公司，制定这一套流程的人一定很牛吧！后来有一年软考，脑子一热报了个项目管理师，猛然发现项目管理教材上的目录和我们的开发流程各环节名称居然一模一样，这下豁然开朗。

我记得当年在老东家最痛苦的事情就是，产品告诉我明天要取包。我当时就在想，我们这种研发管理水平，制度上就不支持隔天发布这种操作呀。需求文档都来不及改，一天时间什么都不干，光提个测都测不了一轮，何况大家都在忙着别的任务。怎么办？只有加班了。很多时候加班也来不及，那就流程上能省则省，我以前帮别的项目复查代码，很多项目的svn，交互设计、需求开发目录下面内容很多，其他目录基本都是空的，概要设计里的文档，好久没有更新过了，这就是大公司研发管理的现状。

直接到有一天我看到了敏捷开发：

心想这才应该是我们的追求呀！我知道我写需求很差劲，大家多有怨言，但我压根从来没有考虑过要提高我的需求分析技能（真要那样做的话，我的技能树就点偏了）。反而我一直认为需求文档不需要写得很详细，正如敏捷宣言所说的，可用的软件重于复杂的文档。要知道用户用的是我们的软件，我们不是把需求文档拿去给用户用，在需求文档上耗费精力的意义在哪里？

需求文档存在的意义在哪？是因为我们人为的在软件开发活动中设立了一个个独立的角色：开发、测试、需求、交互、前端、后端，很多公司还声势浩大的设立了开发组、测试组、需求组、交互组等各种职能部门。而为了解决这些部门之间难以逾越的鸿沟，人们又开发了各种流程和工具，需求文档就是这些角色之间传递信息的重要媒介。那么是什么让软件过程变得如此复杂的呢？这一切都归功于上世纪70年代兴起的一门学科：软件工程。

软件工程这个学科是如此的深入人心，很多学校为此单独开设了一个学院，叫软件学院，学费还比一般的学院贵好多，我就是软件学院的软件工程专业出来的。然而我们国家的专家们引入软件工程时，一开始就跑偏了，不知道是不是因为有“工程”两个字，软件工程最喜欢拿实体制造业做类比，认为软件工程的管理也要像制造业一样做好分工。现在的制造业早就开始搞精益生厂、定制开发了，软件工程还在那搞流水线，因为软件工程的专家们心里想像的制造业就是几个工头带着一群工人没日没夜的干活。

我们为什么不能直接沟通呢？当面都说清不楚的东西，需求文档就能写清楚吗？需求文档记录的应该是一些标准化的东西，比如对象状态、提示文案等等。开发和测试不需要去主动记需求，天天在做的需求，该记住的都会记住；这一版开发了，下一版就改了的需求，没必要记住。至于需求细节，就应该在开发过程中沟通确认，这才是最简单高效的方法。为什么还会去追溯需求，去验证哪个功能哪一版改的，纯粹是闲得没事干，产品经理能不知道哪一版改了什么功能么？不正常的团队才会有这种不正常的举动。

瀑布模式依靠程序员的本能，那么敏捷开发是如何保证工期和质量的呢？其实也是靠程序员的本能。软件开发和实体制造业就是不一样，只有依靠程序员优秀的技能素养才能解决工期和质量问题。敏捷开发比其他所有研发方法都要重视人的作用，Scrum的很多措施都是为了激发团队成员积极性和凝聚力，比如以站会为代表的各种会议，比如团队决策确定工作量，比如团队成员自发领取任务等等。可以说Scrum是最讲究以人为本研发管理方法。

为什么失败？

Scrum如果像我说的那样能解决各种问题，那么为什么推进了一年，最终却失败了呢？我觉得存在两个难以解决的问题：态度和能力。

态度问题

一个新事物的出现，总是有阻力的。Scrum有一个伟大的使命就是去除各部门之间的鸿沟，推进Scrum首先要做的事情就是调工位。然而这看似简单的第一步就要侵犯多少人的利益呀，很多公司搞Scrum连这第一步都没走完就失败了。Scrum为了方便沟通采取了很多措施，团队必须坐在一起，团队成员都全职参与一个项目等等。我在招人时故意没有按技术线安排工位，让大家混坐在一起，就是为了让大家“你中有我，我中有你”，促进交流。然而就我这点小心思，都遇到很多阻力，有的人就是不喜欢和某人工位挨得近；有的人恨不得和某人坐在同一个椅子上；有人要靠窗子啦，有人要旁边有柜子啦。隔三差五有人跟我说：要不我们调整一波座位？后来眼看着Scrum失败了，我也不得不跟风随大流，按技术分工重新调整了座位。

面对一个陌生事物，不可能所有人都信任我，即使私下关系特别好。当然大部分人还是愿意尝试的，这是我工作的前提；有的人不反对也不赞同，比如领导：你先试试看呗；有的人会通过一些途径表达出比较明显的反对。我能做的就是尽可能团结一切可以团结的人。比如最基本的站会，有人就说：我项目是一个人做的，没有人和我开站会呀。其实这个想法不对，毕竟咱是一个大项目，都是为了服务用户，咱不能把需求割裂，否则项目衔接会出现问题，事实上已经出现过不少项目协调的问题了。他有这个想法，我反而觉得更有必要开站会了。

为了让他加入站会，我想了些“歪招”，比如我决定轮流主持站会，让大家人人都来当ScrumMaster，体现人人平等，避免让他觉得我要“管他”，消除心里上的芥蒂；然后我为了体现诚意，把白板扛到了他工位旁边，就在他旁边开站会。我这是“阳谋”，成效还可以，当然最关键的还是因为那位同事比较通情达理，能认可我。

有些阻力显得非常难以抗拒，比如来自测试的阻力。对于这点我没有资格埋怨他，因为是我对不起他。我和测试的同事私下关系也很好啦，现在放弃Scrum了嘛，我终于可以随便说了。在标准Scrum框架体系里，是没有“测试工程师”这个岗位的。Scrum全盘否定了软件工程经典的V模型：

Scrum认为V模型右边的测试工作是几十年来软件工程领域最大的错误，测试和开发不能分割，测试工作理应由开发人员自己完成。很多敏捷大师评价敏捷开发成熟度的首要标准就是看有没有做到TDD（测试驱动开发），敏捷开发认为保证工期和质量的惟一办法就是让程序员采用技术手段——测试驱动开发加自动构建，就是所谓的CI/CD。从一线互联网公司的实践来看，事实确实是如此。这一点我在推进Scrum的时候，说得比较模糊，甚至都不敢透露这个事实，生怕测试人员会强烈不满。在标准Scrum框架下，没有测试工程师，但是可以有质量保证工程师呀！他们不需要再做“人肉测试”了，而是提出需求，让开发人员开发测试脚本。那时候测试工程师的工作就是确保测试脚本的准确性，以及评估测试脚本的覆盖范围。

但即便我现在说得如此轻描淡写，绘声绘色，那也是需要测试人员转变思想的呀，这很难。而且我也不能保证Scrum能实施到什么程度，所以我没有底气要求别人全盘接受Scrum。测试同事的态度，我百分百完全理解。ScrumMaster的宗旨就是引导别人，不能强人所难。当然这侧面反应了我能力不行，引导力还不够。

能力问题

能力问题是Scrum失败的最主要原因。

首先我做为ScrumMaster，缺少实践经验，对推进难度评估不足，最大的失误，是忽视了一个重要的问题——团队做不到TDD。团队缺乏经验，不能快速编写单元测试。去年的项目推进比较艰难，团队一直都比较紧张，没有精力做单元测试，这个即是能力问题，也是态度问题，要转变真的太难了。也许应该找个小项目试点，但是去年项目一直连轴转，找不到试点的机会。后台接口做单元测试比较合适，但是就一个后台开发对多个前端，工作已经饱和了，没有多余精力；前端技术栈又特别的多，我自己也拿不定主意，一起做没有把握，只做一端又担心导致各端进度不统一。技术栈太多的问题一下子暴露出来了。去年下半年还尝试把移动端的某些模块H5化，想统一前端开发，最终觉得时机不成熟，风险太大放弃了。

另一个比较痛苦的事情是，团队需求工作薄弱的问题被再一次放大了。可能是领导觉得我需求做得不好，他看不下去了，决定亲自上阵。这本来无可厚非，关键是今年开始领导也特别忙，经常出差，沟通就成了问题，很多需求没有明确，不知道怎么搞，开发和测试都感觉特别难。而且项目启动时领导就打了招呼：这个项目特别关键，大家多多努力呀！其实这压根就没有解决需求问题，只是以前我压着的，改成了领导亲自压着。本来这种需求不明确的情况，做敏捷开发特别合适，但是最关键的一个沟通环节出了问题，敏捷也敏捷不起来了，那段时间我非常焦虑，想推进Scrum实在是推不动。

后来下半年的时候，事情出现了转机。有些难以启齿，因为转向更坏的局面了，压垮我Scrum事业的最后一根稻草出现了——团队有了产品经理。引入产品经理，本来是个好事，团队上上下下都是很赞同的。Scrum架框里的PO是很重要的角色，是团队的核心。但诡异的是，领导招聘产品经理不得，直接指派了一位测试转岗担任产品经理。我一下就想到了头条发布多闪的时候，那个闪亮登场的90后产品经理。我觉得很荒唐，产品经理不是“总经理”这种通用的经理，总经理很容易跨界，但是开发海天黄豆酱的产品经理可以跳槽去开发运动鞋么？也不是不可以，有些互联网产品经理摇身一变就去造车了，他造车也不是因为会做软件，是因为有别的本事呀，我们看看就好了。产品经理需要很多业务技能，是有门槛的。古时候的封建体制下，哪怕皇帝6岁登基，身边都有一群大臣兢兢业业，国家还能照常运转，软件开发不是这样子的。

新上任的产品经理接手了需求工作，这下领导解放了。新的产品经理缺乏经验，需求做得一般，我倒觉得这不是问题，关键在于沟通。可是我万万没想到沟通居然成了大问题，同一个需求点，和不同的人解释，总是解释得不一样，因为她总是说不到点上，还依然自我感觉良好。今天说完，明天再问，又不一样，开发就摸不着头脑了。最难以接受的是，提测之后给测试讲的和给开发讲的还是不一样。这下开发和测试都忍无可忍了：需求文档必须要写得很详细！只要有不明确的地方，就做如针毡，不接受，不信任。这下又苦了产品了，哪有绝对的详细的嘛，写到何处是个头哇。从这个角度看，其实有了产品经理后，依然没有解决需求问题，只是把原来的需求压力传递给了毫无经验的产品经理，产品能力一般，大家不买账。只见刹那间，开发和测试把需求方面压制了多年的情绪全释放到了产品身上了，就像开闸泄洪的洪水一样，拦都拦不住。那个时候大家都已经疲惫不堪了，这种情况下再提Scrum，真就是天方夜谭，人人喊打了。

产品经理不仅接手了需求工作，还接手了项目管理工作，这样的话我也解放了，用领导的话说，可以专心做技术了。我本来就应该专心做技术的，这两年瞎忙活，都写不出技术文章了，我理解领导的决定。但是那个刹那我很失落，因为这标志着推进了一年的Scrum彻底宣告失败了。年底的时候，团队又回到了18年的那种混乱状态了，差别就是，一年之前，我是混乱的中心，天天焦头烂额；一年之后，我成功置身事外，看着我的小伙伴们在那混乱。折腾了一年，心累，无可奈何。

后记

莫伤心，做人呢最重要的就是开心。年底的时候，我们又请来一位大牛做咨询，大牛梳理了一下开发流程，认为我们团队除了产品经理之外，还是需要一位项目经理，其实就是开发负责人，我欣然接受了，这下就和老东家的那一套一模一样了，驾轻就熟。

话说回来，其实就算没有那根稻草，我们的Scrum也不会推进得很好，大概率会跑成“僵尸Scrum”，就是假装Scrum，实质还是瀑布，那样我可能会更累，团队也会不舒服。究其本质，还是因为能力问题，Scrum讲究以人为本，其实是“以人才为本”，对程序员的要求太高太高了。团队的技术能力不行，说到底，还是因为我的能力不行。做管理耗费精力，那不如简单跑跑瀑布，多花点心思夯实技术。毕竟，没有最好的，只有最合适的。

年底面试的时候，偶然遇到一个哥们，他告诉我他们的产品一天一个版本，我惊呆了，仔细询问了他们的实施细节，特别兴奋。我以为只有腾讯、阿里这种大厂才能做到一天一版，没想到一个小游戏公司也能做到。我特别激动，跑去和领导说，领导拍着我的肩膀，语重心长的说：老徐啊，我们还没那个必要啊…其实这话领导不是第一次对我说了，可能领导早就觉得Scrum很有难度，搞不好他早就想劝我放弃了呢。

失败归失败，我要正视失败，没有能力基础强推Scrum，是无源之水，本来就是不现实的事。正面强推推不动，那我改进策略，缓慢渗透，徐徐图之。先把技术基础夯实再说，不就是CI/CD嘛，多大点事。现在我们弃python换Java了，成熟工具有的是。而且我们有的是机会，有些项目人工测试确实很困难，有做自动测试的必要。年底的时候，我给新来的员工排任务，就明确要求了开发单元测试脚本。对于新事物，新员工比老员工往往更容易接受一些，希望我的这点小心思能够以点带面，给部门带来一些新气象。

为了Scrum而Scrum是不合实际的面子工程，毕竟Scrum不是目标，我们的目标是要开发出又快又好的产品。我们要让团队和谐相处，让大家工作的时候脸上都洋溢着幸福。未来还是很有希望的，慢慢来，加油！