产品经理如何用Scrum敏捷开发带领团队

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

mimngjiekaifa

前段时间,我们发现开发过程有些混乱并且不容易管理。为了团队更好的协作,我们在顾问的引导下,开始尝试使用Scrum敏捷开发。(Scrum相对官方的资料,附在文章最后)

几轮Sprint下来,有点个人体会,和大家share之。立场当然是是不褒不贬,纯客观描述啦!不过,每个团队情况不一致;因此,这个“客观”针对的是我们团队。啊哈~

首先,Scrum的官方流程如下:

QQ截图20151023101320

我们的Scrum流程如下:

1

23

接下来会详细讲解每个步骤中应当注意的点:

开发前:

阐述&调整需求:

产品要在这之前需要考虑清楚每个需求的逻辑、页面交互展示,不然在这一步就会造成很多讨论,延长开会时长,影响效果。至于如何思考清楚内在逻辑,有多钟方法,这又是一个topic;

对于优先级的确认,一定要明确,这是后面实现的先后基础;

如果程序猿们对某个需求逻辑提出质疑的话,最好不要太任由发散讨论,能立刻调整的,那么就调整;不能立刻确认调整的,先保留,然后在真正开发前要确认;

如果产品汪在阐述需求的同时,开发人员们开始相互沟通如何实现的问题,那么建议开发们先听完所有内容,在后面的需求分解中再进行详细讨论,不然在需求源头错过就容易有需求上的认知偏差;

需求分解为任务:

小团队没有项目经理的情况下,建议项目负责人(Scrum Master)是经验比较丰富的技术人,这样对项目进度比较容易有把控,同时对需求的分解以及后期的追踪会有很大的帮助;

要强化需求追踪人(Owner)追踪需求的意识,不要流于形式:有个这么个角色,但是并没有发挥作用这种情况。owner的存在可以分担SM的责任的同时让开发人员之间关联性更强,因为一般某个需求会同时涉及到前端、后端、API、移动端,让开发去推动开发;

开发人员们要适当把需求拆的细一些,这样在拆的过程中更容易吃透需求、理清逻辑,发现逻辑上的问题。针对需求,相关的人进行技术讨论,有疑问的地方要及时和产品这边沟通,问题越早发现越好。最后,要把每个任务对应的人以及需要的完成时间都记录下来。

有关于时间预估问题,我暂时还不知道哪种方法比较好。在文末最后有个敏捷估算的方法,乃们可以参考看看。

在拆分的过程中,SM最好能够根据需求的难易程度,进行辅助沟通。这样,能够相对避免因为具体代码人员因为经验/能力不够而导致的拆分、预估问题;

产品汪要在讨论过程中,时刻穿插在其中,尽量保证需求理解的正确性;

确认该期目标:

  • 完整过一遍每个需求的分解情况,看是否有遗漏或者误差,有疑问即刻提;
  • 必须按照需求的优先级来确认目标;
  • 要明确目标,确认哪些一定要做完(这里有个argue/挖坑的地方,会在下文“开发中”-“3其他”-2中进行描述);

开发中:

有关中期会议:

一定要在一期sprint的中间进行进度回顾和确认,如果进度偏差很大的话,要适当的调整目标,以免最终跟预期相差太大;

中期的时候,可以check下人力分配,如果有相对空闲,那么可以再安排一些任务。看不同情况,是安排产品线的新任务还是基础建设任务或是代码优化任务等等;

有关测试:

在开发过程中,建议开发完一个功能就跟进一个功能的测试,以免最终测试任务都堆积起来;

提测可以在项目结束的前2-3天开始,这样可以保证有足够的时间进行修正;

如果功能和业务强关联,可以让业务人员在提测阶段使用测试版本,一起发现问题;

开发人员在开发新功能过程中,可能会遇到之前存在的bug或者突然发现了之前没发现的bug,这时候应该要告诉测试人员跟进,而不是自己直接修掉。因为你以为的修掉并不一定真正没问题,一定要进行回测,同时留下记录,可能会给以后的追溯带来帮助;

其他:

团队每天开站会,目的在于描述自己的进度情况。一定要明确!要明确!要明确!如果不明确表述,其实等于没有开站会;

在适应新开发流程的初期,SM最好能够每天or每两天确认下组员们的真实开发情况,包括进度and需求理解上;

一开始尝试Scrum敏捷开发时,容易预估(目标、时间)不准确,导致2周一个迭代版本比较困难,可能会经常延迟。面对这种情况,我目前是倾向砍掉部分需求,先满足2周一个版本,让团队先形成这么一个周期惯性,再去优化惯性内的效率问题(也就是之后再提高目标的要求);

Scrum要求是:

  1. 目标、质量验收标准不能改变;
  2. 完成目标的要求不能过低;(文末有相关资料)

关于如何解决这个问题,也还在摸索状态 T_T,大家如果有好的建议和想法,求沟通呀~

开发后:

  1. 组员们要一定总结下这期开发中存在哪些问题,如何解决或者减弱这些问题的影响,不要流于形式。毕竟对团队来说,这是新的开发流程,不适应或者做的不好很正常,不要怕说不要的地方,大家在错误中磨合、改善、成长才是最重要的;
  2. 结合上一点,每期也要对上期提出来的问题进行回顾,看在这期中是否有改善这个问题。只记录不回顾,等于什么都没干;

以上,是目前的一些体会和总结,希望在不断实践中,能够得到新的解决方法和体会…

最后附Scrum的官方资料:

什么是Scrum?

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html

Scrum团队的三个角色?

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-5

Scrum的三个工件?

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-6

Scrum的五个活动?

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-7

敏捷估算?

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-14

sprint?

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-15

每日站会?

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-16

完成的“定义”?

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-17

 

本文由华尔街见闻产品经理 @梁露瑶(微信公众号killifer) 原创发布于人人都是产品经理 ,未经许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。

评论( 5

登录后参与评论
  1. 你确定这是产品经理不是项目经理么

    回复
    1. 回复

      大公司有项目经理的岗位,但是中小公司没有项目经理岗。
      在这种情况下,谁更负责谁就有可能做项目经理干的活儿。我觉得,产品经理更有可能会做这方面的事情。

      个人的一点想法^_^*

    2. 回复

      项目经理最好还是有技术背景的人来负责,产品经理兼任的话容易被开发牵着鼻子走。

    3. 回复

      从技术上容易被牵着走
      更忧伤的是,对技术人员没有任何管理权(不是为了要权而权),即使是技术的问题,也很难去说什么…

    4. 回复

      产品经理本来就是容易背黑锅的岗位,项目管理这种同样背锅的事情还是交给专业的去做吧,不然好事没有,出了错都是自己的,简直苦逼。

加载中