[心得] 大陆互联网公司产品开发流程

楼主: blabla123 (念不停 烦不烦?)   2014-10-28 22:04:13
CSDN: http://blog.csdn.net/shanwu1985/article/details/40482497
这是最近的工作心得,想和版里的前辈请教/交流一下~谢谢大家
从开始上班到现在,也快满一年了,在这,就谈一下软件开发的几个阶段。各公司应该有
不同的名称,但是开发流程较完整的公司应该是会有下面的几个阶段。下面是我对这几个
产品周期阶段的理解还有心得,还请大家不吝指教~
需求评审
  在此阶段,产品经理(PM)会提出新的需求,比如说软件的一些新功能,并解说此需求
的动机,完成产品需求文档(Project Requirement Document)后招开相关会议;研发人员
(RD)则会在会议上评估此项新需求是否可实现、所需要的工作日、对产品稳定度的影响,
是否在既有产品已有相关功能等等;测试人员(QA)则会提出一些测试上的疑问及意见,
方便后期进行 Case 评审。这个阶段容易发生的问题,一般是产品经理和开发人员意见不
一致,或者是二者有信任问题而导致的。曾经见过冲突案例是这样的:一位产品经理,因
为在前一家的公司,有做过类似的产品,便认为此项设计容易实现,而他不知的是,每家
公司的产品,其架构不见得类似,实现的困难度肯定是不大相同的,因此便开始质疑RD开
发能力,还有是不是想要偷懒之类的情绪性发言,于是冲突便发生了。私以为这种情况其
实是无解的,因为这和冲突双方的个人特质及个性是极度相关的,唯有尊重对方的工作及
专业,并且注意自己的发言及语气,才是专业化的表现。
开发阶段
  在需求明确了以后,RD即开始进行开发工作,在 FC (Function Complete)期限之
前将相关功能实现并且自测完毕。因为一个小功能,测试人员往往需要执行数个测数案例
以确保其功能正常,因此研发人员在进行开发工作时,一定要给自己留至少一天的自测时
间,确保在正常情况下的操作是没有问题的,这样不但减轻测试人员的工作量(当发现一
个 bug 时,在开发人员解完 bug 后,测试人员是需要复验的),这样连带的也使自己的
名声好听一些,如此,何乐而不为呢?
Show Case
  在基本功能开发完成了以后,便会邀请其它小组人员观看、评论新开发的功能,如果
有必要的话,做小幅度的调整。
测试案例评审
  测试人员在完成自己编写的测试案例,会将召集产品经理, 研发人员,以确保相关案
例(case)足以覆蓋此项新功能,新功能能正常地发挥该有的效果。研发人员在开测试
case 评审时,应该想想自己的代码逻辑,在更动的代码部份,提出可能会遇到的情况,
确保 test case 有完全覆蓋到这些改动造成的影响。
测试阶段
  在测试人员测试过每一条 test case,且开发人员完成 bug 的修改了以后,便可以
进入 RC (Release Complete)阶段。而我们一般说的 RC 时间,便指的是 RD 该把 bug
都修复的最后期限。在这边有一点需要注意的是,进入RC前的测试阶段,使用的测试环境
是线下测试环境,而进入 RC后,便开始使用线上测试环境进行测试。在测试阶段,也是
研发人员容易和测试人员冲突的时候,常发生的场景如下:
一、测试case 因某些 bug 而被 block 住,无法往下测,而再过多久便是期限了。遇到
这种情况,必须尽快解决 bug,否则会影响新版本的发行,一方面,可能也得注意自己的
语气,缓合任一方的情绪,因为多和几个人吵架,并不会让进度变得更顺利。
二、对bug的认知。某些情况下,是按照正常产品设计所产生的必然结果,而测试人员从
用户的角度,自然便认为是个 bug,此时应和产品经理一起讨论解决问题。
三、开发未完成自测,导致在进入测试阶段后,立刻出现一堆 bug。
四、Bug修改导致其它地方出现问题。  
  其实,每个角色总是得以团队为重,产品为上,所以必须克制一下自己因忙碌而产生
的负面情绪,不能因为这些负面情绪影响了工作的进行。但是如果遇到个别无法控制自己
情绪或行为的人员,也应兼持自己的为人処事原则,该怎么办就怎么办,不能事事忍让对
方,有时也必须“站出来为自己的原则吵上一架”不管是在谈话语气方面,或是公事的
mail往来方面,都是一种処理方式。有时候恰恰是因为你对原则的坚持,反而会得到对方
对你专业的尊重。
灰度
  在这个版本进入 RC 状态了以后,在线上环境测试没问题了以后,测试人员会发布
RC 报告,并进入灰度,灰度主要是先将新版本公开给一小部份的用户,因为平台及使用
行为的差异,此时有可能会有一些产品的 crash 及用户回报的问题,而依问题的严重性
,可能会有一次灰度,二次灰度等,然后便是全面发布,将产品公开给全部用户使用,此
时全部的用户便会收到相关的升级讯息。灰度期间主要的问题,应该是反馈的 bug 一般
比较不容易解决,不容易解决的原因主要是不容易复现,比如说没有用户所使用的平台,
又比如说当时的操作环境可能是非常特别的等等各种不同的原因,这时我想就得靠经验解
决了。
以上,就是我目前的心得~谢谢大家阅读~请多多指教~
作者: a926 (Aaron)   2014-10-28 22:24:00
(阅) :D Thank you share .
作者: Wolfken   2014-10-29 00:01:00
基本就很标准的瀑布式开发,不过互联网还用瀑布式应该算是颇落伍...大陆都这样?
楼主: blabla123 (念不停 烦不烦?)   2014-10-29 08:16:00
主要是看公司的需求吧?但是我们没大量文档就是了wolfken 大公司采用哪一种型式的开发?
作者: alexlucifer (你管我叫啥)   2014-10-29 08:36:00
不是什么都要用最新,公司已经有一套稳定的方式就可
作者: Wolfken   2014-10-29 09:25:00
不不不,Waterfall的效率跟Agile和DevOps相差太远,绝不是什么用习惯就可以的,遇到用DevOps跟Agile成熟的公司Waterfall的龟速一定被打趴在地上用大刀很熟练也打不赢拿自动步枪的
作者: GoalBased (Artificail Intelligence)   2014-10-29 12:57:00
Wolfken 公司用agile吗? 羡慕-.-
作者: Wolfken   2014-10-29 14:50:00
目前正在往DevOps的路上迈进,不过还有很多努力空间
作者: alphadog (圣无极煞气阿法豆‧再改X)   2014-10-29 19:11:00
(阅) 感谢分享。然而 私以为贵司开发流程看看即可 并无什可学习之处强烈依赖成员品质之开发流程,还不如不要制定开发流程
楼主: blabla123 (念不停 烦不烦?)   2014-10-29 20:58:00
可以请 alphadog指教何处我司可加强?
作者: viper9709 (阿达)   2014-10-29 23:43:00
Waterfall跟Agile有差这么多喔@@
作者: Wolfken   2014-10-30 00:05:00
有,只是很多公司还在用waterfall,当你的对手也都是拿刀那你拿刀也无所谓,但是如果你对手有人拿自动步枪,你不拿就肯定GG,现在是拿刀的还很多,所以还没感觉那么强烈
楼主: blabla123 (念不停 烦不烦?)   2014-11-01 21:13:00
thanks ~

Links booklink

Contact Us: admin [ a t ] ucptt.com