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的數據庫。
以上的方法不一定是最好的，只是我在做項目的過程中總結的一些適合自身的技巧。希望對大家有幫助。也希望起到拋磚引玉的作用。