首先推荐两篇王垠的博客文章：
今天回看了一遍王垠的这两篇文章，比较庆幸的是，自己在平日的工作中，很少在无意间触犯到王垠提到的这些礼节问题。
会突然想起这个话题是因为工作中的一点小事，也挺有意思。起因是我擅自 merge 了没有经过 review 的代码，我的同事就开始在群里批判我的代码，也许是他觉得不经过他 review 就合并代码的行为，伤到了他在团队中的尊严和地位。
我现在在一个 web3 项目的开发团队工作，团队总共也就四五个人，内部管理却非常混乱，这是我在之前的工作中没有遇到过的。不过说实话我之前的工作经历不太够看，没有什么参考价值，所以我总结不出什么有用的结论。
要我对比的话，现在的工作和以前的工作，工作方式上最大的区别，在于分配任务的粒度不同，或者说分配到个人头上，负责的事情大小不同。
比如我在 Onchain 工作的时候，需要开发 Solidity 合约，来支持我们的分布式文件系统对 EVM 链的兼容，那么这件事情就是我在做，有人 review，但实际上整个 合约仓库 的代码只有我一个人提交（这里不是在强调提交人数的问题），在这样的模式下，自然也就不存在现在遇到的什么代码质量之类的问题。
（Onchain 这家公司已经解散了，当时项目的代码并没有开源，现在的代码仓库是我私自备份下来的，两年过去了，应该不会有什么风险吧）
再比如我在 Fusionist 工作的时候，整个 Endurance Network 的网络是我一个人启动并维护的，没出过什么问题。主网上线的时候有一个专业的运维同事帮忙开服务器、配置 Docker 之类。
（我已经离职了说出来应该没事吧）
包括更早先的工作经历，不管是我自己还是同事，直观感受上就是每个人都会负责某一块的业务，对整体业务负责而不是对某个具体的开发任务负责，个人的职责相对明确，在负责事情的时间长度上，都是几周到几个月为单位的，所以倒是没有出现过管理混乱的情况。
现在的工作模式是不太完整的 Scrum 风格，每个任务都是两到三天的开发周期，也就是小的开发任务，这些开发任务一定程度上是不区分业务线（代码仓库）的，开发人员会随机参与到不同的事情上。每个人都是在对自己的开发任务（PR）负责，而不是整个仓库负责。这种模式下，每一个开发任务都会有不同的负责人，造成感官上是比较混乱的。
侧面来对比的话，我之前的工作，如果某个人离职，是需要做很长时间工作交接的，因为需要一段时间来让别人接手。现在的工作，如果某个人离职，其实也没啥需要交接的，最多也就两三天的任务内容。不知道是不是远程工作的缘故，让公司被迫选择这样的管理方式。
我的大老板曾经把这种工作模式上的差异，总结为中国式的管理风格和欧美式的管理风格之间的差异。
我只是个普普通通的开发人员，没有管理经验，也不懂这些管理模式什么的，并不想也没什么机会需要我去思考这些问题。只是现在有点能感受到，其实管理本身是一门学问，挺大的学问……
解释一下 “不完整的 Scrum” 风格是什么意思。上面的内容看起来是开放式结尾，实际上是在对 Scrum 风格表达不满，只是因为当时还在职，不好意思说太明白。
原版的 Scrum 敏捷开发，是指团队成员之间互相平等，产品经理来决定事情的优先级，而具体事情在技术上怎么分工怎么做，完全是团队成员自发决定的事情。团队成员真的就是在合作，共同完成某些目标。
在原版 Scrum 敏捷开发中，是没有管理员（Leader，领导）这种角色的，只有产品经理+技术团队，技术工作不是来自于领导的分配，而是团队成员协商决定的，这样不但每个人都有参与感，任务完成后，也会有成就感和归属感。Scrum Master 属于仆人式领导，主要帮助成员解决技术问题，以及让团队贯彻 Scrum 模式，而不是对团队进行管理。
而 “不完整的Scrum”，是指 Leader 既不愿意放弃自己的领导身份，放下对团队成员管理的权力，又希望使用 Scrum 框架里 Sprint 的模式进行开发任务的管理。
相当于想把传统瀑布式管理的好处，和 Scrum 管理的好处结合起来。事实证明这种做法是非常糟糕的。
如果在 Scrum 管理模式下，当 Sprint 任务来自于领导的策划和分配，而不是团队成员自发组织时，首先就会让团队成员失去责任感，失去 Owner 精神。任务是领导事先规划好的，我操什么心？岂不是安心做一个 Code monkey 就好？也因此在团队里能留下来的，大概率是安心做 Code monkey 的人。
其次就是没有成就感，一个任务也就两三天的时间，做完一个任务接着做下一个任务，上一个任务做完就跟我没关系了，紧接着进行下一个，完全是外包式的工作。只有当上一个任务的内容出现 bug，才需要回过头去修复，只要不出 bug，就不需要任何优化（显然是没有编程经验的人才会是这种想法）。我常有的一个体会是，做的越快，下一个任务就来的越快，导致效率越高反而做的越多。
然后是领导的问题，从领导的角度，感觉每天做任务分配就是他的职责，一旦把任务分配好，就松了一口气，安心了。刚才提到的，开发工作，是经常需要一些持续性的优化的，哪有一个需求开发完就再也不去动的道理。而领导似乎不懂这一点，一旦一个任务标记为完成，如果第二天说优化了什么什么，他会不理解，“这个需求不是已经 close 了吗？”
再然后是测试的问题，我们团队内没有专门的测试人员，而神奇的事情是，似乎领导觉得不需要测试人员，甚至连集成测试都是极其不重要的，最最重要的竟然是单元测试。上面提到，一个需求标记为 close 了，标记为 close 的标准是什么？标准是写完了代码以及单元测试。集成测试是什么？没听说过。这种模式下会发生什么情况？情况就是上线的（公开测试网）的代码，是完全没有经过集成测试的。也因此确实出现过很多次上线事故，大概上线 5 次测试网宕机 4 次这样的频率吧。
最后是 Sprint planning 管理表格的问题。目前的方式是一个任务对应一个 PR，单看这句话的描述，是不是觉得很外行？怎么就能恰好是一个PR？PR可大可小。比如，命令行 description 里存在一个 typo，就一行代码，我提了一个 PR，需不需要大动干戈地到 Scrum 表格上加上这一条？如果加吧，Scrum 上的任务可以理解为 OA 系统中的流程条目，每个步骤都会艾特相关的人，而且需要填很多字段，比如属于哪个项目，优先级是多少，reviewer 是谁等，为了修复一个 typo 就艾特那么多人实在不值得。可如果不修吧，难道就眼睁睁看着这个问题一直存在吗？于是，实际上经常发生的情况是，大家会在一个正规的 PR 里杂糅进去一些不相干的优化，让 Scrum 表格整体的使用体验非常糟糕。