敏捷也需要一双隐形的翅膀

2017-09-20 03:46:52      作者:1502937487

提起敏捷大家并不陌生,不乏两大阵营的声音,有正面的拥趸,也有提出异议者,但敏捷理论真正切实的解决了很多日常研发问题,特别是互联网背景下,更能淋漓尽致的发挥其作用,敏捷着实变的越来越重要,有继续火下去的趋势。

理论有时候很受人诟病,很多企业、组织、团队很希望能够理论结合“本土”实际,真正的落地生根,而不是飘在天上,所以我根据多年研发领域的经验,再谈一谈敏捷,加一些干货,也深入谈谈那些倡导敏捷的先行者提供的一些工具,以及工具这双“翅膀’如何帮助团队“飞“起来。

切肤之痛

记得几年前带一个团队负责的项目,搭建某集团公司的会员体系,当初研发团队大概20人,产品团队当初是业务部门抽调的,虽然有一定的业务背景,真正做产品的经验匮乏,整体团队规模不大。由于是集团级大领导挂帅的项目,所以也呈现通常的形态:时间紧、上线压力大、业务需求不明确、资源分配依然不足、人员磨合度不够等等。

这种状况下当然想到先用quick start把项目启动起来,让一句话需求,快速的具象起来,能够有一些用户体验地图,并且做一些技术穿刺,也做了用户故事拆分,一切看起来还不错。

甜蜜期总会过去,项目大概在两个月后有一个雏形,这到了上线的前夕,很多问题冒出来了。

PMO 当时觉得项目信息收集非常困难,持续动态变化,项目风险不好把控,更不能在事前进行预警。

研发经理:为了提升项目满意度,保证信息同步,跟业务部门的沟通非常频繁,需求变更不好把控,往往交付产物跟业务部门的预期相差较大,精力耗费点太多,在管理上承上启下的工作无暇顾及,技术欠债非常多。

研发人员:每天加班,无尽的功能与bug堆积非常严重,也分不清优先级,工作杂乱无章加上很多会议需要参加,处在疲于奔命的状态

测试团队:很忙的时候需要跟研发一起通宵达旦,闲的时候又不知道做什么。

业务部门:对研发和项目进度非常不满意,多次被迫验收上线。

运维人员:版本发布频繁,并且每次发布成功率非常低,一般经常回退版本,让研发修改代码。

总之,每个角色每个点上问题都很严重,这是一个真实案例,项目中的所有干系人都体会到了这种痛楚,这也是传统研发迈向敏捷的必经之路,瀑布研发慢慢的在互联网化的今天掉队了,越来越多的组织在体味这种切肤之痛。

破解之道

敏捷确实能够解决很多研发上的问题,从一个idea到需求实例化,再到用户故事的拆分都有了一个合理化的标准,各个角色都开始get敏捷方法下的各项技能,工作也通过可视化的手段展示在看板上,通过看板就能看到每个人的工作状况,以及阻碍项,当然看板的一些理论在这里就不展开讲了,项目风险、阻碍等细节信息,贯穿在研发过程中的各项会议效率也有了明显提升,测试也从饥一顿、饱一顿的形态转化成平稳的工作,慢慢的团队又开始进入一个良性发展的时期。

业务部门也会将需求进行优先级的排布,并且严格限制在制品的数量以保障质量,研发可以进行技术欠债的偿还,做到测试前置,运维环境也不断完善,发布窗做到灵活管理。

这时候每个版本迭代下的数据统计也能够起一个导向作用,能够很客观的反映每个迭代下的问题,也为版本回顾会议效果起了保驾护航的作用,一切看起来还不错。

工欲善其事必先利其器

研发团队作战总是想不断的通过技术手段解决人工的瓶颈,于是很多研发负责人都在寻敏捷的“翅膀”—工具,要保证持续交付,必须要做到从一个idea开始就敏捷起来,做到规范化,从版本管理、分支管理到测试自动化、代码扫描、review,甚至到运维部署都要打破传统的人工模式,需要更加可视化、自动化、智能化的工具来支撑,开始尝试一些开源的工具,如:Jenkins,jira等工具,

也有很多商业化工具应运而生,如:腾讯的TAPD,阿里的云效平台等等;本人在银行金融行业工作十几年,也会遇到一些困惑:开源工具,有时候需要投入巨大的资源进行改造或开发,很难控制,达到日益复杂的业务需求,大多数只能解决一部分问题,也很难把必要的信息流打通。

找工具的过程相当折腾,走了很多的弯路,金融行业的特质又决定了不能采用TAPD、云效平台的PAAS、SAAS模式,后来接触到平安的神兵,有种梦里寻他千百度的感觉,这个平台很好的支撑了研发团多日常所需的所有功能,在支撑传统业务的同时,敏捷转型研发团队对工具的要求都能够很好的满足,真正打通了各个角色的信息流,也算是一个非常完善的DevOps平台,听说最近他们还推出了“平安敏捷方法+”以及工具的一些咨询和培训服务,能够更好的让工具在研发团队中落地生根,长成参天大树,经过深入的交流,发现平安开发这套工具也颇费周折,投入100人的研发,1个多亿的费用,这样看来也验证了开发工具是一个烧钱的买卖。经过前期的选型和对比,近期我们团队开始全面接入神兵,让敏捷腾飞。

苦尽甘来

传统的研发团队/组织都在寻找敏捷转型,敏捷转型过程肯定沟沟坎坎,布满荆棘,要想顺利,多在业内进行交流是很必要的,特别是借鉴别人的成功经验,这样才能摸索出一套适合自己的敏捷之路,当然工具也很重要,这需要决策者认真的衡量几个问题:1、用外部开源工具 2、自行研发3、引入外部工具+经验,当然第三种方法是最实际的捷径,希望关注敏捷转型的,以及在转型路上的金融行业研发组织多多交流,最终找到真正适合自己的那条阳光大道。


0
评论(0)
点击换图 登陆发表评论