原创

敏捷管理之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也是团队的一份子,可以把自己的期待跟困难点跟团队说明,一起找出方法。有不满也可以说出來,敏捷说的透明度不止是工作事项的透明度,还有包含想法和心情的透明度。

正文到此结束
本文目录