新闻动态

Scrum的扩张

2019-03-08 21:15:48 作者:小麦

Scrum和敏捷给业务带来的好处通常是通过在同一地点工作的小型跨职能团队达成的。最理想的团队由不多于11个人组成包括负责人、Scrum master软件开发团队每个Scrum团队都能够在没有外界的帮助下独立完成一个特定产品或者应用程序的设计1开发测试和交付。

但事实上,使用Scrum获得的成功必然会促使其在更大的项目、系统和应用程序上使用,因此必然需要更多团队,甚至分布式团队来开发和交付。幸运的是, Scrum已经被证明在拥有数百名开发人员的项目中同样适用,因此Scrum确实能够扩张使用到更大规模的软件企业中。但是,扩张会带来一系列必须解决的特殊问题,尤其是下列的几个。

(1)扩张团队结构:建立Scrum团队之上的团队

(2)为企业级敏捷准备工具和设施

(3)协调团队之上的团队

下面的内容中将介绍如何解决这些问题。

扩张团队结构:建立Scrum团队之上的团队

为了保持“少即是多”的原则, Scrum只有很少量的规则。然而,这些规则中的大多数都是固定的和不能违反的。其中一条基本的规则就是团队成员不能多于11个人,而且这些团队成员应该尽可能地被安排在同一个工作区域内。这种方式是最有效也是生产效率最高的,因为这样可以使团队成员之间的经常性非正式交流更加方便,加强团队合作精神,使每天一起工作并熟识的团队成员可以为了共同的Sprint目标一起努力。此外,如果团队超出810人的规模的话,Sprint计划会议和每日 Scrum站会这些强制的Scrum实践会轻易地瓦解。组建分布式团队和过大团队应该要仔细权衡。

即使要将Scrum的应用范围增大,也不能放弃这条原则。因此,如果要将Scrum推广到300人的应用中,那么就需要组建大概30 Scrum团队。每个团队需要满足前面所述的条件,并且能够在每个 Sprint开发出潜在可交付的功能模块。对很多组织来说,这就需要围绕着产品的特性、服务、组件或者子系统重新组建团队,而不是根据每个人的职能(例如软件开发人员、测试人员等)来划分。当我们之前在讨论组织暲碍的时候已经发现随着团队人数的增多,团队组建的难度也会增大。

组织架构跟随产品架构

如果不理解每个团队如何相对整体地交付终端用户功能,就无法便利地组建Scrum团队。这就要求我们将程序的架构分解成独立的组件或者子系统,使每个部分都拥有概念完整性,并可以独立地交付商业价值。这种组织架构调整可以在早期 Sprint中由先实行Scrum的团队完成。这个方法在Scrum张到更大的项目中时尤其有效。具体方法如下,先行的团队一边交付客户需要的价值,一边对系统进行调整使正在进行Scrum培训的新软件开发团队可以在加入后负责独立的模块。这样当每个新团队组建好的时候,其在系统中的角色就清晰可见了。