建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
请选择 进入手机版 | 继续访问电脑版
设置昵称

在此一键设置昵称,即可参与社区互动!

确定
我再想想
选择版块
标签
您还可以添加5个标签
  • 没有搜索到和“关键字”相关的标签
  • 云产品
  • 解决方案
  • 技术领域
  • 通用技术
  • 平台功能
取消

敏捷江湖桃花岛张教主

发帖: 6粉丝: 2

级别 : 新手上路

发消息 + 关注

发表于2020年03月09日 15:07:41 1694 6
直达本楼层的链接
楼主
显示全部楼层
【DevCloud · 敏捷智库】开发团队中的任务没人领取,你头疼吗?

封面.png


背景

在传统开发模式下,开发任务是由项目经理指派给个人的,而在敏捷开发模式中,开发任务是团队领取的。很多企业在转型中遇到过这样的问题:“计划会议认领开发任务的时候,有几个任务没人认领怎么办?”

问题分析

首先,相对于传统开发模式的指派开发任务,我们需要知道为什么在敏捷开发中是领取任务。在敏捷中,不管是敏捷宣言还是Scrum指南,都没有指派(assign)一词,而是使用了一个术语“自组织”,如下:

  • 最佳的架构、需求和设计出自于自组织的团队(敏捷宣言12项原则)

  • 自组织团队自己选择如何以最好的方式完成工作,而不是由团队之外的人来指导(Scrum指南)

  • 他们是自组织的。没有人(即使是 Scrum Master)有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量(Scrum指南)

那么“自组织”是什么呢?

从字面的意思来理解,“自组织”就是:安排分散的人或事物使具有一定系统性或整体,而安排的人就是他们自己。在敏捷开发中,自组织团队就是具备自我管理、自我驱动、自我学习等能力的敏捷开发团队本身,这样的团队一般具备如下特点:

  • 团队成员自己“拉”工作,不是被动等待他们的领导分配工作;

  • 团队作为一个整体管理他们的工作;

  • 团队仍然需要辅导和指导,但不需要指挥和控制;

  • 团队成员彼此沟通紧密互通有无;

  • 团队主动发现和提出问题并共同解决;

  • 团队不断提高自己的技能,鼓励探索和创新。

更多关于“自组织”的相关内容不在此FAQ的范围内,如感兴趣请参阅更多文献。

敏捷宣言Scrum指南关于任务的工作方式上来看,在我们践行敏捷的时候,主要发挥的是开发团队自身的主观能动性,开发团队由原来的控制性转变成了自组织性,而开发任务也就由原来的指派变为了领取。这样的好处是,领取任务就是发挥了人的主动性,而自主性是人们从事创造性和解决问题的动力之一,良好的自我组织能给团队和个人带来高绩效、出色的工作成果以及喜欢的工作环境。另外,每个人都是最了解自己的,也擅长为自己分配任务,相对于传统的指派开发任务所带来的易主观臆断、分配不当等更具有合理性。

然后再回 “计划会议认领任务的时候,有几个任务没人认领怎么办?”这个问题上。不过在此之前,需要先澄清的一个观点就是,在计划会议中,不一定非要全部领取完开发任务。在Scrum指南中指出“领取工作在Sprint计划会议和Sprint期间按需进行。”这个期间,可以理解为在每日Scrum站会上基于目标领取任务。另外,Mike Cohn 也表示过,不建议在计划会议中领取开发任务,这样可能会导致目标由团队变为了个人,进而违背了敏捷的本意,降低了灵活性。更多请详见参考附录“Should Team Member Sign Up for Tasks During Sprint Planning?”。一般来说,开发任务没人认领的原因主要有:

  • 开发任务的难度大:当开发任务比较难以解决,超出了团队大部分成员的能力时,团队成员可能会存在担心加班加点,甚至“996”的情况而不愿意认领。

  • 开发任务超范围当开发任务的内容超出团队成员所掌握的范围时,如 Android 不会 IOS,开发不会测试等,就可能会出现“我是想认领的,但实例它不允许啊”的情况。

  • 担心受到他人指责工作内容存在一定的挑战性,担心由于自己没有做好,导致团队目标没有达成而受到指责。

那么应该如何解决呢?

解决方案

在一个敏捷Scrum团队中,Scrum Master扮演着重要的角色,该角色一部分的作用就是要帮助团队成为自组织型团队,以便让团队能以积极的心态去面对冲刺的开发任务。此外,当出现任务没有人愿意认领的情况时,首先 Scrum Master应该帮助团队弄清楚没有人认领的原因是什么再对症下药,下面基于分析中的三种情况分别给出解决措施。

开发任务难度大

对于开发任务难度大的情况,Scrum Master应该组织团队进行有效的任务分解,使用探针Spike技术,探索出解决措施以降低任务的难度,再由团队去认领(更多关于Spike的解释请见附录)。或者鼓励技术能力较一般的成员和技术大牛通过结对编程的方式来一同认领任务(更多关于结对编程的解释请见附录)。在华为云DevCloud中,可以对该类难度大的用户故事通过子工作项的方式进行拆分,同时在基本信息中通过设置处理人和抄送人的方式以记录结对编程的人员配对情况,如下图。

656456.png


除此以外,在每日Scrum站会的时候,要留意和了解该开发任务的情况,进行风险评估,如有问题及时帮助协调解决。在回顾会议中,应对该类情况问题进行分析并能输出基于团队的一套标准工作方式方法,然后将解决方案记录在团队知识库中,华为云DevCloud提供了Wiki的功能,可以为团队很好的整理和记录工作方式,如下图。


77777.png

开发任务超范围

敏捷提倡的团队是跨职能团队,但是团队的跨职能并不意味着个人能做所有的事情,我们希望的跨职能团队往往是由掌握多项技能的T型人才(每个成员在一个专业领域具有深度,而在其他领域具有广度)所组成的。那么首先,需要Scrum Master能够和团队整理和维护成员技术矩阵,把个人技能掌握情况对团队公开(知道团队欠缺什么、知道可以和谁学等),然后定期组织技术分享等活动以帮助团队成员学习(主要以学习一项新的技术后的分享方式),这样可以在一定程度上提升成员在冲刺中愿意领取其他任务的热情(学完了当然是想去用一下咯)。另外,还可以由专长成员和意愿成员组队,采用结对编程的方式领取任务,以实现个人技术的扩充。团队成员的T型能力建设,不仅仅能让团队领取任务的时候有更多的选择,也提供了成员的backup能力,减少无人认领的情况发生。此外,同样也需要Scrum Master留意日常评估风险和引导团队回顾该事项并维护团队知识库。

担心受到他人指责

工作内容存在一定的挑战性,担心由于自己没有做好,导致团队目标没有达成而受到指责。Scrum Master应该对团队贯彻以团队为整体的思想,并指导和强调Scrum的价值观,尊重团队的每一个成员的背景、经验,当然也包括开发任务的选择,还要鼓励成员能有勇气去选择和尝试。在实际的工作中,我们可以通过在墙上、白板等贴上标语(如“尊重他人”、“只有团队没有个人”等)的方式,让团队从思想意识方面发生转变,慢慢敢于去领取有挑战性的任务。此外,Scrum Master要充分保护好成员对有挑战工作认领的热情。如,防止在回顾会议上出现指责和批斗的情况,回顾和总结永远应该聚焦的是做事的方式方法而不是对人的苛刻和指责。

总结

以上三种没有人认领任务的情况,是比较常见的。但在真正的实际项目中,每个公司或团队的情况都不尽相同,无法穷举所有,应具体情况具体分析。比如,当一个公司首要考虑的是存活问题时,又比如一个刚刚转型的敏捷团队,在开发任务的领取上可能会更偏向于半指派半领取的方式,就像FAQ《从敏捷管理的角度来说,是团队主动认领任务好还是通过管理任务分发好》中所提到的,当团队敏捷成熟度较低时,可先由团队认领再让领导管控。这就好比中国经济一样 “以市场经济为导向,适当进行宏观调控”。但不管这个“调控”的力度如何,我们都应该鼓励团队成员能积极主动地领取任务,并随着任务的进展情况灵活调整,及时做好风险把控,必要的时候需要其他渠道的协调帮助或相关领导的介入,以保证迭代的目标不受影响。

参考附录

spike

华为云DevCloud

Should Team Member Sign Up for Tasks During Sprint Planning?

文章博客地址:https://bbs.huaweicloud.com/blogs/152629

举报
分享

分享文章到朋友圈

分享文章到微博

敏捷江湖桃花岛张教主

发帖: 6粉丝: 2

级别 : 新手上路

发消息 + 关注

发表于2020年03月10日 09:39:09
直达本楼层的链接
沙发
显示全部楼层

欢迎大家讨论交流~

点赞 评论 引用 举报

FloraRen

发帖: 11粉丝: 5

级别 : 注册会员

发消息 + 关注

发表于2020年03月10日 13:55:17
直达本楼层的链接
板凳
显示全部楼层

这三种确实是比较常见的原因,尤其是超范围这点,大多数团队的成员都是各有所长,T型人才很少,所以领任务很难推行下去,所以做好团队人员的能力培养和提升是很重要。感谢楼主分享!

点赞 评论 引用 举报

李惠玉

发帖: 0粉丝: 0

级别 : 新手上路

发消息 + 关注

发表于2020年03月11日 16:48:24
直达本楼层的链接
地板
显示全部楼层

很有用~谢谢分享

点赞 评论 引用 举报

lte网络工程师

发帖: 154粉丝: 8

级别 : 外部版主

发消息 + 关注

发表于2020年06月15日 14:33:28
直达本楼层的链接
5#
显示全部楼层

完全自组织的团队,应该是目标。实在不行,我觉得抓阄也可以啊!


点赞 评论 引用 举报

Lhosv

发帖: 1粉丝: 1

级别 : 中级会员

发消息 + 关注

发表于2020年06月30日 10:33:47
直达本楼层的链接
6#
显示全部楼层

一般来说,开发任务没人认领的原因主要有:

  • 开发任务的难度大:当开发任务比较难以解决,超出了团队大部分成员的能力时,团队成员可能会存在担心加班加点,甚至“996”的情况而不愿意认领。

  • 开发任务超范围当开发任务的内容超出团队成员所掌握的范围时,如 Android 不会 IOS,开发不会测试等,就可能会出现“我是想认领的,但实例它不允许啊”的情况。

  • 担心受到他人指责:工作内容存在一定的挑战性,担心由于自己没有做好,导致团队目标没有达成而受到指责。


开发任务难度大的解决方法

Scrum Master应该组织团队进行有效的任务分解,使用探针Spike技术,探索出解决措施以降低任务的难度,再由团队去认领。或者鼓励技术能力较一般的成员和技术大牛通过结对编程的方式来一同认领任务。在华为云DevCloud中,可以对该类难度大的用户故事通过子工作项的方式进行拆分,同时在基本信息中通过设置处理人和抄送人的方式以记录结对编程的人员配对情况。


开发任务超范围的解决方法

首先,需要Scrum Master能够和团队整理和维护成员技术矩阵,把个人技能掌握情况对团队公开(知道团队欠缺什么、知道可以和谁学等),然后定期组织技术分享等活动以帮助团队成员学习(主要以学习一项新的技术后的分享方式),这样可以在一定程度上提升成员在冲刺中愿意领取其他任务的热情(学完了当然是想去用一下咯)。

另外,还可以由专长成员和意愿成员组队,采用结对编程的方式领取任务,以实现个人技术的扩充。

此外,同样也需要Scrum Master留意日常评估风险和引导团队回顾该事项并维护团队知识库。


担心受到他人指责的解决方法

crum Master应该对团队贯彻以团队为整体的思想,并指导和强调Scrum的价值观,尊重团队的每一个成员的背景、经验,当然也包括开发任务的选择,还要鼓励成员能有勇气去选择和尝试。在实际的工作中,我们可以通过在墙上、白板等贴上标语(如“尊重他人”、“只有团队没有个人”等)的方式,让团队从思想意识方面发生转变,慢慢敢于去领取有挑战性的任务。此外,Scrum Master要充分保护好成员对有挑战工作认领的热情。


点赞 评论 引用 举报

张辉

发帖: 78粉丝: 29

级别 : 金牌会员

发消息 + 关注

发表于2020年07月15日 12:25:18
直达本楼层的链接
7#
显示全部楼层

Scrum强调自组织,任务都放在那里,在计划会议和Spring期间等人认领,但为啥没人认领?

主要有以下原因:1.难度大,2.超范围,3.怕指责。其实这三个原因归根到底还是:不会(或者不大会)或不敢。

对于难度大的应对方法是拆分任务,将难度降低。但其实如何拆分任务,本身可能又有难度。当然教主提出了有效方法:

A:使用探针Spike技术,探索解决措施

Spike技术来自XP,是以“回答问题”或"收集信息"为目的的任务,目的是提供“解决问题的方法”或者“寻找解决问题的答案”。

XP大师Ward Cunningham 提到:“我经常问Kent[Beck],我们能做的最简单的事情是什么,它能让我们相信我们在正确的轨道上?” 这种走出目前困难的做法常常使我们能够找到更简单和更有说服力的解决办法。Kent称之为Spike。“我发现这种做法在维护大型框架时特别有用。”

我们开展一个有时间限制的spike活动(在一次迭代中完成),用以帮助定义即将到来的用户故事的估算,和下一次迭代开始的起点。

B:让技术一般的成员和技术大牛结对编程。

结对编程其实是一个技术一般的小白成员通过“结对编程”方式向大牛学习的过程。当然,这点其实有点矛盾,即如果是个大牛,他应该可以直接领任务。他不领任务的原因不得而知。但既然大牛和小白一起做,那么小白从这个实践中获得提升是绝对的。也就是说,在实践中传帮带变成了让这个小白成长,以便能自主领取下一个类似任务的方法。如果一直是大牛领这个任务,反倒是不合适的。因为如果老是大牛在做,也许小白永远成长不了。

超范围,从深层原因来说,还是小白不会。

那么,SM应该有个小本本,记录每个团队的成员会啥不会啥(知识能力矩阵)。然后定期通过“学习后分享”的方式使得这些小白得到成长。

所以说,结对编程和知识能力矩阵等方式,只是是构建学习型组织的不同方式。

对于3怕指责这事情,其实是营造一种敢于挑战的氛围(文化)。允许试错(你都会那么会写bug了,还接受不了自己出错吗?)而且,即便出了错,团队也应该不是指责还是鼓励。

总之,目的是迭代的目标不受影响。方式方法可以多样。


点赞 评论 引用 举报

游客

富文本
Markdown
您需要登录后才可以回帖 登录 | 立即注册