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