簡單的回答就是需求催生出來的。
首先是市場調研,發現使用者有這樣的需求。然後產品經理去整理需求,將使用者的需求轉換成文件,比如BRD(產品需求文件), MRD(市場需求文件), PRD(商業需求文件)這類的。
如果公司決定做這個需求了,那就開始排期開發,產品經理會先把PRD文件給到開發(PR)和測試(QA)。開發和測試明白需求後就幹活,開發人員做開發,測試人員寫測試用例。
開發人員開發完後會提交測試,這時候測試人員會按照PMD的說明去驗證程式是不是滿足文件的要求,如果有不滿足的就反饋給開發人員進行修改,直到程式滿足文件的說明,然後產品經理再驗證。
開發完後的軟體專案會交給運維,運維將專案部署到伺服器上後QA還需要去驗證線上的專案是不是正常,不正常的話需要進行回滾到上一個版本,修復問題後再發布(所以一般都是做灰度釋出,就是老版本的專案和新版本同時執行,使用者還是訪問的老版本服務,QA卻能訪問新版本服務)。釋出完成後這個開發迭代就算完成了。
然後下一個功能又來了。
不同的產品可能會有不同的流程,比如App的流程可能就和網站開發的流程不一樣,因為我是後端開發的,下面說的是網站開發的一個流程。
簡單的回答就是需求催生出來的。
首先是市場調研,發現使用者有這樣的需求。然後產品經理去整理需求,將使用者的需求轉換成文件,比如BRD(產品需求文件), MRD(市場需求文件), PRD(商業需求文件)這類的。
如果公司決定做這個需求了,那就開始排期開發,產品經理會先把PRD文件給到開發(PR)和測試(QA)。開發和測試明白需求後就幹活,開發人員做開發,測試人員寫測試用例。
開發人員開發完後會提交測試,這時候測試人員會按照PMD的說明去驗證程式是不是滿足文件的要求,如果有不滿足的就反饋給開發人員進行修改,直到程式滿足文件的說明,然後產品經理再驗證。
開發完後的軟體專案會交給運維,運維將專案部署到伺服器上後QA還需要去驗證線上的專案是不是正常,不正常的話需要進行回滾到上一個版本,修復問題後再發布(所以一般都是做灰度釋出,就是老版本的專案和新版本同時執行,使用者還是訪問的老版本服務,QA卻能訪問新版本服務)。釋出完成後這個開發迭代就算完成了。
然後下一個功能又來了。
不同的產品可能會有不同的流程,比如App的流程可能就和網站開發的流程不一樣,因為我是後端開發的,下面說的是網站開發的一個流程。