看完一堆敏捷文章，讲了一口好敏捷，但真的实际去实作或推动总是力不从心吗？Daily Stand meeting, Planning meeting, Demo meeting, Retrospective meeting… 这些会议是什么、会议要持续多久、要注意什么、成员在会议中扮演什么角色？如果你对这些不太清楚，读完这篇你会对敏捷实作更有一些想法：
主要讲的是：
1. 跑Scrum 的几个重要会议，包含会议内容以及哪些人应该要参加，还有很重要的是「替代方案」
2. 整个团队以及组织过于庞大，该怎么踏出第一步
敏捷管理的名词解释
Scrum Master（没有简称，叫起来怪怪的…）
又称敏捷教练，宣传以及教育敏捷方法给自己的队员、主持敏捷相关会议、持续改善流程及帮助团队解决困难(或找到对的人帮忙解决)。由于没有实际掌权的能力，却又要领导团队往对的方式进行工作，需要「Strong communication skill」激励士气并让人信服。
Product Owner（简称PO）
基本上是产品经理的角色，负责规划团队的roadmap，了解使用者以及Stakeholder 需求，规划一个推出后会让市场发出wow 的产品。写User story（Feature) 到Backlog (Feature pool) 中，并能判断哪些Story 是优先要做进而放到每次的Sprint 中。
Scrum Team
参与这个Scrum 的成员，包含Scum Master、PO、工程师、设计师、测试，最多5–9 人，建议这些人的座位就坐在一起，方便讨论，敏捷推崇有什么问题「即时且面对面的讨论」。
强烈建议讨论文需要文件纪录，以免之后很难回溯，要交接也会有口述上的落差，程式码真的很难三言两语就说的水落石出啊。
Stakeholder
通常是业务方、客户、股东或是老板本人，只要是「有权利」可以否决产品的并且非上述以及QA 团队的，你就可以当作是Stakeholder。
Sprint
指Scrum 团队完成一定数量工作所需的短暂、固定的周期。基本上Sprint 的周期为2–4 周。
固定时间很重要，多一天少一天都不行，这样可以让团队的工作有一个固定的节奏，如果时间不断更动，会让团队成员觉得「在这个时间内完成不了也是没关系的心态」。如果真的做不完，我的建议是带着RD leader 去review 为什么不行？如果在立会（文章下一段会提到）上都没有提出遇到的问题，照理来说是必须要在时间内完成的，所以立会很重要，Review 机制也很重要。
全员参加的重要会议
![图片[2]-敏捷式管理白话文！ Scrum Master、每日立会是什么？ - NowX 游读社-NowX 游读社](http://nownexts.com/wp-content/uploads/2024/06/e4c10d7be1dd06635800b782d47b2608.webp)
每日立会（Daily Stand meeting）
Scrum master 主持会议，目的为同步所有人的情况；一个人的时间不超过3 分钟，总会议不超过15 分钟。找一个空间（小桌子围绕），有白板最好但非必要，大家依序同步专案的内容给所有成员，内容快速带过昨天做什么/今天做什么/目前面临的问题是什么？如果需要花时间讨论的会后再去讨论，（Scrum master 请严格把空时间，超过三分钟不能解决就会后讨论）。注意请以维持整个团队资讯透明同步是这个会议的宗旨！
看过很多失败的立会，例如一站就是半小时，脚酸不能坐下只因为这是「立」会、参加的人太多，一次十几二十个，即使一人讲一分钟就过了二十分钟、或是开发团队不好意思说遇到什么问题，一整个礼拜都在讲修Bug 仍然没有进展，这些是立会被误用的例子。
建议：我会用电脑纪录大家今天准备做什么以及遇到什么问题，隔天的Daily meeting 可以检视是否做到，或是一件事情是否做太久以及问题解决了没。这个好处是有个Log 把大家做的事情都记录起来。常常会遇到今天说要做什么，隔天会议在讲昨日工作时完全没相关，请不要太相信RD 的专注力（sorry 各位RD 朋友…）
计画会议（Planning meeting）
Product Owner 主持会议，每一个Sprint 开始前计划本次Sprint 要做什么，把所有产品要阐述的说得一清二楚，并且跟着工程师一起拆分任务（大需求拆成小任务的概念），以及大家估计每个任务大概需要做多久。通常这个会议是最耗时的会议，可能有人到4 个小时或一整天；我觉得不错的做法是请PO 阐述完要做的工作后，请较资深的RD 分派任务，或是Scrum master 跟着团队一段时间会大概知道哪些人可以做哪个，但是我还是倾向没有人是专精什么的，大家都可以轮着做，以免有人离职会对团队伤害很大。
估时真的是一个智慧，在Scrum 的估时有一套方法，我个人觉得很复杂，但我看过最清楚的是这部影片。我尚未实行这个方式，一来我觉得太过复杂，二来太过费时跟大家解释(人性就是只要一复杂大家就懒)，目前的做法我还是请RD 用一天5 的小时去估计工作量，让时间以及经验让辜时更准确。
如果真的估不出来请讨论是否任务分得不够细或是可以拿之前做完的task 与之相比，是更容易还是更难呢？只要有标准一定可以比对的（或是把任务比拟做衣服的尺寸，s/m/l 大概哪个任务对应哪个尺寸去评估时间）。
建议：RD 或QA 的工作做的熟悉后就轮着做，并且可以指派熟悉的成员帮忙，这样整个团队都不断地在upgarde，这也是Scrum master 很重要的工作之一。在这个会议中，很重要却容易忽略的是「定义可以交付的标准」在一开始实行敏捷或是新成员很容易RD 的任务跟PO 的任务完成是有落差的，我吃过很多次亏， RD 说得完成可能还需要一天去上线，那这样时间以及对下一个任务的安排就会有所影响。
我的case 将Plaining meeting 稍作变形，将PO 阐述拆分任务以及估时分成两个会议，一个在星期一一个在星期五，中间的时间PO 与RD 可以讨论后需要修改有些弹性，想了解的可以看我的上一篇：不纸上谈兵，所以Scrum Schedule 怎么规划？#新创公司实验心得(上)
Demo meeting
性质就是UAT (User Acceptance Testing)，这个会议是让开发团队展示他的成果，可以是已经测试完的或是开发玩只差测试（可以在Sprint 一开始订定可以Demo 的标准），如果有需要甚至是可以请相关的业务团队一起参加此会议。
回顾会议（Retrospective meeting）
Scrum matser 主持会议，约一小时。在每次Sprint 结束会有个检讨会议，检视「怎么让团队更好」、「怎么让工作更有效率」，把团队视为石头去打磨，如同幽助从灵弹、灵光拳到最后的妖灵弹（超宅）。
请注意这绝对不是一个好棒棒互相吹捧的会议，Scrum 毕竟是国外传来的，亚洲人的性格就是不敢面对面得罪，Scrum master 的职责就是鼓励大家发言，并且成为大家的榜样，说出哪里需要改进，或是所有人都讲至少一个需要改进的地方，并在会议结束时跟大家说：「大家真的好棒！我相信之后会越来越好的」。
建议：以我的case 来说团队成员约20 人，将他们分成三组去工作，所以如果每两周开个回顾会议，会议会太多太杂；我的做法是在团队周会是顺便检视整个团队遇到哪些问题以及需要优化的部分，我这个会议中我会让所有团队知道整个Team 做了哪些事，鼓励做得好的(技巧性的所有人都会轮流被鼓励到) 需要改进的地方一定要记起来，不然这个会议会沦为形式开身体健康的，在下次下一次会议中检视要改进的改了吗？
去抽丝剥茧混乱的来源，并一步步的使之清楚明了，并像传教士般感染全部的成员，是Scrum Master 的职责。
大家都没听过敏捷，我该如何下手
这是大家敏捷看得拍案叫绝，还没做就放弃懒得叫的原因之一。我觉得方法有几个：
-
像提Proposal 一样跟主管提案，大刀阔斧。（不建议，通常想得太美好之后做起来被主管黑掉，除非你就是主管本人，但也得考虑实施的结果不好让底下团队很无力，方向变来变去）。
-
找一些简单时间线拉比较短的的专案小组实行，如同以前生物课的实验主以及对照组。这个case 对于你要看专案以外也要看小组成员，然后把敏捷的正向以及方法不段的在这个专案中植入他们的工作以及思考；不要忘记把QA 以及设计师一起加入本次实验组里，事先规划好每个Sprint 的周期，以及每周大家主要任务要做什么。
![图片[3]-敏捷式管理白话文！ Scrum Master、每日立会是什么？ - NowX 游读社-NowX 游读社](http://nownexts.com/wp-content/uploads/2024/06/cf3d41f7c92305d055080e3048beb58f.webp)
-
整个Team 或是你可以掌握的人员，开始部分实行敏捷流程，比如说从每日立会（同步）以及检讨会议（优化）开始，这个即使你的团队目前的专案是waterfall 也是可以的，这个不管有没有导入敏捷都是对团队有益的；做些纪录比如说开始了这两个会议让专案的进展（把专案拆分成task, 每周完成的任务是否有变多或是完成复杂的任务时间是否缩短了）以及团队合作的效率提升，想办法值化出来以及邀请主管参加回顾会议，循序渐进的把更多的敏捷方法导入。
不是追求快，而是追求质量以及高效
敏捷不是照本宣科，而是了解敏捷精神后为你的团队去客制化敏捷流程，哪里需要多一个会议，哪个会议其实不需要…等等。像是以每日立会来说，在快要发布一些重要功能的紧急时刻时，我会一天两个立会，一是一早，二是下班前再次确认问题解决没，一个晚上你可以有更多的思考，为明天一早做打算或是申请加班；如果你有在看番茄工作法你会会觉得方法跟番茄工作法的精神类似（早晨AM review 以及晚间PM review）。之后会分享最近看得子弹笔记/番茄工作法的心得，将发现这些增强效率的方法跟敏捷的大架构是大同小异的。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
THE END
暂无评论内容