这个地方可能有些朋友产生了误解.
传统的waterfall模式非常严谨, 整个系统从需求评审一直到最后测试上线, 要耗费大量的
时间. 因此不可能快速响应各种需求变更, 这在瞬息万变的互联网行业中是不可接受的.
事实上, 在互联网行业中, 最盛行的是waterfall模式的变种: 快速迭代模式.
快速迭代模式讲究的是分而治之, 把整个系统拆解成非常小的模块, 然后针对每个模块进
行waterfall, 并且若有需要还可以跳过某些阶段. 每个waterfall的运行时间可能就只有
1周甚至更少.
这种模式下, 产品经理在尚未弄清楚所有需求的情况下, 就可以从已经确定的部分开始一
轮迭代, 有新的需求就再下一轮迭代. 响应速度非常快.
至于有朋友提到敏捷开发, 其实这与快速迭代并不冲突.
虽然大多数情况下, 快速迭代在每一轮迭代中都是使用waterfall模式, 但你也完全可以根
据需要在每一轮迭代中使用敏捷模式. 或者这一轮是敏捷, 下一轮是waterfall. 这都可以
没有什么问题.
而devops则又是另一个范畴的事情. 传统软件研发中, QA, OP, RD的角色非常分明并且各
司其职. 这样就造成了一个问题就是三种角色会互相扯皮, QA讲你RD东西做的烂不可测,
RD讲你QA什么都不懂连搭建环境都要我帮忙, OP讲你们QA RD不好好做事, 线上程序出问题
全部要我来擦屁股...
还有一个问题是, 没有哪个OP和QA愿意一辈子做OP和QA, 大家都想着要做RD, 工作积极性
就明显不如RD高.
devops强调的是, 不再区分这三种角色, 大家都是RD + QA + OP, 统称RD. 有句俗话怎么
讲来的? 不会做QA的RD不是好OP. 那这种情况下, 又出来了一个问题, 就是对RD的要求非
常高. 之前三者的工作量全部压到了一个人身上. 而相对应的解决办法就是, 开发各种工
具协助RD快速进行QA和OP. 持续集成, XaaS, 等各种新技术新方法都可以大大减轻工作量.
而原有的QA和OP团队, 则转型成专职的平台研发RD: 现在如日中天的amazon ec2就是
amazon的OP团队厌倦了无休无止的机械操作而研发出来的. QA团队则通常会转型成持续集
成平台以及其他质量保障平台的RD.
※ 引述《blabla123 (念不停 烦不烦？)》之铭言：
: 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 一般
: 比较不容易解决，不容易解决的原因主要是不容易复现，比如说没有用户所使用的平台，
: 又比如说当时的操作环境可能是非常特别的等等各种不同的原因，这时我想就得靠经验解
: 决了。
: 以上，就是我目前的心得～谢谢大家阅读～请多多指教～