迭代敏捷开发的最佳实践网站首页 学无止境

迭代敏捷开发的最佳实践

javaRoger 2025-02-15 00:01:02

简介迭代敏捷开发的最佳实践

1.概要

目前我们团队的工作模式是产品提出需求，告诉团队中某个人或某几个人要做什么，然后人员自己估计需要那些协助和依赖，再就开始开发，开发完后提给测试，测试测完后，提给产品UAT，最后开发同学上线，看似整体流程畅通，但其实内部隐患很多我们经常遇见如下问题：

需求任意插入，由于没有计划，往往一个需求过来后，感觉优先级比较高，在当天就会跟开发人员确认，然后开发人员正在做的事可以停下来，接入此需求

多人协作的时候，由于依赖和联调时间没有确定，往往出现依赖方和被依赖方没有达成协定的情况

测试人员和开发人员信息不同步，测试人员往往是开发送测或者是开发已经进入一半的时候才开始了解需求，对需求的影响点和相关性往往了解不深

测试完后，上线随意，产品的UAT往往来不及，也就是用户方还不清楚最后做成的样子是什么，是不是有跟PRD不同的地方，就上线了

针对如上问题，我们需要整理需求研发的流程，让大家能够按照此流程高效，可靠完成目前我们的任务

2.迭代开发

敏捷开发：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发，强调快速响应，没有（分析师、设计师、架构师等）的划分

迭代开发：每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫做一个迭代，每一次迭代都包括了需求分析、设计、实现与测试

一般来说2C的系统，需要快速响应的系统会采用敏捷，但2B的系统更加适合迭代

迭代开发的核心 3355

3个角色：SM、PM、开发团队（自然包括了我们的开发人员和QA）。PM对产品负责，开发团队勇于对自己承诺的故事负责，SM是团队效率和质量的保护伞（由技术负责人担任）

3个产出物：Product Backlog、Sprint Backlog、需求交付。

5个活动：冲刺会、sprint评审会、总结会、每日立会、Product Backlog的梳理（发生在整个SCRUM周期的任何时间）。

5个价值观：公开、专注、勇气、承诺、尊重。

3.迭代开发流程

一个迭代暂定2周（目前根据需求不同迭代的时长也不同），看实际操作情况再做调整，一般迭代是2-6周，只要找到自己合适的节奏即可

有些项目测试人员目前是单独的，迭代开发完成后再提测

	T-6	T-4	T-3	T-2	T-1	T	T+1	...	T-3	T-2	T-1
PM	产品经理提供下个迭代产品需求列表，输出PRD	对重点需求进行需求预评审	产品沟通设计完成预设需求的设计文档	跟SM确定需要进入下个迭代的具体需求	review，并输出设计和最终的产品PRD文档	冲刺会	有可能参与ERD的评审	配合解决一些需要从产品角度解决的问题	UAT	UAT	总结会
SM		参与需求预评审	技术负责人完成下个迭代需求的技术评估，确认技术上具备下个迭代启动的条件和粗略估算时间若评审不通过，再次进行	评审通过后，技术负责人根据产品需求列表做好技术需求列表	将评审完后的需求整理，发送邮件周知全组	冲刺会 1.产品经理跟全员讲解评审过后的需求 2.根据技术需求列表分配任务 3.开发人员估时，确定任务依赖	开发人员各自输出ERD，由技术负责人确定可行性，并跟开发人员确定最优方案，需要周知产品经理	负责每日进度的跟进，问题解决参与case评审	确定所有问题已经解决未解决的问题，整理上报确定影响的功能模块是否上线整理上线文档，合主干 merge reqest code review	配合PM进行UAT,对UAT的问题及时跟进 UAT通过后准备上线	总结会 1.做的好的 2.做的不好的，做的不好的给出Action 3.每个人都要参与，说出自己看见的整个团队的好与不好 4.抽出5条好的，和5条不好的，下个迭代改进
开发						冲刺会	输出ERD	开发对应模块参与case评审	所有功能开发完成	修改UAT问题	总结会分享
测试						冲刺会	理解需求，编写testcase	1.编写case 2.测试已经送测的功能	所有功能测试完成	测试UAT问题	总结会