从开始上班到现在，也快满一年了，在这，就谈一下软件开发的几个阶段。各公司应该有不同的名称，但是开发流程较完整的公司应该是会有下面的几个阶段。下面是我对这几个产品周期阶段的理解还有心得，还请大家不吝指教～
需求评审
在此阶段，产品经理(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 一般比较不容易解决，不容易解决的原因主要是不容易复现，比如说没有用户所使用的平台，又比如说当时的操作环境可能是非常特别的等等各种不同的原因，这时我想就得靠经验解决了。
以上，就是我目前的心得～谢谢大家阅读～请多多指教～