产品需求到开发需求-南通*通活性碳纤维有限公司

产品需求到开发需求

发布时间： 2022/7/22

　　我们已经把用户故事拆解到了适合开发的大小，把这样大小的用户故事交给开发团队，是可以指导开发的。问题是，这样的用户故事对于成熟的开发团队、经验丰富的开发人员或者说对这种敏捷开发方式比较熟悉的开发人员来说，是足够作为开发的依据的；但是，对于成熟度术高的开发团队来讲，需要将产品需求中拆解过的用户故事再转化为开发需求。
　　我们前面也说过。一个用户故事只是以用户能够明白的方式，描述了一个系统的外在行为，它完全忽略了系统的内部动作。”“用户故事中不要提及任何有关数据库、记录、字段之类的对用户一点意义都没有的东西”，而开发需求中就要关注。系统内部动作”“数据库”“记录”“字段。等因素，以便开发人员对所开发的功能有统一的认识和接口一致性。所以，开发需求是将产品需求与具体的开发技术结合起来的产物，这个过程在职责划分清晰的公司中，往往是由负责产品开发的项目经理或技术经理来做，而不是产品经理来做这个转化。
　　我们来举个例子。产品需求中拆解好的一个用户故事可能是这样描述的：作为一个运维工程师，我希望所使用的数据采集与监控系统具有记录功率因数的功能，以便更好地了解电能质量的相关参数。而开发需求可能这样描述：数据采集与监控系统具备记录功率因数的功能，功率因数每1小时被写入数据库1次，写入格式采用ComTrade格式，数据库至少保存1年内的功率因数记录。
　　可见，开发需求更多地采用了“开发人员的语言”来描述某个功能的实现需求，而产品需求中的用户故事更多地从用户角度反映需求的由来、背景和价值。显然对于开发人员来说，开发需求更能够指导开发的进行奋除菲开发团队的人对这些技术细节已经心照不童并且对驾驭这些用户故事中的技术背景轻车熬路，否则我还是建议针对开发团队还是要根据产品需求拆麓避开发需求。所以，很多即使是使用敏捷开发流程的团队，除了要写产品任务测表（Product Backlog)这个文档(产品任务列表文档是产品需求文档的一种)之外，还薹写一个技术任务列表(Technical Back均)文档，这样做就是为了将产品需求拆解为技术需求以便于指导开发。
　　有的开发圈队使用敏捷流程的成熟度并不高，团队成员的技术能力也并不是很好，仍然直接使用产品需求中的用户故事作为驱动开发的直接来源，并且开发工作也运行得不错，是不是说这从一方面印证了将产品需求转化为开发需求是多余的呢?其实这样的开发团队使用了一种将产品需求与开发需求结合在一起作为开发驱动的方式——他们在用户故事上添加了“技术验收标准”。然后把这样的一个“用户故事”作为指导开发的任务包。比如，对于上面举过的例子，他们用来指导开发的“用户故事”是这样写的，有以下几点。
　　1．用户故事：
　　作为一个运维工程师，我希望所使用的数据采集与监控系统具有记录功率因数的功能，以便更好地了解电能质量的相关参数。
　　2．验收标准：
　　(1)功率因数每1小时被写入数据库1次。
　　(2)写入格式采用ComTrade格式。
　　(3)数据库至少保存1年内的功率因数记录。
　　看到了吗?对比将产品需求中的用户故事转化为开发需求(“数据采集与监控系统具备记录功率因数的功能，功率因数每1次、对被写入数据库1次，写人格式采用 ComTrade格式，数据库至少保存一年内的功率因数记录。”)的方式，其实什么也没缺。其实这种写用户故事的方式并没有省略将产品需求转化为开发需求的过程。