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