原文：https://ieeexplore.ieee.org/document/8812076
脑图
论文简述
本文的领域是软件开发，本文的研究对象是产品需求列表（Product Backlog），结果是分析了敏捷开发过程的13个实践流程，6个困难风险带点，然后在理论层面给出了产品需求列表的定义，开发过程中的扮演角色，以及何时会产生需求列表。
敏捷开发过程
Balanced teams ：敏捷的团队应该由项目经理，产品经理，开发团队组成。
- Dual track agile：双轨并行
- 轨道一主要是是产品经理工作，包括识别与调查利益相关方，绘制界面示意图，编写用户故事
- 轨道二主要是开发团队工作，包括软件构建，测试，架构设计，重构，部署，运维。
- 在此之中，项目经理负责调度和制定计划，弥补两者工作的缝隙。
- Stakeholder mapping：利益相关方识别，识别那些人是利益相关方（包括用户，产品赞助商等等），以及将利益相关方进行分类。
- Interviewing：与不同类别利益相关开会讨论需求
- Persona modeling：角色建模，将系统最终用户分成为各类虚拟的角色。
- Affinity mapping：用户需求整理，整理来自用户访谈或会议的数据，以产生一些结论和全局的认识。
- Design studio ：产品设计，产品经理提出和讨论产品设计方案，在产品概念上达成共识。
- Sketching / mockups ：绘制草图和界面示意图
- Usability testing / validation testing：对界面示意图作可用性测试
- Writing user stories：编写用户故事，use case
- Story showcase：在敏捷团队中分享用户故事，是每个人理解要做的事
- Backlog grooming：对用户故事排优先级，安排开发任务
- Accepting stories：编写验收故事，确定用户故事开发后如何进行验证。
困难和风险点
- Preconceiving Problems：先入为主的问题
- Preconceiving Solutions：先入为主的解决方案
- Pressure to Converge：项目整合压力
- Ambiguity：需求含糊不清
- Time Pressure：时间压力
- Blocking Access to Users：产品不可用
Product Backlog 的理论
产品需求列表的定义：描述产品要完成的需求列表，包括优先级，工作量估计，需求的依赖关系以及详细要求。
产品需求列表的作用：产品需求列表是一个边界对象，它弥合了实际需求与实际产品的差距，是产品经理和开发团队的中间产品。产品需求列表既不是需求规范，也不是设计规范。
产品需求从那些地方产生：
需求调研时：产品经理对需求进行调研时产生需求列表，包括前面提到的与利益相关方讨论，角色建模，用户需求整理等
产品实现时：开发团队开发产品时会产生需求列表，包括重新设计需求，针对开发测试过程提出需求等。
举例：作为开发者的你，开发完整系统需要完成日志、网关、数据库配置等任务。而这些任务对于产品经理是透明的，所以就需要开发者提出这些需求加到排期中。
产品经理与开发团队间的交流（学术名词为边界跨越）：意思时在产品经理与开发团队介绍用户故事、验收故事时，可能产生新的事项需要去做。
举例：作为开发者的你，发现产品经理给的产品设计漏洞百出，或者根本不可能实现。你对其方案进行猛喷，迫使产品经理修改需求或者增加排期
评价
优点
- 全面的介绍了敏捷开发过程的各个实践过程，对没有相关经验的同学是很好的入门引导文章。
文中描述的敏捷过程与实际敏捷开发过程较为符合，有实际工作经验的同学比较容易理解其中的概念，借此可以提升理论水平。
- 在理论层次对产品需求列表的定义，角色，由来进行了分析，并给出了令人信服结论。
缺点/改进
- 缺少具体案例，有点空中楼阁的味道。如果可以加入更多更详细的具体案例分析就好了。