近期根据我们开发团队敏捷开发项目的实践磨合，对比较传统的开发团队如何提高团队效率进而转化到敏捷开发团队，主要是结合我们团队的实际情况总结的，大家在实际过程中可以参考。
团队转化前的困境
- 团队协同比较乱
- 以项目为中心，产品经理地位不高，产品没有沉淀
- CICD自动化流水线不存在
- 人员复用情况比较严重，效率比较低
- 需求到产品及产品到开发中间断层
解决方法
- 规范软件产品开发项目管理过程。
- 开展项目研发、管理等活动。
- 构建CICD自动化流水线。
- 建立需求池，制定长期及短期计划。
- 建立需求到产品及产品到开发的标准流程。
角色及职责定义
项目负责人、项目经理
保护团队不受外界干扰，是团队的领导和推进者，负责提升 Scrum 团队的工作效率，控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化，他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念。
产品负责人、产品经理
- 确定产品的功能，拆分用户故事。
- 需求功能确定优先级。
- 需求转化成标准PRD及原型设计
- 接受或拒绝开发团队的工作成果。
- 参与产品开发过程中的有关会议。
- 参与及决策产品开发过程中需求的变更
UI设计师
- 根据用户故事，负责产品的功能交互及界面设计。
- 组织开展人机交互及用户体验，不断跟踪改进，提高产品表现力。
- 参与产品开发过程中的有关会议。
开发团队
- 根据用户故事，负责产品的技术架构设计及功能开发。
- 评估、设计及维护产品相应模块，确保模块的稳定性、易用性、高效性。
- 参加产品开发过程中的有关会议。
测试人员
- 根据用户故事，设计产品测试标准，确保产品品质满足市场需求。
- 合理分配测试资源，组织产品测试并优化测试流程及测试标准，提高测试效率。
- 编写产品测试用例，提交测试问题，编写测试总结报告，以测试角度来确定产品版本是否发布。
敏捷过程的产物
Product Backlog——Backlog 待开发项，积压的任务
产品 Backlog 包括了所有需要交付的内容，其内容根据业务需求的价值顺序排列，每个 Backlog 的优先级是可以调整的，需求是可以增减的，因此产品 Backlog 将根据不断增长来持续驱动维护。
Sprint Backlog——Sprint 本意为“冲刺”，指迭代周期，长度通常是一至两周
在 Sprint 开始前，定义本次 Sprint 要讨论的“Sprint Backlog”，从中产生本次 Sprint 要完成的 “已定 Product Backlog”。
已定 Product Backlog是 Sprint 计划会议的产物，它定义了团队所接受的工作量，在整个 Sprint 过程中它将保持不变。
User Story、Task——用户故事、任务
用 User Story 来描述 Sprint Backlog 里的项目，User Story是从用户的角度对系统的某个功能模块所作的简短描述。一个 User Story描述了项目中的一个小功能，以及这个功能完成之后将会产生什么效果，或者说能为客户创造什么价值。一个 User Story的大小和复杂度应该以能在一个 Sprint 中完成为宜。如果 User Story 太大，可能会导致对它的开发横跨几个Sprint，此时就应该将这个 User Story 分解。为了能够及时，高效地完成每个 Story，Scrum 团队会把每个 Story分解成若干个 Task。每个Task 的时间最好不要超过8小时，保证在1个工作日内完成，如果 Task的时间超过了8个小时，就说明Task的划分有问题，需要特别注意。
障碍 Backlog——问题列表，积压的待处理事务
列举了所有团队内部和团队相关的和阻碍项目的进度的问题，Scrum Master 需要确保所有的障碍 Backlog 中的问题都已分配并可以得到解决。
项目管理过程
- 需求启动
- 需求设计
- 开发测试
- 上线
- 运营跟进
总结
项目经理指导产品经理收集总结项目的产品运营数据（度量指标）及需求，产品经理对需求进行梳理及转化，同时指导团队成员从自身角色进行总结，包括测试、开发、UI等。
