標籤：android job 軟體開發 工作 經驗
從開始上班到現在，也快滿一年了，在這，就談一下軟體開發的幾個階段。各公司應該有不同的名稱，但是開發流程較完整的公司應該是會有下面的幾個階段。下面是我對這幾個產品周期階段的理解還有心得，還請大家不吝指教～
需求評審
在此階段，產品經理(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 一般比較不容易解決，不容易解決的原因主要是不容易複現，比如說沒有使用者所使用的平台，又比如說當時的作業環境可能是非常特別的等等各種不同的原因，這時我想就得靠經驗解決了。
以上，就是我目前的心得～謝謝大家閱讀～請多多指教～
互連網公司產品開發週期
