SCRUM 实践规范[试行]

在外部项目和内部项目开发中，我们遵循此文档中的敏捷开发实践说明，敏捷开发总体上遵循SCRUM 说明，同时根据自身团队工作模式，和项目开发需要做适当调整。

核心概念

这里的核心概念主要基于使用Clubhouse的概念改进形成。

Sprint(Interations)

有固定截止日期的项目都回计划分割为若干个Sprint，并在开发过程中采用增量开发的模式，每个Sprint后为客户提供可以验收的软件产品。

• 每个Sprint有固定的工作时常上线，当Sprint工作量超过Sprint的上线时需要减少开发工作或替换开发工作或者增加开发人力。

Epic

每个Epic代表项目的一个主要功能模块，每个Epic下有若干的Story，Epic通常用来查看项目完成的总计进度。

Change Request

当客户对已确定的Story有改动需求(功能/设计等各方面)时需要首先提交Change Request，Dozto根据提交的Change Request来评估改动对项目产生的影响，并进一步同客户分析改动是否行，以及改动的安排计划.

对于非紧急的改动请求，确认时间工作量后在接下来的Sprint中添加该Story。

Scrum实践

Sprint

每个sprint有开始和结束，开始前同客户确认好Sprint内的相关内容。 并和团队沟通好Sprint相关细节，作出工作量预估。

开发流程状态

Unscheduled: 未列入开发计划的项目，通常作为记录和整理需求使用。 Ready for Review: 需求确认清楚，需要等待客户确认需求包含了客户所需的所有内容，没有错误和缺失。 Ready for Development: 可以进行开发，在开发前，开发人员需要预估项目用时，预计交付日期(供有以来项目来计划后续开发)，并根据需求自行拆解开发任务并记录。 Doing: 表明正在开发/设计工作中。 Ready for UAT: 开发已经完成，进入等待验收阶段。 Done: 验收通过之后，任务结束，可以进行交付。

紧急任务处理

ClubHouse

如何预估工作，统计工作量，工作进度

极端情况处理

• 如有紧急BUG修正，可以优先安排紧急bug修正，可以插入当前的开发队列。