民初思韻網

加入收藏   設為首頁
選擇語言   簡體中文
你好,請 登陸 或 注冊
首頁 人文思韻 傳奇人物 歷史思潮 時代作品 話題討論 國民思韻 民初捐助 賬戶管理
  搜索  
    時代作品 >>> 讀書—連接古今充實信仰
字體    

大道至簡——軟件工程實踐者的思想 第4章 流于形式的溝通
大道至簡——軟件工程實踐者的思想 第4章 流于形式的溝通
周愛民(Aimingoo)     阅读简体中文版

      第4章 流于形式的溝通
 
    “足下求速化之術,不于其人,乃以訪愈,是所謂借聽于聾,求道于盲。”
 
                           ——唐韓愈《答陳生書》
 
1. 客戶不會用 C,難道就會用 UML 嗎?
 
    我們總是要先接觸客戶的,是的,如果不這樣,我們將無法確知要做什么。
 
    作為開發人員,可能更希望客戶能學習或者精通 C語言,這樣客戶就知道開發人員正在做什么,以及有多么地勤勞。或者,這樣的客戶還能以 C 語言的方式告訴開發人員他們究竟想要什么。
 
    然而要求客戶學習 C 語言明顯是自殺式的行為。在客戶(的代表)學會用 C 語言來向開發人員描述他們的需求之前,可能他就已經被老板開掉了。因此沒有客戶會笨到愿意用 C 語言來描述他們的需求。
 
    C 語言是程序員與計算機交流的語言,而不是他與客戶交流的語言。程序員面對的是計算機,但計算機不是客戶。
 
    因此在前面所提到的 R 模型中,開發人員最好不要直接面對客戶。項目經理有這樣的一種優勢:他可以不用了解 C 語言,也可以用一種非 C 的語言來與客戶交流(比如說漢語)。
 
    ——或者你更愿意開發人員盡早地進入狀態,那么你可以讓開發人員以需求調研的身份出現在客戶面前。但是,請注意這個人員的角色將變成“需求調研”,如果他不能適應這種轉變,那就別讓他去。——那會是災難的開始。
 
    要深入項目的需求階段的項目經理或者調研人員,被
 
要求深諳項目所涉的業務。但這往往我們所做不到的,因
 
為我們是軟件公司,而不是做這些(客戶的)業務的公司。
 
這時慣常的做法是聘請行業咨詢公司(或者個人)來介入
 
需求階段,協助了解和分析需求。
 
    他們總是很喜歡把事情搞得很復雜,所以他們會說這
 
一切的過程有個專用名詞,“En...這叫需求建模”他們很
 
專業地說。
 
 
    現在你應該發現了差距。比如我們的項目經理,以及
 
那個被調來充當調研角色的程序員,他們就不會什么“需
 
求建模”。
 
 
    接下來咨詢公司會與我們的客戶一起做業務建模,然
 
后再做業務到需求的映射,再抽取需求并完成需求建模。
 
他們做業務建模的時候,可能使用一些客戶業務范疇內的
 
符號和標識;而在做需求建模時,則需要使用一些軟件行業中(的設計和分析人員)習慣的符號和標識。
 
     這些符號和標識也有個專用名稱,“En...這個叫模型
 
語言(ML)。”他們無時無刻不在向你展現他們的專業(這已
 
經是他們還存在的唯一原因了)。
 
     如果他們更加專業,他們會告訴你他們用的是 UML。
 
向你介紹這個名詞的時候,他們的眼鏡或者眼睛里通常將
 
大放異彩。
 
     UML是模型世界里的世界語①。
 
 
     到現在為止,你應該看到,咨詢公司除了把問題搞得
 
更加復雜之外,他們仍然需要面對最直接的問題:與客戶
 
如何交流?
 
     他們的解決之道是模型語言。
 
 
     有什么差別嗎?
 
     程序員不能要求客戶會 C Language,難道需求分析師
 
們就能要求客戶會 Modeling Language 嗎?!
 
 
 
2. 項目文檔真的可以用甲骨文來寫
 
 
     獨 孤 木 (http://www.javaworld.com.tw/) 曾 經 在 一 篇
 
《UML, OOAD and RUP》中討論到 UML 實際應用中的問
 
題。其中的兩個問題是:
 
 
① 現實的情況未必如此。但UML這個名詞起碼顯示了它本源性的 
期望:Unified Modeling Language(統一模型語言)。
 
 
        “大部分的使用者,以及客戶的信息人員,其實
 
        并沒有足夠的能力,來確認這些文件(User Case) 
        的正確性與完整性。”
 
        “除了客戶不了解 UML,OOAD 跟 RUP 以外, 
        另外一個更糟糕的現象就是 project team 里面 
        的人也不懂。”
 
 
    這實在是很有趣的事。
 
    看來在一些情況下,在項目中使用 UML 只是完全不
 
懂的老板,以及什么都懂的博士的主意,而真實的場景中
 
去做事的那些客戶與項目成員,其實是未見得就能用好
 
UML 的。
 
 
    僅以 UML 的 User Case 來說,由“用例圖”和“用
 
例規約”組成。規約跟我們寫的需求說明書差不多,不過
 
更加細節罷了,而且還有一套相應的方法論來闡述如果去
 
實作。圖則很簡單,就是幾個圖形符號來描述系統邊界和
 
角色關系。
 
    顯然甲骨文也能描述范圍與關系。例如甲骨文中的
 
“家”這個字,就是上有房子下有豬①,這個邊界就定義
 
得很好;在古文中,“三”通常是泛指,跟UML圖中的線
 
條上標注的那個“*”是同義的,而甲骨文中“眾”這個
 
① 至于是“內有豬”還是“下有豬”的問題,不是我們要爭論的。 
有些考古學家根據甲骨文的象形來認為古人與家豬是雜居的,但 
我想那時的豬可能還比較野性,因此這種可能性還是小些。
 
字,就是日字下立有三個人,也就是在同一個日頭下做事
 
的很多人即為“眾”,這個關系也描述得很確切。
 
 
     所以只要你運用得法,甲骨文一樣可以用來畫用例圖
 
和寫用例規約。同樣的,只要約定一套“語法”,你同樣
 
可以用甲骨文來做活動圖、類圖、構件圖……以及這些圖
 
相關的規約。相比來說,古巴比倫人使用的楔形文字“象
 
形性”差一些,因此我不建議用它來畫用例圖。
 
     既然甲骨文可以用來做為一種模型語言(同時它也是
 
一種文字和口頭的語言),那么,如果你的項目中面對的
 
對象是商周文化的考古學家,以及你的項目組都由精通這
 
種語言的成員構成,這時你就可以用甲骨文來做項目文
 
檔,以及畫各種模型圖例。
 
 
     你要明白,要讓考古學家看懂用例圖,難度遠大于看
 
懂甲骨文。與其要求他們學一種語言,不如使用他們那個
 
世界的通用語(當然,前提你的項目組也懂得這種語言)。
 
 
     在韓愈的《答陳生書》中,他因自己不會“速化之術”,
 
所以說陳生是“求道于盲”。然而他用了一個不恰當的比
 
喻:要知道盲人并非不知道路如何走,只是他不能象常人
 
一樣描述他所知道的路。因此“問道于盲”是沒有錯誤的,
 
真正錯誤的是你睜著眼睛問。
 
     我們需要在正常人與盲人之間建立一種溝通的方式,
 
既然盲人不能睜開眼睛,那么你就閉上眼睛好了。
 
 
 
                                               -48- 
 
                                              『大道至簡』
 
    UML 圖在一些客戶眼里無異于盲人的世界,如果需
 
要向他們做需求調研,你只能使用一種這些客戶能夠理解
 
和接受的方式,例如表格、流程圖以及……更深入的交談。
 
    你要確認你的溝通方式是否有效,而不是去追求這種
 
方式是不是 UML,以及用 UML 表達得是否正確。——客
 
戶是因為他認為你理解了他們的需求,而在“需求確認書”
 
上簽字,而不是因為你的 UML 畫得是否精準。
 
 
    現在來思考:為什么非要讓客戶看UML圖呢?如果 
有能夠滿足“極限編程(XP)”所要求的“現場客戶①”,那
 
當然可以不畫用例圖;相反,如果客戶雇了一個專家組來
 
評審需求,那么你就老老實實地畫用例圖好了。
 
    需要留意的是,專家組還要一種方式與客戶溝通,這
 
有可能不是 UML。——當然,客戶愿意增加溝通成本,
 
那是他們的事。
 
 
    一旦源頭確定,你就可以接下來約定在項目組中要使
 
用的溝通方式。愚公——這個偉大的項目經理——所使用
 
的“聚室而謀曰”,就是很好的溝通方式。當然,如果客
 
戶精通 UML,那么我想愚公采用的項目溝通方式將會是
 
“聚室而論 UML”。我想一定會這樣,因為愚公是很懂得
 
溝通的、偉大的項目經理。
 
 
① 這是極限編程的特征之一,指的是要求客戶可以在程序員開發 
的第一現場,隨時可以向程序員確認完成功能的有效性,以及修 
正需求或者先前的需求描述。
 
3. 最簡溝通
 
 
     在 D 項目中,我向我的項目組員提出在需求階段與
 
客戶的溝通計劃。這個計劃只有三條:
 
          在一個月中,只能跟客戶作三次聯系;
 
          三次聯系中,最多只能有一次面談的機會;
 
          一個月后,提交全部的需求調研報告、需求分析
 
          和關于該項目的遠景規劃。
 
 
     D 項目并不大,所以從主觀上來講,客戶(代表)并不
 
會為這個項目投入太多的精力。重要的是,我們在前期交
 
涉中已經發現:這個客戶代表為大量其它的項目和工作所
 
困擾,他不會有時間來處理我們的問題。因此,減少溝通
 
和保障溝通質量的問題就顯得非常突出。
 
     在大多數的項目中,這樣的問題都是存在的。真正能
 
滿足極限編程(XP)所提出的“現場客戶”的情形并不經常
 
出現。即使能將程序員送到客戶現場中去,溝通問題仍然
 
是不可避免的。
 
     因此在 D 項目中我提出了“最簡溝通”。
 
 
     我們開始在網絡上查看相關的軟件系統的特征以抽
 
取客戶所關注的內容;了解該客戶的公司、經營理念、組
 
織結構形式以及工作模式;了解同類公司的成功經驗和優
 
秀的管理模式,以及客戶的競爭對手在做什么和在關心什
 
么……
 
     最后,我們開始綜合以下兩個方面的因素:
 
 
        客戶在公司層面的外在表現、內部機制和運營管
 
        理手段。
 
        客戶在項目中既已明確的需求和可能發生的需
 
        求,以及客戶圍繞其公司行為(和方向)所提出的 
        需求。
 
    這樣我們就了解了客戶項目中所有會產生需求的信
 
息點。
 
    我們開始設計提問,每一個提問涵蓋盡可能多的信息
 
點,盡可能的具有發散性以便形成更多的推論和假設。
 
    我們把這些做成項目概要用 mail 提交給客戶,并在
 
第二天電話回訪他。他以口頭的形式回復了這封 mail,這
 
讓我們盡可能地得到了項目在方向上修正。
 
 
    我們確定了項目的實際目標,以及遠期的方向。接下
 
來就是設計需求條目。
 
    客戶已經先期提供了一些關于項目的文檔、報表和工
 
作數據。因此基于這些數據的需求分析,將是下一個溝通
 
前所進行的最堅苦的工作。項目組員被要求:
 
        分析用戶的每一個表格,以構建基礎數據庫;
 
        分析每一條數據的含義以確定它的上下限,以及
 
        數據間的相關性;
 
        從工作文檔中去了解客戶的組織機構及其相互
 
        關系,同時確定了每一類使用該系統的角色;
 
        從報表中去了解客戶關注的數據信息,以及被他
 
        們所忽略掉的數據信息。
 
    我們從數百條的需求條目中,整理出系統結構和模
 
塊,需求條目被映射到各個模塊。我們很快畫出了模塊間
 
的相互關系圖,并通過這個圖分析了數據交叉關系,設計
 
了相應的數據索引并增加了一些新的關系性數據。
 
     我們對用戶角色、原始數據和系統結構進行了梳理之
 
后,我們花了很短的時間實現了第一個系統模型。當然,
 
很多的功能項目,我們都只是簡單 show a dialog。但我們
 
優化了每一個操作流程,以保證不同的用戶(角色)在使用
 
時都盡可能流暢。
 
 
     這一次的溝通我們使用了面對面的模式。我們很慶幸
 
的得到了與這個系統的每一類用戶(角色)接觸的機會,而
 
正好我們有一個模型,我們便讓他們來操作并提出意見。
 
這一次我們終于有了一份詳盡的的調研報告。
 
 
     接下來的分析設計是順理成章的事。我們在一個月后
 
完成了這個項目的需求分析報告,以及在這個分析上的一
 
些框架型的設計。還有,一個被用戶所接受的原始模型。
 
     ——盡管,第三次的溝通中還發現了一些問題。但我
 
們終于有了一個好的開端。
 
 
     應該清楚的是,保障每一次溝通的有效性都是最重要
 
的事。溝通不是打電話或者請客戶吃飯那么簡單的事。你
 
得到的每一次溝通機會,都是向客戶了解更深層次的需求
 
的機會,因此最好在見到客戶之前,你就已經設計了所有
 
的問題和提問方式。
 
     吃飯并不是有效的溝通。大多數時候,那將以酒醉收場。
 
4. 為不存在的角色留下溝通的渠道
 
 
    大多數人不會知道,我們中國的“五千年文明史”實
 
際上僅有三千年“有史可查”。
 
    司 馬 遷 在 史 記 中 寫 道 :“ 維 三 代 尚 矣 , 年 紀 不 可
 
考,……于是略推,作三代世表”。也就是說,他在寫史
 
記時“(夏商周)三代”的年代已經不可考了,因此只能做
 
“世表”;而其后十二諸候國的年代才可考證,因而有“(十
 
二諸侯)年表”。
 
    世表和年表的準確性和可靠性有明顯的差異,因此我
 
國古代編年史能追溯到的上限,就成了《史記·十二諸侯
 
年表》中記載的西周共和元年,亦即公元前 841 年。
 
    司馬遷無法做夏商周三代的年表是因為其年代不可
 
考,這是因為自黃帝以來的許多文獻材料部分雖有年數,
 
但比較模糊且不一致,所以他只能棄而不用。
 
     現在國家在“夏商周斷代工程”中再次推算和考證編
 
年史,這些相關資料也同樣只做參考,實際采用的方法是
 
更有可信度的金文(記載)、歷史學、天文學、碳-14 測年
 
等。
 
     資料的缺失、及其有效性的缺乏,給中國編年史撰寫
 
帶來了莫大的困難。
 
 
     項目的中斷和中止,與歷史產生斷層的內因是一致
 
的。——我發現很多的項目(尤其是產品計劃)在負責人員
 
離開后,就自然而然地死掉了。我把這一切的原因歸咎于
 
“沒有 history”。
 
 
     在先人寫“譜牒”(簡、冊)時想必是沒有考慮過后人
 
要讀的,或者更為遠古的先人可能根本沒想過要留下他們
 
的生活和部落記錄,再加上有象秦始皇這樣的人在前面放
 
火燒東西,所以司馬遷拿不到夏商周三代的確切史料,也
 
是情理之中的事了。
 
     ——遠古的先人不知道司馬遷這一號角色的存在,司
 
馬遷也沒有辦法跟古人約定一下要留點記錄給他寫《史
 
記》。
 
 
     我 們 做 項 目 的 時 候 , 如 果 也 不 留 下 歷 史 記 錄
 
(History),那么以后別人來看這個項目,也會是兩眼一抹
 
黑,要么就象司馬遷一樣“存而不論”,項目便就此中止;
 
要么就象“夏商周斷代工程”一樣,花大量的人力物力來
 
攻關。
 
    維護舊項目比做新項目更難,許多人深有同感。然而
 
這些“有同感”的人又何曾想過,自己在做“新項目”的
 
時候,要為“項目維護”這種還不存在的角色,留下一個
 
溝道、對話的渠道呢?
 
 
    我把項目的 History 作為跟這種“不存在的角色”溝
 
通的一種方式。History 的豐富和準確為項目的后繼開發、
 
維護提供了可能。
 
 
    歷史記錄(History)與注釋(Comment)不是一回事。代
 
碼中的注釋是為閱讀代碼而留備的,而 History 是為整個
 
項目而記錄的。一些參考的記錄內容有:
 
        需求階段:與誰聯系,聯系方式、過程、結果以
 
        及由此引發的需求或變更;
 
        設計階段:如何進行設計、最初的構架、各個階
 
        段的框架變化、因需求變更導致項目結構上的變
 
        化(有助于了解構架的可擴充性); 
        開發階段:每一種技術選型的過程、每一種開發
 
        技巧的細節和相關文檔、摘引的每一段代碼、算
 
        法、開發包、組件庫的出處和評測;程序單元的
 
        測試框架;每一個設計和構架變更所導致的影
 
        響;
 
        測試階段:還記得測試用例和測試報告嗎?那是
 
        最好的 history 之一。
 
 
     當然,另一件最重要的事,是記得在每一筆記錄后寫
 
下時間和你的名字。你的每一筆記錄都是打算留給一些根
 
本不了解這個項目的人看的,之所以要記下你的名字,是
 
便于那些人能夠再找到你并溯源到問題的源頭。——當
 
然,這得趕在你和古人一樣“與天地共存”之前。
 
 
     我們知道,大多數的工具都有歷史記錄的功能。在開
 
發工具和測試工具中尤為突出。此外,版本管理工具也留
 
下了每個階段的印跡。然而,我不建議過于信任它們①,
 
如果不明確要求項目組員寫下詳細的History,那么他們可
 
能在每一次版本簽入時都只寫下兩個字的備注:“完成”。
 
 
 
5. 流于形式的溝通
 
 
     在很多的時候,我所聽到的溝通,都是一種形式。例
 
如與客戶吃飯或者打回訪電話。
 
     其實溝通是具有目的性的,如果在沒有明確目的的情
 
況下與客戶溝通,那將是浪費客戶和自己的時間。這種目
 
的,可以是了解項目的訊息、挖掘潛在的項目……最末了,
 
才是交流感情。
 
     然而大多數的情況下,它僅僅被看著交流感情。這便成了形式。且往往是客戶所討厭的一種形式。
 
① 大多數的軟件公司已經意識到版本管理的重要性。然而項目各個階段的文檔、代碼及其它輸入輸出都是具有版本問題的。單一的版本管理軟件并不能勝任這些。因此我仍舊采用相對原始的、編寫History這樣的方法,來彌補ClearCase、SourceSafe、CVS等這些軟件的不足。
 
 
    溝通問題不僅僅存在與客戶交流之中。還存在于與項
 
目的各個角色之間。項目的分析報告為設計人員所看不
 
懂,設計人員的方案為開發人員所看不懂,而開發的結果
 
以為測試人員所看不通。等等都是溝通問題。
 
    UML 的確是解決溝通問題的最佳手段之一。然而如
 
果項目一開始就不能用它,那么強求的結果必然是痛苦
 
的。——要讓 UML 在一個沒有經過相關培訓的團隊及其
 
各個角色之間用起來,幾乎是不可能的事。即使用得起來,
 
也存在經驗問題。千萬不要指望僅僅一個項目,就能讓你
 
的組員深刻的理解 UML 的思想。
 
    也不要指望在每個項目中都能用它,如果你的客戶能
 
理解并支持使用 UML,那以這個項目就會有一個良好的
 
UML 使用環境。否則,開發環節中資料的不一致性,將
 
會使得項目難以收場。
 
    使用與不使用 UML,其根本的問題在于溝通方式的選擇。只要是行之有效的、能在各個項目角色間通用的,就是好的溝通方式。
 
 
    在每一次回顧項目時都應該注意:流于形式的溝通,可能是使得你的項目被不斷推翻和不斷延遲的最直接原因。
2013-08-24 22:23

歡迎訂閱我們的微信公眾賬號!
春秋茶館訂閱號
微信號 season-tea(春秋茶館)
每天分享一篇科技/遊戲/人文類的資訊,點綴生活,啟迪思想,探討古典韻味。
  清末民初歷史人物  民初人物
革命先行者民國之父
孫中山(1866年11月12日-1925年3月12日),本名孫文,字載之,號日新、逸仙,廣東香山(今中山)人,是醫師、近代中國的民主革命家、中國國民黨總理、第一任中華民國....
教育專家大學思想啟蒙
蔡元培(1868年1月11日-1940年3月5日),字鶴卿,又字仲申、民友、孑民,乳名阿培,並曾化名蔡振、周子餘,浙江紹興山陰縣(今紹興縣)人,革命家、教育家、政治家。中....
資助民初精神網
        回頂部     寫評論

 
評論集
暫無評論!
發表評論歡迎你的評論
昵稱:     登陸  註冊
主頁:  
郵箱:  (僅管理員可見)

驗證:   验证码(不區分大小寫)  
© 2011   民初思韻網-清末民初傳奇時代的發現與復興   版權所有   加入收藏    設為首頁    聯繫我們    1616導航