專案管理大法歸檔，專案管理歸檔

專案管理大法歸檔，專案管理歸檔

專案管理大法歸檔 - 思維導圖、原型工具、介面測試、設計模式、版本管理、單元測試、持續整合、代碼審查、Bug 跟蹤

太陽火神的美麗人生 (http://blog.csdn.net/opengl_es)

本文遵循“署名-非商業用途-保持一致”創作公用協議

轉載請保留此句：太陽火神的美麗人生 -  本部落格專註於 敏捷開發及移動和物聯裝置研究：iOS、Android、Html5、Arduino、pcDuino，否則，出自本部落格的文章拒絕轉載或再轉載，謝謝合作。

專案管理大法歸檔：

1、思維導圖

如果你在想事情，而又不那麼清晰明確，那麼就用思維導圖吧，它可以隨著你的思維，很自然地記憶你思維的過程。

其實使用思維導圖，並不需要很刻意地構建成什麼樣，相反，它就是記錄，整體展示給你一個你自已靈亂思維的有序組合。

另一方面，思維導圖應該像筆記一樣，記錄於平時，最終自動整理出的圖反應了一段時間內你的思維過程。

與上面的使用方式正好互補。而我們更多是現想問題，現記錄，以便思維能基於現在能繼續進行下去，這中間選詞描述可能成為困難，隨便記些什麼表達就好了。

2、原型工具

選擇一種存在形式，也即鬼上身，或附體。

其實思維永遠要基於軀體去承載和執行，那麼思維導圖整理出的東西，必定要選擇一種方式去表達出來。

3、介面測試

藉助外物，那麼就得先瞭解外物，確定哪些可用，哪些不可用，以便計劃路線。

而介面的定義分三種情況：一種是雙方協商、一種是用戶端定義（此時商務邏輯重心壓在用戶端，小型項目）、第三種是服務端定義，當然也需要用戶端充分對需求和整體架構提出意見。

總之，脫離任何一方而制定出來的介面協議，必定是不完善的，只能是概要設計的一部分，在使用過程中，都會進行一定量的修改與完善，形成詳細設計。

是先行分析制定詳細設計方案，還是邊走邊看，邊做邊制定，這就看實際的人員能力和項目的需要了。

4、設計模式

把上面的東西組合起來，進行路線計劃吧。

23 種設計模式，其實只要理解了類的繼承、多態、複合、封裝，並能靈活地從繼承角度和派生角度去看這一體繫結構，那麼 23 種設計模式就不難理解了，

而且每種設計模式真正是為瞭解決一類問題而出現的，著重理解解決了什麼問題要比記錄寫法更容易掌握和靈活運用。

"獨孤九劍的最高境界是不拿劍"，設計模式運用的最高境界可能就是不受設計模式本身的限制，隨時根據自已的情況去運用對象的性特組合。

5、版本管理

其實版本管理系統應該在更早階段就應該在組態管理部分完成布署，這是 CMMI 的流程，它不光肩負著代碼的版本管理，還有文檔，更有一些文檔工具是支援版本比較的。

之所以放到這裡提到，主要是針對後兩者，就代碼而言。

或者現在的孩子們做開發，已經沒有這樣的習慣了，但我想那是一種應對現時環境的自我保護心態，相比之下，感覺現在的孩子的隨性、無所謂等等心態更適合生存，反而是我們這些紅旗下長大的一輩人，過重的責任心和約束自製，反而很容易被時下的環境所累，輕而易舉地被 Cancer 擊敗。

迴歸正題，設計模式部分完成了整個工程的架構設計和架構搭建，那麼接下來就是各個功能模組的編碼實現，每完成一塊兒，就要進行單元測試確保自已所實現的這一部分代碼是完整、可用的，再提交到開發版本庫中，

首先達到了最基本的代碼安全備份的作用;

二是代碼共用給團隊其它成員;

三是下一階段的開發基於此進行。

當然，這中間可能還會有開發到一半中途停止的情況，這個情況，當然是 Git 的本地版本庫管理對代碼進資料列版本設定才是較好的方案。而在團隊中進行共用，無論是通過SVN還是 Git 伺服器共用，都是可行的，相比較而言 Git 更靠譜。

當一個版本迭代所需要完成的所有單元模組都已經單元測試通過之後，進行整合測試，功能全部實現且健壯，再提交到審查程式碼程式庫中，產生版本號碼，交由主管審查。

這裡要說明的是，

一、整合測試並不只是在最後所有單元模組都完成時才進行，而是在每一個單元模組完成並整合到系統中（當然了，我們都是習慣直接在工程中去開發的，已經第一時間進行了整合）時，隨時進行測試，測試的目標是這個單元路徑上所關聯的一切部分（因為你要到達此單元模組，必定要依賴其它模組的事務完成）。

二、代碼審查針對單元測試進行才是最接地氣的。代碼審查庫（Redmine所監管的版本庫）的每一個接交版本，必須是開發版本庫中進行了有 效單元測試並驗證所開發單元模組功能可用，並且整合到項目中進行相關性測試也可用，不會引入新問題的情況下，才提交的。

相較笨重的 SVN，Git 的分布式版本管理特性和基於檔案系統而非伺服器的構建方式，更適合做代碼管理和代碼審核這樣的二級版本管理所用。

當然使用本地 Git + SVN 的方案也是可行的，那麼就要求開發人員，不要輕易的有更改就提交到 SVN ，而是最終開發確認沒有問題了再提交。

這中間存在一個本機宕機所帶來的風險。這樣考慮，提供開發版本伺服器也是必要的，達到冗餘備份的效果。

6、單元測試

無論是 Android 在 Eclipse 中使用 JUnit， 還是 iOS 在 XCode 中使用 OCUnit 或 XCTest，相比上面所講述的單元測試方式，可能更有針對性。

在上面所述的單元測試過程中，其實已經有了持續整合的測試過程，也有了測試驅動的概念，因為測試案例雖沒有寫出來，但實際是按照預其去測試來分析實際單元模組存在的問題並進行改進的。

那麼使用本節中的單元測試架構進協助進行測試，可以簡化很多麻煩，對被測部分提供有效預期前置。

但總體來講，即使再好的單元測試架構，也是需要由開發人員清醒的開發過程掌控來安排得當，才能充份發揮其效能，否則，單元測試架構就會變成不負責任的擋箭牌，而非懶人創造發明的助力。

7、持續整合

多餘否，不多矣！

單元測試完成了，開發的功能模組功能實現了，可是加入項目中，一是加不進去，二是加進去配合不起來。

這開發的是神馬東西呢？！可是一直有這種情況發生。因為沒有責任心，而這個時代，就是個沒有責任心的時代，就像“給員工發一個億”實現不了，就可以當沒說一樣，這是這個時代的特徵，而這種特徵確保了他們能生存下來，因為這種心態讓他們不那麼焦慮，而我們這一代人過重的責任心確成為了我們的負擔，甚至致命。不信，你看看現在的 Cancererer 們，有幾個是能夠拿得起、放得下、想得開、看得透、說做就做，做完可以不負責任的這類人？！確實沒有的。那麼 Cancer 時代的一個重要特徵，就是新生代不再有那麼大的壓力給自已，他們天生就適應這個時代，當然責任。。。那是另一回事了，也是很重要的東西，關乎社會的進步。不過總體來講，這一代人的心態，能保障生命的延續，難道我們也要像那些自稱優等確要滅絕的人口負增長民族？！

所以包容、理解，才能更好地接近和混跡於這一代人中間，聽得懂他們在說什麼、看得懂他們在做什麼，畢竟我們的餘生是在他們維繫的社會中度過，瞭解和理解很重要。

言歸正傳，之所有有持續整合，就是因為很多年的不持續整合！而不持續整合的原因是，機械化的開發，CMMI 應該是罪魁禍首。可是 CMMI 也沒這樣說啊，反問一下，引入國內的哪些技術是為了應用這門技術的，更多是如何用這門技術來管制的。這源於能動性，再深入不做探討。

總之，持續整合本是不該出現的東西 ，因為開發就是個持續的過程，為什麼會有不持續的事情發生呢？！

迴歸自然的開發，什麼事情都沒有了。

8、代碼審查

Redmine 有一個一鍵安裝包 Bitnami，可以快速構建代碼審查系統。

它可以關聯 SVN 或 Git 版本庫，還可以關聯郵件系統。

這部分有待進一步深入研究應用，後續補充體會。

9、Bug 跟蹤

持續整合以完善的單元測試作保障，這是代碼級的、功能級的，但絕不是業務級的、互動級的、使用者體驗級的。

而且在快速迭代的過程中，往往只考慮開發主線，而忽略了各種容錯處理、安全校正。

我想，Bug 跟蹤，應該是在不斷的整合過程中和進行系統測試時，對發現問題的反饋，這是一種黑箱測試的結果跟蹤，問題本身可能並不是問題的跟源。

而且這時所應該測出的不應該再有程式異常、崩潰等問題，而實際上是大大地存在的，這就要迴歸單元測試才能快速發現問題並解決。

而且有時一個問題，所牽扯的方面，並不指一個單元。

這就要求對 Bug 進行記錄，並跟蹤其整個解決過程。相比這種工廠式的生產過程，更容易出現 Bug，10 倍的人力投入，最終僅產生 5 倍的效果。

而把大任務進行模組化拆分，變成小系統，這樣針對小系統的管理成本相對要低，溝通成本也低，迴歸人性，由人來保障軟體的可用性，而非制度。

當然，制度可以規模化，但前提是你得把人先變成制度化的人，而且制度化的人，在離開崗位之後，其工作適應性很差，因為他是做重複性體力勞動的，不是腦力勞動。

Bug 跟蹤，很有必要，清晰地瞭解 Bug 描述，針對地處理，並能在同一個地方反饋問題的解決過程和結果。至於其它的，感覺起不到什麼作用，過份的管理，只能

讓敷衍成為一種風氣。

相比之下，人是有能動性的，充分激勵和發揮人的能動性，再配以這些工具管理，才能如虎添翼。

管理，永遠都是為了清晰、明了、有序，而非為了管理而實施任何手段，除了激勵和發揮人的能動性之外。

著作權聲明：本文為博主原創文章，未經博主允許不得轉載。轉載聯絡 QQ 30952589，加好友請註明來意。