本文章主要聚焦在項目流程管理，匯總記錄一些工作中心得體會。

項目流程

流程體系旨在提高工作效率，明確流程接口和步驟，確定相關崗位和相關事務要求、原則和規則。流程管理，簡而言之，就是各司其職，節奏合適。產品的需求和開發的Bug有工具跟蹤，軟件發布按照節奏來，需求提交給具體開發前，需要和開發主管討論可行性，有專門的測試反饋和每日進度規劃。知道今天要做什麽，也知道明天要做什麽。

個人在開發過程中，要提前計劃好要做的事情，在自己目前能力範圍內，做到目前的最好水平，保值保量。

開發流程

提出問題

當我們發現別人代碼裏面不好的地方時，如何既能提醒別人，又不讓他人尷尬。作為代碼當事人，面對對方挑錯時，正常的第一反應是：你在挑我毛病，我不接受。而受過良好訓練的人，會做到“君子聞過則喜,小人聞過則怒”.

在與跨部門、跨地區同事進行溝通時，在正式開始溝通前，自己需要做一些準備工作，將問題域有關的背景情況整理出來，發送給其他同事，讓大家在後續的討論中有一個相同的上下文環境，在正式溝通中，按條理提出具體問題，對每一個回復的答案，自己心裏要問自己，針對這個問題，我得到滿意的答復了嗎？如不滿意，及時提出反饋。

具體在給別人描述問題時，發現文字的表達力度不夠，經過一段時間的時間，發現將問題發生的現狀截圖下來，在一旁備註上必要的描述信息，圖文並茂，關聯信息聚合在一起，便於對方迅速了解問題。

討論大問題時，要先對大問題進行分解，分解為若幹互相關聯的子問題，在提出討論之前，自己需要在腦子裏面過一片，哪些是這些問題鏈條的頭，先討論哪個，哪個有結論後可以繼續下一個問題，直到所有問題，按照順序依次得到確認。

對於一些更復雜的流程性問題，建議繪制流程圖來提出問題，根據流程圖的定位，可以分為概要設計流程圖和詳細設計流程圖，就溝通對象負責的層級，選擇不同層次的流程圖予以溝通應對。
下面通過一個例子來給出概要和詳細流程的區別。
例如，某種物品要進行賣出，賣出前要根據相關信息判斷是否有賣出的權限，如果能夠賣出，接下來要做什麽提示和操作。

從概要流程出發，該問題就一個分支，“物品是否允許賣出”，從詳細流程觸發，物品在條件1或條件2，成立時是不允許賣出時，不同情況的錯誤提示語是不同的，而其他情況是允許賣出的。

小結一下：概要設計、詳細設計是針對開發實踐來說兩個不同層面的流程抽象，我們在一個層面上考慮時，不要過多考慮另外一個層面的細節，否則，整個流程就會抓不住重點，既有概要過程、又有詳細處理，顯得冗余繁雜。

討論問題

在同別人討論問題時，發現自己容易激動，很容易討論著，就把問題給帶偏了，本來剛開始在討論A問題，討論討論著，就跑向B問題，再討論一段時間，就忘記剛開始要討論的問題了。這個過程中有需要改進的地方：

• 在討論的時候，要尊重別人的意見和看法，等別人把話說完，如果可以的話，先復述一片問題，提出對別人的看法後，再就討論的問題給出自己的看法。如果中途自己嘗試打斷別人，一定要忍住這個沖動。

正確理解別人的前提是能夠完整接收別人的信息，對於同一個問題或者說是概念，不同人有不同人的判定是很正常的事情，同別人討論會多一些思考的角度，更加完善的看待事物。同時，要對自己有明確的認知，認知到自己在哪些地方存在不足，下一步往哪裏去提高。

記錄問題

在工作過程中，有一些問題在qq群裏面討論的，一位同事拋出一個問題，大家東一句、西一句的討論，很多時候，討論到最後，沒有一個最終排版確認的人，造成討論的很多，實際能落地執行的很少。當遇到這種情況時，開發人員需要就問題域以及各方提出的意見方案，梳理匯總成郵件方式，召集有關各方一起討論確定，達成一致後，由產品人員在JIRA單記錄關於此問題的已確認的解決方案，然後再轉交給開發進行開發修改。這裏應該是有開發來主導的，秉承著誰開發、誰負責的原則，來主動推動。不管前期是如何討論的，一旦方案確定下來，大家就要堅定不移的去執行。

如果是開發人員自己覺的有一些重構優化方面的需求，在動手之前，需要在JIRA上建一個優化需求單，限定好邊界，規定好內容，先交由上級審核，審核通過後再進行開發，這是事前告知流程。如果嫌每次重構都建單麻煩，可以以先將自己每次待重構的修改整理為補丁形式，和其他同事一起，選取一個集中時間，大家一起過一片這些重構類的補丁，一致審閱通過後，再建JIRA單和提交到代碼庫中。

召開會議後，一般需要會議記錄人員做一個會議紀要，會後要求會議記錄人員將會議紀要已確定達成共識的事項通過郵件群發給參會人員，明確後一步的工作方向。

接到新需求

接收到新需求時的工作流程

在接收到產品人員的需求或者級要求時，在時間允許的情況下，要主動詢問該項任務需要要做什麽，期望達到什麽樣的目標？對於一些尚不明確的地方，預備是如何處理的？要商量好整體業務流程和功能界限，討論清楚並且有合適的文檔指導情況下，在進行後續的概要設計和具體編碼。

詳細閱讀需求文檔和原型設計圖，這些文檔往往混雜著業務背景、需求說明，與需求無關的一些信息，需要在開發前，將文檔中與開發、測試相關的功能要求抽取出來，匯總在獨立的文件中，以此文件作為後續開發的參考文檔，當發現有不確定的地方時，先分類匯總起來，得到全部了解後，將這些不確定的地方一一同產品人員確認.

作為開發人員來說，不能生搬硬套產品提供的需求，要從自己的專業角度出發，對一些不合理的地方或者冗余的流程處理給出自己的意見，對於一些有悖於通用性的流程和交互的地方，需要產品給出信服的理由來說服開發人員實施，產品是著眼於這個需求，而開發考慮的是整體交互的一致性，能統一處理的，最好統一處理。

簡化合並某些業務流程，甚至在產品需求的基礎上，提出更好的業務流程，也是一個專業開發人員應該要做到的。

當產品提出了看似很簡單，但確需要修改框架才能實現的功能時，開發要第一時間站出來提出質疑，盡量引導產品提出在現有框架內能夠實現的功能。在一個已經成熟的軟件產品上，進行框架級別的改動來滿足某個蹩腳的需求，是具有極大風險的。有時候，寧可不做，也不要做錯。

• 待實現功能的前後邏輯關系和一些限制性的要求等。
• 非功能性需求，比如UI、交互的一致性，錯誤處理等要一一確認。這些需求文檔一般不會給出來，需要在開發過程中去產品人員討論後決定。
• 當前遇到的問題，以及對應的各種解決方法和對應的輸出結果。
• 異常情況的處理
• 自測流程

在一個已有實現的基礎上進行新界面的繪制，修改的原則是：保留原有實現不變，不要在原有實現上面去修改，而是用一個新的實現來代替原有的實現。

在一些必須要公用修改的地方，比如顏色的取值之類的，如果新的修改會影響到舊的實現，那就要討論下，是用新的顏色段還是修改公用的顏色段。

進度報告

對於開發量比較大的開發任務，需要較長時間才能全部，在向上匯報時，需要註意技巧，不要說還剩多少工作沒做，改為已經完成了多少工作。至於量化的進度，比如完成了50%、80%之類的，自己說出來都覺的不可信。自己接收前，要進行任務分解，有大至小，逐步細化，一直細化到可落地實踐的程度，以1，2，3，4，5這樣羅列出來，每天完成了什麽，就打上一個勾，讓上級知道工作進度，

換位思考，作為領導，向下屬發出一個任務時，領導希望得到什麽？個人認為是希望得到及時的反饋，無論是階段性的成果或者是遇到難題卡殼，及時，主動，條理清晰地向上級反饋工作，在實際工作中是非常重要的。

寫工作總結的時候，整體最好以總分總的形式排列，具體到各個分任務時，在內部也要遵循先總後分的原則，第一句話概括提煉該段文字的中心思考。重點工作要重點描述，對於重點工作的判定，起初我是這麽認為的，自己在哪項任務上面花費了最多的時間，就認為哪項任務是重要任務。經過同事的指點後，發現自己的這種認識是存在偏差的。重點的工作，不能僅僅從完成這項工作的時間長短上來判斷，而需要站在更高一層上上，從團隊職責、功能模塊層面去考慮。這種需要從具體功能點的編碼，上升到功能實現對外體現的價值上來。

在此以一個例子來說明：

比如，針對查詢頁面，完成的各頁面的拆分，列表支持穩定排序，表頭統一對齊，這些是很具體，很細節的工作，如果硬要從這幾項具體的工作中找出重要的工作進行描述，那往往會顧此失彼，抓不住重點。

解決方法是：站在更高一層上面去看待目前的工作，層級提高，就會缺少對細節的描述，但會從一個更加高的視角去看待工作所在的意義。比如說，這些改動，從用戶的角度上來看，統一UI風格，優化用戶交互視覺體驗，具體包括查詢表的穩定排序、風格統一、刷新邏輯統一等。高層次的描述，需要具體層面的配合，才能更加有說服力，可以配合一兩個具體的頁面來描述。另一個視角是從開發上來看待，按業務拆分後，有效降低代碼耦合度，減少後期維護成本。

改Bug

總體原則

不要混合修改Bug和優化流程，這一次，又在這裏掉坑裏面去了，JIRA單分為Bug單、新功能單和優化改進單。

每次提交代碼的範圍要最小化，一次提交解決一類問題，不要在提交中混雜其他問題。

嚴格守好提交紀律，對於已經測試過的代碼，在沒有新需求或者新功能之前，一定不要去修改。

只有JIRA單流轉到我名下，我才有需要去做，否則的話，別人口頭上一句話、或者QQ群裏面的一切討論，不管有沒有最終定論，如果沒有反饋到JIRA單上面，就都不算數。白紙黑字寫下來的才行，口頭告知、或者群聊天等，無法明確留痕的討論，都不算數。不要別人一句話，自己哼次哼次的思索分析了大半天，結果別人又來一句，不用管了，那自己之前的心血就白費了。

當和別人共同修改一個問題時，JIRA單在別人名下，自己做的修改以及提交，要及時的更新到JIRA單上，以明確自己在此Bug解決過程中所做的工作。

在改一個Bug時，不要僅僅局限於當前這個模塊產生的Bug，想一想類似的Bug，在工程中其他地方會不會存在，如果存在的話，要一並修改，並且在JIRA單上註明修改影響範圍和測試建議。

具體到戰術層面上的，可以分為如下幾個方面去逐步思考，探究。

1. 分析之前寫的不好的地方，找出可能的隱患，總結出這個不好的地方所有可能的測試案例，有可能一些測試案例是測試那邊覆蓋不到的，或者說觸發此測試案例的組合條件非常隱蔽，難以觸發。

2. 分析如何修改，從這幾年的編碼經驗上來，對於最終的Bug表現來說，若從表現上逐漸深入查找，往往會找到一系列觸發條件，最終有一個根條件，我稱之為Bug觸發鏈,找到了該觸發鏈條，也就有了對應層級的修改方法，舉一個簡單的例子，比如說，因素A-->因素B-->因素C-->Bug現象，那麽解決方案可以C層級上處理，也可以在B上處理，也可以在A上處理，具體在哪一個節點處理，要看引入的處理會不會影響其他正常業務邏輯，最好的狀態是，只修改了Bug，而對其他業務沒有影響，這可以稱為改Bug的隔離性。若修改會對其他業務流程有些許影響，那看該影響是好的影響還是不好的影響。如果決定在這個層面上修改的話，不管是好的影響還是不好的影響，都要分析清楚利弊，同產品和測試人員溝通好後，再行動手修改，同時在提交Bug的備註信息上面進行詳細的說明。

3. 在具體動作編碼之前，要評估開發的時間。評估開發時間，是一個技術活，這不是說完成有多難，而是評估的準確度。
   就一個顯示用戶資產總覽的需求來說：經過前期任務分解，有如下子任務要完成：
4. 完成6條基礎數據指令的收發
5. 完成界面搭建
6. 在界面上測試基礎指令，封裝基礎數據
7. 同前端網頁聯合調試
8. 處理異常情況，比如頁面重入、請求失敗、切換賬號請求、請求回來前關閉窗口等等

9. 優化代碼效率，比如增加緩存已減少請求次數，優化業務邏輯，合並錯誤處理等。

具體操作

接到Bug的，首要任務是重現它。在改 Bug 的過程中，要定位是哪一行是造成該 Bug 的關鍵行或者關鍵塊？努力做到在不改變原有業務邏輯的基礎上改對Bug。

在進行分支Bug的修改時，經過生產實踐，討論的流程如下，大家一致在主線分支上開發，當開發到合適時候，拉出發布分支，
比如V0.1，在此分支上面修改Bug，待到V0.1分支調整到一個較為穩定的、可發布的狀態，就可以對外發布了。當V0.1分支正式發布後，將在V0.1分支上做的修改，逐個merge到主線分支上，這種方法較繁瑣，但可以保證提交到主線上面的修改可以對應到每一個Bug單。

在分支上，只做修改Bug，至於優化改進類的操作，建議在主幹分支上去做。

實現同樣一項功能，有的開發20行能解決問題，有的只需要10行，結果都是實現了功能，只不過一個效率不是那麽的好而已，項目組如有條件，可在開發和測試之間，如果條件允許的話，增加一個開發審核的流程，由高級開發人員審閱檢查本次Bug提交情況，並且提供思路和實現上的優化意見，有助於加強開發質量，降低Bug的打回率。

提交Bug規範

提交Bug的備註格式要統一科學的格式說明，目前工程中用到的格式如下：

Bug備註信息：

Bug單號：問題單號以及對應的標題描述，例如：JIRA-1000, 用戶在wifi情況下登陸會失敗
修改版本：V1.0
問題原因：描述問題產生的原因，盡量以精簡的語言描述
修改方法：用簡練的語言描述出來,文字要有前後的邏輯關系，比如，點擊刷新按鈕時，重置提示語、清空列表數據和緩存數據，滾動條復位。
影響範圍：以功能模塊或者頁面展示為單位來描述，能夠具體到特定業務模塊的，最好具體到特定業務模塊。比如一個功能模塊XXX，下面有子模塊A、子模塊B和子模塊C，此次                 
         修改影響到了子模塊C，那麽在這裏最好寫影響了功能模塊XXX中的子模塊C，而不能只寫影響了功能模塊XXX，給測試人員帶來了額外的測試負擔。
測試建議：如果Bug表現很簡單，那麽此處可以寫略，如果Bug表現的背後業務邏輯很多，那麽有必要業務邏輯通過1，2，3，4的流程列舉完整，列出此次改動的影響到的執行
        路徑（即使是調整了下原有路徑的命令規範等也在影響範圍內），一方面，要寫修改點的影響，另一方面要寫，該修改點所涉及到的界面的相關功能(包含修改點涉及到的功能以及未涉及到的功能)

Bug備註要簡潔精煉，想明白才能寫清楚。

寫Bug的問題原因時，要盡可能減少閱讀者的知識依賴，讓看到這個Bug的人員看一眼就能了解該Bug的前因後果，不要想當然的認為測試人員已經知道自己明顯知道的上下文背景知
識。沒有上下文的Bug描述規範，不是一個好的描述。想清楚問題的起源，闡述清楚問題的表現以及解決方法，是一個很重要的能力。

在一次提交中的所有涉及到的文件修改的內容和現有的說明，都要在JIRA備註裏面寫清楚，讓測試人員和產品人員知道。
改一個Bug，如果是單單針對這個頁面的Bug，改正很容易，但如果想要改正通用的，讓所有人都滿意，那很難。
凡是改Bug，就要限定修改的範圍，同一類型的問題，在其他界面往往都存在，限定修改和測試的範圍，讓各方人士統一目標。

在寫Bug描述時，千萬不要使用程序中的代碼，而要使用和代碼相關聯的界面顯示元素，因為測試在看這些描述時，是不知道你寫的代碼是什麽意思，他們只能看到界面，使用於代碼相關聯的界面元素，方便測試理解改動給界面帶來的影響。

有時候的Bug修改，可能既改對了當前JIRA單上面描述的問題，又改對了之前測試沒有發現的問題，對於這樣的修改，在備註裏面要註明清楚，修改後，一並改正了一個尚未被測試發現的問題。
如果你的修改涉及到其他分支上的修改，不管涉不涉及到具體執行邏輯的修改，只要對其他分支路徑造成影響的，都應該寫相關的分支的測試案例來進行覆蓋測試，已確保本次修改未影響其他分支邏輯。

提測格式：

提測版本：X.XX.XXX
版本路徑：\\XX\\XX\\XXX
提測內容：
測試建議：
請安排測試！

一般來說，一個Bug可能會經過兩三次反復修改後，才能算是完完整整的解決了，此處以提交2次代碼解決了一個Bug為例子，在第二次提交時，提交的備註要緊跟第一次提交到備註後面，關聯上SVN提交編號和對應的Bug單號，有助於從代碼回溯找到對應的Bug單。

Bug思考

對待一個Bug的看法，可以從Bug本身出發，哪裏有問題就改哪裏？這是第一種情況。

第二種情況是，不僅僅著眼於Bug本身，圍繞著這個Bug的相關流程，是不是有問題？

這裏指的有問題，指的是含雜了無關的、說不清道不明的業務邏輯代碼。或者是本來需要自身來處理，卻交給外部來處理的地方。在這種情況下，與其在已有基礎上修修補補，還不如整體重做，保持之前一樣的接口，內部實現邏輯完全重寫，向著最優、最簡的路線走上去。

每一種正確的改Bug方式都是各有利弊，沒有最好，只有最適合。

修改代碼保持謹慎，對別人的代碼保持敬畏。

改Bug有一個驅動原則：無Bug單，不要提交代碼，可以先在本地做一些簡單的修改測試，但直到有任務單，才去提交代碼，凡事可能影響其他路徑的，那麽一定會影響，要依賴完善的測試來覆蓋改動影響。。

修改的層級性，比如，來了一個Bug，經過初步分析後，發現只需要改動一處代碼即可解決此Bug，此時為“Bug修改”，但改正這裏，可能和前面的已有代碼有重復，因此，可繼續進行相關的邏輯合並修改，形成第二份修改，形成“優化修改”。

在提交時，就有多種方式了，具體哪一種方式更好，各有各的場景吧。

方式一：只提交“Bug修改”

方式二：將“Bug修改”和“優化修改”，作為整體，一次提交到代碼庫，此處的優化修改，很容易，也可以說是一定會有 超出範圍的修改，比如說，那個變量名看著不合適了，哪些重復的邏輯需要合並了之類的

方式三：區分提交“Bug修改”和“優化修改”，分兩次提交到代碼庫。

從開發目的來看，所有的開發工作，都可以匯總為三點：改Bug，新功能和重構。

• 改Bug期間，測試提JIRA單或者自己發現Bug來驅動，目標是改Bug，所以你的修改著力點就是改Bug，即使看到了一些特別容易重構的地方，只要和當前Bug不是緊密相關的，不要貿然去重構，讓改Bug的改的純粹些。

• 增加新功能期間，又可細分為兩種，一種在已有實現上增加新功能，另一種是另起爐竈，開發新功能。第二種方式毋庸置疑，第一種方式，也不要想當然的擴大修改範圍，將當前的精力聚焦在增加新功能上，小的重構手法可以使用，不要貿然實施大的重構手法。

• 重構開發，如果是單純的重構開發任務，那麽要聚焦優化範圍，一次只提交一種類型的重構改動，保證每次提交的功能一致性和可測試性。

開發小結-流程管理類-上篇