第四讲 Scrum团队_开发团队

讨论主题 

Scrum开发团队是：

1、自组织团队

2、跨职能团队

3、小团队

4、只有一个头衔

5、公共责任

Scrum开发团队的特点 

说完超人一样的产品负责人，必须得花时间聊聊咱们勤勤恳恳、默默无闻、太辛苦又太低调的软件开发小伙伴们。听说敏捷很流行，小伙伴们有点好奇；听说敏捷不用写文档，小伙伴们很开心。Scrum开发团队有什么不同之处？不要道听途说，且听我说。

特点1：自组织

Scrum Guide说，开发团队是自组织的，即没有人告诉开发团队如何把产品待办事项列表变成潜在可发布的功能。即使是ScrumMaster都不可以这样做。产品负责人不管技术，当然不会这样做。用大白话说，需求是输入，可发布的软件是输出。怎么把输入转化为输出，这其中的所有工作，由开发团队全权处理，开发团队以外的人无权干涉，即使是ScrumMaster也无权干涉。在怎样开发这件事儿上，开发团队可以向外部求助，咨询，但不接受外部的命令。

1.自组织的好处

开发团队自组织有什么好处？要回答这个问题，我们可以反过来思考，不自组织有什么坏处！

自组织的反面是被管理者领导。组织仅授权团队成员执行任务，被管理者监控和管理。例如，传统的项目经理负责管理，包括估算工作量，制定计划，监控进度，分配人力，制定工作流程。管理职能固定的集中在项目经理身上。开发团队仅执行项目经理安排的任务。

开发团队完全被管理，看似可以专注于技术，不必烦心管理方面的事，其实不然。我讲个案例。有个组织高薪聘请了一位世界知名的架构师，负责这个组织的软件系列产品的架构设计。这位架构师会说11种语言，擅长n种先进软件技术。他给某团队负责的产品进行了架构设计，并要求开发团队把设计思想整理成设计文档，向他汇报。这位架构师空降以前，开发团队一直受产品经理直接领导。架构师在说明架构的时候，产品经理也旁听了。产品经理觉得架构师的想法太过冒进，一旦将来产品上线出现问题，担心自己hold不住，于是要求开发团队按照自己的保守技术方案写代码。请注意，这个开发团队是典型的管理者领导的团队，自己对架构没有决定权。项目面临里程碑审批，开发者们可犯难了。服从架构师吧，就违背了产品经理，服从产品经理吧，就违背了架构师。这可咋整才好呢？最后几个小伙子凑在一起一合计，这样吧，设计文档按照架构师的要求写，代码按照产品经理的要求写。

这是个真实案例。不自组织，开发团队除了听话干活，没有其他的权力。

2.自组织的任务

开发团队自组织是什么样的呢？软件开发小伙伴们需要做什么呢？听我介绍一下自组织开发团队需要完成的任务。组织授权开发团队设计软件架构、估算工作量、监控进度，定义和改善开发团队内的工作流程。原来集中在项目经理这个管理者身上的工作，现在分散给开发团队，由开发团队集体完成。例如估算，谁写这部分代码，谁负责估算，其他相关的人参与。例如任务分解和分派，开发者集体完成架构设计，分解任务，然后各自主动认领任务。例如监控进度，每天开站会，大家都说说进展，互相监督，群众的眼睛是雪亮的。再例如改善工作流程，谁有困难谁就说，谁有好主意谁就提。开发者们商量好，咱们就这么干啦！开发者们怎么开展工作，开发者自己做主，开发团队自己对自己负责。回顾刚才讲的奇葩案例，如果组织授权开发团队自组织，开发者就不会这么为难。产品经理也好，架构师也好，你们的宝贵意见我们开发团队可以参考，最后怎么决定，组织授权我们开发团队自己做决定。

3.成功自组织的因素

组织授权开发团队自组织，开发团队一定能胜任吗？不一定。成功的自组织团队有外因和内因两方面因素。组织授权是外部环境，是外因；开发团队具备自组织能力，是内因。开发团队需要能够自律、自强，自己能管好自己，自己还能鞭策自己不断进步。从外因分析，没有授权，团队的自组织能力没有发展空间，反正得被领导管着，自己想什么也是白想。从内因分析，开发团队的自组织能力不够，如果组织授权，就会出现“领导放权，群众放羊”的混乱局面。开发团队自组织，对开发者的职业素养提出了很高的要求。

4.自组织的范围

自组织是不是从此不用领导了？咱们必须划清自组织的范围。自组织强调的是开发团队内的活动由开发团队自组织。开发团队以外的，需要服从组织的安排。例如，开发团队如何组队，是组织安排的。组织安排你到哪个团队，你就到哪个团队。自组织强调的是在“怎样开发产品”这个问题上自组织，这个问题以外的，不能自组织。例如，产品愿景和冲刺目标是产品负责人制定的，开发团队必须为产品负责人马首是瞻。

有一些自组织水平较高的组织，对开发团队授权更多。一个团队由哪几个人组成，组织不做安排，而是把这个权力下放。假如你是一名开发人员，你想参加哪个团队，可以自己选。哪个人有很棒的想法，共享给大家，如果你对他的这些想法感兴趣，就可以加入他那一组。成型的团队还定期调整。如果你觉得现在这个团队很棒，可以继续和你的队友们呆在一起。如果你又对别的团队感兴趣，也可以换。有的传统管理者对此很怀疑：自己喜欢哪个团队，就去哪个团队，怎么像找对象啊？这是要把公司搞成《非诚勿扰》大舞台啊！会不会天下大乱呢？微软已经这样实践过了，不仅没有天下大乱，而且开发者们都找到了自己最理想的团队，工作热情空前高涨！

特点2：跨职能

什么是职能？比如UX设计、编程、测试，就是三种不同的职能。“跨职能”就是要求一个开发团队具备所有必备职能，而不需要依赖团队外部的职能部门。举个极端的例子，Facebook的最初版本是扎克伯格一个人在大学宿舍里开发的。UX设计、编程和测试都是他做。当然我们不能期望每一位开发者都像扎克伯格一样是全才，但我们可以组建这样的团队，这个团队相对于某个产品，相对于产品的某些特性，拥有必备的职能，拥有必备的知识和权限。

跨职能的特点对开发团队有什么好处吗？我讲个反例你就有体会了。很多传统大公司，UX设计部门，软件开发部门，测试部门是3个独立的部门。软件开发主导项目，UX部门，测试部门支持。软件开发者要开发一个应用，需要UX设计师出设计图。UX部门说，我们正忙一个更重要的项目，你们等等行吗？得，排队等着吧~ 软件开发者想让测试者每天和开发者工作在一起，一边开发一边测试，测试部门经理说“那可不成，你得打测试申请，我来安排，我指派谁去给你测，谁才能去。我们需要管理测试工作量，每测一轮，都得打一次申请。你申请一次，我安排一次。”开发者心里抱怨“有这天天打申请的时间，我自己都测完了。” 我再介绍一下Facebook的Scrum开发团队构成：设计师加工程师。如果做一个简单的小功能，一般是一个设计师加两个工程师，比较大的项目，比如说改版、在新版开发两三个功能，基本上两三个工程师一起做，也可能扩展到五到十位工程师。Facebook没有专职的测试员，工程师自己测。整个流程中，设计师和工程师互相合作，联系是非常紧密的。不同职能的人坐在一起讨论，有任何疑问马上当面沟通。看到了吧？跨职能团队，意味着不管什么职能，咱们是一个团队的成员，像橄榄球争球那样，同进退。团队成员之间沟通方便，配合流畅。

特点3：小团队

Scrum开发团队是一个小团队，有多小呢？最少3个人，最多9个人。为啥不能少于3个人呢？我们前面讲了，Scrum开发团队必须是跨职能团队，人数太少，难以做到跨职能，毕竟像扎克伯格那样的全才太罕见了。为啥又不能多于9个人呢？有两个原因，其一，为了防止滥竽充数。人数少的时候，谁干的怎样，大家心知肚明。人数一多，有人跟着混，打酱油，就不容易被发现。其二，人数多，就意味着人与人之间的沟通变得更复杂，团队协调更困难。Scrum开发团队需要保持灵活而有战斗力的特点。

特点4：只有一个头衔

开发团队中的所有成员，只有一个同样的头衔“开发者”，没有其他的头衔。整个开发团队也是一个整体，不允许存在子团队，一小搓。不像传统组织里，分“架构师、程序员、测试员”，骨子里，人们还是认为“架构师地位最高，程序员还行，测试员没地位。”当然也不会论资排辈，称呼什么“部长、科长”。Scrum开发团队统一的称谓践行了Scrum价值观中的最后一条“尊重”。这种尊重是在开发团队内对所有人的尊重，不分高低贵贱，不论资历深浅，人人敬我，我敬人人。这种统一的称谓也强调了“我们是一个团队，我们风雨同舟”的精神。这种平等、民主的氛围，是鼓励创新的基础，是创新型产品诞生的土壤。

特点5：共同责任

有个成语“同舟共济”，用来解释共同责任最合适不过。比如三个人在一条船上，突然坐在船头的人说：“不好，船漏水啦！”坐在船尾的那两个人该怎么办？赶紧过来帮着修船啊！难道还说：“漏的不是我这边，没我的事。”这就是共同责任。

具体到开发团队，团队成员在开发技能方面，人人都是一专多能，不仅可以胜任自己的任务，还可以分担别人的困难。进展顺利的时候，各司其职，互相配合，进展受阻的时候，不会卡在一个人身上，其他人也应该来帮忙。

Scrum开发团队的责任

作为开发团队，最重要的责任是交付高质量的软件，在每个冲刺结束时，交付的软件增量必须是“完成”的，是可以使用的，潜在可发布的。以上讲到的开发团队的5个特点，都围绕交付高质量软件这个最终责任。

除了完成交付的责任，开发团队还应该腾出少于10%的时间，协助产品负责人梳理产品待办项。

最后我想谈谈工匠精神。我向开发者们推荐一本书《The Software Carftsman》（软件工匠）。这本书里有一句话特别打动我：软件工匠要像照顾自己家的后花园一样照顾自己写的代码。

小结 

最后我们用几句话小结一下。Scrum开发团队是自组织的团队，他们自律、自强；Scrum开发团队是跨职能的团队，他们配合顺畅；Scrum开发团队是小团队，他们灵活高效；Scrum开发团队是只有一个头衔，共担责任的团队，他们风雨同舟。Scrum 开发团队，梦之队！