×

从PM的角度聊聊敏捷开发

96
Loafer
2017.10.23 21:40* 字数 2637

从去年年底开始负责APP的社区功能,技术实现上用可H5的形式,从APP团队中独立出来。以小团队尝试敏捷开发模式的探索,而我作为产品经理,自然也是这个敏捷项目的Scrum Master。

我们团队的构成为:

  • 产品 * 2/3
  • 设计 * 1/3
  • 测试 * 2/3
  • 前端 * 1
  • 服务端 * 1
  • 后台 * 1/2

这应该算是敏捷开发中最mini的团队,而且大部分人还不是完整的一人力投入到社区工作中,包括我自己。但好在其他人额外的工作也由我这边管理,从需求排期上我可以灵活支配大家的工作排期,不影响到社区项目整体节奏。经过这快一年的磨合,我们的迭代速度从2周变为1周,也把敏捷开发流程修改践行到最适合我们团队的模式。

有一些我作为产品经理对于敏捷开发的思考,将其记录下来。

1. 坐在一起

所有讲Scrum敏捷开发的文章里都很重视团队每日的站会,“今天做了什么,将要做什么,有什么障碍”的站会三个主题是为了团队每个人快读沟通当前的进度与困难,促使团队更好的协同开发,认为站会是敏捷开发中必不可少的环节。但是在施行中,站会的效率很难保证,经常变成昨日热门话题的集中闲聊会,当然也是我这个PM组织的烂。而且因为是弹性工作制,加上北京早上糟糕的交通,召集会议也花很多时间。

鉴于此,我们不再开晨会,而是直接坐在一起。每天需要同步大家进度的时候,直接转个椅子快速沟通就结束了,而且遇到问题也及时让同事提出来,大家一个转身就去看具体问题了。

另外这种从技术、产品、设计的独立团队中剖离出来的独立感,坐在一起能让团队成员有项目团队的归属感。除工作以外,大家也更熟悉生活中的彼此,能更好分担协助彼此完成项目的工作。

2. 不要用传统的项目管理工具

在公司开发流程中最常用的项目协作工具是Readmine。我个人是对传统的这类软件开发时代用的协作工具Readmine、Bugzilla……抱有无限的敌意,因为这类工具经过这么多年的更新,实在是太完善了,太大太全太复杂。并且传统项目管理工具的受众是专职的项目经理,产品经理用这类软件做项目管理太耗费时间,太容易掉到琐碎的项目管理细节中。

所以,在我们项目中采用Tower做项目管理工具。类似的看板类项目管理工具如Trello、Teambition、Phabricator、Tower……大多大同小异,找一个自己顺手习惯的就好。看板类的项目管理工具最方便的就是拖拽任务,可以在一页上看清该版本各个任务的进度。另外这类项目管理工具有更好的扩展性,有丰富的插件可以去选择性集成以提高开发效率。

在敏捷开发的流程中,产品经理需要做好项目管理的工作。而项目管理工具是必不可少的,至于如何选择每个人使用习惯差异很大,可以根据自己团队现实情况去选择。总之不要用传统的项目管理软件,因为传统项目管理工具的受众是项目经理,而不是产品经理。

3. 轻文档、重交流

我们公司没有UE,产品经理除了出需求,还需要给出交互。如果按照正规的文档流程规范,一个版本的文档写完,留给开发的时间也就不多了。至少在我们项目中,我不写文档只出交互,重要的点直接在图中文字标注。但产品的逻辑细节,我会在画交互稿的同时记录在个人的印象笔记里。好记性不如烂笔头,尽管不输出正式的文档,但产品的逻辑必须明确。毕竟后续的需求修改、测试用例都基于原始的产品逻辑,产品经理忘记自己设计的东西,无论如何都是说不过去的。

输出交互稿之后,我会单独拉上开发、测试和视觉去开一个会,具体讲一下这个需求的设计,传达本来需要我用文字写在文档中的意思。当然不写文档,不代表需求模糊,经不起其他人在会上的挑战。

会上说需求设计的最大的好处是,我能明确的用口语传达出对需求细节的感情色彩,哪儿是重点,哪儿细节体验要保证,哪儿做成什么样都行……很多是无法拆分的需求细节,但是通过言语说出来就很容易被拆分掉,更好地让开发容易理解需求重点,加快开发速度。

4. 需求评审、总结复盘拉上所有团队成员

一般项目的需求评审一般是产品拉着各个老大来做需求评审,各个老大接了需求后会上评估下工期,会下再把相关的需求分给下面的人做。具体做事的人,往往是接到需求后再啃文档,自己理解后再去开发。总结复盘的邮件更是只在产品组内部和leader的邮箱里呆着,根本不会给到每个开发成员

而敏捷开发从需求评审阶段就必须拉上所有团队成员,产品经理要把需求场景、优先等级、用户调研……讲给所有人听。然后要在团队中达成一致,让团队所有的小伙伴都认可你的需求,并且愿意主动把这个需求做下去。版本上线后的效果也需要同步给团队的小伙伴,让大家都输出的结果都有反馈,然后也可以听听团队每个人的建议与感觉,再综合考虑及时调整产品。这些能极大强化团队的凝聚力,让每个人并非只是做自己手头的工作,更有产品的主人翁意识。

5. 所有人都是测试

这点经验与我们项目类型有关,因为我们做的是社区类产品,很多测试的case流程必须要帐号间的互动,久而久之我们团队在测试阶段每个人都演变成了测试。

测试同事写完测试用例,等提测之后,我们所有人都汇聚在一个小会议室里。每个人分工其中的一些流程测试,快速协助测试走完case,然后快速将bug记在白板上发到群里备份,一部分需要专业手段的测试还需要测试同事专业的方法,大家协助测试的部分主要还是流程测试。快速过完之后,开发回去解bug,测试同事整理测试报告。遇到重大的bug block版本,大家就直接在会议室里讨论预案。

这种快速的团队测试能极大的提升测试效率,往往测试同事花一天才能跑完的用例,我们四个人在会议室一小时就搞定了,而且因为开发也参与了测试流程,连问题描述、复现步骤都不用写就可以直接定位问题。

6. 每个Sprint间要注意重要功能的穿插

这点其实是所有开发排期的都需要注意的问题,只是敏捷开发更容易暴露这个问题。这里的重要功能,并不是产品优先级上的重要,而是开发难度上的定义。因为敏捷开发的周期很短,每个重要功能上线后往往需要一定时间进行稳定。如果在排期上每个Sprint都有重要的功能,稳定上个版本与开发下个版本交叉,基本上会造成下个版本的delay。

所以在需求排期中,临近的Sprint要注意功能上的间隔。有的功能干脆就在需求排期中强制拆开,留足稳定的buffer。另外,有时候版本发不出去就不要发,不要为了敏捷而发版,那样就本末倒置啦!我们团队还有一个约定俗成的事,如果大家齐力克服困难将一个眼看需要delay的版本弄上线了,上线后必须tb大吃一顿作为奖励刺激,23333~


总结

我们项目经过大半年的敏捷开发,无论是团队气氛还是产品数据都取得了比较好的结果。与其说敏捷开发是一种项目管理的方法,不如说是一种切换大家工作角色的方式。让大家抛开原来的螺丝钉角色,全方位的参与到整个项目的流程中,强化主人翁意识。让团队的每个人切实地认识到自己就是这个产品的主人,主动为产品考虑,主动协助上下游更好地完成目标。

工作
Web note ad 1