通常大家接触最多的敏捷实践框架是Scrum,但初期需要先理解Scrum 到底做了什么事情来解决问题,因为最佳实践都是别人的团队得出来的,而我们要找的是最适合自己团队的实践。
敏捷框架
做敏捷需要一个规范的流程让团队知道在每个阶段应该做什么,避免大家认知不到位。普遍的做法是先进入看板体系,在无入侵的情况下,把交付过程可视化,然后找浪费,最后优化每个阶段的浪费。
交付流程是固定的,只要知道一个价值的流动是怎样实现的,在固定的时间内让它流动起来,尽量快地流动起来,就可以提升交付能力,这是最常见的优化做法。
很多团队喜欢用看板是因为没有入侵性,看板不会对当前的关系人产生冲击。例如你现在是团队领导(Team Leader,TL),会想用了敏捷后团队都扁平化管理了,扁平化后不需要自己了怎么办? 你会担心做了这件事情后,就被淘汰了。所以会希望不要去实施类似于Scrum 之类的体系,还是稳固当前的工作习惯,甚至于在工作中有所谓的门槛,最好需要你确认签字后再执行下一步。在传统流程中责任人在你,虽然麻烦但是能有存在的价值感。在敏捷团队中责任却是整个团队一起承担的,个人价值被均摊了。
这时的你不希望出现类似于Scrum 的框架将现在的局面打破,希望能保留住自己,这种角色叫作既得利益获得者。即现在已经知道一件事情我是既得利益获得者,需要先保护自己。保护自己是短期视角还是长期视角呢? 如果我知道了未来会怎样变化,那么应该先革自己的命,这样以后有人想来革我命也没有机会了,又回到了跳出舒适区的理念。
所以在整个过程中,关注看板中的流程总会进行到你这个阶段,而你要做的是加速交付,减少在你这儿停留的过程继续往下流动,不要让自己成为瓶颈,要让自己去做更有价值的事情。
Scrum 管理体系和看板的差异化还是很大的,所以大家需要重点关注以下3个问题。
(1) 敏捷与Scrum 体系框架的相互关系。
(2) Scrum 管理体系到底是怎样实施的。
(3) 如果在公司做敏捷项目管理体系,应如何落地。
这里先解释项目管理体系,敏捷项目管理体系有两个层面,一个是需求域管理模式,即怎么去管理用户价值; 另一个是研发域管理模式。在DevOps中这两个层面是统一的,但在实际情况中大多数初期转型团队很难解决业务和技术之间的部门墙。
1
●
常见框架
当团队落地敏捷的时候会涉及很多分支,例如框架中最大的软件统一过程(RUP)、极限编程(XP)、Scrum、看板或者瀑布流程等,如图9-1所示。这些分支都会在实施过程中产生区别,在极限编程和软件统一过程中其实还有别的框架,例如规模化敏捷框架(ScaledAgile Framework,SAFe)或大规模敏捷Scrum(Large Scale Scrum,LeSS),这些都是常见的框架。不同框架有不同的侧重点,不同的公司也会基于环境选择对应的应用模式,例如RUP偏规范,而看板偏适应,所以其中的最佳实践项也会少很多。
■ 图9-1 常见敏捷框架
记得有学员问过,在工作中每天早上大家都会聚在一起讲一下进度,但是他不知道为什么要这样做? 其实这是在做敏捷中的每日站会(Daily Meeting),然后他一听就觉得做这个很好,高端、大气、上档次。
框架、名词、关键字是拉通人和人之间认知的快速手段,例如了解Spring、AOP、Swagger、RestFul等名词,在和开发人员一起讨论问题或方案时能更容易统一认知。SAFe、LeSS、XP、Scrum 和看板之类的框架,其实就和Selenium、JMeter、Request之类的专业名词一样,都属于框架的一种,而这也是我们希望达到的目标,快速交付高质量有用价值,在实施过程中需要使用各种框架来解决问题。
2
●
LeSS
LeSS由克雷格·拉曼(Craig Larman)和巴斯·沃德(Bas Vodde)在2013年共同设计,框架基于Scrum 进行扩展,通过大量的实践经验,糅合精益思想沉淀而成,支持企业以敏捷的方式进行大型产品研发,是一个轻量级的规模化敏捷框架。LeSS不是新的和改进的Scrum。相反,LeSS旨在尽可能简单地弄清楚如何在大规模环境中应用Scrum 的原理、规则、元素和目的。
产品负责人(Product Owner,PO)为多个团队根据组件或者特性规划迭代交付目标,构建以整体MVP为基础的多团队协作模式,如图9-2所示。
■ 图9-2 大规模敏捷Scrum
随着团队的扩大(超过8个人的团队)会采用LeSS Huge框架,添加领域产品负责人(Area Product Owner,APO)角色来帮助PO 划分团队交付范围。
3
●
SAFe
SAFe的设计和主要方法论在2011年由迪恩·莱芬威尔(Dean Leffingwell)主导,是另一个流行的规模化敏捷框架,其特点是将敏捷实践在企业中分层而治,从团队级(TeamLevel)到项目群级(Program Level)乃至投资组合级(Portfolio Level),糅合精益敏捷知识体系。
SAFe中有个叫版本火车(Agile Release Train,ART)的理念,把软件交付的过程比喻成一列行进的火车,在不同的站点会挂上对应的车厢,每节车厢代表一个团队的交付物,当火车到达终点时,本次需要运输的所有交付物都正确到达,用户获得了所有的价值。
SAFe是一个相对来讲大很多的框架,传统公司更喜欢这样的强管理模式,其中的PI(Program Increment)Plan是与别的框架最大的区别,SAFe通过它来集中规划本列火车各个车厢的交付时间及顺序。
4
●
敏捷相关认证
与测试行业恰恰相反,敏捷相关的认证非常多,这也许是文科和理科最大的区别。获取证书来强化对敏捷的认知是一个非常好的手段,因为认真备考的过程可以让你更加专注学习。
从广度入门来讲,敏捷管理专业人士(Agile Certified Practitioner,ACP)是个不错的选择。首先,PMI的考试和培训比较规范; 其次,ACP的知识面比较全面,覆盖用户故事、Scrum 敏捷实践及文化。
如果想对Scrum 体系有进一步深入的理解,可以考虑CSM(Certified Scrum Master)、ASM(Agile Scrum Master)或RSM(Registered Scrum Master)体系。
到这里是不是发现绝大多数主流的框架包含了Scrum 体系,接下来展开介绍什么是Scrum。
参考书籍
《敏捷测试从零开始》
从零开始、从测试视角构建完整的全局体系！多位技术专家联袂推荐
ISBN：978-7-302-60089-3
陈霁、王富、武夏 编著
价格：69元
内容简介
本书针对当前正在敏态化交付的团队，围绕敏捷思想从测试的角度、从零开始构建知识体系，讲解如何做到高质量交付，从质量视角构建基于敏捷理念的全面认知并从基本框架体系跳出构建敏捷思想的质量交付能力，为进一步研发效能提供支撑。本书共11章，从敏捷理念到优化交付目标，以Scrum体系为基础，详细介绍看板、用户故事地图、故事实例化、分层自动化体系等，助力个人和团队搭建完整的敏捷交付能力。构建以业务价值为目标，以高质量快速交付用户价值的团队，从而构建统一认知。本书不但适用于测试团队，而且适用于敏捷团队中的各个角色互相了解工作内容及知识体系。
编辑推荐
精彩推荐
微信小程序游戏开发│猜数字小游戏（附源码+视频） Flink编程基础│Scala编程初级实践 Flink编程基础│FlinkCEP编程实践 Flink编程基础│DataStream API编程实践 Flink编程基础│DataSet API编程实践 数据分析实战│客户价值分析 数据分析实战│价格预测挑战 数据分析实战│时间序列预测 数据分析实战│KaggleTitanic生存预测
