敏捷开发 我的经验（三）运转

在一个sprint中整个开发过程中大概分为4个阶段，启动、开发、评审、后期处理
每个sprint都是连续的，所以sprint之间的工作会有一些交叉

1. 启动

• sprint启动从上一个sprint后期开始，从Sprint Planning Meeting开始，当前sprint已经进入准备阶段。
• sprint正式开始是Sprint start meeting的，在这个sprint的第一天。
• sprint正式开始后，第一天、第二天基本上在做sprint的story分析，story拆解为task工作
• 在这三天中需要约定一次Sprint Retrospective Meeting，会议时长约30min~120min

在sprint第三天一定要完成story的分析与拆解，进入正式的编码阶段;
如果在任务分解时有任何问题，可以向SM(需求相关)和TL(技术相关)提出，如果SM和TL无法解决，可以像PO提出或者请求上一级的TL解决;
如果还是没有结果应请PO评估是否应该放回到product back log中。

理论上不应该出现这样的问题，这样的问题出现，说明在Sprint Pre-plan meeting中评估有问题。

2. 开发

• 从sprint第四天开始应该正式进入开发阶段，这个开发阶段会占用整个sprint的50%~60%的时间
• sprint的周期越长，开发占用的时间越短，最短不应少于50%，最多不应该超过70%，否则后续评审和sprint会无法正常继续下去

3. 评审

主要是评审会议：Sprint Review Meeting或者叫Sprint Demo Meeting
包含以下内容

• PO对已完成内容的评审，确认是否符合预期标准
• TL对已完成代码进行评审，确认代码是否符合代码规范，也可借助于junit、pmd、checkstyle等工具进行评审
• 如果有测试，则TL和ST需要对测试案例进行评审，确认测试案例是否符合PO的要求。

    以上评审需要在开发结束的1~3天内完成

4. 后期处理

前3部分大概占掉了整个sprint的60%~70%

• 处理在评审过程中PO提出的改善建议，注意这里不应该包含需求变更，需求变更需要PO另外建立story
• 处理在评审过程中TL提出的改善建议，这里不会有需求变更，可能包含小型重构，不应包含大量重构，如果确实有必要需要请上一级TL添加tech debt story
• 处理junit和测试过程中发现的异常或bug
• 完善相关文档或完善story描述，方便后续人员维护