干货分享|敏捷开发流程

最近一直在学习敏捷，同时在公司里也尝试从原本无序的开发流程向敏捷转变，整理出一套比较简易的敏捷开发流程。
在开始讲敏捷开发流程之前，我们得先了解几个名词概念。

• Product backlog：产品需求池，即罗列产品需求的文档。
• Sprint：原意为冲刺，指一个迭代。
• Sprint Backlog：Sprint待办列表，指Sprint任务清单。
• Product Backlog Item：产品待办清单条目，简称PBI。
• Story board：故事看板，通常可以用于展现每天每个人需要做什么事情。
• 燃尽图：团队用于做Sprint内的进展跟踪图。
• 产品文档：记录所有的需求、变更记录。
• 站会：每日站会是开发团队的一个以 15 分钟为限的事件。

通常一个Scrum 团队由一名产品负责人、开发团队和一名 Scrum Master（简称SM，敏捷教练，通常是指导管理工作和辅助需求方案分析） 组成，团队不需要大，但要齐备。

团队组建完毕，就可以开始干活了。

通常需求会来自于外部（市场需求、用户反馈）或内部（战略规划），以敏捷的方法来收集需求，建议是采用User Story用户故事的方法（不了解用户故事的伙伴可以看看我前些日子整理的《谈谈敏捷中的用户故事》）。

当收集好需求，接下来就可以梳理出Product Backlog了，通常收集需求到Product Backlog这一步是贯穿整个项目的生命周期的，尤其是对于面向甲方的外包项目。

根据需求池，产品负责人和SM首先需要确定每一个Sprint的周期是多长，一般都是按照一周的时间安排，然后需要规划出接下来的一个sprint要开发的需求，并和开发团队一起根据这个Sprint Backlog对需求进行分解，形成PBI，也就是具体的开发任务。

当整个团队对PBI没有疑问或意见后，即可绘制燃尽图，将PBI按照日程分配到看板上，安排进行开发。在一个Sprint的进程中，每一天都应该举行一次站会，站会的目的是跟进一个Sprint的进度，然后解答团队成员的疑惑，及时解决问题，避免对进度产生影响。如果是无法在当前Sprint完成的任务，应该进行评审，推入到下一个Sprint中。当一个sprint完成之后，项目组应该对此进行评审，过审则上线，不过审也应该推入下一个sprint中。最后还可以开一个sprint的回顾会议，审视上一个sprint中存在的问题，吸取教训，总结经验，然后推动下一个sprint的执行。
最终以此循环完成一个项目的开发。

敏捷项目开发流程.png