iOS 开发每天分享优质文章@IT·互联网

技术眼里的敏捷开发

2021-05-15  本文已影响0人  落影loyinglin

正文

我们是否遇到过这样的问题:
1、需求评审时有些疑问,不知道从何问起;又或者好像听着明白,开始做的时候就有些困惑?
2、技术方案设计时无从下手,感觉整个需求比较杂乱,就是一些逻辑堆叠而成;
3、在需求开发过程中,记不清楚具体的需求过程,需要频繁回顾产品需求文档;
4、需求提测之后,自己感觉问题不多,结果QA测试出来很多Bug;在bugfix的时候解了BugA,又漏出来BugB;

如何来减少这种问题的出现?下面分享一些敏捷开发的经验。

需求开发流程

产品经理分析、调研用户需求以及整体市场环境情况,对于某些功能产生预期收益,就计划如何去做来拿到收益,把具体事情整理成方案之后就形成了需求文档。
需求到了研发这边,当我们接触需求之后,可能就会开启一系列流程:需求细评、工作量评估、技术方案评审、需求排期、需求开发、需求自测、需求提测、问题修复、版本灰度、线上发布、数据跟进。

将上述流程整理、简化成开发视角下的过程:


《一个需求的上线流程》

PM是产品经理,RD是研发,UI/UE是设计,DA是数据,QA是测试。

1、需求评审

这是PM主导的评审,对齐需求目标和预期收益,较为复杂需求会有UE同学讲解交互;负责开发的需求会先参与需求细评,中间会涉及的具体细节;可以提前做好功课,先看文档以理解产品逻辑,因为会议时间往往不长,最好是用来确定核心述求和讨论一些疑惑点,避免去对需求细节的解释
在会议结束之后,研发将需求进行拆解,可以按照客户端同学最熟悉的页面维度去拆分,大致描述每个界面的核心要素;也可以按照产品需求文档,从业务逻辑的角度去拆分,描述该需求的产品逻辑要素;也可以从数据流的角度去拆分,从数据产生(用户操作,后台产出)、数据接收(接口请求)、数据消费(界面展示、用户交互)、数据上报(埋点上报)等,来描述该数据层面上的变化。
核心点就是有一个思路来贯穿整个需求,将一个需求拆解成树形的结构,以便于我们去评估需求复杂度和完整了解整个需求。

2、方案设计

由需求开发RD主导,输出整个需求的技术方案。这时候前面的需求拆解就非常重要,因为方案设计的前提就是需求的整体理解,将复杂的需求进行拆解,再借由一些通用的程序设计思想进行组合,将前面拆解出来的需求整理成一个方案
方案设计出来之后,会有相关的RD同学一起进行review,针对方案的扩展性、稳定性等进行讨论,也会根据已有业务评估方案的影响点,尽可能在方案设计时暴露出来风险点。

3、逻辑开发

现在对需求有全面的了解,同时也有完备的技术方案,接下来就是按图索骥把方案实现出来;一个稍复杂的需求在实现过程中,RD既需要专注在代码实现,还要记住需求细节,保证最终实现出来与之前设计一致,这并不是很简单的事情。
此时,前面两个环节沉淀出来的需求拆解文档和技术方案文档就非常重要。我们先按照技术方案的设计,从某些模块入手;实现过程中,按照需求拆解文档进行一步步实现;在实现完部分模块之后,再回顾技术方案,开始下一步的模块;如果实现过程中,发现方案设计有些欠缺考虑点,则先停下来代码实现,优先考虑如何修改方案设计,再继续按照方案去实现

4、五方验收

需求开发完成之后就需要自测:回顾需求文档看看是否遗漏的实现点,对着设计稿看看界面实现是否偏差,检查交互文档特别注意里面的小字说明,跑一遍测试给出的case,保证埋点验收能看到所有的埋点
自测完成之后,就可以进入验收环节。PM会检查功能实现是否符合预期,UI会进行像素级别对比,UE会体验产品细节交互,DA会验收所有埋点细节并记录,QA则会用各种无法预期的操作去测试。
经过多方锤炼之后,需求终于可以合入。

5、灰度上线

在正式上线之前,会进行多次灰度。RD会打开AB实验、下发settings配置,灰度期间再看看功能的问题反馈。如果灰度发现问题则要追本溯源,确定问题出现的真正原因,修复完成跟下一次灰度。
直到整体质量稳定之后(达到准出标准),才会进行正式版本的发布。

开发过程的建议

一些提高工作效率的注意点:

技术如何参与团队决策

1、需求可行性的判断

这是从技术的角度,来分析需求的可行性。产品的思维非常发散,有时候会提出一些天马行空的想法,比如说根据手机壳颜色调整手机主题色。这些也有可能不是奇思妙想,如果手机具有识别颜色的传感器,这需求也可以实现;或者说采用降级方案,通过手机先对手机壳照相,提取手机壳颜色,再根据提取出来的颜色进行主题色适配。
先尝试从技术的角度去评估可行性,有实现的可能,才能讨论具体收益和实际投入。

2、丰满理想下的骨感现实抉择

PM/UI/UE在考虑功能设计的时候,往往希望产品功能完善、体验极致,但是每个双月的时间又是那么短暂,技术可以对需求进行理性评估,拆分出来需求各个模块的投入人力,进行后面的一些决策:在保证核心收益的前提下,如何快速完成该需求并上线进行验证,如果预期收益合理再进行下一步改进,如果和预期不符,则快速调整需求,或者及时放弃以止损。

3、数据化的重要性

有时候功能上线之后,用户反馈和产品直觉不一定相符合,此时用数据来量化收益就非常重要。技术会帮助产品将这个过程量化,除了关注需求的具体内容,也可以关注需求的前因后果。数据化能帮助团队优先做一些有收益的事情,而不是一些看起来应该做,但是目前拿不到太大收益的事情。

4、趋之若鹜的AB

PM为了更好量化需求收益,往往都会在需求中添加实验,甚至一些文案、toast的修改都想加一些实验来衡量收益,是否实验就是需求上线的保障?数据化是非常重要的,但是万物皆AB明显是存在不合理的地方。AB并不是万能的,有些需求甚至有可能因为正向收益不大,受到实验随机波动导致实验组负向。
合理AB应该是将收益数据化,看到要做事情的价值,辅助进行决策。

思考🤔

经常到一种言论:技术决定业务门槛,产品决定业务发展,真的是这样吗?
这句话其实忽略了技术的很多价值,也是一种不完整的认识。
在一个团队中,每个人都是构成项目的一部分。我们可以觉得自己只是一个打工者,不去太操心项目的走向;也可以只关注自己的工作内容,自扫门前雪。但是还有一种可能:尝试去理解自己负责的内容在整个产品的作用,还有未来发展方向以及原因,尽自己的努力去完成目标和提出改进的建议。或许会徒增一些烦恼,但是会多一些影响团队、项目、产品走向的机会,也会多一些主人翁精神带回来的成就感。

以上内容来源于日常版本迭代的简化,实际情况会比更加复杂。

上一篇下一篇

猜你喜欢

热点阅读