Scrum & Jira 使用问题记录
Scrum 结合 Jira
Story
- Story的时间不能超过3天的时间。如果超过了三天，先拆解。
- 技术Story和Story必须拆分subtask，估时和工时在subtask上填写
- 所有的Story需要关联需求。
- 处于”测试中“单： 根据测试种类处理
- ”开发人员测试“ ， 创建测试subtask， 开发人员部署测试环境，开发自测接口， 测试完成后”点击测试通过“
- ”无需测试“， 开发人员直接点击”测试通过“
- ”测试人员测试“， 开发人员跟测试人员沟通测试完成时间，并跟进，直到测试人员完成并点击”测试通过“ ； 当测试人员无时间测试时，开发人员改为修改subtask的assignee为自己，并自行测试。
- 处于”验收中“， 可通过GT 找BA或者Leader进行验收。
- 当jira单处于”Done“完成状态时，可以不用做任何操作了，如果上线，联系leader创建运维单。
- Story的时间超了，怎么处理？
- 在原来的Story的subtask上log上超出的时间。前提是这个subtask确实需要花这么时间。
- 新增subtask，在新的subtask上log上时间。 前提是这个Story里还包含了一开始并没有考虑到其他的子任务。
- 新增Story，前提是存在一种情况，时间评估差距很大，这个Story的完成需要依赖于其他的Story。
Subtask
- 不创建无关的subtask
- Story状态是否需要更改 是根据subtask完成情况来定
- BA或者Leader对Story宣讲完成后， Story状态更改为 ”待开发“
- DEV对Story以及subtask有了解清楚并没有疑问后，Story状态更改为“待开发”
- subtask已经开始开发了，Story状态更改为“开发中”
- subtask里开发工作已经完成，Story状态更改为”待测试“
- subtask都完成后，Story状态更改为”待验收“
通用
- 使用明确的形容词， 避免使用类似如下形容词 ：
- “相关的”
- “ 部分
- “
- 每日 log work。（如果你做不到每日更新，可以至少两天做一次更新）
- Sprint 启动后 jira 单（技术 Story+Story）的增加修改删除由 scrum master 来操作， 勿擅自操作。
- 周中会议前更新会议内容
- 不管是 Story、技术 Story、运维单还是 BUG 单，找 reporter 验收。
- 为什么 Story Owner 找 reporter 验收？ 正常逻辑是我做完了改状态就 OK 了，才符合流水化作业。
- 不做的单 拒绝
- Jira 单拆分时并不了解需求。
Sprint指标
Sprint不仅仅有完成率的指标，另外还有更多的指标可以了解Sprint的状态
- 迭代变更率： = 插入和移出任务数、计划任务数 * 100% （任务数仅限：story + Tech Story）
- 迭代投入比： 迭代工作投入比 + 运维投入比（Jira 总投入时间 / 团队总数108）
- 需求积压：
- 平均开发周期：Story、Tech Story 在看板中启动开发到完成所耗的平均天数
- 迭代逾期关闭
运维
类似“线上问题和故障”
每天都会在产品和研发群发布”线上问题日报“， 以报表形式展示每个业务团队的问题存量，以及这些问题的持续时长 — 来自有赞
针对运维单的问题，可以同样的思路来处理。运维单不处理最终积压的问题会在某个时刻点爆发。
TODO: 如何整理出这样的报告？
Bug 管理
“Bug 看板”中统一管理
Bug 流程
测试 Bug 必须关联到 Jira 模块、影响版本和解决版本， 我们可以根据“模块”和“经办人”来统计某个版本中遗留的测试 Bug 存量分布。
Bug 描述标准模板
重现步骤、实际结果、期待结果、抓包数据
复盘
使用“海星图”， “KISS”或“做的不错的 / 应该做的更好的”方法进行复盘 ，复盘的改进措施会被录入到“复盘 Action 跟进看板”， 每个 Action 必须是可执行的具体措施，且有一个主要负责人（JIRA 经办人）和完成日期（JIRA 到期时期）。
Scrum 之星
激励动机，利出一孔
- 即时激励四个原则
- 提倡什么，反对什么
- 注重精神激励，同时兼顾物质激励，前者为主
- 及时给员工反馈
- 公开透明、有理有据、有事实
定位
PM (Program Manager)
负责的事情有：
- 和客户交谈，组织用户调查，发现用户需求
- 了解和比较竞争对手的产品
- 怎么让软件变得可用 (Usable)、有用（Useful）
- 怎么改进团队的流程
更全面的任务有：
- 带领团队形成团队的目标 / 远景，把抽象的目标转化为可执行的、具体的、优美的设计
- 管理软件的具体功能的生命周期（需求 / 设想 / 设计 / 实现 / 测试 / 修改 / 发布 / 升级 / 迁移 / 淘汰）
- 创建并维护软件的规格说明，让它成为开发 / 测试人员及时准确的指导，而不是障碍
- 代表客户和用户的利益，主动收集用户反馈，预期用户新的需求。协调并决定各种需求的优先级
- 分析并带领其他成员形成对缺陷 / 变更需求的一致意见，并确保实施。
- 带领其他成员确保项目保持功能 / 时间 / 资源的合理平衡，跟踪项目进展，确保团队发布让客户满意的软件。
- 收集团队项目管理和软件工程的各种数据，客观分析项目实施过程中优缺点，推动项目成员秩序改进，从而提升士气。
PM 做开发和测试之外的所有事情
Program Manager vs Project Manager
| Project Manager | Program Manager |
|---|---|
| 是团队的行政领导者，带领大家在项目中工作 | 和大家平等工作，推动团队完成软件的功能 |
| 通常是团队外和外界打交道的唯一代表 | 一个团队可以有很多的 PM |
| 对项目的功能有最后的决定权 | 和其他团队成员一起大形成决议 |
| 管事也管人 | 管事不管人 |
| 不一定做具体的工作 | 一定做具体的工作 |
为什么不让 PM 领导开发和测试人员，这样 PM 工作起来不是更梳理“ ?
如果 PM 得到团队成员的支持，会是怎样的呢？
成为项目流程的主人 — 驱动流程，组织会议，实践 Scrum，保证进度；代表团队向上级 / 伙伴团队 / 客户 / 市场部门报告项目进度；团队成员都乐意和你交流，你赢得了大家的尊重；你不用自己写一行代码，也同样可以积极影响项目和产品。
反之， 如果得不到团队成员的支持？
你会在各种会议或流程中浪费大家的时间，发一些大家不读的 Status Mail， 不能凝聚团队，形不成共识；你对团队的状态不太了解。也不能有效和准确的像有关方报告团队的情况并获得支持；你对行业和产品的发展方向把握不准，对项目和产品造成负面的影响。
软件设计和实现
从 Spec 到实现
一个开发人员拿到设计文档 (spec) 之后，他会做下面几个事情。
- 估计开发任务所需的时间
- 会试着歇一写快速原型的代码，看看效果会怎样。期间发现了若干问题，与 PM 沟通后，最终达成了一致意见。
- 在看到初始效果和了解实现的细节后，开始写**设计文档（Technical Spec、Design Document），写好之后，可以请同事一起来复审设计文档（复审可选，因为一般情况下任务都不大）
- 设计文档写好之后，按照设计文档写代码。在实现过程中，他又发现一些意想不到的问题，与 PM 沟通后，找到了解决方案。
- 写好代码后，对照设计文档和代码指南进行自我复审，重构代码。
- 创建或者更新单元测试
- 进行单元测试（不仅要自己创建或更新单元测试，还要通过整个模块或者系统的单元的测试）
- 得到一个可以测试的版本，交给相关的测试人员测试，或者在网上进行公开测试，如 A/B 测试等。
- 修复测试人员或者用户发现的问题，等到问题都被解决得差不多了，在请同事进行代码复审。
- 根据代码复审的意见修改代码，完善单元测试和相关的文档，然后把代码签入到代码仓库中。
Testing Process in Scrum
敏捷测试在实践中出现两种声音：
- 将测试与 Sprint 分离， 看做是与开发截然分开的“下一个阶段”
- 测试作为 Sprint 的一部分，当 Sprint 结束时所有的测试工作也结束
前者带来的问题
- 导致在实践敏捷开发过程中遇到种种问题： 要么是忽略了代码质量，导致在频繁的迭代过程中，每个迭代的问题层出不穷；
- 沿用原有的方法安排对系统的系统测试，导致测试团队疲于奔命，却总也赶不上开发所要求的的进度。
什么是敏捷软件测试 #TODO
敏捷开发中不把测试单独拿出来描述的原因，恰恰是在敏捷开发中，测试不再是一个单独的，和开发独立的过程，而是变成了驱动开发、衡量产出的主要手段，成为敏捷开发中所有工程师在工作时必须时刻考虑和实践的一个部分。
敏捷测试是基于自动化测试的
详细Scrum的敏捷测试。
- Product Backlog, 测试需要考虑客户的价值大小（优先级）\工作量基本估算外，需要认真研究与产品相关的用户行为模式，产品的质量需求，哪些质量特性时我们需要考虑的？
- Sprint Backlog， 需要明确具体要实现的功能特性和任务，作为测试，这个时候后特别关注“Definnition of Done”， 任务完成的验收标准。
- 在每个Sprint实施阶段，主要完成完成Sprint backlog所定义的任务，这时出了TDD或单元测试之外，应该进行持续集成或者通常说的 BVT （build virification Test)。 如果有专职的测试人员角色，一方面可以完成测试用例、集成测试框架，协助开发人员进行单元测试；另一方面可以按照针对新视线的功能进行更多的探索式测试，同事开发验收测试的脚本。如果没有专职的测试热源角色，这些事情也是要完成的。只是由整个团队来完成。
- 验收测试可以自动化测试工具万恒，但一般情况，不可能做到100%的自动化测试。
来自 Best Practices for Testing Process in Scrum
In Scrum, a cross functional Development Team has all the resources needed to complete a ‘Done’ Increment by the end of a Sprint.
Solution One
Breaking each selected product backlog item into many small subtasks which can be devlivered and tested.
Taking the help of testing team during integreation testing itself
the testing team starts writing test cases based on each task.
testing team helps dev team during the integration testing and they test each sub-story deployed in test enviroments.
Solution Two
Testing should be factored during sprint circle
As per definition Development Team are cross functional team and they should be able to test the solution, during the sprint cycle.
Solution Three
QA Team write test cases accourding to Acceptance criteria DoD for each Story
so Dev Team will take the responsibility of the testing for each cases in the story.
Test Cases will be part of DoR for the story
问题：
- 每个迭代里， 开测试计划评审会议， 产生测试计划文档并得到批复的话，将会是一笔非常大的管理开销，而且每个测试计划的重复信息都很大。
- 缺陷追踪实践，记录版本的时间长，修改这个问题可能几分钟搞定了。
- 迭代开始时，测试人员却很空，空的无事可做，到了迭代结束的时候却是忙的不得了。
解决：
- 开发项是新提出的概念，将软件的规格说明书撰写、设计、实现和测试封装在一起，作为最小的原子化产品组件（Component）。原子化的意思是保持开发项之间的互相依赖在可以做到的最低水平；移除或重排任何开发项的时候，对其他开发项不产生（或产生最小的）影响。
- 在迭代开始前，先有技术报告或需求文档，由此而产生出开发项；然后是和以往的项目一样的入口阶段，确实项目日程并且生成相关的高阶文档，包括集成计划文档，项目计划文档，模块测试策略以及开发测试计划文档都在此时创建。
- 所有开发项相关的测试活动都在 Sprint 内完成，这些测试被称为 DIT（开发项测试），测试用例本身还是属于以往的功能测试级别。但是开发项的测试计划、测试执行、报告等一些列过程全部都要在一个 Sprit 中完成，测试用例的自动化比例未做硬性规定
- 项目成员主要分为开发和测试两类工程师，但是角色的定义并不是拿来当做不可以逾越的红色使用，必要的情况下，开发工程师也可以承担部分测试任务甚至整个人投入测试，或者测试工程师也会与开发一起，结对开发代码。
- 开发人员的工作安排会受到测试工作的影响，每日站会或者平时工作中，可能会发现软件不容易测试，就需要开发人员协助检查以及修改代码提高软件的可测试性。
参考
The Role of Automated Build Verification Test (BVT) in Agile-DevOps Methodologies
<现代软件工程构建之法> by 邹欣