熊节；极限追问 041

【验收条件怎么写？】

背景：开发人员希望业务代表讲清楚验收条件是什么。业务代表却经常会说：你们是技术人员，你们要帮我想清楚才对。

分问题1:验收条件应该由哪些人来写？

分问题2:在编写验收条件的过程中，每种人分别应该贡献什么？

罗磊

熊节；极限追问 041

【验收条件怎么写？】

背景：开发人员希望业务代表讲清楚验收条件是什么。业务代表却经常会说：你们是技术人员，你们要帮我想清楚才对。

分问题1:验收条件应该由哪些人来写？ 验收条件个人认为应该由需求提供方来写，如果需求团队无法撰写，则可以由聆听需求的那个人写好归纳，起到桥梁作用，但一定需要得到需求提供方的确认。 验收条件即是一种需求预期结果的表述。

分问题2:在编写验收条件的过程中，每种人分别应该贡献什么？ 业务方： 提供需求，作为验收条件的基本参照 项目管理者： 成为业务代表与技术团队的桥梁，承担起需求文档（口述需求）到验收条件的转译，需要的时候直接编写验收条件并与各方沟通 测试人员：在我们团队，通常业务方与项目管理者沟通需求时进行整理，并据此编写验收条件，最后在产品完成或者阶段性完成时进行验收测试，并将最终测试结果输出给业务方与开发人员 开发人员： 按验收条件编写程序，在实现过程中对不合理的验收条件，或者验收条件中存在的瑕疵提出建议与问题

陈旭

熊节；极限追问 041

【验收条件怎么写？】

背景：开发人员希望业务代表讲清楚验收条件是什么。业务代表却经常会说：你们是技术人员，你们要帮我想清楚才对。

分问题1:验收条件应该由哪些人来写？ 理想情况是大家坐下来一起写，需求方，BA，开发人员，QA，等等。现实状况一般没有这么乐观，即使坐在一起，往往也是打太极，这种会一旦有正式的会议记录，出口即责任，有经验的同志们经常避而不及。

分问题2:在编写验收条件的过程中，每种人分别应该贡献什么？ 因为是内部项目，我们刚开始没有详细的验收条件，需求方描述完基本需求后，开发团队进入短迭代，提供MVP交付。需求方往往也是看到交付物后，才进一步的明确他们自己的真实需求。讲到，关于编写验收条件每个人的贡献，我认为是尽量高频次的参与沟通，从自己的职责角度提出问题，澄清问题，所有人参与讨论，达成共识。随着时间的推移，完善和细化验收条件。 不过，合同制的项目可能并不太适用这种做法，因为评估工作在这种情景下很难立项初期就精确，经济效益无法衡量，没有成交基础。

Page

【验收条件怎么写？】

背景：开发人员希望业务代表讲清楚验收条件是什么。业务代表却经常会说：你们是技术人员，你们要帮我想清楚才对。

分问题1:验收条件应该由哪些人来写？

BA、DEV、QA三个角色都会参与验收条件的编辑。

在经历的项目中会有两种实践：

（1）BA预先写好AC，DEV, QA补充

在Kick-off前，Dev会提前了解一下Story的信息和AC，Kick-off时，由DEV向BA、QA描述清楚这个Stroy是在描述什么业务需求，以及AC分别是什么。BA、QA给出反馈，形成共识，确保能够DEV开发出来的都是客户期望的。

（2）一起写AC。

kick-off时，BA介绍清楚Story的内容，BA、QA、DEV一起编写AC。

在Kick-Off前、中、后，BA、QA、DEV倘若发现有遗漏的可以沟通后确认后补充AC

分问题2:在编写验收条件的过程中，每种人分别应该贡献什么？

BA描述业务需求，并解答其他两个角色的问题，确定边界。

DEV站在开发角度，提出问题确认自己是不是理解了业务需求，以及某些情况是不是在该Story的关注的，确认自己要开发的共识是符合业务需求的。

QA站在质量视角，确认该Story的业务需求的范围，以及功能质量上的场景补充。

当出现三个角色都确定不了的情况是，需要BA在去确认，最后是决定是在该Stroy的功能还是另一个Story要实现的业务需求。

夏天

熊节；极限追问 041

【验收条件怎么写？】

背景：开发人员希望业务代表讲清楚验收条件是什么。业务代表却经常会说：你们是技术人员，你们要帮我想清楚才对。

分问题1:验收条件应该由哪些人来写？ 业务代表和开发都说不清楚，那就坐下来一起写。写验收条件的过程，本身也是进一步澄清需求的过程，一起写可以加强沟通协作，不写出来不准走。 分问题2:在编写验收条件的过程中，每种人分别应该贡献什么？ 业务代办可以贡献应用场景，客户偏好，用户画像分析等；开发可以贡献逻辑思维，对条件分支进行分析，对异常情况进行分析。