大家在实践Scrum框架时，有时候会不会遇到一些棘手的问题但却找不到答案，尤其是在多个团队各自运作Scrum的情况下；或者一条产品线由一个团队来支撑已经完全不够，领导在盲目加人；或者一个端到端的产品被分成几大块，由具有互相依赖关系的不同组件团队来交付，等等这些现象随处可见。不仅给我增加了很多沟通协调的工作；而且往往存在一些系统难题无法解决，像死锁一样解不开。
那么Less框架是怎么解决上述问题的呢？
首先Less产品的定义尽可能广泛，并以最终用户/客户为中心。
也就是说交付到用户手上的产品是一套完整的系统或者为客户解决问题的方案，不是部分的功能应用或程序片段。那我们在划分产品线时要覆盖端到端，并且把组件团队转变成特性团队。组件团队是指交付特定应用模块的小组，应用模块交给用户，用户是没办法单独使用的；特性团队是指可以独立交付端到端产品的小组，端到端的产品交给用户，用户是可以走完整个业务流程的，可实际使用的产品。
一个完整的可交付产品对应一个产品负责人和一个产品待办事项列表。
一个产品由一名产品负责人负责，一个产品负责人下面有几名产品经理，不同的产品经理对应各自的交付团队。一般来说Less由2-8个团队产品开发组成，这些团队共同拥有一个产品待办事项列表。产品待办列表在梳理时由产品负责人、多团队、客户、用户、其他利益相关方共同参加，优先级排序由产品负责人确定，优先级澄清由团队、客户、用户参与。
Less Sprint与Scum Sprint 的区别
Less 框架下只有一个产品级的Sprint，每个Sprint都会产出一个集成的整体产品。那么多团队是如何配合完成Sprint里的工作呢？Sprint计划会分两部分，Sprint计划会一和Sprint计划会二。Sprint计划会一需要产品负责人和团队代表参加，他们一起探索性的识别每个团队要做的工作条目。团队识别一起协作的机会并澄清问题。Sprint计划会二由团队自己开，各自决定如何实现执行所选条目。每日站会由各个团队自己开，站会上聚焦Sprint目标，分享进度，抛出问题寻找协作机会。产品交付前整体团队开一个产品级的Sprint评审会，邀请客户、用户、利益相关方参加，并请他们给出意见或提出需要调整的内容。产品交付后，各个团队先开各自的回顾会，然后再开全体回顾会。再全体回顾会上要讨论跨团队问题和全系统范围内的问题，并建立起改进措施。
Less里的角色与职责
产品负责人主要是规划产品愿景和方向；团队主要负责产品创建和交付；经理帮助成员个人能力提升，致力于结构调整、推动改进试验，最终提高组织能力；Scrum master负责Less采用的顺利开展，他需要关注团队、产品负责人、组织以及开发实践。
总之，Less里的特性团队取代组件团队有利于解决组与组之间相互依赖带来的浪费。以客户为中心定义产品，并再此基础上开展Sprint活动，有利于团队成员深度学习业务知识、特定知识（架构、设计等特定知识），加强协作。全员视角系统化，有利于组织系统问题的暴露和改进优化。
网友评论