sprint敏捷开发,敏捷开发sprint和story

敏捷开发中的sprint是什么意思

sprint[英][spr?nt][美][spr?nt]

vi.冲刺，全速短跑;

n.全速短跑; 速度或活动的突然爆发;

第三人称单数：sprints过去分词：sprinted复数：sprints现在进行时：sprinting过去式：sprinted

例句:

1.

One is its monthly calling plan from sprint.

一个是sprint的月话费计划。

2019-10-17 scrum敏捷开发流程梳理

TB项目规则：

1. 每个团队默认会有2种类型的项目，1）user story 2) Development Task项目 （两种项目内的任务写法见图）

2. 我们采用2周为一个迭代，每个迭代每个团队都会创建一个user story项目以及Development Task项目

3. 一个迭代项目内的任务可以有不同的发版时间，但必须在这一个迭代内（2周）发布完成

TB任务规则：

1. user story 内的每个任务必须是一个最终可以被QA 测试 以及最终用户使用的功能点

2. 一些比较小或者零散的任务，也可以写成一个单独的user story 任务然后关联对应的开发任务。

3. 每个user story任务都需要通过关联附件，或者备注链接的方式把需求写明

4. 每个user story任务都必须有开始和结束时间

TB QA测试规则：

1. QA 测试过程中报出的bug，在user story项目里创建bug任务并关联。QA不需要在Development Task项目里创建任务

1. 头脑风暴 会议（基本针对比较大的需求）：

** 风暴产品需求，实现方案，可行性，确定owner 及 大概可以进入的Sprint灯**

** 参与者： 产品， CTO，架构师**

2. 需求沟通会（多次）

** 由产品与owner，QA进行需求的沟通，私下里约会议，可能多次**

** 注意：建议在每个sprint 第二周的周三，周四之间进行沟通，因此第一版本的PRD 需要在这个时间就有**

2. 正式 Planning meeting

** 每个sprint的planning meeting必须在每个sprint第一周开始前召开结束（建议是每个sprint 第二周的周五）。召开会议的前提条件是 PRD 定稿，定稿的标准：**

** - 对涉及到页面的需求，需要mockup并配有文字描述**

** - 对异常逻辑的分支需求的描述**

** - 涉及到导入导出的模版描述**

** - 没有还需要确认的关键节点的疑问**

对不能定稿的产品需求，不考虑进入Sprint开发

** 参与者： 产品， Owner，QA，（ 产品， CTO，架构师 随机）**

** 会议目标：了解需求以备拆分User story**

** 确定优先级，**

** 依赖性，**

** 风险，**

** 确定测试环境，**

** 确定开发提测时间，**

** 确定是第一周的周四还是第二周的周四上Stage**

Planning meeting****的产出：

- 所有研发都已经把任务拆解到****3manday****之内，且****owner****完成该迭代甘特图。

- ix****环境已经分配完毕。

- planningmeeting****之后的****3****天内，****test case review****需要被完成，****smoke case****和****test case****都被产出。

对PRD 的格式有一些需求

- PRD 统一上传到Confluence

**- PRD 建议有统一的格式（现在有 PDF，Axure，Confluence wiki 甚至图） **

- PRD 需要进行版本管理 （文件名上带日期，每更新一次一个新的文件）

1. Ix 环境作为开发环境，在每个sprint开始前做 刷新以及DB restore （CMS 以及 Magento DB）

2. 原则上，每个业务团队会有属于自己的一个专有开发环境。开发环境由owner自己维护需要部署服务的分支以及tag。

3. Stage环境在一个sprint里默认有2次发布机会，****每周周四****。理论上stage环境的占用不应该超过1天，也就是当天上stage的功能，当天上生产环境。平时stage都保持和生产一致以备hotfix

TODO // 默认状态

Dev In Progress // 开发中

Dev Done

//前端：页面开发完成，与后端接口在IX环境整合完成

QA In Progress // QA在Ix 环境测试

QA Done //Ix 测试完成，可以发布Stage 环境

Done // Go live

[Scrum敏捷开发之] Sprint评审和回顾会议

Sprint最后包含两个部分：

最后一点常常被忽略。有时Sprint评审会被误以为是另一个演讲机会。“看看我们做了多少伟大的工作……PowerPoint…”这不是客户或stakeholder希望看到的。他们想看真正的产品!

如何进行优秀的Sprint评审会：

有了一个很棒的Sprint评审和许多积极的反馈以后，是时候把这些积极的能量带到Sprint回顾会中了。

执行”回顾会“给团队带来的好处：

就像在Sprint计划中一样，执行Sprint回顾的最佳方式是玩游戏。这被称为 "Retro Game"

敏捷团队的内心可以通过优秀的回顾和审查变得更加强大。然而，在一开始，这种做法会让那些身处言论文化不太开放环境的人感到尴尬。这正是采用游戏方式的原因，也是Scrum Master需要成为一个伟大的推动者的原因。

这个过程的核心应该是团队建设。 这就是为什么还有一个步骤经常被遗漏，但却非常需要的原因：

整个团队走出办公大楼(或区域)，一起做一些社交活动。

如果有什么需要记住的，那就是我们都是这个团队的人。 这正是关于“个体和交互 重于 流程和工具”。 当你在冲刺仪式结束时，奋力冲刺的冲劲和潜在的疲劳感就会慢慢消失。不要让惯性或者说惰性占上风。摆脱它，运行伟大的，个人的回顾和评审，尤其要尊重个体。

很快，你就会有一个高效的团队，喜欢他们每天工作的方式，以及与他们一起工作的队友。

我对于敏捷式开发的经验分享

1、敏捷开发的定义

敏捷式开发，其具体表现方式，是一种工作方法，其真正的精髓，是在互联网行业快速迭代发展的环境中，团队内部形成的一种行为意识上的共识。

2、工作方法

敏捷开发中，我们通常把一个敏捷开发的小组称为scrum团队，scrum单词源于争球游戏，本意是一支小规模的精干团队，不断争取胜利的含义。

一个完整的scrum，通常能够在不依赖外部资源的情况下，独立完成一个需求的上线，故在组建scrum团队时，需要充分考虑到团队所负责的领域内，需要哪些职能的资源来组成。

举例，某个负责app平台的scrum团队，通常需要由以下资源来组成：

此处的项目，是指jira平台中的项目，而非实际工作中的需求类项目，应理解为一个domain，一个负责的领域更为恰当。一个scrum团队，建立一个独立的jira项目，专注于某个领域内的产品迭代及优化，该项目专属于本scrum团队，其保持一定的独立性，减少与其他团队的互相干扰及耦合度。

产品经理（PO）需要随时记录来自各方的需求或待改进事项，通过统一纳入需求池的管理方式，实现需求的有效管理，防止遗漏，并可以根据实际资源情况进行对应的优先级评定和实施管理。

在一个sprint迭代过程中，通常包含需求计划会，每日站立会，推进需求进度并及时更新看板，定期回顾总结及优化等主要流程环节；

站立会

看板

在sprint迭代结束前，我们通常会通过开一个回顾会的方式，来总结本次sprint迭代过程中，做的好的，以及做的不足，保持好的，弥补不足，持续优化，同时针对本次迭代中的成果进行展示，鼓舞团队士气；

3、敏捷迭代的标准流程

4、角色的定义

在敏捷团队中，SM的角色至关重要，通常SM由我们的pmo（product managerment office，pmo是一个组织，或部门，而非个人，个人的定义为pm）来担任居多，但并不完全限定于pmo。

SM是敏捷开发团队中，为小组成员提供各类支持的角色，同时承担部分项目管理的工作职能。SM在scrum团队中更多扮演的是教练的角色，通过帮助成员获取、了解工作的事实情况，服务团队，帮助团队解决困难及问题，引导团队用正确的方法做出正确的决策，在不断在sprint迭代中，帮助团队在负责的领域内，不断成长、精干，并将团队所负责领域内的产品，做的更好。在敏捷开发中，SM更多是老师的角色，而并不是领导者角色，他并不承担决策义务，团队和PO是真正的负责人。

在敏捷团队中，PO通常由产品经理（PD/PM）担任。

PO负责管理scrum团队所负责的领域内，所有的需求的收集、整理、优先级评定、分析、设计、评审、跟进的工作。PO带领着scrum团队，对所负责的领域内的工作成果进行负责。

5、敏捷式开发的主要特点

敏捷开发不同于传统的瀑布式开发，在敏捷的工作方式中，我们以某个时间周期（通常是2周）来作为一个计划。而通常我们采用的瀑布式开发，其典型特点是以项目制，或者需求制方式进行开发，当需求产生时，进行严格的开发流程推进对应的工作（需求评审，开发架构评审，测试用例评审，开发，测试，……上线）

敏捷式开发并非抛弃传统瀑布式开发过程中的标准环节，我们仍然遵循需求评审，架构评审，测试用例评审这些必要的流程，但我们是以固定时间周期来进行这些对应的工作，而非针对项目或者需求；

敏捷开发的过程中，团队需要实现的需求，通常都缺乏标准特性，需求的规模大小，属性类型，均有非常大的不确定性，通常固定式的开发流程并不能时时套用。所以在实际工作中，敏捷开发团队会根据实际的需求特性，进行对应的流程分析，根据对应的流程，拆解出对应的子任务体系，通过子任务的分配，实现快速的响应效率；（而在实际工作中，我们可能突然会发现需要在中间插入一个工作事项，在敏捷的工作方法中，我们只需要临时建立一个子任务即可，而不用将整个需求进行工作流程的切换）

敏捷开发中，非常重要的一个工具就是看板。看板源自于日本丰田汽车的精益生产理念，在看板中建立4个工作状态（待处理、进行中、待验收、完成），每一件子任务都与之相对应。通过看板的使用，便于整个scrum团队对于各位成员间的工作状态做到了如指掌以及实时响应，这种方式，尤其在scrum团队这种高度默契的组织中非常适用。

对于需求管理的极致性。通过jira的backlog管理，我们可以将所有的需求，事无巨细地进行收集和管理；

结构化思考。每一项需求的实现，通过结构化思考的方式，去拆解对应的子任务，不断提升团队的配合默契以及战斗力

信息同步及透明。通过需求管理的全面记录，优先级的唯一性，工作状态看板，可以让所有相关协同部门的成员，都能快速掌握所需的信息，并能够及时发现过程中的问题，实现快速响应及解决

需求变更的常态化。互联网企业的需求，变更的情况时有发生，敏捷式开发的过程中，快速响应机制可以快速匹配市场的需求，而真正因为工作不到位导致的需求变更，在持续的迭代过程中，会通过总结改进、以及团队结构优化等方法，实现持续优化；

[Scrum敏捷开发之] Sprint开发过程详解

首先，讲解下Sprint开发过程的一些原则：

当仔细思考这些原则的时候，将会看到Agile宣言渗透其中。接下来详细讲解每一原则。

请注意，这些技术中有许多是从精益方法中借来的，特别是WIP的看板。这是因为一旦故事计划好了，团队就应该像一台运转良好的机器一样运转。因此，持续改进和减少浪费的目标在此也绝对适用。

然而，Scrum与众不同且保持敏捷的一个关键方面是，产品负责人在团队中，他们可以增量地接受工作。另外，Sprint Backlog对所有人完全透明地显示了团队在Sprint结束前必须完成的工作，开发团队可以根据Sprint的需求来管理他们的时间。这些故事结合在一起形成了一个有意义的、可交付的产品增量。

正是基于这些原因，敏捷为开发团队提供了可持续性、目的性、掌控性和自主性，而不是纯粹的精益方法。这些要素已被证明是最能激励知识型员工团队的。

[Scrum敏捷开发之] Sprint 计划会议详解

Sprint计划会议有三个关键步骤:

但是，为了确保这些目标的确切的达成，需要确保下列工作:

为了正确的实施，团队必须要避免：

做好Sprint计划的关键有两个方面:

优秀的用户故事编写意味着SM和PO需要共同合作来确保质量， 尤其是当团队有了一个新的产品负责人，而他之前没有在Scrum团队或这个Scrum团队中工作过时，这一点更加重要。

规划游戏的使用是必不可少的，因为它有助于促进和激发团队的创造力。通常这时许多团队会问，“为什么不只是谈论用户故事本身呢?”不使用“开放讨论”的关键原因:

这就是在Scrum中使用Games的原因，最通常使用的是 扑克牌游戏 。

扑克牌游戏 规则的关键规则可以参考:

这个过程用于完成三件事:

很多时候，对于如何确定一个 point scale 存在分歧。有正当的理由相信，尤其是当团队成员或团队之外的管理人员误用Story Point时。以下是一些需要考虑的要点：

请注意，在是否Story Point应该是绝对的度量标准方面，许多“规模化框架”对此有争议，或有偏差，亦或认为应该在跨团队时仍保持一致。对于Scrum和它的变更来说，这并不重要。Story Point仅仅是为了帮助团队了解可以完成多少工作，以及团队是否在一个又一个Sprint中变得更快速。

最后，在Planning会议中还有一些额外的事情需要考虑:

通过遵循这些指导方针，你的计划将比任何小组讨论或面试过程更快速、更全面、更准确。

关于缩写：

Product Increment - PI

Product Backlog - PB

如果觉得对您有帮助，烦请动动小手点个赞！这也是对我最大的激励。