黄国瑜&黄意钧2020-05-29  

引言

这几年在敏捷(Agile)圈子吹起了一股学习引导的风潮，也让我因此结交了很多敏捷圈子的朋友。在这些朋友当中，Vince是最让我感到印象深刻的一位。Vince长期活跃于敏捷圈，目前是KKTV产品研发中心总监。如果要用一个关键词来形容他，我会说他是「推坑王」！因为他不仅自己开始学引导，也介绍了一大群敏捷圈子的朋友来学引导，而且除了在不同领域学习，他也不藏私地与他人分享他的学习以及实践中的体会。

因为结交到越来越多敏捷圈子的朋友，有一天我再也忍不住，想要以一个外行人的角色，了解敏捷到底在做什么，以及引导在敏捷的实践到底扮演了什么角色，所以我就对Vince发起了邀约，Vince也豪爽地一口答应，也因此催生了这篇文章。

在这篇文章中，Vince分别谈到了敏捷的本质，以及Scrum的几个核心概念—Sprint、三大角色、五大会议。此外，Vince也谈到了他在运用Scrum带领团队的具体实践与心得，还有引导在Scrum所扮演的角色。全篇内容主要为Vince的口述，然后再由我整理成本文。

关于黄国瑜 Vince

Vince是视频串流平台KKTV的产品研发中心总监，同时也是台湾元智大学资工系的兼任教授。他在攻读博士学位时，研究的是高效能数据探勘演算法(High Performance Data MiningAlgorithm)，取得学位后历任研究机构研究员、科技公司工程师与Scrum Master。他自许成为一位「持续改善者」(Kaizener)，希望持续学习并且与团队成员共同成长，实践圣雄甘地所说的「成为你想要在世界看到的正向改变」(Be the change you want to see in the world)。

关于黄意钧 Ivan

Ivan是Open Quest的核心引导师，也是国际引导者协会IAF认证的专业引导师(CPF)，并且拥有生态学、系统动力学及管理学等三个硕士学位。他长期为各式组织提供组织发展的引导服务，并且也引导跨领域利益相关人之间的对话与协作。除了引导，Ivan也热衷于研究及实践系统思考、行动科学及调适性领导，希望可以结合不同领域的方法与伙伴，致力于人类社会的可持续发展。

敏捷的本质是一个思维模式

每个人对于敏捷的诠释不一样，所以就形成不同的派别。回到源头，敏捷就是一个mindset (思维模式)：在面对世界多变的情况下，如何快速调适自己和团队的脚步，去因应不同的变化。以项目管理为例，传统项目管理会需要押上时程、资源与步骤，但是对于敏捷而言，这些东西都是死的，难以因应外在环境的改变。即使你押了时程与资源，事情还是可能会变，资源还是可能会不够。敏捷是一个大的想法，大约是起源自1980年代，随后从这个想法衍生出不同的作法，而Scrum是目前其中一个比较流行的作法。一般来说，在谈到Agile都会谈到Toyota，他们虽然没有定义敏捷这个词，却贡献了很多想法，其中一个就是在业界常提到的PDCA (Plan-Do-Check-Action)。这个PDCA的循环如果一年才做完一轮，迭代学习的周期就会太长，因次Toyota在他们工厂做了很多事情缩短周期、加快PDCA的循环。虽然敏捷被运用在许多领域，但是这种快速迭代的思维与作法特别符合软件开发的需要。相较于软件开发，传统制造业的开发成本很高，可能一个硬件开发失败就会损失上千万，因此比较不太容易接受失败。相反地，软件开发比较需要的是人工以及人力的调控。在写程式的过程中，如果发现问题就可以马上修一修，或是客户有什么问题也可以马上修，因此成本相对低。此外，硬件是上市前的成本就已经很高，因此较无法接受失败，而软件是上市前的成本不高，但是上市后的成本很高，所以敏捷的应用比较多是在软件的开发。Scrum是为了敏捷而设计的一套方法。为了不要让这个方法变得太难、让大家比较容易接受，所以Scrum一开始就仿效英式橄榄球。英式橄榄球会有争球的动作，每一个策略的运用都是希望可以往前推进几码，这个持续的推进就是敏捷的精神，而基于这个精神，Scrum就设计了一套框架性的方法。

Sprint—一个迭代周期

Scrum的一次迭代叫做「冲刺」(Sprint)，这是来自英式橄榄球的冲刺。每一次的冲刺就是要做一轮PDCA，通常一次冲刺是一到四周，我自已喜欢的是一周，市面上比较多人喜欢的是二到三周。虽然每一个团队的冲刺周期会有不同，但是一个团队的冲刺周期是固定的，这样就会有节奏感出来，久而久之习惯这个模式之后就会比较顺畅。

Scrum的三个角色

• 产品负责人(Product Owner)：敏捷是以产品为主，而不是以项目为主。因为项目的周期比较短，团队是为了这个项目而不是为了产品在做事情。「以产品为主」指的是要把产品做好，「以项目为主」指的是只要把事情及时做完就好。所以在以产品为主的敏捷团队中，会有一个角色负责产品的走向，而我现在在公司的角色就是产品负责人。
• 开发团队(Development)：开发团队通常是一群人，而Scrum希望这群人能够很频繁地沟通，所以人不能太多。一开始建议的人数是六加减三，也就是三到九人，后来改版为五加减二，这似乎是基于魔术数字「七」，超过七个人沟通复杂度会变高，迭代速度也会因此变慢。但是，并不是所有的软件开发都只要七个人就做得起来，有时候会需要更大的团队，所以后来就有人提出Large Scale Scrum，主要是用在上百人的团队。
• Scrum Master：负责观察会议的进展与动态，让大家觉察并且决定是否需要调整，不是去要求大家改变，而是让大家觉察并做决定。一开始如果大家对于Scrum不熟，Scrum Master就会教大家Scrum要怎么走。当大家熟悉了以后，他的角色就会变成观察整个团队或组织有什么可以调整的地方。Scrum Master注重流程并且也扮演引导者(Facilitator)的角色；他服务团队、产品负责人，还有上面的利益相关人，并且让团队变得更好。虽然Scrum Master可以被视为一个领导流程的领导者，但是他不是用命令控制(command and control)的方式。我觉得要扮演好Scrum Master很靠个人特质，不同人带起来的风格会不一样。我的做法是，当团队碰到一些问题，有人可能会在团队回顾的时候提出来，一开始其他人可能会不以为意，所以我会再观察一阵子，让子弹飞一下，等到有很多人开始觉察到问题的存在，我才会提议可以如何调整。所以有人把Scrum Master比喻为保母，有些保母是小孩子一怎样就去照顾，有的保母会倾向只是看着，只要没有出大事就会放着小孩去学习，也就是所谓的「actively doing noting」，很自主式地知道自己不做事情：我知道这件事可能有问题，我也注意到，但是我先按兵不动。有人则是一有风吹草动就会去干预，变成「actively doing everything」。我去上课时老师有提到，如果一个小孩坐在椅子上，椅子离地面只有五公分，小孩子摔下来不会有事，有些保母就会冲过去扶，但是这样一来，小孩就失去了学习的机会。

Scrum的五大会议

• 计划会议(planning meeting)：在这个会议里，团队会讨论这次的冲刺要做什么。会议目的有两个，一个是让产品负责人跟团队说这一次冲刺要做什么、目标在哪里，接着团队伙伴会讨论如何做到。每个周期的第一天会开这个会议，会议时间的长短会因为冲刺周期长短而有不同，如果周期是两周，计划会议大概是两小时。
• 每日站立会议(Daily Stand Up Meeting)：团队会在每天固定的时间花最多15分钟聚在一起，讨论三个问题：昨天做了什么？今天打算做什么？遇到什么阻碍需要别人帮忙？站着开会的原因是坐下来时间会拉长。在会议中，每个人会轮流用两分钟回答上面三个问题，这样团队即使有七个人也不会超过15分钟。如果有些议题只需要跟某几个人讨论，就可以会后再聊，不需要占用大家的时间。这个会议的目的是让大家每天有一个快速同步的时间。有人说这个会议的目的是盯进度，我觉得不是，因为最重要的不是「你做了什么」，而是「为什么你要做这件事情」。因为在围圈的时候会有一个板子，上面会有大家正在做的事情。虽然说不要超过15分钟，我还是有看过有团队超过30分钟。
• 检视会议(Review Meeting)：这个会议会发生在周期的最后一天，让大家分享这一个周期的成果并进行讨论，也可以邀请客户参加，讨论这个周期所做的东西是否与目标相符，时长大概一小时。
• 回顾会议(Retrospective Meeting)：在这个会议，大家会坐下来沟通，反思这个周期团队的工作状态与变化，时长大约一小时。通常我们会用ORID的方法，讨论发生了什么事情、大家有什么感受、哪些东西其实下次可以做得更好或是有不同的作法，话题可能涵盖产品、开发、对外协调及内部运作。在回顾会议最后列出行动的时候，有些人可能会列很多项行动，但是我会要大家不要那么贪心，因为列得越多做得越少。如果有很多行动，我会希望尽量聚焦在一、两个比较优先的，其他只是作为参考，有空再做。把前一、两个行动做好，比列了很多行动却都做不好还重要。虽然有些人会说在回顾会议一定要产出行动，但是我认为更重要的是让团队有一个好好沟通的时间。
• 精炼会议(Refinement Meeting)：如果回过头看看我们目前为止提到的会议，有计划会议、检视会议、回顾会议，看起来好像够了，但是有时候事情的发生不会那么准确。有时候下一次的冲刺可能会需要新的东西(例如新的技术)，做这些研究会需要时间，所以如果等到计划会议才开始做，可能就来不及了，所以精炼会议的目的是要能够预知下一个冲刺的可能需求以及需要先做的准备，时长大概一小时。我的心得是，精炼会议的精神是要「把模糊变清晰」，有些事情可能很模糊，透过讨论就是要把大事变小事(例如一件很大的工作要如何分解)，把模糊变清晰。如果一次冲刺是两周，精炼会议通常是在第一周结尾或第二周开头，例如第一周的第四或第五天。之所以说「第一周的第几天」而不是「星期几」，是因为并不是所有的Scrum都是从周一开始，像我们团队喜欢从周三开始。

有人说跑了Scrum会让会议变多，但是如果细细去拆分时间的利用，你可能会发现没跑Scrum的时候会议更多。因为没跑Scrum的时候，别人有事要找你，工作会随时被这种非正式会议打断，但是你不会仔细去算这些非正式会议的时间有多少。我之前有算过，在跑了Scrum之后，一个冲刺花在会议上的时间大概是13%，可是如果没跑Scrum，会议时间可能会占20%以上。

Vince 运用 Scrum 带团队的具体实践

我在安排团队的工作时有几个原则，第一个是随时动态调整，第二是把工作依照重要性排序，第三是不要把时间塞太满。在一般的项目管理，排了三件事情如果做不完就会加班，而Scrum的希望是，如果你每天都知道工作的状况，就不会到了最后一天才在加班，做不完的时候可以提前让产品负责人知道。况且，如果那三件事原本就有依照重要性排序，而且最重要的事情有做完，这样即使其他两件事情没做完应该也不会出大问题，所以是只有真的需要把那两件事做完的时候才会加班。此外，传统的作法是把时间用工作塞满，但是我在带团队的时候，习惯排到60%。让大家有60%的时间专心做事情，因为过程中可能会有变数，会有其他事情需要做，所以我的经验是六分饱(60%)就好，即使是八分饱(80%)，也还是可能会出事。如果真的没有变数、一切都很顺利地做完也没关系，可以提前先做下一周要做的第一件事情。我相信每个人都可以认真做事，但是有些人会担心员工摆烂，所以才会想要把时间都填满。团队做不出来，我不认为是失败，每个人没有认真做事情，我也不认为是失败，重点是有没有提前去觉察到。如果每天都有回顾，最后一天却还是会出问题，我就会觉得是我的失败。很多事情你可能会觉得错的是别人，但是我觉得事情会失败，主管要负80%的责任。或许我们应该要停下来想自己做了什么事，而不是团队做了什么事。
在考虑要不要使用Scrum的时候，要回到最终你想解决的问题是什么，或许Scrum根本就不合适，那你为什么要硬用？硬用可能就会烂掉。如果思维方式就是命令控制，这样用Scrum也是会烂掉。所以一个是主事者心态，另一个是想达到的目的。如果不适合用scrum就不要用，因为它不是万灵丹。此外，团队的素质也会影响Scrum的使用成效。如果是技术不足，这时会容许他犯错，并且留一些时间让他能够在技术上成长，此时坚持Scrum的做法可能就没那么重要。有些人是技术很行，但是心态不行，例如我找五位高手一起做事，这样出事的机会通常很大，因为大家都想要自己来，所以虽然会议都有参加，有问题却不会讲出来，所以这时帮助大家调整心态就会比较重要。

引导在Scrum所扮演的角色

我之所以会学Scrum的原因是希望团队可以沟通，但是沟通不是一个人说了算。每日站立会议因为只有15分钟，需要讨论的东西不多，但是在计划会议、检视会议与回顾会议，如何让大家能够敞开心胸就会很重要，因此就会需要引导方法，而精炼会议是为了协助团队大事化小、模糊变清晰，所以也会需要引导方法。

至于做敏捷的人需要学到多少引导方法，我觉得这要看个人与公司的状况。

有一些方法是要大团体才可以做的，例如一个团队20人，里面又分成几个小组。我目前很少有机会让整个团队做一个大的决策，所以这种团体比较大的引导方法就会学少一点。而ORID焦点讨论法、深度汇谈，不论是一对一或是三、五人一起讨论都可以派上用场，所以我就会想学。当然我们公司还是有大的、整个部门的会议，但是因为我现在已经是主管，所以就倾向让其他人去带。刚开始我兼主管又带人做这个东西，会觉得怪怪的，团队成员也会觉得很累，因为他们预设我是主管，会变得有点像是讨好你。我觉得大家都学了方法，或许要先想想你的意图，否则如果是为了用而用，就可能会出事。

访谈后记：用敏捷的方法做敏捷

在与Vince聊过之后，我有几个心得。首先，从Vince的分享当中，我深切感受到他对于学习、分享与实践的热情；他不仅积极学习各种方法，也会留心方法的使用边界：什么时候可以使用，什么时候不该使用。如果是引导圈子的朋友，也许也可以从Vince分享他带领团队的心得当中，看见引导的精神。对于敏捷，如果要选取两个关键词，第一个我会选「动态调整」，也就是要随机应变，有时候你可能会因为团队的状况而必须暂停使用敏捷的「手法」，但是这样做才正是符合敏捷的「精神」；第二个词是「觉察」，注意当下的情况，关注团队需要什么，这也是动态调整的基础。

希望这篇文章有让大家更认识敏捷。未来引导在敏捷的实践可以扮演的角色还有许多探索空间，而我也相信敏捷的理念与实践也会有很多我们引导者可以借鉴学习的地方！