敏捷开发Scrum在项目中的合理使用

     前两天，有群里的朋友在管理团队开发过程中有一些敏捷方面的疑问，类似如何评估工作量、如何高效的进行早会等问题。今天开一篇敏捷开发相关的文章，说说我对敏捷的理解和实践。

     Scrum 是什么？

     Scrum 是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周，在互联网开发领域，像类似app的开发，可以缩短到一周。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。

     接下来我们以实际的项目为例，详细阐述敏捷开发的运用。

1.首先，项目开展之前，项目经理同产品部门达成一致，明确产品的形态，功能等，项目经理输出backlog，针对本次迭代，列出需求列表，并进行优先级排列。

2.

（1）backlog输出后组织开发人员进行本次迭代会议，会议上向所有开发人员通报本次迭代的任务，时间点。

（2）根据本轮迭代的需求按照story的优先级，组织大家进行任务的认领。此时有两种方式，一种是项目经理根据每个开发人员的特点指定任务，另一种是让大家自己根据兴趣认领。

（3）第三步与第二步其实是并列的，安排story的时候需要评估工作量。工作量的评估也有两种方式，一种是大家举手表决，比如对于story A，三个人给出的工作量是4天，另外两人给出的5天和3天，这个时候就需要最低和最高的给出具体的原因分析，最后取合理值。另外一种是个人认领了相应的story，这时候可以给出工作量，或者在任务分配后，预留一段时间，会后大家反馈给项目经理。

      注意：工作量的评估不单单包括开发的过程，还包括前期的分析设计，自测以及测试部的签收等，要预留出时间，以免工作量评估与时间时间相差悬殊。

（4）迭代会议完成后，项目经理在确定完工作量后，将backlog归档，后期按照这个结果进行每天的项目进度跟踪。

（5）正式迭代开始前，所有的story都需要上状态墙，状态墙分为以下几个部分：初始化、分析、设计、编码、自测、BA验收、测试，最初story都走到初始化阶段。

（6）迭代开始，每天早上进行站立会议，时间尽量缩短，每人不超过2分钟，先描述自己昨天干了什么工作，今天准备干什么，同时将相应的story移到对应的状态。

（7）本轮迭代结束，项目经理召开迭代总结会议，针对本次迭代的情况，进行总结。主要包括以下几个方面：迭代是否符合预期，有没有延期等。然后组织大家针对本次迭代过程有哪些好的方面和不好的方面，每人分别写几条。项目经理进行归类，挑选出公认的观点，进行总结，同时督促大家在下一轮迭代过程中发扬上次的优点，避免上次的缺点。

        以上就是敏捷开发的全部过程。在实践的过程中，要根据项目本身的情况，如果团队人员较多，可以划分出来，比如安卓和iOS，还可以按业务再细分，每次早会时间控制在15分钟以内，提高效率。此外，backlog确定后，迭代过程中不要插入其他需求，破坏敏捷的完整性，新需求放到下次迭代。

        欢迎大家添加我的微信，有任何问题都可以一起讨论，不限于安卓，iOS，后台，项目管理，创业等。