微型專案是指絕大部分工作由乙個人員負責的專案，這個核心成員負責專案的系統分析、構架、及絕大部分的編碼工作。專案的持續時間一般不會超過乙個月。專案的參與人員除了核心的程式設計師外還可能一部分輔助人員，包括第二程式設計師（負責一部分編碼工作）、美工（負責介面設計）等。
微型專案的規模一般很小，業務邏輯也比較簡單，**一般也不會超過10k。程式設計師通常直接和對方領導打交道。客戶大多沒有任何技術背景。需要程式設計師直接負責系統的需求分析。
微型專案的流程可以說沒有什麼特別的，因為專案較小，通常談不上工程學方法。但是因為系統需求的不確定性較大，一般來說，敏捷得思路比較適合。流程如圖所示：
1， 需求分析。
2， 構架設計
3， 撰寫**
4， 增量交付
5， 應對需求變更
6， 最終交付
以上過程有時候並沒有什麼明顯的界限。鑑於專案的規模，大多時候在分析需求的時候，構建就慢慢的形成了，在形成構架的過程中，很多編碼上的難點也就了然於胸了。對於需求上的變化，幾乎是必然的。很多時候，專案預期乙個月，但是乙個星期就可以做完，剩下的三個星期都是在應對需求的變化。
這種小型專案的需求可能會千奇百怪，從常見的oa到醫院的藥房管理。從使用者的角度看，他們通常是為了方便自己的工作，提高效率。但是什麼樣的程式才能滿足他們的要求，他們也不知道。所以程式設計師就需要自己找到需求。
怎樣進行需求的分析呢，一般是從使用者溝通和對使用者工作流程的觀察出發。
在和使用者的溝通之中，使用者一般不會有系統的想法，或者使用者的想法不現實。我們要做的就是把使用者的想法記下來，然後從中提煉出真正的需求，打個比方：在乙個醫院藥房管理系統中，使用者說藥材會分為中藥和西藥。真正的需求其實是藥材需要進行分類，否則當專案開發出來使用者或許就會要求增加中西合劑。當然，這裡是要求敏銳的捕捉到使用者的真正需求，而不是無限制的做猜想而增加專案不必要的複雜性。還有一些是不清楚的需求描敘，仍然用那個藥房管理系統為例，使用者要求記錄入庫出庫資訊。這條描述其實很不清楚：要記錄哪些資訊？紀錄多長時間內的資訊？資訊需不需要有彙總和統計？當然需求的分析是乙個漸進的過程。這裡不但要求分析人員有敏銳的捕捉能力，還要求和用不斷的和使用者溝通，更多的讓使用者參與到系統的開發中來。
一般交付之後使用者的需求都會變更，這是因為使用者沒有技術背景，根本不可能清楚的描述系統的需要。所以使用者一旦看到最終的系統，就會發現和自己預想的想法有很大的出入。所以這裡的交付是個相對的感念，實際是指持續交付。所以敏捷開發在這類專案中是非常合適的工程學方法。
對於微型專案，幾乎乙個目錄就可以儲存所有的檔案，這樣做的方法也是為了便於備份和轉移。我常用的目錄結構如下：
從圖上可以看出，這乙個目錄包含了所有的資訊，以下詳細分析：
1， database。資料庫目錄。如果系統有不同的多種資料庫，可以在該目錄下根據資料庫型別建立子目錄，比如說sqlserver，access等。然後根據版本建立下一層子目錄。需要注意的時，有的資料庫，比如sqlserver 2000。會鎖定資料庫檔案，這樣在備份或者轉移專案的時候就需要先停止資料庫服務。
2， design。主要是儲存pagedesgin或者uidesign。
3， document。這個目錄比較重要，儲存的時所有的文件。下面按照「日期+文件名稱」的規則為每乙個文件建立子目錄。注意，這個目錄下的文件是正式提交的文件。同時，乙個文件可能提交過n個版本。
4， member。重要目錄。用於儲存專案所有成員的文件。類似於版本控制器。每個成員按名稱建立自己的子目錄，再在自己的目錄下按照「日期+該工作名稱」的方法建立目錄。目錄下儲存該項工作所有資料。包括文字、等。這樣每個成員的工作記錄都有據可查。
5， publish。專案發布的目錄。按照「時間+版本」的方式發布，我們的目標就是盡早的發布！注意發布中應該含有所有相關資訊，包括程式（安裝程式）、資料庫指令碼、幫助文件，甚至是燒錄光碟的autorun.inf。
6， ref。引用目錄，裡面放的是專案引用的第三方類庫和相關的幫助文件等。
7， solution。重要目錄。這就是我們的解決方案所在的地方了！一般是按照版本建立解決訪問。
9， team。團隊的公用資料夾。存放公用的資訊，比如說成員的****等。
10， template。模版。一般指文件模版，即dot檔案。目的是為了保證專案的文件都有一致、良好的格式。這點在對企業單位，特別是國有企業的專案中尤其重要。混亂的格式會給人不可靠的感覺，領導對此尤為敏感。
11， tools。專案所用到的工具軟體。比如說**生成器等。
12， tryproject。每個專案都可能涉及到一些我們不太了解的技術，這就需要我們做一些嘗試，這些嘗試也應該儲存下來，作為參考。我們可以建立一些tryproject進行實驗。
以上就是我管理文件的方法。從文件的管理方法其實可以反映出很多專案的情況。乙個良好的專案應該有良好的條理性。，具體展示出來的效果如圖所示：
需要說明的是，這個圖所展示出來的只是乙個demo。也是我為這篇文章所建立的。所有非常的小。真正的專案資料夾有幾個g大小是很正常的。
任何專案都需要有版本控制，這是無可厚非的。版本控制就是個大型的undo/redo。保證你隨時可以吃後悔藥。
版本控制的概念不應該僅僅只是捕捉**。所有和專案相關的資料都應該在**捉的範圍內。這些資料通常包括：文件、設計、資料庫（及指令碼），發布過的二進位製包。採集的資料等。這也是現在的版本控制軟體發展的方向。
對於文件、設計等，其實前面的文件管理方法就是一種版本的控制方法。
對於**，這個級別上的專案vss無疑是最合適的選擇。不管有沒有第二個程式設計師，**的版本控制都是有益無害的。
1， 資料庫
資料庫如果在團隊專案中，一般是架設在專門的伺服器上的，這樣大家都可以根據同乙個版本進行開發。不過資料庫的修改就要比較謹慎。同時要建立好資料庫備份計畫。
如果能夠分離資料層，或者採用orm等框架，支援資料庫型別的轉換，那麼採用access進行開發，部屬的時候採用sql也是乙個不錯的選擇，這樣備份和轉移的時候依然可以乙個copy搞定。
2， 備份
由於檔案都在乙個目錄中，所以備份文件就是把整個專案目錄copy以下，不過有的時候最好清理一下testresults（單元測試結果）資料夾，再壓縮一下solution資料夾。如果使用了vss，還要記得備份vss的資料庫。
以上的方法不一定是最好的，只是我在做專案的過程中總結的一些適合自身的技巧。希望對大家有幫助。也希望起到拋磚引玉的作用。
艾偉也談專案管理，微型專案實踐感悟
微型專案是指絕大部分工作由乙個人員負責的專案，這個核心成員負責專案的系統分析 構架 及絕大部分的編碼工作。專案的持續時間一般不會超過乙個月。專案的參與人員除了核心的程式設計師外還可能一部分輔助人員，包括第二程式設計師 負責一部分編碼工作 美工 負責介面設計 等。微型專案的規模一般很小，業務邏輯也比較...
微型專案實踐（1） 用XML描述實體
系統設計的第一步當然是分析需求，目前能夠想到的就是對日誌的管理，恩 再加上乙個分類好了，大體就是這樣子 我們使用乙個xml來描述這兩個實體 1 xmlversion 1.0 encoding utf 8 2 entities xmlns 3 entity title 日誌 name blog mod...
專案管理感悟
專案進行到設計階段時，持續時間偏差已經達到80 而整體進度不允許時間偏差，這就意味著需要在後面的階段中追趕進度，把 前面耽誤的時間給追回來。人力沒有補充，工作量在那裡明擺著，開會時所有的開發人員都怨聲載道 量那麼打，時間那麼短，肯定完成不了，如果實在要在指定的時間內完成，那只有湊合，不能保證質量 我...