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