文章

Scrum团队

Scrum团队初建的十一件事

越来越多的公司(IT/非IT)正在做或者计划做Scrum转型。很多的团队往往对于转型无从下手,且转型开始后实际效果往往并不如人意。在这里我们系统性的去讲一讲怎么把一个新的Scrum小组从0做到1,怎么让大家快速热身起来

1. 要有充分的准备期

很多的公司可能拍脑袋说我们下周开始做Scrum吧,然后Scrum就开始了。还有一部分公司请Scrum Coach来给大家做一个两天的培训,然后就期望Scrum团队就完美了。

希望是美好的,现实是残忍的。如果我可以选择Scrum 培训热身的时间,我觉得1-2周会是一个比较合适的时间,给团队足够的时间去消化理解,因为在Scrum Guide里清楚的写明了Scrum is easy to use, but hard to handle。不过我并不赞同完全设置培训Sprint,在开始的Sprint我们还是要交付增量的,但是我们可以交付的少一点。

在互联网节奏的今天,很少有企业让大家有1-2周的时间培训,理解和消化。如果只有两天,我个人会选在一天讲述Scrum的基本知识,第二天让大家在一起团建,在团建中通过一些游戏,活动,交谈加深协作的理解,同时让大家更加熟悉对方。往往这样的准备能够让团队更加快速进入Scrum的状态。这也许就是所谓的磨刀不误砍柴工吧。

 2. 对团队其他成员的工作的熟悉时间需要占据自身工作的一半

很多人觉得对于一个全新的团队才需要做很多熟悉的过程。其实不管是新旧团队,只要是一个新的Scrum团队,一个新的里程碑式的开始,让大家互相熟悉,信任对方,对工作都是有百利无一害的。

在这个过程中我时常做的是让每个人描述他/她最想成为的那个漫画英雄和背后的原因,或者做一个自己生活的时间线的分享。这些都能从侧面映射出团队成员的性格和偏好,从而能帮助团队快速的进入协作的状态;并增加团队的归属感和认同感。

3. 开始的失败是为了未来的成功

正因为很多时候管理层的期望过高,大家觉得花费了这么多成本去培训,Scrum应当可以解决很多的问题。但是实施Scrum后,往往和期望值有着非常大的差距。

作为团队的开始,允许失败,甚至是鼓励失败是未来成功的关键。这里的鼓励失败不是说大家无底线的乱做一气,降低质量标准,或者任由大家去自由发挥。这里的鼓励失败更多的是希望团队要有勇气去面对挑战,有勇气去尝试自己不熟悉的技术,环境,语言。同时怎么在失败种吸取教训,减少下次失败的可能性。

很多国内的Scrum Master是原来的技术经理或者大咖,往往在开始的几个Sprint后发现团队效果不好,或者基于管理层期望值的压力,很可能又回到原来的管理模式,去替代团队做很多决定。 这种行为会伤害团队的成长,同时对于今后Scrum的发展带来非常大的阻碍。

 4. 永远不要停止Teach

基于上面说的很多的团队都会选择2天的培训作为Scrum的开始,往往之后也只有团队里的1到2个人还专注在Scrum可持续提高的研究上,这往往变成了Scrum Master一个人的指责。

其实在Scrum的实践中,Scrum Master一定要发现在任何时间节点可以培训Scrum的机会。当团队出现问题,或者遇到困惑的时候。这是最好的Teach的时机。所以千万不要被自管理这句话迷惑了,那是针对特别成熟的团队。在非常青涩的初始阶段,频繁反复的培训有助于团队快速纠正之前的工作习惯。(这其中有很多游戏可以帮助大家到大家,会在另外的系列里展示)

 5. 建立团队的文化

Scrum的终极目标实际上是解决一加一大于二的问题,随着沟通协作的增加,团队的效率在降低,所以Scrum才设计出一种工作模式(3-9人)能够在这个空间里把战斗力发挥到极致。

这里给大家分享一个塑造团队的小游戏,让团队成员每人分别给出最好和最坏的团队的一些特征,然后让大家结对讨论,最后在做陈述的时候,让大家一起加入到讨论。这个练习能帮助团队对什么是好的团队达成共识,并能对不好的行为进行预防。

 6. 建立团队的契约精神

扁平和透明是Scrum团队的显著特征,在创建团队初期,我们就需要定义好每个人的职能,我们可以设置一些非常简单的问题来抽样调查大家对Scrum认可程度。尤其是commitment,这是所有团队的一个重要基本素质

同时也需要给团队一个清晰的目标,包括管理层对大家的期望值。这些也是在团队初建时对团队成员的一种鼓励和鞭策。

 7. 选一个团队名号

给团队起名看似是一个很幼稚的游戏,但是这却是一件花小钱办大事的工作。团队选择的名字往往也代表着团队向往的状态,对提升团队士气有着很重要的作用。

我们通常做的是,让每个团队成员自己给团队起一个名字,然后投票选出最优方案。 这样做会带来团队更多的团队归属感、团队荣辱感。

 8. 设置合理的期望值

老板们总是希望有更多的产出,所以怎么管控管理层对团队的期望值显得很重要。过高会对团队的压力很大,团队很可能会出现人员流失不稳定的情况,过低也不利于团队自我创新和突破。

我觉得设置阶梯的期望值,比如1-5个Sprint是什么情况,之后根据现状在做适当调整是一个比较好的选择。当然,Scrum是应该越做效果越好的,如果越来越糟,Scrum Master有义务去找寻问题出在哪里。

 9. Retrospective/ Retrospective/ Retrospective

如果让大家选择Scrum的核心组件,很少有人会选择Retrospective。其实Retrospective和其他组件一样重要。 在Scrum这种体系下,我们更应该关注人,而Retrospective是唯一一个正式的可以帮助大家的机会。同样在Sprint任何时间节点都不要放过可以帮助大家提升的空间,当然对于一些比较复杂或者不清晰的问题,我们可以放到retrospective上再做详细的讨论

 10. 尽量让管理层也参与进来

让管理参与到Scrum中来是一个很难完成的任务,但是请至少确保他们能参加大部分的Sprint Review, 并第一时间传递对产品的反馈和市场的新要求。

另外,影响是相互的,这也是一个很好的机会让团队可以把自己的意见想法模式影响管理层,帮助他们更好的理解产品是如何迭代的产出的。相反管理层的介入也会让团队在后续工作中更有信心。

 11. 培养团队自己做决定的习惯

毫无疑问我们最终希望团队能够达到的就是能自我管理并解决绝大部分问题。好的Scrum Master是帮助团队解决问题而不是替团队解决问题。循序渐进的解决问题会提升团队的自信心,帮助他们在未来尽快能够实现自管理

罗马不是一天建成的,让团队自管理也不是短期可以实现的,Scrum Master和公司管理层都需要有信心和耐心给团队成长的空间和时间。

在团队初期,大家可以做较多尝试怎么去热身团队,但是一旦发现不适合的时候,一定要及时纠正。请记住Scrum是基于经验主义的框架,更多的定义不如实践得出的真理。也欢迎大家在这里留言讨论。

 

本文作者:

Derek Ding 丁志润,11年IT行业从业经验,曾在全球前三的跨国科技公司,全球前三的在线旅游科技公司工作,拥有近十年项目管理,敏捷的经验,CSM,CSP,PMP。

ScrumMaster – 指派还是团队选择?

一个新Scrum团队对ScrumMaster的选择会影响到团队Scrum实施的成败。选错了人,团队就会一方面试图变得自组织、另一面却又受制于命令控制型的经理,从而进退两难。选对了人,他符合新ScrumMaster的技能、满足团队初期需求,则团队在实施Scrum上有了一个梦幻般的开端。 Read more

Scrum团队中的架构师

 很多架构师在努力了很多年才得到这个威严的头衔“架构师”。他们确实应该为他们的知识、经历和能针对技术和业务挑战提出一流的解决方案的能力而骄傲。我发现很多架构师在面临采用Scrum时提出的担忧可以归纳为下面2类:

•大家仍会按照我告诉他们的架构去做实现吗?

•我如何能在没有一个提前设计架构的阶段后保证我们构建了一个架构不错的产品?

Read more

短之又短的用户故事

Scrum团队通常喜欢使用用户故事来表示待办事列表项目。但是很不幸,一个用户故事中最重要的一环通常会被渐渐忘掉,那就是用户故事应该保持简短,慢慢地用户故事失去了它的本质和效力。

用户故事现在通常以“作为一个…我希望能…”的形式来描述。用户故事的编写者,应该马上利用约束列表或者自动化验收测试的形式来记录下该用户故事的验收标准。很多人觉得如果团队以外的成员(例如,高级经理或者股东)不能在没有别的文档的帮助下明白用户故事的目的,那么这个用户故事的编写就是失败的。

一个理想的用户故事的描述应该是一个简要的描述——Robert Martin把它叫做“助记令牌”。
Read more

Scrum中的测试:人少事不少

导读:Scrum团队以小著称,团队中一般只有一到两名测试人员,那么这一两名测试人员在Scrum团队中又是如何开展测试工作,起着什么样的作用呢?

Scrum敏捷开发有一个明显特征就是重团队,轻部门,每个团队里面包含了开发、设计、测试各种角色,Scrum团队以小著称,团队中的测试人员一般只有一到两名。

在传统的瀑布式开发 中,测试人员经常因进入测试阶段的条件不满足而需要较长的等待。而在Scrum敏捷开发中,测试人员需要尽可能早的开展工作,“等待”在Scrum开发的测试中已属一种错误概念。

测试人员应具备三方面的能力:编码,测试和分析。不同的阶段对测试的要求不同,在功能测试中偏重编程能力,在系统配置测试中偏重分析能力,Scrum团队中的测试人员需要将这三种能力融会贯通,才能适应迭代过程中的诸多变化。

测试是软件开发中必不可少的一部分,那么Scrum团队中测试人员又要如何开展测试工作呢? Read more

依赖专才还是发展通才

依赖专家但要谨慎
一个普遍的误解是Scrum 团队的每个成员都必须是通才而不是专才——在技术和纪律性上具有同等的水
准。这是不对的。我对之感到吃惊的是世界上每个三明治商店都已经知道如何对待专家,而在软件行业的
我们还在为这个问题苦苦挣扎。
Read more

什么是跨职能团队

什么是跨职能团队

跨职能团队也叫做多功能团队,由来自同一等级、不同工作领域的员工组成,他们走到一起的目的就是完成某项任务。

  多功能型团队是一种有效的团队管理方式,它能使组织内(甚至组织之间)不同领域员工之间交换信息,激发产生新的观点,解决面临的问题,协调复杂的项目。但是多功能型团队在形成的早期阶段需要耗费大量的时间,因为团队成员需要学会处理复杂多样的工作任务。在成员之间,尤其是那些背景、经历和观点不同的成员之间,建立起信任并能真正的合作也需要一定的时间。
Read more

自我管理型团队

自我管理型团队的背景与发展

自我管理型团队模式最早起源于20世纪50年代的英国和瑞典,比如沃尔沃现在的管理模式非常先进,其位于武德瓦拉的生产基地,完全由自我管理型团队进行整辆轿车的装配。在美国,金佰利、宝洁等少数几家具前瞻意识的公司在20世纪60年代初开始采用自我管理型团队模式,并取得了良好的效果。随后很久,日本引入并发展成为强调质量、安全和生产力的质量圈运动,到80年代后期美国借鉴并创造性地把团队模式发展到了一个新阶段。在这20年里,企业所采用的团队类型在不断变化着,以求得最佳效果,很多公司己逐渐从关注于工作团队,转变为强调员工参与决策和控制决策的实施,其中以团队成员自我管理、自我负责、自我领导、自我学习为特点的自我管理型团队越来越显示出其优越性,也逐渐被主流接受。根据Law Jeretal的研究发现,1993年68%的《财富》1000强公司使用了自我管理型团队。施乐公司、通用汽车、百事可乐、惠普公司等都是推行自我管理型团队的几个代表,据估计,大约30%的美国企业采用了这种团队形式。
Read more

团队管理的“头羊效应”

广袤的草原上,到处可见由数百只羊组成的羊群在两名牧羊人的指挥下有序地出发、吃草、返回。如果我们把这些羊群看成一个团队,我们会惊奇的发现:这个团队是如此的协调一致而又管理扁平!因为这个团队只有两名管理者——牧羊人,而这两名管理者却高效并且轻松地指挥着这个数百个主体按照同一方向前进,他们始终保持着共同的目标!
Read more