橙厂的真实敏捷历程
背景
在橙厂中,有很多业务线都是采用的瀑布式研发模式,存在发布周期长,需求多,逻辑复杂,响应慢,产线事故多的情况.我所在的项目组前期也是这样的现状,但是在2021年后逐步尝试了敏捷的管理模式.到2022年完全固化了敏捷管理.改变了之前的问题,现在的节奏是小步快走,快递迭代,产研结合.快速响应.需求迭代提高,出现问题几率减少.
先说说一下自己吧,本科学历,资深研发工程师,架构师,曾就职与携程旅行和互金行业.目前就职于橙厂下的电子商务公司.拥有7年的软件研发,项目及团队管理经验,和敏捷管理经验.
在此之前我也曾在二家公司实践过敏捷开发的管理模式,但是因为业务规模较小,研发和产品业务无法很好配合,导致我们只能强推研发的敏捷模块. 当时那是我的第一家互联网金融公司,当时做技术leader角色.针对后端研发部门7-9人团队做了像模像样的敏捷研发管理.从产品那里接收到产品需求.将其任务拆分,人员自主选择,开发时间自行评估,leader也要调整任务时间,外加每天的敏捷站会,看板模式,TODO列表,每晚邮件汇报今日进度,虽然不算真实意义上的敏捷管理,但是也是学的有模有样.但是尽管如此,还是缺少敏捷的另一大特点,小步快跑的特性,在那家公司因为任务的多少是在上游业务,产品就已经定制下来的.所以很难固化研发发版的节奏.有时会很久发版,比如之前封闭开发时会长达二个月的研发版本.有时任务会很少,只是更改一些配置和样式,这样就一个星期就可以发版处理.
之后在另外一家面向C端的游戏公司担任过项目经理角色.负责7人研发团队,其中包括三名后端研发,ios,安卓,前端,测试各一人,.在这也是使用敏捷项目的管理机制.除了负责后端的开发情况,还要了解其他技术方向的项目进展情况.但是在这里可以商业务的需求量和评估研发的发版节奏.所以整体的节奏还是比较好把握的,在发版周期上接近二周或者三周一个版本.每日有站会和任务看板.因为部署和运维都是研发兼职,所以这一块的东西都是自己做的.
最后在橙厂中,真正经历了一个从无到有的,并逐渐完善的敏捷模式的系统.也是让我了解和知悉这一套模式真正的意义,众所周知,不想当将军的士兵不是好士兵,以此类推,不能降本增效的模式就不是一个好模式.在之前的公司或者橙厂前期的项目工作中,或多或少的存在很多弊端,这些弊端严重的影响业产研的发展.例如
业务痛点
- 业务需求实现慢,发版周期长
因为发版周期长,导致需求积累的多,响应市场的节奏也比较慢.无法及时响应市场变化,这个需求就会死亡,做这个需求也可能没有意义.
- 发版周期长会导致市场可能已经变化,但是业务想需求变更很困难
因为周期长,就会可能导致业务会变更业务需求,产品会变更产品设计.这对研发来说会带来麻烦.变更需求业务痛苦,产品也痛苦,研发更加痛不欲生.
- 需求优先级没有体现出来
在需求分类中,如果没有采用敏捷的思维出想问题,可能整个业务是无法拆分的,可能一整块大需求中,有A有B,因为产品设计的模棱两可,研发的时间限制,可能A需求比较着急,但是实际上线的是B需求.
产品痛点
- 需求周期长,就带来需求变化多
有时需求是为了快速响应这个市场的,但是我们的需求周期太长,会导致市场发生了变化,这时需求就显得有点不合适,这时业务无奈提出变更,产品被迫完成需求变更设计,对与技术来说,这些已经完成或者即将完成的功能要变化,内心是崩溃的.双方都没有错误,但是所有人都不开心.
- 需求质量不高,一句话需求太多
我在公司就遇到过这样一位产品经理,在需求评审前期没有文档拿出来,只有在需求评审时才会按照需求文档解读,有些需求问题废话连篇,但是却是简单问题.有时需求问题一笔带过,但是仔细考究起来,确实很大的模块需求,究其原理就是产品对自身业务逻辑不熟悉,或者是没有和技术了解需求的技术背景.
- 临近结束,增减需求
这个是最无语的,我是实实在在遇到这样的问题,已经好好的写完了,但是最后又通知不上线了,之后的版本上线.产品无法定制好需求优先级,无法评估好需求的价值比,很容易做出前后不一的需求变更.
研发痛点
- 紧急需求多,差不多一个星期会有一次
在橙厂的经历来说,这种紧急需求再普遍不过了,因为需求周期长,但是又有一些紧急需求和紧急缺陷需要发版.所以需要单独拆分支去发版,最后也会造成合并代码的问题.
- 产线质量不佳,故障率很多
在项目前期,或者是未拆微服务化,产品质量会有一些问题,这些有一部分是因为需求大而杂的原因在,也有项目设计问题.这个和敏捷是一种潜在的关联.这里只提及但是不做详述.
敏捷的管理方案是这样的,在需求处理流程上,由原先的一个月需求周期,缩短为二周的周期,这样就可以做到小步快走,步步为营.快速发布快速响应快速变化.这个也是我认为敏捷最核心的优势,这是和瀑布管理模式的区别.一切都是为了尽可能的增加价值.
减少周期时间,解决需求上线时间问题,要知道一些热点需求的市场变化是非常快的.如果能做到比竞争对象更快上线,更快地响应变化.
为了减少需求周期,这其实就是对业产研提出更高的能力要求,
- 从业务上,业务人员不能再一股脑盲目提出需求吗,而是需要将需求最小单元化,从最小的闭环需求做起.以最小的需求去提供给产品.
- 从产品角度上,需要设计业务需求,将需求模块化,任务列表化,结合业务需求和产品设计角度,规划出需求的阶段排期,和需求列表的优先级.
- 从研发角度上,我们需要和产品一样紧密配合,因为在需求周期缩短,就要求对产品和研发要求更高了.研发要知道产品设计的意图,产品需要知道需求的技术难度.这些都是很难处理,这就需要产品团队中有一个了解整体产品需求的leader,研发中也要一个熟悉整个项目的技术leader.由他们二人牵头开骨干需求评审,这样开最少人的会,完成最大的会议内容.
业产研时间流程图
研发时间流程图
总结
1 需求周期缩短为二周.小步快走,快速上线,快速变化.
2 业产研沟通会节奏改变,最少的人开最有效的会议.
3 业务产品需求根据研发周期切割最小的业务内容和产品设计任务列表.这个需要上级领导的支持和允许.
4 需求任务列表需要体现价值比和优先级.根据价值优先上线那些需求.
5 敏捷管理中,研发自测需要自行处理测试用例,及其全覆盖.
6 敏捷管理中,测试需要提升自动化测试的工具,帮助敏捷版本中快速上线.因为版本的缩短,带来版本的快速迭代,一些已知的功能需求可能测试无暇顾及,这时需要自动化测试帮助全部覆盖测试.
7 敏捷管理中,运维部署需要做到自主发布,自主运维,因为版本的缩短必将带来频繁的部署上线.
浙公网安备 33010602011771号