我所经历过的项目流程与痛点

2017-03-19

我所经历过的项目流程

> LexisNexis

彼时我所在的LexisNexis开发团队规模不大，后端开发5、6个，前端2、3个，对应1个产品经理和1个技术Leader，另配有1个QA，有时候来不及了产品经理经常一起负责测试验收（:-D）。

因为LN是一家外企的上海办事处，所以prd都是英文的（所幸邮件和日常交流不用英文，想想我的办公室邮件文化启蒙之旅就是在这里），一份prd 40+页英文看起来也是蛮痛苦的，还出过因为英文表述/理解不达意而导致开发出来与项目经理期望有差的情况。

当时的业务项目起止流程一般如下：

产品经理出raw prd

拉上开发过需求，QA过程中开发熟悉业务，PM根据反馈记录需要再沟通的事项

prd移交

技术Leader拉着拆任务、估时间

如有需要，技术架构评审

开发录入自己的task，测试录入测试用例case
（追踪管理工具：redmine，技术文档、prd、task、bug都放在上面，多功能）

开发阶段，每日进度汇报
（一般是早上10点的快速会议，Done Yesterday & Todo today & Any Questions need to help）

部分模块功能开发完成直接测试
（敏捷的雏形有没有，只不过没有走冒烟+交付流程，还是最终全部开发完成后一起测试上线）

提测，进入测试阶段，历经dev、staging2、beta、ga四个环境
（beta有点像灰度发布，但是不是导流量，而是在beta环境开通测试账号的方式，让部分用户使用）

正式上线，线上验证
（测试阶段再完美也会有线上问题，出现过几次早上发布搞到凌晨才能撤退的情况）

我在LN一年半都是遵着这个流程来的，在线法务平台主要是针对to B的商业模式，价格都是dollar计价，找几个优秀的交互师和前端整理下在线浏览体验对企业用户帮助更大。

> PAHF@瀑布式

在PAHF，项目流程更“丰富”于LN，大大小小地会议也更多；而且由于团队规模、技术架构等因素，做一个项目会牵涉到若干个由其他团队提供的service，直接增加了沟通成本和开发联调复杂度，对于跨团队项目的时间、进度把握也是在LN体会不到的。

brd商业需求文档，业务部门到产品部门的一个沟通文档

需求沟通，答疑会

prd移交

划分story和子任务，系统间沟通，评估工作量和开发、联调时间
（跨系统业务开展往往在这一步需要花一些时间，线下沟通，需要拍板的时候再组织个通气儿会）

开发沟通，定几个时间节点
（伪接口、开发环境联调、提测、上线）

开发环境各自开发，使用伪接口串流程

接口完成后CI环境联调

st环境提测

anhouse环境发布

GA上线
（如有大功能改版，会有灰度发布流程，导x%的流量到灰度机器查看有无问题）

相比LN，在PAHF因为有跨系统之间的接口调用，也有过一个app页面需要调用4、5个后台service，如用户服务、房源服务等，完全走RPC调用，因此联调往往需要花费不少时间，也是项目开展的不确定因素所在。

> PAHF@敏捷

在HF还走过一段敏捷开发，当过Scrum Master的角色。敏捷的流程期望以持续接收需求、持续交付、敏捷迭代的"流"方式来完成产品的快速更新，相比于瀑布式开发流程来讲更快一步地接受到用户的反馈，快速试错快速调整。

无论何种开发模式都没有对与错的绝对界限，但是可以毫不留情地说敏捷在PAHF是失败的一次尝试，在历经了快半年的"折腾"后，敏捷大旗落下了帷幕，其中有很多因素不为外人所知，也不多谈了，这里就谈谈我们的实践和个人反思吧。

首先团队的人员组成发生了变化，之前都是前后端小组各自管理，需要联调时再一起开会过下app接口；走敏捷后小组被称为scrum team：将原来的前后端人员打散，每个team由2、3个app开发，2、3个后端开发、1个前端，2个QA组成，其中一个开发担任scrum master的角色。所以每一个team都是可以单独从接需求到完成开发提测上线交付的，这也是敏捷流程要求的team组成形式。

准备工作：

物理卡片，可以准备多个颜色的卡片，代表story，task, bug等

个人头像，头像代表负责人，哪个task由谁负责就把头像贴上去，便于快速找人

看板，每个team一块组内小看板，大组一块大看板

小看板，划分成：story | selected | task | dev (app、前端、后端、Done) | 联调（Doing、Done）| Test (Doing Done)

大看板，划分成：ice box | sprint (selected、dev、testing、UATing、UATed) | share

名词解释：

sprint：一次sprint代表一次迭代，包含了从选取story，估点，拆分task，正式开发，验收，提测到测试完成，UAT，上线的完整流程；在本轮sprint过程的后期就需要展开下一轮sprint的故事选取，就像是一个流水生产线，输入是需求卡片，输出是经过一次sprint后产出的一次迭代上线

story：每个需求卡片被称为一个story，可能包含前后端的各自任务以及联调等，也可能包含了技术任务需要额外处理，如何拆分需要开发进行评估

story point/估点/故事点数：这是敏捷过程很重要的一个因子，故事点数代表每个story评估出来的任务复杂度，这里点数不代表人日，而是一个估值，当然复杂度与人日是直接挂钩的；点数一般分为1、2、3、5点，5点以上复杂度的故事会要求再细分

task：story拆分出来的子任务叫task，由各端开发各自认领

selected：本轮sprint选取要做的story放在这一栏

ice box：需求池，需求化为一张张物理卡片放进ice box，每轮sprint需要做的stroy从这里产出

UAT：产品验收

share：show case，每次迭代结束向业务部门展示迭代中的产出

紧接着，沟通的方式、需要开的会议、对于需求的切分都有了很大的变化，可以算是“耳目一新”：

没有prd了，需求变成卡片的形式进入ice box

sprint开始，确定一轮sprint要做的卡片范围

UX/UI进行资源切分等工作

team leader对故事卡片进行估点，选取story
技术故事、技术债务需要用另个颜色的卡片写出来，计入工作量中
如果是第一次sprint，那么需要选取一个公认的story作为复杂度为1的基准，后面的点数估点都以这个基准来判断

测试开始根据选取的story进行用例编写

开发对selected story进行task拆分，分配task

开发阶段，伪接口联调

某个story开发完成进行打包测试验收、冒烟、提测

测试完成通知产品UAT，上线还是等到sprint完成后上线

到sprint周期最后一天下午（一般是周五）迭代成功则进行show case，失败要进行道歉

紧接着准备下一轮sprint的工作

敏捷过程中我们开了以下几种会议:

看着挺好是吧，我们当时在走敏捷流程的时候经常开玩笑，敏捷开发 == 敏捷bug == 敏捷hotfix，那么...

痛点在哪儿？

1.沟通，还是沟通

之所以说软件开发没有银弹，是因为总有一些我们能够看见但是却没有完美解决方案的问题，无论走什么样的开发流程模式，沟通就是其中一点。

特别是业务开发团队，每个开发对于需求的理解都是主观的，往往需要通过几轮的沟通会/答疑会来达成一致。这里不得不吐槽下PAHF的业务开展，动不动就是模式全部翻新重做，一个重做几多泪水啊。

还有就是跨团队协作，到底是业务开发给service提供者提需求还是其他团队从需求沟通初期就要参与进来，我们也经历过不同的尝试，最后发现开发给开发提需求完全就是一场灾难，更别提在敏捷的时候还给其他团队提需求了，时间一个没有定好就等着show case失败吧。

至少从个人的实践体验下来，还是需要服务团队的部分人员（核心开发或者技术leader）提早介入，理解业务是什么、需要提供什么样的服务，再来评估现有的服务是否满足等，也便于领导们安排工作任务，人力资源是开展项目一个不可或缺的关键因素。

2.开发是否只该待在产品后面？

遍观上面提到的三个项目流程，鲜有开发出现在brd和prd之间的身影，很多时候开发都接受了“既定之任务”，无暇或者也不想去思考这个业务功能对于产品的意义在哪儿。

我在敏捷流程中很重要的一个“受挫”就是，敏捷强调的持续用户反馈完全没有出现在整个过程中，导致开发不知为何做、不知做为何、不知何为做，没有反馈就没有成就感没有调整的方向，所以每轮sprint都变成了业务方主观上认为“这个功能应该这样调整用户会觉得好”。

37signals的开发坐得离客服很近，用户但凡有什么使用上的问题会直接找到开发者，马上解决马上发布，所以形式不是那么重要（很多会议也很恼火），达到敏捷的目的就是好的流程；Facebook公司大门进去就有一块大大的显示屏显示这家公司的热点流量，哪些业务在赚钱，盈利如何，完全是开放透明的环境，让每个开发者知道自己的开发成果确实地影响了世界范围内的使用者。

3.我要专门罗列下敏捷里的痛点

以下都是我实实在在遇到过的问题，有些找到了缓解的方法而有些没有;

1.分支合并痛点，冲突过多。
这其实stroy划分的问题，前期开展的时候没有操作经验，有些关联的story划分的太细了，在代码上就表现为复用的模块会有多人一起修改，导致冲突很多。
这个问题在后面按大模块划分story后减少了不少。

2.故事点数评估问题，过大过小不明确

3.bug数明显增多。敏捷流程过于紧凑，新需求又大多是全新业务，导致业务了解时间变少
压缩了架构评审的时间，慢慢只满足实现，代码质量和code review没了，导致bug增多

4.准备工作不足，各种CI/ST环境问题频出，联调验收前期颇为艰难

5.没有自动化测试，测试同学人数来凑

6.缺失了敏捷很重要的一个环节：持续反馈，导致很多功能做了没有响应，成就感缺失

7.更别提单元测试、behat、sonr了

8.敏捷对于团队人员的整体素质要求很高

总结

所谓流程都是在一些践行之后总结出来的、约定俗成的步骤，就像很多构想与变法，止于理论时看上去都很美，但是实际执行起来又会各有波折，就像架构一样，没有最好的，只有历经磨难后那个最合适的。