从PM的角度聊聊敏捷开发

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

我们团队的构成为：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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