[心得] 大陸互聯網公司產品開發流程

作者: blabla123 (念不停 煩不煩?)   2014-10-28 22:04:13
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 一般
比較不容易解決,不容易解決的原因主要是不容易復現,比如說沒有用戶所使用的平台,
又比如說當時的操作環境可能是非常特別的等等各種不同的原因,這時我想就得靠經驗解
決了。
以上,就是我目前的心得~謝謝大家閱讀~請多多指教~
作者: a926 (Aaron)   2014-10-28 22:24:00
(閱) :D Thank you share .
作者: Wolfken   2014-10-29 00:01:00
基本就很標準的瀑布式開發,不過互聯網還用瀑布式應該算是頗落伍...大陸都這樣?
作者: blabla123 (念不停 煩不煩?)   2014-10-29 08:16:00
主要是看公司的需求吧?但是我們沒大量文檔就是了wolfken 大公司採用哪一種型式的開發?
作者: alexlucifer (你管我叫啥)   2014-10-29 08:36:00
不是什麼都要用最新,公司已經有一套穩定的方式就可
作者: Wolfken   2014-10-29 09:25:00
不不不,Waterfall的效率跟Agile和DevOps相差太遠,絕不是什麼用習慣就可以的,遇到用DevOps跟Agile成熟的公司Waterfall的龜速一定被打趴在地上用大刀很熟練也打不贏拿自動步槍的
作者: GoalBased (Artificail Intelligence)   2014-10-29 12:57:00
Wolfken 公司用agile嗎? 羨慕-.-
作者: Wolfken   2014-10-29 14:50:00
目前正在往DevOps的路上邁進,不過還有很多努力空間
作者: alphadog (聖無極煞氣阿法豆‧再改X)   2014-10-29 19:11:00
(閱) 感謝分享。然而 私以為貴司開發流程看看即可 並無什可學習之處強烈依賴成員品質之開發流程,還不如不要制定開發流程
作者: blabla123 (念不停 煩不煩?)   2014-10-29 20:58:00
可以請 alphadog指教何處我司可加強?
作者: viper9709 (阿達)   2014-10-29 23:43:00
Waterfall跟Agile有差這麼多喔@@
作者: Wolfken   2014-10-30 00:05:00
有,只是很多公司還在用waterfall,當你的對手也都是拿刀那你拿刀也無所謂,但是如果你對手有人拿自動步槍,你不拿就肯定GG,現在是拿刀的還很多,所以還沒感覺那麼強烈
作者: blabla123 (念不停 煩不煩?)   2014-11-01 21:13:00
thanks ~

Links booklink

Contact Us: admin [ a t ] ucptt.com