Larman和Vodde:对于2-8个团队的LeSS采用,或许有必要这样。但是对于大型LeSS采用,就不太可能了。
不过,首先让我们定义一个术语:功能团队(在LeSS中或常见用法中),是一个跨职能以及“跨组件”的团队,为了了解和交付以客户为中心的功能,无所不作。可能包括UX调研、分析、设计、架构、组件整合、视频、图片、音频等。为了完成功能,要对所需的任何和全部组件(微服务、应用、层、模块、类…)进行编码。
这是否意味着,对于功能团队的每个产品,开发人员都要了解全部内容呢?答案是否定的。这种“不是...就是...”的看法是软件行业的常见模式,所以计算机从业者通常具有二元思维,是有原因的。因此,我们在几年前第一本关于LeSS的书中写了一章《假两难推理》。
假两难推理是说,个人或团队要么只了解某一件事,要么了解所有的一切,但实际上,很有可能不同的团队成员具有不同程度的专业知识,了解不同的模块。因此,为了完成一个功能,团队作为一个整体,需要拥有必要组件的相关知识,但不是每个人都需要了解全部。如果某个组件没有任何人了解,那么学习的时间就到了,学习是LeSS组织中一个关键和主导的行为。这并不新鲜,早在1986年HBR(Harvard Business Review)的一篇描述Scrum起源的论文中已经定义过“多重学习”是Scrum的一个重要特性,意思是学习多层次技能和功能。
另外,一想到要处理不熟悉的代码,非程序员以及经常同垃圾代码打交道的程序员,会觉得这很可怕,令人生畏。但如果使用了LeSS在“技术卓越”中建议的TDD重要实践,来开发整洁的代码,就不是什么大问题。我们俩(Bas和Craig)除了作为LeSS的组织设计咨询师和高级管理者一起工作,也依然在亲自作为专业的程序员和其他开发者一起工作(这是一种对跨越职能架构的尝试)。因此,有了多年在开发整洁代码和TDD方面的直接经验,我们才敢说出“这不是什么大问题”这样的话。而对于要在遗留有大量垃圾代码的情况下采用LeSS这一常见问题,有一套补救指南和实验,包含分组的导师制度、现行架构学习研讨会等。
对于小规模2-5个团队采用LeSS,有人了解代码库中的大部分或全部内容,是相对常见的。产品规模越大,则越不可能。Bas正参与一个千人规模的大型LeSS采用,让一个人去了解每一部分代码是几乎不可能的。不过在这种规模下,也无需如此。为什么?大型LeSS由众多以用户为中心的部分构成,相互间有功能相关性,例如“交易处理”和“监管报告”。这些都被称作需求范围。团队倾向于在单个需求上花费更长时间。要注意,这些是客户需求的范围,而不是架构上的组件。即使这些需求不是基于架构组件的,专注在某个需求上(例如监管报告)的4-8个功能团队只需关心整个代码库的部分可预测子集也是可能的。这样,他们需要了解的代码便少于整个代码库。
来源: http://www.infoq.com/cn/articles/book-review-large-scale-scrum