微型項目實踐感悟
1
什么是微型項目
微型項目是指絕大部分工作由一個人員負責的項目，這個核心成員負責項目的系統分析、構架、及絕大部分的編碼工作。項目的持續時間一般不會超過一個月。項目的參與人員除了核心的程序員外還可能一部分輔助人員，包括第二程序員（負責一部分編碼工作）、美工（負責界面設計）等。
微型項目的規模一般很小，業務邏輯也比較簡單，價格一般也不會超過
10K
。程序員通常直接和對方領導打交道。客戶大多沒有任何技術背景。需要程序員直接負責系統的需求分析。
2
微型項目分析
2.1
一般流程：
微型項目的流程可以說沒有什么特別的，因為項目較小，通常談不上工程學方法。但是因為系統需求的不確定性較大，一般來說，敏捷得思路比較適合。流程如圖所示：
1，?????
需求分析。
2，?????
構架設計
3，?????
撰寫代碼
4，?????
增量交付
5，?????
應對需求變更
6，?????
最終交付
以上過程有時候并沒有什么明顯的界限。鑒于項目的規模，大多時候在分析需求的時候，構建就慢慢的形成了，在形成構架的過程中，很多編碼上的難點也就了然于胸了。對于需求上的變化，幾乎是必然的。很多時候，項目預期一個月，但是一個星期就可以做完，剩下的三個星期都是在應對需求的變化。
2.2
需求分析
這種小型項目的需求可能會千奇百怪，從常見的
OA
到醫院的藥房管理。從用戶的角度看，他們通常是為了方便自己的工作，提高效率。但是什么樣的程序才能滿足他們的要求，他們也不知道。所以程序員就需要自己找到需求。
怎樣進行需求的分析呢，一般是從用戶溝通和對用戶工作流程的觀察出發。
在和用戶的溝通之中，用戶一般不會有系統的想法，或者用戶的想法不現實。我們要做的就是把用戶的想法記下來，然后從中提煉出真正的需求，打個比方：在一個醫院藥房管理系統中，用戶說藥材會分為中藥和西藥。真正的需求其實是藥材需要進行分類，否則當項目開發出來用戶或許就會要求增加中西合劑。當然，這里是要求敏銳的捕捉到用戶的真正需求，而不是無限制的做猜想而增加項目不必要的復雜性。還有一些是不清楚的需求描敘，仍然用那個藥房管理系統為例，用戶要求記錄入庫出庫信息。這條描述其實很不清楚：要記錄哪些信息？紀錄多長時間內的信息？信息需不需要有匯總和統計？當然需求的分析是一個漸進的過程。這里不但要求分析人員有敏銳的捕捉能力，還要求和用不斷的和用戶溝通，更多的讓用戶參與到系統的開發中來。
一般交付之后用戶的需求都會變更，這是因為用戶沒有技術背景，根本不可能清楚的描述系統的需要。所以用戶一旦看到最終的系統，就會發現和自己預想的想法有很大的出入。所以這里的交付是個相對的感念，實際是指持續交付。所以敏捷開發在這類項目中是非常合適的工程學方法。
2.3
文檔的管理
對于微型項目，幾乎一個目錄就可以保存所有的文件，這樣做的方法也是為了便于備份和轉移。我常用的目錄結構如下：
從圖上可以看出，這一個目錄包含了所有的信息，以下詳細分析：
1，?
Database
。數據庫目錄。如果系統有不同的多種數據庫，可以在該目錄下根據數據庫類型建立子目錄，比如說
SqlServer
，
Access
等。然后根據版本建立下一層子目錄。需要注意的時，有的數據庫，比如
SqlServer 2000
。會鎖定數據庫文件，這樣在備份或者轉移項目的時候就需要先停止數據庫服務。
2，?
Design
。主要是保存
PageDesgin
或者
UIDesign
。
3，?
Document
。這個目錄比較重要，保存的時所有的文檔。下面按照“日期
+
文檔名稱”的規則為每一個文檔建立子目錄。注意，這個目錄下的文檔是正式提交的文檔。同時，一個文檔可能提交過
N
個版本。
4，?
Member
。重要目錄。用于保存項目所有成員的文檔。類似于版本控制器。每個成員按名稱建立自己的子目錄，再在自己的目錄下按照“日期
+
該工作名稱”的方法建立目錄。目錄下保存該項工作所有資料。包括文字、圖片等。這樣每個成員的工作記錄都有據可查。
5，???????
Publish
。項目發布的目錄。按照“時間
+
版本”的方式發布，我們的目標就是盡早的發布！注意發布中應該含有所有相關信息，包括程序（安裝程序）、數據庫腳本、幫助文檔，甚至是刻錄光盤的
Autorun.Inf
。
6，???????
Ref
。引用目錄，里面放的是項目引用的第三方類庫和相關的幫助文檔等。
7，???????
Solution
。重要目錄。這就是我們的解決方案所在的地方了！一般是按照版本建立解決訪問。
8，???????
Source
。參考資料。可以是文檔，圖片，也可以是別人的產品，開源項目等。只要是對項目有參考價值的，都應該被捕捉。
9，???????
Team
。團隊的公用文件夾。存放公用的信息，比如說成員的聯系方式等。
10，???
Template
。模版。一般指文檔模版，即
dot
文件。目的是為了保證項目的文檔都有一致、良好的格式。這點在對企業單位，特別是國有企業的項目中尤其重要。混亂的格式會給人不可靠的感覺，領導對此尤為敏感。
11，???
Tools
。項目所用到的工具軟件。比如說代碼生成器等。
12，???
TryProject
。每個項目都可能涉及到一些我們不太了解的技術，這就需要我們做一些嘗試，這些嘗試也應該保存下來，作為參考。我們可以建立一些
TryProject
進行實驗。
以上就是我管理文檔的方法。從文檔的管理方法其實可以反映出很多項目的情況。一個良好的項目應該有良好的條理性。，具體展示出來的效果如圖所示：
需要說明的是，這個圖所展示出來的只是一個
Demo
。也是我為這篇文章所建立的。所有非常的小。真正的項目文件夾有幾個
G
大小是很正常的。
2.4
版本控制
任何項目都需要有版本控制，這是無可厚非的。版本控制就是個大型的
Undo/Redo
。保證你隨時可以吃后悔藥。
版本控制的概念不應該僅僅只是捕捉代碼。所有和項目相關的數據都應該在被捕捉的范圍內。這些數據通常包括：文檔、設計、數據庫（及腳本），發布過的二進制包。采集的資料等。這也是現在的版本控制軟件發展的方向。
對于文檔、設計等，其實前面的文檔管理方法就是一種版本的控制方法。
對于代碼，這個級別上的項目
VSS
無疑是最合適的選擇。不管有沒有第二個程序員，代碼的版本控制都是有益無害的。
2.5
其它方面
1，?
數據庫
數據庫如果在團隊項目中，一般是架設在專門的服務器上的，這樣大家都可以根據同一個版本進行開發。不過數據庫的修改就要比較謹慎。同時要建立好數據庫備份計劃。
如果能夠分離數據層，或者采用
ORM
等框架，支持數據庫類型的轉換，那么采用
Access
進行開發，部屬的時候采用
Sql
也是一個不錯的選擇，這樣備份和轉移的時候依然可以一個
Copy
搞定。
2，?
備份
由于文件都在一個目錄中，所以備份文檔就是把整個項目目錄
Copy
以下，不過有的時候最好清理一下
TestResults
（單元測試結果）文件夾，再壓縮一下
Solution
文件夾。如果使用了
VSS
，還要記得備份
VSS
的數據庫。
?
以上的方法不一定是最好的，只是我在做項目的過程中總結的一些適合自身的技巧。希望對大家有幫助。也希望起到拋磚引玉的作用。