Devops-敏捷团队开发流程

近期根据我们开发团队敏捷开发项目的实践磨合，对比较传统的开发团队如何提高团队效率进而转化到敏捷开发团队，主要是结合我们团队的实际情况总结的，大家在实际过程中可以参考。

团队转化前的困境

1. 团队协同比较乱
2. 以项目为中心，产品经理地位不高，产品没有沉淀
3. CICD自动化流水线不存在
4. 人员复用情况比较严重，效率比较低
5. 需求到产品及产品到开发中间断层

解决方法

1. 规范软件产品开发项目管理过程。
2. 开展项目研发、管理等活动。
3. 构建CICD自动化流水线。
4. 建立需求池，制定长期及短期计划。
5. 建立需求到产品及产品到开发的标准流程。

角色及职责定义

项目负责人、项目经理

保护团队不受外界干扰，是团队的领导和推进者，负责提升 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 中的问题都已分配并可以得到解决。

项目管理过程

1. 需求启动
2. 需求设计
3. 开发测试
4. 上线
5. 运营跟进

总结

项目经理指导产品经理收集总结项目的产品运营数据（度量指标）及需求，产品经理对需求进行梳理及转化，同时指导团队成员从自身角色进行总结，包括测试、开发、UI等。