難題 #6 過多的項目甲方想參與進來
有時你會發現想參與的人太多了。這種情況通常發生在項目的初期，大家都抱有濃厚的興趣，或者你的項目與個人的業績相關，很多人都想沾光。最好的辦法就是感謝每個人的熱情，讓他們明白你現在得到的幫助已經足夠了，而且你已經挑選了一部分人，告訴他們以后當你需要他們的幫助時會同他們聯系。當我處于這種境地時，我會盡量挑選最合適的人選，那些能提供最好的見解而且愿意花時間同我的開發組共同工作的人。同時，我不會疏遠那些現在沒有加入進來的人，有可能在某個時候他們某方面特殊的專長正是我們所需要的，或者可以通過他們來宣傳我們的工作。一般來說，一個積極參與的項目甲方會對這個系統越來越熟悉，但同時盲點也在增加，而越來越難發覺一些潛在的問題。因此保持對合格的外部人員的聯系是頗有價值的。
難題 #7 項目甲方指定了技術方案
我曾經遇到過這樣的情形，一個項目甲方人員說我們需要使用某種技術，比如某個版本的Oracle。而此時我真正需要的是從他們那里得到行為類型的需求，比如“客戶能夠將錢存入一個賬號中”。確實，技術方面的約束是肯定存在，也是開發組應該知道的，但此時有可能他們只是想告訴你Oracle是他們組織的數據庫標準這樣一個事實。很多時候，真正的問題在于你的項目甲方難于區分系統的需求和系統架構的選擇，有可能這個人是技術出身而喜歡討論技術方面的問題，或者只是由于他們剛好從最近 一期的商業周刊上讀到一則成功使用Oracle數據庫的文章。
最好的解決辦法是定義好項目甲方的權責，制定一個適當的工作框架，以使他們能將注意力集中在定義系統需要做什么這個問題上，而開發人員則集中精力在系統如何做這個問題上。另外一種策略就是問他們“如果你已經有了適當的技術，哪它還那么重要嗎？”或者“你想如何使用這項技術”這類問題來識別實際的需求。
難題 #8 項目甲方墨守成規
許多組織中，人們多年來使用同樣的工具以同樣的方式工作著。他們可能從來沒見過另外的方式或從來也沒想過。他們對改變懷有恐懼感，可能是他們害怕沒有所需的技能來適應新的系統，也可能是擔心會被新系統取代。出于這些擔憂，他們會按照適合他們的方式給出需求。 解決這個問題最好的辦法是同他們討論目前的情形，辨別哪種方式運作良好而哪種方式不好，以及向他們講明當前形勢正在如何地發生著變化。假設在SWA Online這個項目中，某個甲方人員在確定需求時告訴你任何一個定單最多只能訂購十樣物品。什么？明顯是因循守舊。如果你就此詳細地詢問，很快就會得知他們目前的運作流程是客戶郵寄或傳真他們的定單到公司，再由客戶服務代表進行定單信息的輸入。每張定單表格只有十行，而且得知以前的綠屏幕（譯注：即單顯）系統也被設計為每屏僅允許輸入十條信息。 其實不必問這么多，你應該指出填寫紙張表格的定單是造成這個限制的真正原因，因為紙張的大小是有限的，然后向他演示你可以很輕易地實現在一條定單訂購多于十樣物品。一會兒之后，他就會認識到這完全是可能的，特別是當你向他展示其競爭對手沒有這項限制時，就更會消除他的疑慮。
難題 #9 項目甲方含糊其詞
有時因為項目甲方不愿意做出具體的答復，給出的需求非常含糊。這主要是由于他們害怕犯錯誤。他們以前的經驗告訴他們重新實現一個改變的需求要付出昂貴的代價，需求事先都必須得弄正確。這基本上是做不到的，由此他們就選擇了含糊其詞，在某些問題上不表態。
“你已經做好準備迎接變化；你的開發方式是迭代式的、遞增式的，這樣能降低變化所帶來的開銷；你的目標是為他們提供最好的解決方案，而這意味著有些需求會隨時間的過去而演化的”，要解決這個問題你就應該給項目甲方留下這樣的印象。言行一致，在實施過程中能夠接受和支持變化。日久見人心，隨著時間的推移，你項目的甲方就會認識到他們可以現在做出決定，日后如果需要可以安全地改變。當你在每個迭代過程完后交付軟件，你的甲方看見軟件隨著他們對系統理解的不斷發展而發展時，害怕表態的疑慮很快就會消去。
難題 #10 項目甲方不懂建模artifacts
絕大多數的項目甲方，可能還有絕大多數的開發人員，都沒有正式地學習過建模。很有可能他們不知道如何去看一個UML活動圖、或一個數據模型、或一個UML使用案例，因為這不是他們的日常工作所需的技能。問題在于他們需要懂得你所作的這些artifacts，這樣才能明白你所表達的意思，才能積極地加入到建模得工作中來。
首先是確定你的項目甲方需要懂得哪些artifacts，這樣才能知道你應該集中精力在哪。對此使用最簡單的工具這個做法可以幫助你。如果你爭取采用諸如索引卡片、紙張和白板這類簡單的工具建模，你就降低了甲方的學習曲線。第二步就是教給他們這些技術，我傾向于Just In Time（JIT）這種方式。即當我們在一個建模會議中第一次需要某項技術時，我會先大致地講解一下，然后就我們所討論的問題深入討論如何應用該項技術。在一個項目的開始，我會概括地講一下一些常用的建模技術，使他們對將要進行得工作有個感覺。同時也會給他們提供一些讀物，一般是The Object Primer 2/e (Ambler, 2001a)，其中詳細地講述了這些技術（譯注：隨時不忘作廣告J）。使用這種方法，我教過那些從來沒有建過模的甲方，象CRC和基本用戶界面原型這兩種簡單工具，每個都用了不到十五分鐘。對于那些復雜一點的技術，如流程圖或類模型，需要一段時間來慢慢學習。第三步是盡可能快地基于模型生成可運行的軟件并得到具體的反饋。當這些模型變為現實時，你的項目甲方一下就能看到他們寫在粘貼紙上的基本用戶界面模型變為了一個HTML頁面，CRC卡片上描寫客戶的概念反應在軟件的功能中。
難題 #11 開發人員不懂業務
一個普遍的問題是在項目的開始階段開發人員不懂甲方的業務，使得與甲方人員交流起來比較困難。這是自然的，就像建模不是甲方人員的日常工作一樣，開發人員也不是一個熟悉甲方業務的專家。這就是為什么需要兩組的人都積極地參與需求建模工作，就如三人行必有我師這條原則指出的，每個人都能為之做出貢獻。開發人員需要花時間去學習相應的業務，雖然他們隨著項目的進展最終能學會，但我們常常發現這樣太慢，必須要通過某種方式來加快這個進程。多年以前，我工作過的一家公司，他們確實地理解到開發人員學懂業務的重要性。在前三天中，我和另外一個新來的員工都是由甲方的副總裁進行培訓。這是一個數十億美元的金融機構，他們向我們描述了他們各部門的基本情況。每個副總裁每次都要花幾個小時對兩個（是的，兩個）開發人員進行培訓。如果你的組織不是這樣的，你可以找幾本與該業務相關的書籍看一下，介紹性的大專院校的教程比較理想。我認為開發人員應該廣泛地閱讀。我經常閱讀財富雜志、經濟家、Utne Reader和國家地理雜志，而不僅僅局限于The Communications of The ACM和IEEE Software這類有關軟件開發的刊物。這使得我有廣闊的知識背景，對我在進入一個新的環境時幫助很大。
難題 #12 項目甲方過于集中于某一類需求
有時你會發現甲方雖然提供了一大堆的需求給你，可能以使用案例或使用情景的形式，但對于非行為類型（或行為類型）的需求來說還不足夠。這個跡象就說明沒有找對人，或者你遺漏了某個方面的人比如操作人員和支持人員。因此，需要重新考慮需求建模中甲方人員的組合。
難題 #13 項目甲方對于需求有許多繁文縟節
許多甲方認為正式（計劃好的會議、需要他們審查和簽字的正式需求文檔和正式的講演）就是職業化的表現。我認為這是我們的軟件產業在過去的兩個時代中所形成的軟件流程理念，我們的甲方不知道有另一條路可走。這同樣也是由于信息界與商業界間的緊張關系所造成的。我們的甲方不信任我們，他們堅持要履行這許多的繁文縟節，以此獲得對他們并不熟悉的開發流程的更多控制。
你需要同他們進行溝通，向他們講解有另外一種更靈巧的方式，讓他們明白現在這種方式所帶來的問題（開發進度緩慢、沒有足夠的機會去理解需求、超支的費用… …）。問問甲方，他們真正的目的是什么。是開發一個可運行的系統呢，還是開會和制造文檔？如果是前者，肯定是它，然后問他們為什么要堅持這些手續。不要接受他們的第一個回答，應該刨根問底，找出真正的原因。如我在Agile Documentation 一問所指出的，他們不相信我們，這是他們拴住我們手腳的一種方式。接下來就是要他們相信你，一般來說比較困難，這主要看他們在以前的軟件開發中經歷了什么樣痛苦。以及要求他們去掉一些手續。然后你就要以事實證明（即交付軟件），向他們展示沒有很多的手續一樣可以取得成功。通過循環的迭代過程減少手續，直到你的軟件能夠有效地工作時交付給用戶。
難題 #14 開發人員不懂需求
“開發人員弄不懂由業務分析師和用戶建立的需求artifacts”，在沒有采用靈巧建模的項目組中，時常聽到這樣抱怨。幸運的是，在采用了靈巧建模的項目組中你不會碰到這個問題。首先，熟悉你的模型和熟悉你的工具這兩條原則告訴你，開發人員應該對所使用的artifacts和常用的工具受過足夠的培訓和有足夠的經驗。如果沒有，那么他們就必須接受培訓和指導。第二，增量改變這條原則建議你將一個系統分為許多小部分，每次針對一小塊，一個一個地建立，這也反映在小增量建模這個做法中。這避免了開發人員一次需要理解太多的需求，陷入一個大的需求文檔之中。第三，項目甲方的積極參與這一做法和三人行必有我師這一原則保證了你的項目甲方能夠向開發人員解釋他們的需求，而開發人員愿意這樣做。第四，創建簡單內容和簡單地建模這兩條原則確保了你的需求模型做到盡可能的易于理解。
技巧
以下所列出的技巧能夠幫助你提高為系統的需求建模的效率，它們也遵循靈巧建模的做法：
需求的收集貫穿于整個項目過程中。大部分項目均是如此。雖然大部分的需求工作是在項目的開始階段，但很有可能你仍需要回到需求上來，直到代碼完全凍結時。記住擁抱變化這條原則。
解釋技術。每個參與的人員，包括項目甲方，都應該對建模的技術有個基本的理解。如果他們從來沒聽說過CRC卡片？花幾分鐘解釋一下它們是什么，你為什么要用這項技術，以及建立它。如果你的項目甲方不能夠使用正確的建模技術，那么甲方的積極參與也就無從說起。
使用用戶的術語。不要強迫項目甲方使用你的軟件開發方面的術語。這個系統是為他們而建造的，因此應該是你使用他們的術語來為系統建模。
樂在其中。建�？梢圆皇且豁椘D澀的工作。事實上，你完全可以寓模于樂。講些笑話，輕松一下。人處于輕快的環境中，可以更加有效率。
取得管理層的支持。為需求模型投入時間，特別是本文所講的以使用為中心的設計技術，對于許多組織來說是一個新的概念。項目甲方積極地參與建模工作，這也許對大多數的組織來說是根本文化的改變。任何涉及到文化改變的事情，沒有高級管理層的支持是不可能取得成功的。你需要取得你的信息部門以及用戶那邊管理層的支持。
采取寬度優先的方法。我的經驗是最好在開始時勾勒出系統的輪廓，盡可能大地了解系統的面貌，然后再集中在某一個小的方面。這樣做，你很快會對系統的整體有個了解，選擇好切入點。
已有的文檔是需求的很好來源。象政策手冊、政府法律、甚至于學校的教科書這些已有的文檔都是很好的需求來源。在我曾經參與的一個電子商務系統中，我第一件事就是找到一本關于電子商務方面的書來確定一些基本的需求（比如支持信用卡的交易）。記住復用已有的資源這一做法。
記住今天的用戶就是明天的分析者和以后的開發者。三人行必有我師這條原則其實也就意味著你的項目甲方在參與軟件項目的同時也在學習軟件開發的基本技能。常常會看見一個用戶先成為一個業務分析者，而后通過學習更多的開發技能而成為一個真正的開發者。因為靈巧軟件開發比以往的軟件開發方法更加強調項目甲方的參與，這種現象會更經常地發生。注視這些愿意進行這種轉變的人，給予他們幫助。有可能以后有人幫助你建立業務方面的技能，而幫助你跳出技術的世界。
參考資料及推薦讀物
參見http://www.agilemodeling.com/essays/references.htm.
腳注
[1] 這個例子揭示了使用案例的常見問題。對于單一的一個迭代過程，它們通常過粗。你可以讓一個使用案例在多個迭代過程中完成，從項目管理的角度來說這不是很好；或者你可以將其重構為更小的一組使用案例，這從建模的角度來說不好。
譯注
Artifact -- 在一個軟件項目中制造或使用的最終或中間產品。
它用于記錄或傳達項目的信息。它可以是文檔、模型
或者模型元素。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
