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