爱华网SCRUM 是一个用于开发和维持复杂产品的框架
Scrum 是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品BaIhUaU.comacklog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。
前段时间，我们发现开发过程有些混乱并且不容易管理。为了团队更好的协作，我们在顾问的引导下，开始尝试使用Scrum敏捷开发。
几轮Sprint下来，有点个人体会，和大家share之。立场当然是是不褒不贬，纯客观描述啦！不过，每个团队情况不一致；因此，这个“客观”针对的是我们团队。啊哈~
首先，Scrum的官方流程如下：
我们的Scrum流程如下：
接下来会详细讲解每个步骤中应当注意的点：
开发前：
阐述&调整需求：
产品要在这之前需要考虑清楚每个需求的逻辑、页面交互展示，不然在这一步就会造成很多讨论，延长开会时长，影响效果。至于如何思考清楚内在逻辑，有多钟方法，这又是一个topic；
对于优先级的确认，一定要明确，这是后面实现的先后基础；
如果程序猿们对某个需求逻辑提出质疑的话，最好不要太任由发散讨论，能立刻调整的，那么就调整；不能立刻确认调整的，先保留，然后在真正开发前要确认；
如果产品汪在阐述需求的同时，开发人员们开始相互沟通如何实现的问题，那么建议开发们先听完所有内容，在后面的需求分解中再进行详细讨论，不然在需求源头错过就容易有需求上的认知偏差；
需求分解为任务：
小团队没有项目经理的情况下，建议项目负责人（Scrum Master）是经验比较丰富的技术人，这样对项目进度比较容易有把控，同时对需求的分解以及后期的追踪会有很大的帮助；
要强化需求追踪人（Owner）追踪需求的意识，不要流于形式：有个这么个角色，但是并没有发挥作用这种情况。owner的存在可以分担SM的责任的同时让开发人员之间关联性更强，因为一般某个需求会同时涉及到前端、后端、API、移动端，让开发去推动开发；
开发人员们要适当把需求拆的细一些，这样在拆的过程中更容易吃透需求、理清逻辑，发现逻辑上的问题。针对需求，相关的人进行技术讨论，有疑问的地方要及时和产品这边沟通，问题越早发现越好。最后，要把每个任务对应的人以及需要的完成时间都记录下来。
有关于时间预估问题，我暂时还不知道哪种方法比较好。在文末最后有个敏捷估算的方法，乃们可以参考看看。
在拆分的过程中，SM最好能够根据需求的难易程度，进行辅助沟通。这样，能够相对避免因为具体代码人员因为经验/能力不够而导致的拆分、预估问题；
产品汪要在讨论过程中，时刻穿插在其中，尽量保证需求理解的正确性；
确认该期目标：
完整过一遍每个需求的分解情况，看是否有遗漏或者误差，有疑问即刻提；
必须按照需求的优先级来确认目标；
要明确目标，确认哪些一定要做完（这里有个argue/挖坑的地方，会在下文“开发中”-“3其他”-2中进行描述）；
开发中：
有关中期会议：
一定要在一期sprint的中间进行进度回顾和确认，如果进度偏差很大的话，要适当的调整目标，以免最终跟预期相差太大；
中期的时候，可以check下人力分配，如果有相对空闲，那么可以再安排一些任务。看不同情况，是安排产品线的新任务还是基础建设任务或是代码优化任务等等；
有关测试：
在开发过程中，建议开发完一个功能就跟进一个功能的测试，以免最终测试任务都堆积起来；
提测可以在项目结束的前2-3天开始，这样可以保证有足够的时间进行修正；
如果功能和业务强关联，可以让业务人员在提测阶段使用测试版本，一起发现问题；
开发人员在开发新功能过程中，可能会遇到之前存在的bug或者突然发现了之前没发现的bug，这时候应该要告诉测试人员跟进，而不是自己直接修掉。因为你以为的修掉并不一定真正没问题，一定要进行回测，同时留下记录，可能会给以后的追溯带来帮助；
其他：
团队每天开站会，目的在于描述自己的进度情况。一定要明确！要明确！要明确！如果不明确表述，其实等于没有开站会；
在适应新开发流程的初期，SM最好能够每天or每两天确认下组员们的真实开发情况，包括进度and需求理解上；
一开始尝试Scrum敏捷开发时，容易预估（目标、时间）不准确，导致2周一个迭代版本比较困难，可能会经常延迟。面对这种情况，我目前是倾向砍掉部分需求，先满足2周一个版本，让团队先形成这么一个周期惯性，再去优化惯性内的效率问题（也就是之后再提高目标的要求)；
Scrum要求是：
目标、质量验收标准不能改变；
完成目标的要求不能过低；（文末有相关资料）
关于如何解决这个问题，也还在摸索状态 T_T，大家如果有好的建议和想法，求沟通呀~
开发后：
组员们要一定总结下这期开发中存在哪些问题，如何解决或者减弱这些问题的影响，不要流于形式。毕竟对团队来说，这是新的开发流程，不适应或者做的不好很正常，不要怕说不要的地方，大家在错误中磨合、改善、成长才是最重要的；
结合上一点，每期也要对上期提出来的问题进行回顾，看在这期中是否有改善这个问题。只记录不回顾，等于什么都没干；
以上，是目前的一些体会和总结，希望在不断实践中，能够得到新的解决方法和体会...以上是用户分享关于产品经理如何用Scrum敏捷开发带领产品团队的资料希望对您有所帮助了，感谢您对爱华网的支持！
