我第一家互联网公司产品开发周期

从開始上班到如今，也快满一年了，在这，就谈一下软件开发的几个阶段。各公司应该有不同的名称，可是开发流程较完整的公司应该是会有以下的几个阶段。

以下是我对这几个产品周期阶段的理解还有心得，还请大家不吝不吝赐教～

需求评审

　　在此阶段。产品经理(PM)会提出新的需求，比方说软件的一些新功能，并讲解此需求的动机，完毕产品需求文档(Project Requirement Document)後招开相关会议。研发人员(RD)则会在会议上评估此项新需求是否可实现、所须要的工作日、对产品稳定度的影响，是否在既有产品已有相关功能等等；測试人员（QA）则会提出一些測试上的疑问及意见。方便後期进行 Case 评审。这个阶段easy发生的问题。通常是产品经理和开发者意见不一致，或者是二者有信任问题而导致的。以前见过冲突案例是这种：一位产品经理，由于在前一家的公司。有做过类似的产品，便觉得此项设计easy实现。而他不知的是，每家公司的产品。其架构不见得类似，实现的困难度肯定是不大同样的，因此便開始质疑RD开发能力，还有是不是想要偷懒之类的情绪性发言。於是冲突便发生了。私以为这种情况事实上是无解的。由于这和冲突两方的个人特质及个性是极度相关的。唯有尊重对方的工作及专业，而且注意自己的发言及语气。才是专业化的表现。

开发阶段

　　在需求明白了以後，RD即開始进行开发工作。在 FC （Function Complete）期限之前将相关功能实现而且自測完毕。在开发时，除了要尽可能注意各种可能会发生的情况，并实现需求以外，更要以产品的稳定度为上。同一时候考虑这个需求假设须要花费大量的系统资源。这是否值得？在实现本次版本号需求之余。也要考虑到对旧版本号的兼容性，还有这样的实现对未来的扩展性。可以在考量这些因子後完毕相关工作，这是眼下我要求自己的标准。最後，在开发完毕後。须要预留时间自己为新功能自測。

由于一个小功能。測试人员往往须要运行数个測数案例以确保其功能正常。研发人员在进行开发工作时，一定要给自己留至少一天的自測时间，确保在正常情况下的操作是没有问题的，这样不但减轻測试人员的工作量（当发现一个
bug 时，在开发者解完 bug 後，測试人员是须要复验的），这样连带的也使自己的名声好听一些，如此，何乐而不为呢？

Show Case

　　在基本功能开发完毕了以後。便会邀请其他小组人员观看、评论新开发的功能。假设有必要的话，做小幅度的调整。

測试案例评审

　　測试人员在完毕自己编写的測试案例，会将召集产品经理, 研发人员，以确保相关案例(case)足以覆盖此项新功能。新功能能正常地发挥该有的效果。研发人员在开測试 case 评审时，应该想想自己的代码逻辑，在更动的代码部份，提出可能会遇到的情况，确保 test case 有全然覆盖到这些修改造成的影响。

測试阶段

　　在測试人员測试过每一条 test case，且开发者完毕 bug 的改动了以後，便能够进入 RC (Release Complete)阶段。

而我们一般说的 RC 时间，便指的是 RD 该把 bug 都修复的最後期限。

在这边有一点须要注意的是，进入RC前的測试阶段。使用的測试环境是线下測试环境，而进入 RC後，便開始使用线上測试环境进行測试。在測试阶段，也是研发人员easy和測试人员冲突的时候，常发生的场景例如以下：

一、測试case 因某些 bug 而被 block 住。无法往下測，而再过多久便是期限了。

遇到这样的情况。必须尽快解决 bug，否则会影响新版本号的发行。一方面。可能也得注意自己的语气，缓合任一方的情绪。由于多和几个人吵架，并不会让进度变得更顺利。

二、对bug的认知。某些情况下，是依照正常产品设计所产生的必定结果。而測试人员从用户的角度。自然便觉得是个 bug，此时应和产品经理一起讨论解决这个问题。

三、开发未完毕自測，导致在进入測试阶段後，立马出现一堆 bug。

四、Bug改动导致其他地方出现故障。　　

　　事实上，每一个角色总是得以团队为重，产品为上，所以必须节制一下自己因忙碌而产生的负面情绪，不能由于这些负面情绪影响了工作的进行。可是假设遇到个别无法控制自己情绪或行为的人员。也应兼持自己的为人処事原则，该怎麽办就怎麽办，不能事事忍让对方，有时也必须「站出来为自己的原则吵上一架」无论是在谈话语气方面，或是公事的mail往来方面，都是一种処理方式。

有时候恰恰是由于你对原则的坚持，反而会得到对方对你专业的尊重。

灰度

　　在这个版本号进入 RC 状态了以後，在线上环境測试没问题了以後，測试人员会公布 RC 报告，并进入灰度。灰度主要是先将新版本号公开给一小部份的用户，由于平台及使用行为的差异，此时有可能会有一些产品的 crash 及用户回报的问题。而依问题的严重性。可能会有一次灰度。二次灰度等，然後便是全面公布。将产品公开给所实用户使用，此时所有的用户便会收到相关的升级讯息。灰度期间基本的问题。应该是反馈的 bug 一般比較不easy解决，不easy解决的原因主要是不easy复现，比方说没实用户所使用的平台，又比方说当时的操作环境可能是很特别的等等各种不同的原因，这时我想就得靠经验攻克了。

以上。就是我眼下的心得～我并非一開始就知道这些的优秀开发者；相反的，我经常犯错，可是犯错之後，我时常反省，怎样才干做的更好，也会去请教资深开发者，怎样才干变得更好更强大。始终没有放弃，如今有空之余，便整理相关心得和大家分享。并希望能得到大家的宝贵意见，以使自己可以有所长进，再次谢谢大家阅读～请多多不吝赐教～