項目，從零開始
----- Jack 于湖大 2007/11/10
一. 調(diào)研需求
<<理論部分>>
由于專業(yè)的限制，用戶很難準(zhǔn)確地把系統(tǒng)需求傳達(dá)給開發(fā)商；由于業(yè)務(wù)的限制，開發(fā)商也很難準(zhǔn)確獲取用戶真實的應(yīng)用需求。需求描述的錯位，容易引起系統(tǒng)設(shè)計的缺陷，最終導(dǎo)致系統(tǒng)應(yīng)用不理想甚至系統(tǒng)失敗。可以說，需求調(diào)研是信息化建設(shè)的第一步，也是關(guān)鍵一步。
需求調(diào)研涉及三個問題。一是如何確定調(diào)研對象，二是如何確定被調(diào)研對象，三是采用何種調(diào)研方法。調(diào)研對象的組成應(yīng)以互補(bǔ)為原則，至少要由三類人員組成：技術(shù)人員、業(yè)務(wù)專家和管理者。被調(diào)研對象主要是人員和業(yè)務(wù)兩類，其間主要涉及人與人、人與事物、事物與事物等三種關(guān)系。
其中，關(guān)鍵是確定調(diào)研范圍。調(diào)研范圍包括關(guān)鍵域和關(guān)鍵活動。而關(guān)鍵活動又由關(guān)鍵流程加關(guān)鍵點(diǎn)構(gòu)成。找到關(guān)鍵域，明確關(guān)鍵流程和關(guān)鍵點(diǎn)，對需求調(diào)研至關(guān)重要，需要專家或咨詢顧問介入。而能否把握這一時機(jī)并找準(zhǔn)需求提煉的關(guān)鍵點(diǎn)，是考驗需求調(diào)研人員的重要方面。優(yōu)秀的需求調(diào)研人員不僅能認(rèn)識問題之所在，還能藉此獲取足夠多的知識，最后成為問題領(lǐng)域的專家。
調(diào)研方法一般有問卷法、面談法、數(shù)據(jù)采集法、用況法、情景實例法以及基于目標(biāo)的方法等。此外，還有知識工程方法，如場記分析法、卡片分類法、分類表格技術(shù)和基于模型的知識獲取等。然而最基本的方法還是問卷法和面談法。
<<實戰(zhàn)部分>>
需求說白了就是用戶需要什么樣的軟件，客戶拿它來做什么。
做需求：
1. 盡可能的熟悉用戶的業(yè)務(wù)，把握其工作流程，這就需要有效溝通。
2. 把我們的用戶進(jìn)行分類，看他們的大概技術(shù)水平，并進(jìn)行記錄，對不同用戶設(shè)計不同的視圖界面，滿足不同層次的用戶。
3. 了解一下我們客戶的客戶，分析他們之間關(guān)系，來發(fā)現(xiàn)隱式的需求。
4. 再就是看看他們經(jīng)常使用的報表，并進(jìn)行分析、整理。
5. 派遣人員到客戶公司實習(xí)工作一段時間, 體驗實際。
6. 還有就是試探性的問，讓他們找問題———我們先說出一個原型，他們看到不對的地方他們提出來，也就是讓他們找錯
這部分需要給客戶一個<<投資計劃書>>或<<商業(yè)理由>>
二. 分析需求
<<理論部分>>
需求工程是繼軟件工程之后的又一熱點(diǎn)工程。從理論上說，包括調(diào)研需求、模擬和分析需求、需求描述、需求認(rèn)可、需求演進(jìn)這五個層次，并且逐層遞進(jìn)、螺旋式上升。需求分析是需求工程的核心，貫穿于系統(tǒng)整個生命周期。
需求分析的出發(fā)點(diǎn)在于：對調(diào)研的需求進(jìn)行進(jìn)一步提煉并指導(dǎo)需求的抽取；幫助需求分析人員發(fā)現(xiàn)問題。需求模擬則幫助檢查驗證對問題的理解。需求分析和模擬又包含三個層次的工作：需求定義、需求建模、需求模擬。
需求定義，是對經(jīng)調(diào)研獲取的需求進(jìn)行初步整理，抽取其中基本需求和關(guān)鍵需求予以界定，并為需求建模提供必要的需求元素。
需求建模，是把抽象的需求通過概念、符號、數(shù)學(xué)模型及邏輯結(jié)構(gòu)表現(xiàn)出來。表現(xiàn)形式有自然語言、半形式化（如圖、表、結(jié)構(gòu)化英語等）和形式化表示等三種。自然語言形式具有表達(dá)能力強(qiáng)的優(yōu)點(diǎn)，但不利于捕獲模型語義；半形式化表示可捕獲結(jié)構(gòu)和一定的語義，也可進(jìn)行一定的推理和一致性檢查；形式化表示具有精確的語義和推理能力，但構(gòu)造一個完整的形式化模型，需要較長時間和對問題領(lǐng)域的深層次理解。相對而言，圖表形式的需求模型直觀常用，比如組織結(jié)構(gòu)圖、系統(tǒng)流程圖、網(wǎng)絡(luò)拓?fù)鋱D等。
描述需求的任務(wù)是撰寫軟件需求規(guī)格說明書，這是需求調(diào)研和分析的直接成果。好的需求規(guī)格說明書需求層次清晰、語言專業(yè)且簡練、基本需求描述完整、特定需求既有現(xiàn)實性又有前瞻性、流程和結(jié)構(gòu)定義準(zhǔn)確、有可操作性、可逆性等。
需求規(guī)格說明書的主要服務(wù)對象可能來自于用戶、系統(tǒng)分析員、軟件需求分析員、軟件開發(fā)者、程序員、測試員、項目管理者等。但歸根結(jié)底還是要尊重用戶發(fā)展戰(zhàn)略和機(jī)構(gòu)運(yùn)行策略所必需的現(xiàn)實的和潛在的期望。
需求描述完成并不意味需求工作的結(jié)束，需求認(rèn)可和需求演進(jìn)是確保系統(tǒng)持續(xù)改進(jìn)的必經(jīng)之路。需求認(rèn)可就是讓上述人員對需求規(guī)格說明達(dá)成一致。需求演進(jìn)的必要性是明顯的，因為用戶需求不斷變化，系統(tǒng)開發(fā)又總是落后于客戶需求的變化和增長，如何及時感知需求變化并系統(tǒng)整理成為系統(tǒng)進(jìn)化的首要問題。可以說，基于需求演進(jìn)的管理效率直接決定了系統(tǒng)能否支持用戶的持續(xù)變革。
<<實戰(zhàn)部分>>
a) 需求分析是整個項目管理中需要重點(diǎn)控制的幾個關(guān)鍵節(jié)點(diǎn)之一，首先思想上一定要重視。
b) 需求分析報告的編寫者要參與到需求的搜集工作中，準(zhǔn)確領(lǐng)會客戶的意圖，并轉(zhuǎn)化成軟件能夠?qū)崿F(xiàn)的功能。對于說不清楚需求的客戶，要善于問關(guān)鍵問題，引導(dǎo)客戶提出自己的需求。可以采取的措施是事先編制一個問卷調(diào)查之類的文檔，詳細(xì)列舉需要客戶回答的問題，以便防止遺漏。
c) 需求報告的編寫者要能夠?qū)蛻粜枨筮M(jìn)行深入分析，區(qū)別出哪些需求存在日后變更的可能，哪些需求屬于相對固定的，哪些需求能夠?qū)崿F(xiàn)，哪些需求需要變通才能實現(xiàn)，以便于指導(dǎo)后面的功能設(shè)計。
d) 需求分析報告對功能細(xì)節(jié)的描述不能有歧義，描述一定要全面、準(zhǔn)確，防止開發(fā)方和客戶只見對同一個問題有兩個截然不同的理解。可以通過評審，用大家的力量來避免這種情況發(fā)生
e) 需求報告的每個關(guān)乎功能的描述都要讓客戶明白和理解，客戶在理解之上的確認(rèn)才能夠保證日后一旦出現(xiàn)問題不致出現(xiàn)雙方互相推托責(zé)任糾纏不清的情況。
f) 需求報告一定要經(jīng)過一個有技術(shù)人員和業(yè)務(wù)人員參加的評審，要充分發(fā)揮團(tuán)隊的力量，重視每個人的才智，一個模塊一個功能的逐一的過，讓大家來共同找出需求報告里不合理的、有歧義的、不完善的、遺漏的等等問題
g) 幫助客戶去理解提交給他的需求分析報告而不是只等簽字，對于有能夠用好幾種方式實現(xiàn)的功能，盡量做到能讓客戶去比較和選擇。不要讓客戶對報告中的部分產(chǎn)生歧義。只有客戶對報告的完全的理解，才能在日后客戶提出的修改被認(rèn)為是需求變更的時候能夠得到客戶的理解
h) 最后，需求分析報告一定要雙方共同簽字確認(rèn)
該階段的最終結(jié)果就是詳細(xì)的《軟件需求規(guī)格說明書》
三. 組建團(tuán)隊
項目成形，資金到位。接下來就是要組建團(tuán)隊來實現(xiàn)之前的構(gòu)想。當(dāng)然組建團(tuán)隊要看你是什么項目，以及項目的規(guī)模，一般項目人員在 6 到 10 人最佳。根據(jù)項目定出幾個角色，定多少角色以能完成項目為準(zhǔn)，然后一個蘿卜一個坑的去選人，先在公司內(nèi)部選擇適合人員，沒有就去招聘（可以到人才市場，可以到人才網(wǎng)站，也可以通過同事朋友介紹，當(dāng)然也可以到 blog 等網(wǎng)站挖挖人才），總之為每個角色找到最適合的人，記住是最適合的，不一定是最強(qiáng)的人。
以之前做的 <<網(wǎng)上作業(yè)系統(tǒng)>> 項目為例。參與項目的共 6 個人（本來 3 人就可以完成，但由于時間問題，增加到6個）。一個項目經(jīng)理 PM，一個開發(fā)經(jīng)理DM，一個測試經(jīng)理TM，一個開發(fā)人員，兩個測試人員。TM 兼任 UI 美工設(shè)計。PM 對項目做整體安排規(guī)劃，DM 對系統(tǒng)做整體架構(gòu)設(shè)計，TM 負(fù)責(zé)測試用例，美工和文檔編寫。PM,DM 和一個開發(fā)人員負(fù)責(zé)代碼編寫。
“一支程序開發(fā)團(tuán)隊之所以成立，是為了承擔(dān)并完成某項由任何個人都無法獨(dú)立完成的任務(wù)”。在我看來，這是對程序開發(fā)團(tuán)隊一個比較貼切的定義，通常在軟件企業(yè)里，會有若干支開發(fā)團(tuán)隊，它們因某一項目或產(chǎn)品而存在，項目完成了，團(tuán)隊也隨之解散，程序員在各個團(tuán)隊中得到不斷地學(xué)習(xí)與提高，除了技術(shù)能力，還有溝通能力、交際能力、協(xié)作精神等等，所以鄙人認(rèn)為，團(tuán)隊工作比孤軍奮戰(zhàn)更有助于個人的成長。
在現(xiàn)代的軟件企業(yè)中，分工合作正成為企業(yè)中一種工作方式的潮流而逐漸被更多的公司所提倡。因為只有團(tuán)隊合作，才能將復(fù)雜的事情變得簡單，將簡單的事情變得容易，使做事的效率倍增，可以說，團(tuán)隊合作正推動企業(yè)向簡單化、專業(yè)化、標(biāo)準(zhǔn)化的方向發(fā)展。在軟件這個特殊的行業(yè)，更需要如此，國內(nèi)的軟件企業(yè)長不大，出不了好的產(chǎn)品，第一大原因就是管理，第二大原因可能就是沒有一個出色的團(tuán)隊。
組建團(tuán)隊的目的是希望通過最小的代價獲得最佳的開發(fā)效果。因此我們盡可能找到出色的程序員，并根據(jù)他們的特點(diǎn)與優(yōu)點(diǎn)，進(jìn)行適當(dāng)?shù)姆止ぃ瑘F(tuán)隊成員間需要相互補(bǔ)充，才能更好地實現(xiàn)團(tuán)隊協(xié)作的功能。眾所周知，人與人的合作，不是人力的簡單相加，而是要復(fù)雜和微妙得多，溫伯格在這一方面總結(jié)了一個大致的規(guī)律：“由3名程序員組成的團(tuán)隊，只能夠完成1名能力相當(dāng)?shù)某绦騿T所完成之工作量的2倍。另外，如果每個開發(fā)組分別由3名程序員組成，那么基于同樣的原因，3個這樣的開發(fā)組協(xié)作完成的工作量，將是單個開發(fā)組的2倍，或者說是單個程序員所能夠完成的工作量的4倍。因此，假設(shè)某個工程由單個程序員需要8個月才能完成，如果我們希望在4個月內(nèi)得到結(jié)果，那么我們就需要派上3名程序員；而如果我們希望在2個月內(nèi)完成工作，就必須分配出9名程序員。”
想想看，是不是有一定的道理？但這不是絕對的，在項目的進(jìn)程中，有太多太多不確定的因素隨時出現(xiàn)，我們大多的項目總不能按時完成。剛開始做項目計劃時我們總喜歡一廂情愿地將開發(fā)過程中的所有條件都設(shè)想為最好的，但在實際的開發(fā)過程中，總會冒出一些亂七八糟的事情，有人生病了，有個嘔氣了，有人離職了，有PC總有故障，有一些BUG花太多的時間……
能在一個出色的團(tuán)隊中工作是一件很幸運(yùn)很開心的事情，你不僅學(xué)到很多的知識，而且系統(tǒng)的成功開發(fā)也讓你很有成就感。那么如何來組建程序開發(fā)團(tuán)隊呢？
溫伯格認(rèn)為：首先規(guī)劃出程序的理想結(jié)構(gòu)，然后按照最優(yōu)的方式，選取最合適的人選來承擔(dān)對應(yīng)的工作。
四. 開發(fā)，測試
人馬到位，就急需一次圓桌會議，項目主要干系人，產(chǎn)品經(jīng)理，項目經(jīng)理，系統(tǒng)分析員等討論立項問題，軟件公司和客戶完成簽字儀式，可以開工了。
開發(fā)前期由于需求不穩(wěn)定，急需客戶支持，必要時可協(xié)商客戶派代表參與開發(fā)。
項目經(jīng)理，系統(tǒng)分析員通過協(xié)商選擇一合適的開發(fā)過程，比如 RUP 過程, 敏捷過程, 微軟過程等等。兩個角色預(yù)先熟讀《軟件規(guī)格需求說明書》，并對需求在開發(fā)組內(nèi)展開討論，目的是讓每個人都熟悉需求，項目經(jīng)理制定開發(fā)計劃，任務(wù)以及相關(guān)文檔的編寫，他負(fù)責(zé)和產(chǎn)品經(jīng)理，客戶代表和測試組溝通，同時項目經(jīng)理和系統(tǒng)分析員要對需求進(jìn)行分解，將大系統(tǒng)分解成多個子系統(tǒng)，對每個子系統(tǒng)排序，每個子系統(tǒng)又分為多個功能模塊，對功能模塊排序。接下來就要精確估計開發(fā)時間和成本，并對系統(tǒng)分出迭代次數(shù)，可以橫向分也可以縱向分。
系統(tǒng)分析員負(fù)責(zé)系統(tǒng)的概要設(shè)計和詳細(xì)設(shè)計。這些可能需要一段時間，在這段時間內(nèi)，開發(fā)小組，測試小組可以熟悉需求，有問題及時交流，測試小組著手寫測試用例，及部分文檔。
分工會議，捉個功能分配人員，讓每個人選擇自己想要開發(fā)的功能并給出大概開發(fā)時間。這樣第一此迭代開始了，項目經(jīng)理可以監(jiān)督組員工作情況，每周寫項目進(jìn)展報告，每個星期收集已經(jīng)完成的功能已郵件的形式通知測試組下個星期的測試任務(wù)。
每次迭代要有緩沖時間，整個開發(fā)時間也要留有緩沖時間。時間多少由項目和具體時間而定。
PM 一定要靈活，項目開發(fā)過程中，對特殊情況及時作出調(diào)整以保證開發(fā)進(jìn)度和軟件質(zhì)量。
五. 實施，收尾
每次迭代都會有一可運(yùn)行版本發(fā)布，供測試小組和公司內(nèi)部人員測試，即內(nèi)測。當(dāng)整個開發(fā)周期完成之后，就需要業(yè)務(wù)人員，技術(shù)支持人員，開發(fā)人員和管理人員到客戶那里驗收。驗收可能需要一定時間，或者需要幾次驗收，直到和客戶簽字。
項目收尾了不代表項目周期的結(jié)束，客戶軟件還需要我們維護(hù)。比如公司可免費(fèi)為客戶維護(hù)一年。之后每年必須繳納維護(hù)費(fèi)用。
本博客為學(xué)習(xí)交流用，凡未注明引用的均為本人作品，轉(zhuǎn)載請注明出處，如有版權(quán)問題請及時通知。由于博客時間倉促，錯誤之處敬請諒解，有任何意見可給我留言，愿共同學(xué)習(xí)進(jìn)步。