一般產(chǎn)品人員進(jìn)行過需求采集，分析，篩選后就會進(jìn)行產(chǎn)品的設(shè)計。
在產(chǎn)品設(shè)計的過程中會產(chǎn)生PRD（Product Requirement Document 產(chǎn)品需求文檔 ）,如果是新產(chǎn)品或者在大公司一般還會有BRD （ Business Requirement Document 商業(yè)需求文檔）和MRD （Market Requirement Document市場需求文檔 ）。
當(dāng)寫好PRD之后就會畫出簡單的線框圖，在畫好線框圖后，為了后面更好的評估開發(fā)難度和開發(fā)時間，這時產(chǎn)品經(jīng)理就會和開發(fā)經(jīng)理和開發(fā)人員進(jìn)行一次簡單的會議，會議主要是介紹產(chǎn)品的功能點和交互。
這時開發(fā)人員進(jìn)行給出開發(fā)難度，如果功能點太難以實現(xiàn)或者比較復(fù)雜且優(yōu)先級不那么高的可能就會先實現(xiàn)主要功能（主要為了降低開發(fā)成本，看上線后用戶的反應(yīng)再進(jìn)行深度開發(fā)同時也是為了把試錯成本降低）。
沒有問題后，產(chǎn)品就會讓UI人員給出高保真原型圖，同時開發(fā)人員進(jìn)行開發(fā)。主要步驟如：
確定需求后，產(chǎn)品人員寫PRD和線框圖。
產(chǎn)品人員和開發(fā)人員進(jìn)行討論，評估開發(fā)難度和開發(fā)時間。（如果開發(fā)迭代時間固定，主要是評估難度）
UI根據(jù)線框圖和PRD設(shè)計出高保真原型圖，同時開發(fā)人員進(jìn)行開發(fā)，項目管理開始。
開發(fā)，測試，修改bug（開發(fā)中可能會出現(xiàn)需求更改的情況）
產(chǎn)品經(jīng)理（項目經(jīng)理）進(jìn)項驗收，沒有問題上線。
以前的開發(fā)大部分都是瀑布式開發(fā)，現(xiàn)在一把都采用敏捷開發(fā)。項目經(jīng)理這個職位一般也是只有在稍大的公司會有，在創(chuàng)業(yè)的小公司一般有產(chǎn)品經(jīng)理或者開發(fā)經(jīng)理來擔(dān)任。我們公司是由開發(fā)經(jīng)理來擔(dān)任開發(fā)進(jìn)度管理，最后由產(chǎn)品經(jīng)理驗收。
一般敏捷開發(fā)流程（每個公司的迭代周期不同，但大致流程相似。下面是兩個星期一個迭代）如下：如果我們需要從第1周周一開始開發(fā)新的迭代（假定第5個迭代）。那么就要在上周的周三，產(chǎn)品人員和開發(fā)人員進(jìn)行PRD評審，如有需要修改的地方進(jìn)行修改。（第四個迭代開發(fā)持續(xù)中，UI按照優(yōu)先級開始繪制已經(jīng)確定需求的高保真圖）
在上周的周五產(chǎn)品進(jìn)行修改后，再次和開發(fā)人員進(jìn)行評審，確定沒有需求沒有大的變動。（UI設(shè)計持續(xù)，啟動新的開發(fā)迭代（第5個迭代），進(jìn)行上次迭代(第4個迭代)總結(jié)會議和新迭代開啟會議），這時項目也會在進(jìn)行拆分，比如按照epic-story-sprint-task的方式進(jìn)行拆分。然后把這個迭代的任務(wù)拆分成各個小的task，然后進(jìn)行人員分配。task的時間顆粒度一般不超過兩天，分的太粗容易造成delay。task維護(hù)一般使用看板的形式，我們使用過的有Jira，kanbanflow，icafe等。（可以根據(jù)喜好使用，里面有相應(yīng)的曲線圖和燃盡圖）
第一周周一上班，UI同學(xué)會給出一部分設(shè)計的好高保真圖。這時服務(wù)端同學(xué)會根據(jù)安排好的優(yōu)先級給出相應(yīng)功能的接口文檔。移動端的同學(xué)進(jìn)行頁面編碼和設(shè)計。同時移動端同學(xué)會根據(jù)給出的接口文檔先造一批假數(shù)據(jù)已備本地測試（如果有相應(yīng)的接口測試工具會更好，我們是用的自己開發(fā)的接口測試沙箱，可以根據(jù)綁定的真假接口進(jìn)行真假數(shù)據(jù)的測試）。同時，每天下班前都要有站會。站會主要說自己的三個問題：1.今天做了什么2.有什么問題3.明天做什么
開發(fā)持續(xù)進(jìn)行，到第一周周四時，會先發(fā)個測試包，讓測試人員進(jìn)行測試。當(dāng)然開發(fā)過程中也在不斷測試。出現(xiàn)問題就進(jìn)行修復(fù),bug修復(fù)不再安排時間，不會在看板上建新的task來修復(fù)bug,開發(fā)任務(wù)繼續(xù)。
到第二周的周三，要確保開發(fā)任務(wù)基本完成。然后發(fā)個測試包，進(jìn)行測試。有bug進(jìn)行修復(fù)。同時產(chǎn)品經(jīng)理進(jìn)行查看。同時和產(chǎn)品進(jìn)行下的迭代（第6個迭代）的PRD評審。
到第二周的周五，再發(fā)個測試包，進(jìn)行測試。有bug進(jìn)行修復(fù)。產(chǎn)品經(jīng)理驗收。（沒有問題，一般會在夜里凌晨1-2點上線。)上線后可能要安排人員進(jìn)行值守，看有沒有問題。同時周五還要和產(chǎn)品進(jìn)行確認(rèn)最終新的開發(fā)。同時開總結(jié)會議和新迭代啟動會議，這兩個會議也可能放在周一開。
至此，一個迭代開發(fā)周期完成。
注意：在開發(fā)的過程中，項目經(jīng)理每天要通過看板或者詢問開發(fā)人員的進(jìn)度是不是符合原來的預(yù)訂計劃，如果出現(xiàn)delay現(xiàn)象，可能就要通過加班來把進(jìn)度提上來。
測試人員也要參與需求的評審，方便后面業(yè)務(wù)測試。
開發(fā)人員要對自己寫的代碼負(fù)責(zé)人，寫好后要進(jìn)行代碼review和自測，不能把沒有測試的代碼進(jìn)行提交。
