來自 Rational Edge：一位經驗豐富的軟件開發專業人員提出了一份他個人的建議，并且描繪了一幅通過改進和提高開發過程從而使項目獲得成功的良好習慣，它涉及到交流溝通、用例、測試和市場營銷等方面。
在過去兩年中，無論是從事內部的還是外部的軟件開發項目，我都會遇到這樣或那樣的挑戰，同樣也會發現一些在不同項目中都普遍適用的良好習慣。既然我懂得了如何利用這些習慣來克服困難，于是我決定將其作一些梳理并記錄下來，作為本文的提要。
這些筆記可以歸納為如下四條策略：
彌補缺乏面對面交流所帶來的不便
撰寫更好的用例
確保有效的測試
支持市場工作
這項別具風格的建議決不是包羅萬象。我的目的并不是教授您如何構造軟件，而是和您探討一些對于項目成功與否至關重要的技術或非技術性的問題。有時，一個好項目和一個堪稱經典的項目之間的差異就是由一些看起來無關緊要的因素造成的。我的建議所著眼的就是那些相對較小卻很關鍵的部分，它們可以作為整個工程的代表。
彌補缺乏面對面交流所帶來的不便
人人都知道項目成功最關鍵的因素就是良好的交流與溝通。這是一個相當大的題目，在此我僅就其中一個確實能使項目之間產生出好與壞差別的方面加以論述。
面對面交流的好處
整個團隊能夠在同處在一個地區是一件非常值得慶幸的事情。通常這種情況會發生在那些小規模的、剛剛起步的業務身上。幾個理想堅定、雄心勃勃的人為共同的目標而奮斗，一同體驗和經歷著每一天中同樣的細節。同樣，一些更大規模的組織有效的使用靈活的方法在面對面交流的基礎上建立它們的內部流程。當某一個團隊同處在一座建筑物內時，其成員能夠在午餐時、走廊內、下班后進行面對面的交流，這些非正式的會面通常比安排好日程的會議更具效率。我至今仍記得無數次這樣的情形：當我在一個長時間的討論之后從被寫的滿滿當當的白板上面抄錄下筆記之后，正是這些被大家分享觀點和想法成為了新的方案的基礎。
然而，業務的成功和事業的發展通常會使得將一個高水準的團隊固定在同一個地點變得越來越不現實。由于并購、合作項目以及外包開發的出現，要求我們能夠在不同時區、不同文化之間成功地進行交流和溝通。在這樣一種情況下，什么才是我們最好的選擇呢？
分布式環境下的交流的開展
第一個映入我們腦海的答案大概就是電子郵件了。我曾經覺得電子郵件確實是一種有效的溝通渠道，但它同時也是被濫用最甚的一種渠道。如果電子郵件的傳送距離過長以至于人們沒有時間去閱讀它們，那還有什么用呢？根據我的經驗，如果包含三條以上的信息，那么您就應當轉而使用電話進行交流了。這個小小的規則幫助我節省了大量的時間，使得我不必去撰寫那些關于Lotus Notes軟件的無意義的文本。
此外，還有其他的一些溝通渠道，盡管它們并不能夠取代面對面會議的親密性，但它們確實能夠提高一個團隊的合作能力和理解能力：
項目主頁。 在網絡上建立一個主頁，從而為項目領導者提供了一個極好的單向交流渠道（如果您使用wikis技術或者論壇/博客方式的話，也可以是雙向的交流渠道）。主頁上可以解釋項目的具體內容是什么，確定所要達到的主要目標，以及介紹團隊的成員。管理者同樣可以應用這一頁面來發布代碼標準，“如何做”將幫助團隊成員設置環境，凡此種種。
在線聊天。 這種交流形式在團隊成員之間創建了一個虛擬的合作環境，營造了一種輕松的交流思想的氣氛。顯然的，通過即時消息系統隨時向同事尋求幫助要比通過電話交流要有效率的多。例如，IBM的系統，Lotus Notes SameTime系統，與Lotus Notes地址錄結合在一起，因此您可以輕易地在您的組織內部找到正確的連接，并且看到那個人是否已經登錄到SameTime。如果您看到指示器顯示“忙”，您就可以判斷出此人同樣也沒有時間接聽您的電話。SameTime同樣允許您邀請多人一同聊天，因此說這是一種進行合作討論并且立刻做出決定的非常好的方法，并且它省去了為進行一次正式會議而作的準備。
一些聊天程序還包括了其他一些有意思的功能，比如個性化可用性消息，為將來之用而保存副本的功能，等等。我之所以加亮了IBM SameTime是因為它提供了許多由于其與Lotus Notes電子郵件系統相結合而產生的附加功能。請記住，不同的聊天工具提供不同等級的安全性，并不是所有的聊天工具都能很好的適用于職業應用的。
缺陷跟蹤系統。 這是另外一種有效的溝通渠道。每一個軟件開發項目都必須能夠處理功能增進的需求以及程序缺陷報告。一個有效的缺陷跟蹤系統，例如IBM Rational ClearQuest，能夠幫助開發團隊規范化這些需求和報告。特別地，通過Rational ClearQuest和IBM Rational ClearCase結合而獲得的統一變化管理（UCM）的能力，將允許您將缺陷記錄和源代碼聯系起來，這將大大提高在日常事務上的交流質量。例如，如果對于一個不能正常工作的組件我需要得到幫助，我就可以找到該組件在缺陷跟蹤數據庫中的入口，并且查明該組件是否在執行進一步的工作，以及誰在執行那項工作。
“一杯咖啡�！� 從另一個方面來說，每一種交流的工具都是人。當有人打電話給你僅僅是問候一下您最近在忙什么，特別是在您處在工作壓力下的時候，難道這不是一件非常令人感到欣慰的事情么？盡管您的同事可能正處在地球的另一端，記得這些非正式的交談對于鞏固一個團隊發揮著多么巨大的作用仍然是非常重要的。即使您使用的是最完善的管理和報告工具，有些時候與另一個人的交談仍然是獲得正確信息的唯一的方法。邀請您遠方的同時共飲一杯咖啡如何？也許一個沒有事先安排的電話會在一天工作結束之前的一小段時間內打來。請記住，如果您起初經常撥出這樣的電話，那么您也將接到更多這樣的電話。
撰寫更好的用例
從某個角度來看，我們可以認為用例也是交流溝通的一種形式。但是，它卻遠遠不僅僅如此，所以我在這里將其單獨處理。
用例較之于其他系統設計技術有兩個大的優點。首先，它們為每一個參與項目的人員提供了一個關于最終的用戶需求的正確理解。其次，您可以在源代碼的第一個原型出來的很長一段時間之前就對這些用例進行裝配。弄清楚應用程序的關鍵原理以及用戶的真正需求，一方面為今后同客戶開展富有成效的合作開啟了大門，另一方面也為在產品合成過程中不同角色和團隊之間的合作奠定了基礎。
簡單的說，用例就是描述下列兩件事情之一的一個簡單的文檔：
用戶要求必須事先的關鍵功能（業務用例）.
或者
用戶（活動者）與業務系統之間的交互（系統用例）。
也許您在想：“所以什么？那僅僅是另一個文檔�！睂嶋H上，當我第一次面對要將需求和用戶的期望寫進文檔之中，使之可以被不同的項目角色共享這一挑戰之前，我也抱有同樣的想法。在項目最初的階段里，測試團隊和文檔團隊就開始向我們詢問一些關于我們將做什么以及各部分之間將如何協同工作等等細節。直到我發現用例之前，我的回答總是矛盾的、混亂的和非常耗費時間的。
當然，一旦我發現使用用例來計劃和回答這些問題是多么的有效，我便面臨著另外一項挑戰：學習如何更加有效的撰寫用例。
了解用戶
在進入交互和特定情節之前，理解所有目標客戶群并將其彼此區分開來，并且把他們的要求和需要列入清單是非常重要的。不同的用戶群有著不同的業務用例。例如，一位負責確認遵循一套特定的全球性標準的測試人員的需求就在很多方面不同于一位擁有相似職責的開發者。開發者也許擁有知識、工具以及職權來修補那些錯誤的地方，但是測試者則是記錄下這些缺陷然后等待開發者來作出改正。
在設計應用程序時，除非您弄清了這兩類用戶的特定需要，否則您就有可能設計出一個兩方面需求都不能得到滿足的系統。
業務用例與系統用例
取決于被討論系統的不同，在業務用例和系統用例之間可能存在著巨大的差異。一個是描述用戶的業務，而另一個描述的是用戶同系統的交互活動。然而，這兩種類型的用例之間的區別也可以變得模糊。例如，在一個軟件開發項目中，系統就是業務。當您開發和測試一個特定的系統功能的時候，很容易就會忘記最終的用戶很可能不會用您所采用的方法使用該系統，甚至都不會擁有同樣的需要。
為了理解業務用例和系統用例之間的區別，想象一下軟件開發團隊已經承擔了一項軟件應用程序開發任務，并且要保證其在全球各種不同地區的環境下都可以同樣出色的運作。為了確保該應用程序達到這些要求，該團隊就必須遵循一套最小化的全球規則。1 這些規則在一套規范中被嚴格定義，不能隨意被更改。開發團隊需要針對這些規則來審核自己的代碼，目前這些工作必須由手工來完成。一位程序師（審核員）必須打開源文件來查找同指定規則相矛盾的地方。
該組織收到一份執行決定，要建造一種能夠使這些全球性規則（及其他規范）得到自動分析的工具，并且集合一支團隊來開展這一項目。目標就是將業務用例中手工操作的那部分替換為軟件應用程序（即系統）。這一手工過程非常耗費時間且容易出現錯誤。并不是所有的程序師都能夠同樣好的理解這一全球性的規則，許多人很可能沒有注意到這之間存在的矛盾之處。另外，團隊成員在持續的工作壓力下變得越來越快的生產產品。一個可以核查全球化規則的自動化的系統將降低忽視某條規范的風險，并節省大量的時間。
在這個特定情節中，業務用例“在核查之前復審每一份源文件”可以被看作：
對于工作區內的每一份源文件：
打開源文件。
逐行閱讀代碼（注：需要深入的代碼知識）。
如果您發現了一個可以的方法，就請參考包含這一規則的網頁（注：非常耗費時間）。
如果可能的話，通過修改代碼解決該問題（對于開發者的業務用例）。
對于測試者來說可選的流程：如果您不能正確地解決這個問題，就請將發現的問題記錄在Word文檔中并提交給開發人員。
打開下一份源文件并重復上面的步驟。
正如您所看到的，這是一套冗長的流程，但卻是實現自動控制的一個非常好的候選方案。
系統用例的價值
一旦您定義了用戶的“就是這樣”的流程和目標，您就能夠指定那些用戶活動的部分是一個自動控制的系統所能提供的。盡管它們仍然包含著用戶的活動，系統用例卻是以系統為中心的，來描述用戶同系統交互的過程。然而，請注意系統用例應當在業務流程的背景下被定義。最終，我們的目標是幫助用戶處理業務問題。
這里就是在我們虛構的項目中，團隊是如何定義基礎系統用例的，假設用戶就是團隊的一個成員：
前提：全球性的規則在IDE的復審特性的代碼中被授權使用。
在IDE中打開代碼復審工具。
（步驟之打開工具）。
運行一個代碼復審。
主流程——點擊按鈕“Run”。
（在新區域內列出可選流程的詳細描述）。
復審自動化復審的結果（發現的問題）。
對于每一個發現的問題，解決之：
主流程：提交缺陷。
（在新區域內列出可選流程的詳細描述）。
如果您不能夠修正這一代碼，則提交缺陷。
（步驟之缺陷提交）。
一個包含以上這些步驟地簡短的文檔將提供充分的信息，使得讀者了解到最終產品應該是什么樣子，它將如何幫助客戶處理他們的業務，等等。即使這一信息沒有被明確的說清楚。
下面是擁有系統用例而帶來的一些顯而易見的好處：
即使沒有一個代碼被分類為“代碼復審完畢，等待測試”，測試人員也能夠針對上面描述的功能制定出一份測試方案。
另外，正是基于這一點，文檔編寫者可以針對代碼復審創建并且（或者）添加文檔中的結構。
開發管理者在此之后可以使開發進度更加優化，以便使得第一份開發構造將至少滿足該用例的主要流程。
用例促進了項目的開發，并且使得全體團隊成員在項目伊始就忙碌起來。如果您仍然沒有將您的工作關注到用例上，那么請給它們一次機會。您所付出的努力將是值得的。
確定系統用例適當的詳細程度
文章來源于領測軟件測試網 http://www.kjueaiud.com/