我在敏捷路上踩过的那些坑 | IDCF FDCC认证学员作品
共 4322字，需浏览 9分钟
·
2020-08-30 02:08
说说我在敏捷路上曾踩过的那些坑
关于敏捷要不要文档
我其实在多年前就听说过“敏捷”这个词，但当时并没有深入学习，而片面的理解总是会产生不少偏差。比如，用了敏捷可以不需要写文档？（嘿，这对于一个开发来说，真是个充满诱惑的利好消息呢！）
但在经历过多次因缺乏文档而难以获知曾经发生过什么、为什么代码要这么写以及新人加入或异地沟通时各种说不清等种种“苦难”后，我不得不承认，我们可以不注重文档的形式，只做到真实清晰的表达即可，但没有文档是万万不行的。
现在，我当然不会再认为敏捷是不需要文档的了，敏捷宣言中左边固然是更重要的，但右边也要承认它的价值。“可工作的软件高于详尽的文档”，我们要产出给客户带来价值的软件，但文档也是不可或缺的。我认为，文档最重要的价值是向后传递信息，面对面的沟通固然是团队协作中效率最高的方式，但文档才是在穿越时间和空间时的最佳信息传递使者。
文档可以固化地保存团队在各个环节过程中思考的成果，也可以简洁地描述我们的软件。我不喜欢刻意地去编写文档，但在面对面沟通时，我们会发现如果用一些书面文档辅助表达，会让沟通更高效。对流程的理解，设计的构思，这些都可以在自己思考时就写下来。和团队讨论时，我们直接在思考时形成的草稿上进行修改，重要的讨论内容还可以记录成会议纪要，讨论结束定稿时形成的自然就是团队的一份积累。在后续很多情况下，都证明了这些文档确有其价值。而且，我认为只有习惯于在沟通时顺带记录下文档，这才是团队能够形成有效的文档记录习惯的方式，而不是去刻意甚至形式化地为了记录而记录。
团队与团伙的区别
曾经认为一起做一件事的就是团队，但后来发现组织和纪律也是团队的重要元素。无组织无纪律的人是做不好事情的，每个人都只关注自己认为重要的内容，哪怕目标一致，步调和路线也是混乱的。
有人和我说，团队应当是具备战斗力的，但我们也会在新闻上看到一个词“犯罪团伙”。我认为团队和团伙两者之间的区别在于是不是有互相认同的共同目标和行事准则。如果缺少这两点，一群人聚在一起哪怕是为了做同一件事那只是团伙，他们可能各自有自己的利益诉求，只是刚好凑在一起而已。只有所有成员互相认同，目标一致并且约定了整体的行事准则，可以做到有纪律地向一个目标努力，那才是团队。前者如散兵游勇自然无法发挥战斗力，后者聚而不散自然也就会被认为战斗力更高。战斗力只是他们的外在表象，而不应该是判断的标准。
敏捷团队首先应当是一个团队，而不是无组织无纪律的团伙，我们作为一个团队为了更好地交付我们的目标，那就需要团队中的所有人共同对齐和认同我们的目标，并约定我们的做事方式和准则（团队建设之初，这可能没有被形成正式的文字稿，但也应当存在且团队成员都能认可），或许还需要约定一些奖惩方式来确保团队的准则得以贯彻（严肃的考核或许不会是个好的选择，团队互相认同的一些有趣的奖惩方式有时会更有效）。
什么是完整的Scrum团队
我们曾经是一个只有3~4个开发的“草台班子”，没有产品或测试，每个人都直接和业务进行沟通，自己完成开发和开发自测。当我在知道Scrum的三个角色时，一度都对团队的组成产生疑惑，团队是否一定要有产品经理和项目经理（当时的我混淆了PO和产品经理以及SM和项目经理），如果那才是完整的团队，只有开发的我们又该怎么Run起来呢。
直到某一天，我意识到团队角色和岗位是完全不同的概念时，才恍然大悟。团队中的角色就像是舞台上扮演的人物，当我在开发时，我的角色是开发，而当我在和业务沟通确定需求时，我扮演的其实就是PO的角色。如果我独立完成一个需求的沟通和开发，我其实并不需要有SM来帮助我和其它成员协同，我可以自己把握好节奏，成为自己的SM（当然，如果只有一个人其实没必要Run Scrum，利用Kanban或许是更好的注意）。
同样的，如果我和同事们一起完成某个需求，只要我们中有人可以扮演PO来和业务沟通，有人可以在团队中协同大家把握好节奏，帮助解决那些可能会影响到我们的因素，哪怕我们是轮流在担任这样的职责，那么我们依然有成为Scrum团队的基础。
所以，判断团队是否可以采用Scrum或者团队是否是跨职能团队，并不能看团队有哪些岗位的人员，而应当看团队的人员具备哪些能力。
小团队是否天生就敏捷
有人说，只有寥寥两三个人的团队是天生的敏捷团队。不可否认的是，相比大规模的团队来说，小团队在某些方面会有天然的优势，这确实使得他们会更容易实施敏捷。特别是当他们都坐在一起时，人数少且能够面对面的沟通会让信息流转尤为顺畅。可是，我们应该认识到敏捷并不只有沟通的要求。在敏捷的12个原则中，面对面的沟通仅仅只是其中之一。
敏捷团队是能很好的适应变化的团队，同时他们的每一次成功绝不是偶然和运气，他们的工作方式尽可能地遵从敏捷原则。而要满足这些，除了人与人的沟通和信任，我们也要能做到以客户价值为中心进行短迭代、稳定节奏的工作，欣然面对变化的同时还能持续改进，追求更卓越的技术和质量。
团队的基础——组织纪律
这里又不得不说到作为团队的前提（前面已经说过团队和团伙的区别了，不再赘述）。小团队无论是几个人组成的，它首先应当具备团队应有的组织纪律。这是前提，特意强调这一点，是因为在团队的发展初期，人员少沟通方便，反而容易忽略尽早地进行目标对齐和规则确立。尤其是技术人员，一上来就埋头苦干可能是常态，有些可能还是“个人英雄”，在团队初期这样做或许可以帮助更快达成目标，但如果长期处于“散兵游勇”的状态，始终无法形成团队合力，带着其他成员共同完成目标的话，那可能失败就是可预见的了。
团队的沉淀——文档记录
缺乏技术和文档的沉淀，这在很多成熟度较低的小团队中是个比较显著的问题。我认为这也是沟通过于顺畅带来的一个负面效果。由于沟通基本靠“吼一嗓子”，很多问题都可以快速解决。但这样的“快速”会让团队很容易忽略关键内容的记录，而我们知道口头沟通是最不利于记录归档的。当出现问题时，“以前好像遇到过”或者“当时我们是怎么说的”等场景下，团队会需要依赖回忆来解决问题，此时记性好的人可能会作为“活文档”变的很有价值。
自然的，我们应当意识到，这样的方式是存在很大问题的。敏捷宣言中说“工作的软件高于详尽的文档”，但尽管可工作的软件更有价值，我们也不能忽略文档的重要性（这点前文已说过，不再赘述）。
团队的节奏
对于经常做一些小规模的需求甚至是一些维护性的需求开发的团队，由于需求的零碎，且这些需求可能本身也不太费时，变化的可能也不多，快速交付可能会成为常态。但这种“快速”和敏捷所追求的“短迭代”还是有区别的。前者依然是一次交付，后者是频繁交付。且长期的处理小需求，缺乏对长期项目的处理经验也会导致团队习惯于按需求进行开发，极少会去在意团队本身的工作节奏是否稳定。当在这样的零散需求中偶然间出现一个大需求时，如果团队没有对这个需求进行拆解，而是按以往的习惯去尝试进行一次性的交付，那团队的工作节奏可能就会像原本拥挤但还算畅通的路上突然插入了几辆大型车一样出现了阻塞。
在我看来，对于一些基础薄弱的小团队来说，短迭代和稳定节奏要做好是尤为困难的。因为这不只是沟通的问题，还依赖工程方面的基础和团队良好的工作习惯。
虽然小团队在开发时很少遇到难以解决的代码冲突问题，但是如果没有好的代码质量和代码管理规范，当关键人员离开时团队可能就会遇到各种麻烦。而且我们应当知道缺乏良好的代码质量和架构，就如同万丈高楼缺少了深厚的地基，终究无法长久。这些工程技术面的麻烦也一定会影响到团队的开发节奏和交付周期。
而团队是否有意识地进行版本的管理，这也是团队节奏控制的关键。我们要避免的是无计划性的接纳和完成需求，这样的成功交付依赖需求本身的规模和项目难度，而非团队之功。控制需求进入的DoR，以及每个环节的DoD，对大需求进行拆解，对小需求控制WIP，度量团队的需求交付周期以及固定时间盒内的吞吐量，让团队养成良好的工作习惯和有节奏的工作方式，这无论对于什么样的团队都是很有意义的事。
总之，相对大规模团队来说，小团队虽然面对面沟通更容易，但也可能会有自己实践敏捷的难点，没有任何成就会是天生的，只在于找到自己那条路上的坑，想办法迈过去罢了。
螺旋上升中的重复表象
团队的点滴进步就像是走在螺旋上升的阶梯上，在前进的道路上会出现看似与出发点重复的现象，但那其实并非是等同的。如同禅宗三重境界“看山是山，看山不是山，看山还是山”，团队的部分做法可能有相似，但本质却并不一致。
如同前面我曾经说过的面对小需求的快速交付与团队有意将需求拆解成满足INVEST 准则的用户故事后达成的频繁交付，这其中的差距绝非一步之遥。
还有，实施DevOps后达成开发一键部署，表象是开发直接部署，可是这和某些小作坊式的团队开发直接操作生产部署看似有着相似的表象，但却是一个天一个地。在有系统控管的情况下快速的部署生产是我们要追寻的目标，但绝不是No Ops。
这些都是在“螺旋上升理论”中的重复表象，这并不是什么高深的理论，在团队通过PDCA进行持续改善的时候，或者是拿团队的日常和一些最佳实践进行对标时，不免会发现有些形似的表象。我们在学习和实践敏捷的路上也会遇到各种往复的情况，这些可能会对我们产生些许迷惑，但我们只要坚持向前，就会发现这些表象底下的实质区别。
我依然走在通向敏捷的路上，就如同螺旋上升的盘山路，虽然有各种颠簸，但我坚定它会通向成功的山顶，望与所有同路人共勉！
