hi，all：
最近完成了個小需求，有很多收穫，小需求成員一起做了總結，與大家分享。
需求流程相關
**********了解需求的背景*************************===
a）搞清需求**，就是誰提的需求，了解需求的商業價值。
b）搞清需求涉及哪幾條產品線。
c）確認產品線pd對該需求的了解情況：確認需求的時間點，需求內容等。
if(需求方不是產品線的pd)
d）搞清楚需求涉眾，常被忽略的是運營或客服
**********需求分析及時間評估*************************===
a）需求的功能點，需求的改動點，需求的影響點，需求的可行性，需求初步方案。
b）借助團隊和一切需要的資源：產品線pd，開發，測試，pla甚至架構
c）時間評估
參考產品線開發的評估時間，考慮自己處理小需求的時間，使用小需求時間評估模板。
重點元素：需求確認時間，設計時間，開發時間，自測時間，單元測試時間，review時間，與測試溝通時間，bug fix時間，聯調時間，發布時間，是否滿足需求方期望？
**********需求開發測試發布*************************===
a）制定小需求計畫，告知相關人。抄送老大。小需求跨度很長的話，定期告知需求進度。
b）設計
目的在於想清楚怎麼做，必要時寫出設計方案，找熟悉的開發，pla review方案。
介面設計，需求的功能點，需求的改動點，需求的影響點（通知到相關人），表結構等，重要資訊都應記錄下來。
c）開發，自測，review，聯調，對tc，功能預演，提交測試。
吃透需求，詳細的設計，這次開發的時間反而比預期短，也比較順利。達到事半功倍的效果。
功能預演：最好是能夠召集小需求涉及的所有人進行功能預演，每個人關注的點不一樣。
功能預演還是能夠在測試環境（開發環境，接近測試環境）下進行，問題也能夠及早暴露。
d）測試（bug處理，使用者體驗）
環境問題常占用很多時間，熟知依賴的環境是有利的。
e）發布
發布計畫（發布內容，時間，順序，負責人。發布前的準備，比如資料訂正的方案和流程。），
發布當天上午，**預合併。時間跨度大的，最好前一天就預合併下。
需求發布後郵件通知，需求歸檔，需求總結，jara平台關閉需求。
資源評估，時間管理
1.沒有ra，溝通時間比以前增加！
要思考如何降低溝通成本。
2.每天投入的時間比
只有會議培訓，正常能投入7h
如果還有應用維護，能投入到6h，已經不錯了。
如果同時還在專案後期，能投入到4h吧。
好的方面
1.充分理解需求，詳細設計，需求附加值
剛接觸這塊業務，完全不熟悉，充分借助團隊力量，除了pd，產品線的開發雲鵬，肖蓉，小紅都參與了需求分析和確認。並且我們也通讀相關**，從**分析業務邏輯。
詳細設計：設計方案（整體方案，**結構等）多次與曉軍，雲鵬溝通。
需求附加值：向處罰中心邁進一步，也是得到曉軍的點播。既要考慮小需求本身的價值，又要了解對產品發展有何作用（平時多關注個產品線的發展）。
2.責任心，良好配合（默契）
需求比較大(修改了78個檔案)，我和小亮還在兼顧阿凡達專案，能按期發布，與我們兩個良好的配合和責任心是分不開的.
由此想到乙個團隊，每個人不僅是完成自己份內的事情，只要稍微向前多邁一小步，就能把事情做的更好，更順，也會增加彼此的信任感和默契。（要讚下小紅和雲鵬，有很強owner感）
3.對需求有整體計畫和分工，對需求進度跟蹤與把控，對需求問題及時跟進。
產生的問題
1.**review問題
1.1 svn問題，正確的ci**原則？---小亮補充
由於不良的開發習慣,改完乙個檔案就慣性的進行比對後提交.特別是用svn外掛程式。
提交方式：命令先svn st svn diff 再svn ci。ci檔案很多，可以選擇外掛程式，最好是多選後，一次性提交。
提交原則：等待開發完乙個穩定可測的版本,比對沒問題後,再一次性提交**.減少svn伺服器消耗.
提交頻率：基於以上，頻率應該超過小時每次。
1.2列舉常量的使用問題,雲鵬已經分享過了。
public enum pricereportpublicitytype
public string getvalue() }
如果是unreasonprice("1")，資料庫的確需要存「1」，這樣可以達到見名知意的效果。
public enum publicitytype
**簡潔，引數傳入列舉（型別檢查），
誤區：資料庫沒有規定只能用小寫。
2.測試環境問題，測試不顯示正確結果，排查半天無結果，很有可能是環境配置錯誤--往往被遺忘這個原因。
3.兩個bug
3.1
乙個任務起不來，如果自測是可以避免的，從**分析，認為不會有問題（沒改邏輯）
充分自測
熟知應用的部署及依賴的外部環境（credit的web應用和daemon是分開部署的，web應用中的service是同過dubbo暴露的）
3.2傳送訊息的**空指標異常.
由於同樣邏輯的訊息傳送**專案中已經存在,所以直接把這一行**copy過來,且單元測試時用了mock,沒有發現此問題.用dzone做介面測試時以為是配置問題,
把此問題給忽略掉了.事實上原來的**在注入該傳送訊息的bean的時候做了id的轉換,所以導致我程式中這個bean沒有注入進來.
改進方法:做測試時一定不能放過任何可疑的地方.
3.信用檔案問題被提到三次是否確認？
問題一定要有owner，確認問題內容，完成時間，結果（有時需要進度）反饋給相關人。
4.發布前修改**（最後修改出問題，產生緊急發布）？
pd，開發等小需求或專案成員集體評估，要不推遲發布，要不不修改。
若果一定要改：
明確改動點，測試分支。一定要測試。切忌不能改**測試。
ci**，一定要svn st，svn diff。
最好兩個人一起完成（乙個改，乙個看著）
5.發布時候才知道有樣式發布，且需要和應用同步發布。
新的樣式，可以提前發布。修改原有的樣式，必須先發模板，後發樣式。這個同步是靠人去控制的。要仔細評估時間差帶來的影響。
跟ued溝通過，還沒有規劃，比如自動和**應用一起發布。已反饋給ued架構。
作為小需求負責人：
信用檔案改動點很小，沒及時跟進這塊的工作。發布計畫也把這塊忽略了，沒有與開發，ued，測試等明確發布計畫。這是乙個失誤。
***************====over******************************=
做需求分析時的小總結
引子 上個專案的在做需求時，改了又改，好不麻煩，現在我就記錄總結一下，下次要吸取教訓啊！1。要編寫需求分析的歷史記錄 因為客戶提供需求的過程是模糊需求 大概需求 明確需求 最後需求，所以需求分析需要不斷滾動完善，通過需求分析的歷史記錄有利於評估每個階段的工作。2 編寫需求分析時不是完全按照客戶的要求...
需求調研總結
以前零零散散的做過一些需求調研的工作，但是都是打醬油似的，對需求調研的乙個流程還是不清楚 經過這段時間和使用者關於乙個模組的二次開發的討論，對需求調研的工作算是有了乙個大致的了解。一 需求調研準備 1 文件方面 彙總相關的文件資料，對專案要有個基本輪廓的認識，需求調研模板，需求調研問題列表相關的資料...
小bug小坑小總結
1.小程式canvas那些原生元件的層級預設是最高的，而且不能更改，平常的div彈框什麼的上面就會顯示出原生元件的內容，解決辦法 cover view,cover image,button share data item item 分享 用這個data item 後的名字可以隨意起，後面的值如果是字...