[Day15] 团队系统设计 - 开发系统

当一个需求，经过规画系统的一连串洗礼後，就准备进入开发。对团队而言，工程实践方法，只有最适合，没有最好。因此，在本篇中，我不探讨程序架构、云端架构或是 CI/CD 这些根据应用场景不同，就可能有不同的实践方式的技术细节。我们来聊聊，在 Scrum 的日常开发中，团队协作上可能会导至系统性问题的坑点。

冗长的站立会议

我曾经在前公司看过最夸张的站立会议，开了快一小时。我相信，大家绝对不是站在原地闲聊，而是很认真的在讨论问题。值得思考的题目是，问题的范围，是否需要整个团队一起讨论？如果是，表示 Refinement 没做到位；如果不是，表示有些成员的时间被浪费了。

站立会议的内容，依据团队不同，可以自由演化，但我认为，再大的团队，站立会议，都不该超过 15 分钟。更重要的是，成员必须要主动的提出需要团队支援的问题，在站立会议上，找到正确的资源，在会後进行「跟进讨论」(Follow-up Discussion)。

避免过度依赖规则

某次检讨会议 ( Retrospective )，大家热烈的讨论一个状况：前端因为不知道後端的 API 何时可以准备好，所以无法准时交付。经过一轮热烈且秏时的讨论，团队表决出一个结论：日後後端 API 必须在 Sprint 开始後的第 x 天，将 API 交给前端，如果发生 xx 情况，则要做 xx 调整。事後我看到这个结论，很显然，大家努力错了方向。

我提醒大家：「有什麽比转身过去问一下夥伴更敏捷呢？站立会议中提出来迅速交换情报，不会比记一堆规则简单吗？」

「脑力密集人才的管理之道」（Peopleware) 中提到，太多的 SOP，会让系统失去自我修复的能力。团队系统也是同样的道理，停止订规则，开始对话吧。

过度依赖 QA

在有 QA 编制的团队，偶尔会观察到一个现像：大家把品质议题全权委托给 QA。交付符合验收标准的的程序，是工程师的责任；QA 应该负责的对象，是产品，是消费者。 RD 该吐掉奶嘴，自己为自己的程序把关。对自己的创作都无法负责的成员，主管应该好好思考，是否合适留在团队中。

主管变成保姆

有些新手主管觉得要充份掌握成员的状况才有安全感，但这样成员会过度依赖主管的关心。相信自己的团队，把状况、进度回报的责任交回给成员。当责与习惯的养成需要时间，不必过度担心是否会有打混摸鱼的情况，海水总有退的一天，没穿裤子的人总就会被发现。

本篇介绍了在开发过程中，团队系统应该关注的原则。一个 Sprint 的生命周期：Planning - 开发 - 检讨。明天，来聊聊我认为最难开但也最有价值的-回顾会议 (Retrospective)。