這個地方可能有些朋友產生了誤解.
傳統的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 一般
: 比較不容易解決，不容易解決的原因主要是不容易復現，比如說沒有用戶所使用的平台，
: 又比如說當時的操作環境可能是非常特別的等等各種不同的原因，這時我想就得靠經驗解
: 決了。
: 以上，就是我目前的心得～謝謝大家閱讀～請多多指教～