02-Less框架结构解读
作者:互联网
上一篇文章中我们简单介绍了Less的10大原则,这一节我们来看一下Less的框架基本元素,如果您在关注这一系列的文章,那么我默认您对scrum已经非常了解,所以不会过多的介绍scrum的内容而是重点说明Less框架与scrum框架的不同之处!
1、关于团队角色
角色部分的描述主要澄清两点,第一是多个团队有且只有一个产品负责人来负责产品规划和管理,虽然在scrum的角色定义中每个团队中都会有一个PO,但是Less中强调多个团队是为了同一个产品目标服务的,所以有一个共同的产品负责人来负责即可,当然您可能会有疑问如果团队太大一个产品负责人无法承担该如何处理,这个属于Less Huge关注的范畴,我们后续会聊到这部分;第二是关于scrum master的定义,在less中scrum master可以覆盖1-3个团队,这其实是在团队级敏捷成熟度达到一定成熟度之后的必然结果,如果团队逐步实现了自组自管理,那scrum master完全有能力和精力负责更大的范围。大家可以关注下这部分的术语是“自管理”而不是自组织,在旧版的scrum指南中也一直使用自组织的术语,但是在2020年最新版本中也修改为了自管理,详细内容大家可以看我之前发的关于scrum指南解读的文章,这样看Less对团队的定义还是比较清楚也比scrum更超前的; 这样看来less并没有太多的角色,那less中是否会有传统的经理角色呢?scrum指南中是没有描述的,但是在less中做了一些澄清,经理的以前的职责主要是做什么和怎么做两个方面,现在做什么由产品经理负责,怎么做由团队共同决策,那经理还能做什么呢?经理成为了为团队赋能的角色,即运用各种措施提高团队技能水平,为团队提供帮助和指导,同时也可能辅助scrum master帮助团队排除干扰。当然我们也要注意经理是一个可选项不能盲目的给经理一个定位,如果组织真的不需要传统经理的支持,那去掉就好了(或者转型为scrum master)。
2、关于工件
在scrum中有三个工件,分别是产品待办事项列表、迭代待办事项列表和产品增量,在less中还是维持了一份产品待办事项列表,这个和上一段落说到的只有一个产品负责人是相辅相成的。另外,sprint 待办事项列表应该每个团队都有一个,毕竟sprint待办事项列表中的内容是每个团队具体进行的任务,所以这个没有必要统一到一份清单中,而不管团队任务怎么划分最终应该是以一个整体来交付产品增量,所以在less中产品增量还是只有一个,以整体产品的维度而存在。
3、关于事件
3.1、迭代计划会议
在scrum中迭代计划会议会分成两个部分,在less中也类似,只不过细节会有些差异,具体来说在less中迭代计划会议的第一部分是由各个团队与PO协商选出各个团队需要负责的需求,而在会议的第二部分各个团队要规划自己团队负责的任务,所以可以分开进行但是建议在一个公共的空间中,这样利于快速的交流跨团队的工作内容;这里面有一定很关键不要把高优先级的需求分给同一个团队而应该将需求尽量按优先级均匀分配,以规避高优先级任务由某一个团队负责又无法按期交付的风险;3.2、每日站会团队除了要进行每日站会以外,还要根据需要每周开2-3次的scrum of scrums 会议,目的是沟通团队间协作问题,比如:需要共同推动的事项,互相影响的工作内容等,上文中我们已经说过scrum master会同时负责多个团队,所以sos会议也不能完全依赖scrum master来负责,每个团队都应该派代表参加,毕竟这个也是团队自管理的一个部分;说到这里大家是不是已经意识到一个问题,那就是在less中期望团队是比较成熟的,是一个特性团队、跨职能团队这样才能有效的支持less架构的运作。3.3、迭代评审会议关于评审会议Less的改动会稍微大一些,直接将团队的评审会议去掉,因为所有团队交付的是一个共同的产品,所以评审会共同进行,虽然内容还是向产品和客户展示产品增量,但是形式上期望更灵活,可以是一个类似展会的形式,可以看到整个产品的功能,也可以对某一个团队交付的部分进行探讨;3.4、迭代回顾会议less的观点认为scrum的回顾会议还是要进行的,但是额外还要有所有团队一起进行的整体回顾会,因为两个会议关注点会有所区别,全体回顾更关注跨团队协作的问题以及所有团队共同的机制问题,因此参会人应该包括产品负责人、scrum master和团队代表;
这篇文章主要介绍了less的角色、工件和事件,相信大家对less有了初步的了解,下一篇我们来看一下less huge又有哪些变化!
标签:02,less,Less,scrum,master,产品,团队,框架结构 来源: https://blog.51cto.com/13676635/2589441