标签：需求 Product 迭代 我司 Scrum 测试人员 丢失 不易

Scrum不是敏捷的全部，它只是敏捷的一个落地方法之一。

Scrum就是3355。

什么是3355？

第一个3代表3个角色，即Product Owner（产品负责人）、Scrum Master 和 团队；

第二个3代表3个工件，即Product Backlog（产品待办事项列表）、Sprint Backlog（迭代待办事项列表）和 Product Increment（产品增量）；

第三个5代表5个事件，这也是大家感受最深刻的，即Sprint Planning（迭代计划会议）、Daily Scrum（每日站立会议）、Sprint Review（迭代评审会议）、Sprint Retrospective（迭代回顾会议）、Backlog Refinement（产品Backlog梳理会议）；

第四个5代表5个价值，即承诺、专注、开放、尊重和勇气；

我司并不按照此方法执行。

6 我司执行的敏捷流程
6.1 特点：迭代式开发
每次迭代都必须依次完成以下五个步骤。

需求分析（requirements analysis）
设计（design）
编码（coding）
测试（testing）
部署和评估（deployment / evaluation）

6.2 任务管理
6.2.1 需求管理
PO(Product Owner): 产品负责人，核心是产品，提需求者可以是产品经理，项目经理，测试人员(适用我司)，最终用户，集成商，代理商；

现代化需求：需求变更快，早上提了，下午就改，敏捷是为了更方便地变更需求，我司非常适用敏捷式开发。

需求管理：关键是要写下来，写到统一的品台teambition里去。写的过程，考虑问题会全面，能溯源。需求文档和开发的代码一样，都要有完整的历史记录，能够追溯到何时什么人做了什么修改，这样可以追责到每一次需求变更。

6.2.1.1 一次具体的需求管理
什么时候开始？
什么时候结束？
负责人是谁？
完成之后交付给谁？@
需求生命周期，全周期覆盖，需求的状态管理

何为全周期？即需求全部状态的流转以及停止流转。

状态的定义添加

6.2.2 缺陷管理
缺陷即bug, 由测试人员经过测试案例之后，建立，指派给之前完成任务的对应开发人员，开发人员手头工作繁忙，向组长反馈实际情况，再由软件组长指派给其他开发人员。

指派流程很重要@
测试人员很关键
反馈很重要
软件组长需要统筹规划
根据优先级安排任务
一次缺陷的修复成为迭代
6.3 统一的管理工具
我司采用TeamBition平台

全周期
需求，开发，测试，缺陷修复，迭代全覆盖
高效
任务燃尽图，项目状态，成员分工职责一目了然，减少沟通成本
积累
相关文档随项目归档，不易丢失，适合新同事切入
任务看板
使公司领导层，产品，团队对整个任务状态及其周期全部可视化
DevOps
结合CI/DI，产品经理，项目经理随时能看网页，随时能修改需求，提高迭代次数，减少沟通成本。给出访问url
代码
给出gitlab url
由测试人员设置完成。并且所有通知信息可由teambition手机App通知。

6.4 角色
– 产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，同时有权力接受或拒绝开发团队的工作成果。

– 流程管理员（Scrum Master）
使得每一时刻的需求都能明确，管理每一次需求变动，变动原因，将变动落实到实处。

–开发团队（Scrum Team）
根据任务优先级编排任务

–测试人员
需求明确完之后，即可针对需求编写验收文档。测试过程，编写测试案例。

标签：需求,Product,迭代,我司,Scrum,测试人员,丢失,不易
来源： https://blog.csdn.net/m0_54080025/article/details/111876822

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。