SharePoint解決方案開發模型系列 - 團隊的創建

大約一年前，我曾經在blog上寫過 一篇文章，講述了我對於SharePoint解決方案開發模型的一些想法，其中包括了SharePoint解決方案開發的方方面面，從開發團隊，到開發環境的創建、物理與邏輯架構的設計、開發流程、信息架構、測試等等等等。這些主題我相信對於SharePoint開發人員、架構師、項目經理而言，都是很是有價值的。

既然直到如今，國內仍然沒有任何SharePoint開發書籍（固然也包括個人《SharePoint 2007 開發入門指南》）講述上面這些主題，因此決定開始在本身的blog上面，陸續就每一個主題，撰寫一些文章。但願這些文章能幫助到SharePoint技術社區。

往往涉及到比「具體」技術細節更高一層的架構、流程、方法論的東西，一般都很容易引發爭議。這是很正常的現象。這些主題和具體的諸如C#語法、怎麼作一個Web Part等等都不相同，由於這些主題根本就不會有一個標準答案。每一個人心中都對如何設計一個架構、如何實施某個流程都有本身的想法，而環境與條件的不一致，更是使得所謂的「最佳實踐」在不少場景中都不適用。因此，若是你對我撰寫的文章中的某些內容不承認，沒有關係，這些文章中的內容原本就不是「金科玉律」，甚至在你所處的場景中根本就是錯誤的。這些文章只表明我我的的意見（但其中確定有很多想法，來自MSDN以及其餘人所撰寫的博客和文檔），同時我也但願它們能成爲交流的一個平臺。若是你對文章中的內容有意見和想法，歡迎留言。高質量、有價值的留言，一般都能讓後來的閱讀者受益良多。

任何軟件項目的實施，都必須從實施團隊開始。因此，首先要講述的主題，是如何創建一個SharePoint實施團隊。

從本質上來講，實施一個SharePoint項目，與其餘類型的軟件項目，諸如ASP.NET、PHP，都不會有根本的差異。因此一個SharePoint實施團隊的組成，也基本上和一個標準的Web項目實施團隊相同。在下面的角色描述中，我基本上只會描述和SharePoint相關的部分，而其餘通用的內容則會盡可能省略。

項目經理

項目經理是整個項目的管理者。他負責指派任務、記錄和跟蹤進度、向老闆們彙報...總之，項目經理的工做就是要保證整個項目處於正常狀態，並能順利完成。在小型團隊中，項目經理有可能同時兼任業務分析人員。

業務分析人員

業務分析人員應當與客戶充分交流，弄清楚客戶的業務需求、流程等等信息（越詳細越好）。業務分析人員與架構師一塊兒工做，撰寫出應用系統的功能規格說明書（也可能叫其餘名字），無論咱們叫這份文檔什麼名字，它都應當至少包含有：
一、整個項目要解決的問題、目標
示例：「ABC公司是一家賣汽車的企業，它總共有300名銷售人員，銷售人員但願經過一個「客戶管理系統」對他們各自的客戶進行管理。在這個系統中，銷售人員可以查看本身負責的客戶、每一個客戶的詳細信息、每一個客戶的訂單歷史記錄等信息。同時，銷售人員還須要經過這個「客戶管理系統」提交季度銷售預測報告...」
二、針對用戶使用場景的User Cases
這裏的User Cases信息，應當詳盡的描述出用戶使用系統的每一個具體場景，它將做爲整個團隊的一個「基礎文檔」，架構師和開發人員根據這些信息，才能知道程序最終要實現的效果。每一個User Case裏面都要包含用戶幾乎每一個操做的描述和說明，以及每一個主要界面的圖示（使用Visio或其餘工具繪製），也就是說，它不能含糊，而應該清晰、明確、有針對性。
示例：「User Case 15 - 銷售人員Dashboard」
「銷售人員在「客戶管理系統」主頁上點擊「Dashboard」按鈕（參考User Case 5），就可以打開本身的Dashboard...Dashboard會自動校驗當前瀏覽用戶的身份和權限，若是的Dashboard以兩欄的方式來展示信息（參考圖15-3），其中左欄自上而下會包含5個連接，分別是...銷售人員點擊了左欄的「歷史訂單數據」連接以後，頁面將轉向到「歷史訂單數據」頁面（參考User Case 26）...中間的向右箭頭是一個能夠容許銷售人員將右欄摺疊起來的圖標，在點擊它以後...銷售人員能夠點擊右上角的「返回」圖標，以返回到「客戶管理系統」主頁...」

功能規格說明書不涉及具體的技術細節，不包含如何實現每一個場景的技術說明，不包含系統的設計內容。咱們能夠這樣想象，假設團隊中忽然來了一個陌生人，他但願能瞭解這個團隊到底在作一個什麼項目，這個項目是幹嗎的，實現了什麼功能，咱們能夠將這份功能規格說明書給他，而他確實能夠從這份文檔中瞭解到他但願瞭解的這些信息。

這份文檔不能由業務分析人員一我的獨自寫成，而必定要有技術人員（以架構師爲主）的共同參與。一方面，架構師的參與能夠保證規格說明書中的內容，在技術上是可行且合理的，另外一方面，也有助於架構師從業務角度瞭解系統，明白客戶的需求。

我我的對功能規格說明書的重要性很是推崇。在項目中，可能咱們不會撰寫詳細的設計文檔，可能咱們不會撰寫詳細的部署文檔，但一份詳細的功能規格說明書確是不可缺乏的。它的重要性體如今：
一、讓團隊中的全部人都明白咱們要構建的是一個什麼東西。若是沒有這樣的一份清晰的功能規格說明書，就不能保證團隊的全部人都一致瞭解團隊的目標。若是沒有它，業務分析人員會根據客戶的描述，在本身的大腦中想象出系統應該有的樣子，而後口述給開發人員，並假設開發人員徹底明白了本身大腦中的想法，而開發人員則會根據本身從業務分析人員那裏聽到的，在本身的大腦中又試圖去想象系統作出來應該是什麼樣子的，並假設這就是業務分析人員想要的樣子...總之，每一個人都會根據本身的「想象」，去猜想別人的意圖。而最後當開發人員把最好的東西給業務分析人員演示的時候，一般是業務分析人員大吃一驚：「我kao，怎麼是這個樣子？這根本和我告訴你的是徹底不同的東東...」而開發人員則會辯解：「胡說，這分明就是我根據你告訴個人要求作出來的...」
二、咱們有了一個能夠和客戶討論的東西。這份文檔能夠儘早的交給客戶審閱，客戶能夠根據這份文檔，瞭解到系統作出來會是什麼樣子，若是不滿意，客戶也能夠及早的和開發團隊進行溝通：「嗯，不對，在這個地方，其實咱們更但願看到一個選擇框，而不是用戶本身填...」
三、它是業務分析人員與開發人員之間的一份「合同」。業務分析人員能夠充分的假定，開發人員最後交付的，就是功能規格文檔中所描述的樣子，而開發人員也能夠充分的假定，業務分析人員須要的，也是文檔中所描述的樣子。

值得一提的是，功能規格說明書並不會（也不該該）限制開發人員的「自由」。它僅僅包含對業務場景、系統功能的詳細描述，可是不會寫上應該如何實現。它確定不會包含諸如「在這裏，咱們要建立XYZ類和ZYX類，前者用於從數據庫中查詢QWE表...」，也不會包含諸如「咱們將使用3層結構，並由5個主要模塊來構成整個系統框架...」之類的信息。如何設計、如何實現，應該由架構師和開發人員討論並肯定，而沒有必要寫到功能規格說明書裏面。

架構師

架構師首先應當與業務分析人員一塊兒撰寫功能規格說明書，以保證其中所包含的內容在技術上的可行性，這同時也能保證架構師很是瞭解整個系統的業務需求。其次，架構師應該以功能規格說明書爲基礎，爲整個系統設計物理架構和邏輯架構，將整個系統合理的拆分紅各個更小的模塊與組件，並將模塊與組件的開發任務分配給開發人員。架構師還要與開發人員很是緊密的一塊兒工做，與每位開發人員討論並肯定每一個模塊的實現方式。架構師應當是技術負責人，確保整個項目在技術上暢通無阻。

系統物理架構也就是整個系統在物理上、網絡上的拓撲模型。整個系統須要多少臺服務器？每一個服務器是什麼角色？網絡設置應該是怎樣的？是否須要DMZ區域中也要部署一臺SharePoint服務器（若是用戶須要從Internet訪問的話）？或是使用DMZ中ISA Server來進行Internet發佈？這些設計都是屬於系統物理架構上的設計。

系統邏輯架構是從邏輯上描述整個系統的結構。整個系統有幾個SharePoint服務器場？有幾個SharePoint Web Application？幾個Site Collection？每一個Site Collection是作什麼的？會包含哪些內容？爲哪一個羣體的用戶服務？各個不一樣區域的安全模型是怎樣的？這些設計就屬於系統邏輯架構設計。

子模塊與組件的拆分也是架構師須要承擔的工做。如何將整個系統拆分紅更小的模塊與組件？按何種方式與原則進行拆分？好比，是按照傳統的N層架構來拆分（將「數據層」模塊交給一個開發人員作，將「業務邏輯層」模塊交給一個開發人員作，將「UI層」模塊交給一個開發人員作...）？仍是按照業務功能來拆分（將「客戶數據維護」功能模塊交給一個開發人員作，將「訂單歷史數據查詢」功能模塊交給一個開發人員作，而每一個功能模塊實際包含了實現那個功能所需的全部從數據到業務邏輯到Web Part展示相關的全部部分...）？不一樣的拆分方式，就決定了如何爲開發人員分配工做，並會影響到後續一系列的諸如集成測試之類的環節。

開發人員

終於，開發人員登場了。開發人員的工做就是理解本身所負責的模塊與組件相關的業務需求，仔細閱讀（並可能參與編寫）功能規格說明書，與架構師緊密合做，將功能實現出來。

做爲一個SharePoint開發人員，是很是有挑戰性的。須要學習和掌握的知識點很是的多，纔可能從容不迫的將手頭的開發任務完成。擁有強有力的SharePoint開發人員，是整個項目可否順利完成的關鍵因素。

SharePoint開發人員須要掌握的知識包括：SharePoint、ASP.NET、XML、Windows Workflow Foundation、JavaScript、InfoPath，將來還可能須要加上Windows Communication Foundation、LINQ、Silverlight、PowerShell...

測試人員

當我說到「測試人員」時，實際上包含了兩類人。一類是對開發人員寫出的代碼進行測試的人，這種人可能由開發人員（經過貫徹Unit Test流程）兼任，第二類則是在SharePoint解決方案開發過程當中，進行集成測試和最終環境測試的人，這種人也能夠由某位開發人員兼任。

集成測試是指，在一個獨立的集成環境中（一般是一個「乾淨的」SharePoint服務器場），按期將全部開發人員交付的模塊與組件部署進來，並對它們的功能以及它們相互之間的關聯進行測試。一個集成測試環境對於SharePoint開發而言是必不可少的。

網絡與系統管理員 網絡與系統管理員是那些負責創建和管理開發團隊所使用的各類環境的人。這些環境包括位於每一個開發工做站上的開發環境，進行集成測試的集成服務器環境，進行部署前測試的最終測試環境，以及生產環境。網絡和系統管理員負責將開發人員交付的模塊與組件，部署到各個環境中（好比測試環境、生產環境）。將有了環境管理員，開發人員也能夠快速的獲得一個標準的SharePoint開發環境。網絡與系統管理員能夠由某位很是熟悉SharePoint管理的開發人員兼任。 固然，根據各個項目需求的不一樣，團隊中還可能有其餘的角色存在，好比美工、文檔編撰人員等。這些咱們就再也不一一詳述了。本系列的下一篇文章，將講述SharePoint解決方案開發中所涉及到的各個環境。