敏捷管理之Scrum中的工作分派与分工

在传统的瀑布模式和公司目前的开发流程中，都是有一个角色负责分配工作，常常是由PM（项目经理）或者是Team Lead（组长）来打人。分配工作这件事吃力不讨好，既要了解每个工作的急迫性和复杂度，还要考量团队中每个人的能力，平衡每个人的工作量。

这种角色常常会成为团队的瓶颈，因为每件事都要经过他的分析、安排、验收、忙着开会，常发生团队成员坐等他来分配工作。更别提有人工作提前完成、或者延期需要去做协调。这样的很容易被上下压力夹杀，苦不堪言，早早阵亡。

敏捷开发或者Scrum是如何解决这个角色的问题呢？

Scrum沒有人负责工作分派！

在我深入了解Scrum之前，我会以为是由 ScrumMaster 来扮演这个角色。

后来才知道跑敏捷中有一个大原则，就是工作是由每个人自己认领的。在Sprint Planning（计划会）中开发团队需要做多少个任务，对每一个任务的明确定义和产出物、所耗时间都已经达成一致，在Sprint（迭代）进行中每个人可以自己选择领取任务。

乍听之下是非常天方夜谭的事情，人嘛都是被动的，闲着没事最好，怎么又可能主动去找事情做？神奇的是在我们的实践过程中，发现团队会自己主动的找出方法。

有些人想做自己希望的工作，做完就自己立马挑下一个，以免被他人领取。

有些人想挑战自己没把握的，学自己不熟悉的东西。

有些人想挑自己最有把握的，因为想尽快上线产生价值。

有些人愿意挑工作内容少一些的，想多花点时间在还技术债。

重点是，这些都是由各个团队依照现在情形，来决定最适合的方式，而且会随着时间环境推移改变。

没人想做的工作怎么办？

这是个经常出现的疑问，有一个解释是团队要做什么完全是由自己决定的，其实不是这样的。

工作事项是经过Product Owner排序过的，开发团队认领的工作原则是由优先级从高到低认领，所以工作都会被处理。

实践来看开发团队不太会提供工作想不想做，因为自己能选择做几个任务，做什么任务，已经是非常大的冲击和超大自由度（跟传统方法比）。团队通常把注意力放在需不需要做，而非想不想做。

有一个好现象是开发团队开始质疑工作的价值和优先级顺序，这代表对产品有想法和认同，也是Product Owner阐述价值和沟通的好机会。如果Product Owner能提出论述也虚心接受建议，经过讨论而产出的产品项目更有品质。

如果团队拿太少工作怎么办？

在实践中，开始导入Scrum时确实对任务的评估不够准确，评估都太主观，造成实际执行迭代结束还有工作未完成，或者是过早完成。

这个在几次迭代修订后，会越来越接近团队的真是产出量，前提是大家都要按真实情况填报任务所耗时间，早期来说应该更看重团队产出的质量表现而不是任务量多少。

有人偷懒干脆不做事怎么办？

很幸运，目前团队中还没有遇到过。我也相信大家都是成年人法则，知识工作者不需要人盯着才愿意工作。

但如果真的有这种现象发生，我相信由Scrum让事情暴露出來，好过在传统的方式中被隐藏起來。

那Product Owner不就很倒霉，只能接受事情做不完？

是也不是。

Product Owner要相信团队已经尽了目前的能力去做，与其计划做多少工作、花多少时间，不如考虑团队是不是在做目前最有价值的事情？

至于之前为什么可以做那么多，现在那么少？用硬编码、拷贝粘贴、不写测试等等的暗黑工具箱，都可以让工作很快看起來做完了，但是埋一堆地雷以后来踩。

重要的是Product Owner也是团队的一份子，可以把自己的期待跟困难点跟团队说明，一起找出方法。有不满也可以说出來，敏捷说的透明度不止是工作事项的透明度，还有包含想法和心情的透明度。