分享一下我自己经历过的几间公司： 1. 职涯最初期，事後回想把 scrum 跑得最好的公司 是一间新创公司，Product owner(PO)就是老板本人， 如所有的老板一般，所有他想要的东西都想要最快速度拿到， 而这位PO的优点是，他知道不能要马儿跑又不让马儿吃草， 所以在给他他最想要的东西的同时，他能够接受其他事情延期， 并不会讲出： 我是成熟的大人，我两个都要。 这种屁话。 此外，所谓「他要的东西」，通常是真真正正的 MVP， PO 决定方向、优先顺序，但怎麽验证 MVP，是整个公司一起决定（没多少人）， 大家都找到最小的成本去验证这个功能是否被需要。 在这间公司工作三年，基本上，开发超过两周的功能都是最後有持续在使用的， 我在的期间开发出来的功能，只有最後被更好的版本迭代掉， 没有花了大笔资源（人力）开发，结果却是进垃圾桶这回事。 结论： 曾经与一个前辈讨论过，当一个团队很少开发出不必要的功能的时候， 就是把敏捷的精神做得很好的象徵。 我可以说，这间公司是我待过最敏捷的公司， 有趣的是，这间公司在我离开前几个月才开始跑所谓的 scrum。 因此，有没有 scrum、sprint、retro、standup ， 对於是否敏捷，一点关系也没有，这些工具名词， 甚至我可以说，这些名词与行为本身，其实不会帮助你更敏捷， 他还是会让你保持原样。 敏捷的团队还是敏捷、导入了 scrum 之後，可以让团队更透明； 瀑布的团队还是瀑布、导入了 scrum 以後依旧是老样子。 2. 挂着 scrum 皮、骨子却是瀑布 大约十个工程师的开发团队、维护一个公司的重要产品， 100% 把瀑布做成 scrum 的团队，每天有着 scrum 的皮、但在做瀑布的骨。 为什麽我这麽说？ Scrum 为了敏捷而生、敏捷的用意在於，在「改变中的需求、不确定的需求」的环境下， 保有工程师的产出能力。 我待的这间公司有这样的需求吗？ 没有。 敏捷强调尽早验证尽早确定资源是否投入、适时的调整人力资源在产品最需要的方向上。 如果没有这样的需求， Scrum 就是瀑布，因为你早期验证做完也没人给你 feedback， 那干嘛不直接往最终目标瀑布下去就好了？ 这公司，有看板有 scrum 有 standup 有 retro， 但 retro 都在聊大家的心情、谁狗怎麽样、关心一下少数族群（我）， 有在跑 scrum ，但最後变成了大家互相关心对方心情的「交谈」， 产品方向上有问题吗？我们下个 sprint 重心是什麽？有没有什麽要砍、要加的？ 没人在乎。 3. 瀑布与敏捷混合的公司 最後一间公司就比较有意思， 平常的时候很瀑布，但部分的专案可以跑得很敏捷， 这也是我待过最舒服也最有成就感的公司。 绝大多数的时候把 scrum 跑得很瀑布， 陨石砸下来可以、那瀑布就拉长一点，瀑布不想变长也可以，那就砍功能。 而有全新专案、提高盈利项目的时候， 团队也能跑得很敏捷，尽快做出 MVP、尽快验证、投资人力在最重要的地方。 必须说，从个人生活的角度，瀑布绝对是比敏捷舒服的方式， 因为你很清楚自己要做什麽事情，陨石掉下来就加时间或砍功能， 而敏捷是随时都在想要怎麽用最小的资源来验证假说， 假说成立以後，该把资源放哪里可以效益最大化。 如果可以，我会想要瀑布敏捷两个交替， 想认真搞产品的时候做敏捷、想让心力休息的话做瀑布（专注在coding即可）， 是我最理想的环境。 -- 我的结论是， 与其扒着 scrum 这个词不放， 我更在乎的是一个团队的敏捷与否， 而一个团队是不是敏捷，其实聊个十分钟就能感觉出来。 至於工作能不能开心、能不能有 WLB， 主要还是看团队氛围，而不是瀑布还是敏捷。 从做产品的角度，敏捷绝对能提高产品存活的机率， 从工程师能维持专注的角度，瀑布能让工程师更稳定的走在自己的规划上。 可惜的是，绝大多数的我们没办法影响自己身处的团队， 我也曾经天真的觉得，我体验过敏捷团队的好处、希望能带给团队正面的影响， 最後发现，一个不需要敏捷的团队，是不可能把敏捷给跑好的，甚至说， 「为什麽要敏捷？」 如果一个团队真实得不需要敏捷，那又何必强推呢？ 想通了这个问题， 我就开始能接受大家把 retro、standup、planning 乱搞了。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 174.164.246.228 (美国) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1732790712.A.418.html ※ 编辑: RiverSki (174.164.246.228 美国), 11/28/2024 20:19:16