![]() |
Gary Pollice, 實踐教授, 伍斯特工學院 2008 年 8 月 18 日 最近我對一個領域產生了興趣,我認為該領域有潛力創造軟件開發中的下一個根本的改變:協作和創造力支持。敏捷運動令團隊不斷且良好的溝通的需求引人矚目。它強調了好的開發人員都知道的其他實踐,并且將這些實踐編入不斷增加的實踐和原則集合中。我遇到的所有成功項目的公共特征是在整個團隊中的有效溝通和協作。 整個團隊包括客戶、開發人員、管理人員、質量專家、文檔人員,和其他參與項目的所有人。不管項目使用瀑布、迭代,或敏捷方法,這一點都是一樣的。 許多工具都聲稱支持協作,然而直到最近實際的協作支持程度也是最小限度的。但是,一種新的工具已經出現了,它讓我有希望看到團隊協作實際支持中的驚人增長。協作支持之后的是創造力的支持。這兩個領域 —— 協作和創造力 —— 密切相關。這個月我將探討協作、一些現在可用的工具,并且預見一下我們能達到哪里。成功開發協作和創造力的自動化支持會讓我們達到生產重大軟件系統的下一個層次。 開始讓我們確保對協作和創造力有個一般的了解。雖然有大量描寫創造力的資料,但是協作是這兩個概念中更容易掌握的,因為在軟件開發環境中我們對其了解的更多。在本文中,我將協作定義為 一組人合作達到一個共同的目標。協作本來意思是一人以上參與。協作還是面向目標的。人們為特殊的目的而協作。在軟件開發中,目的是及時并在預算之內成功地開發并部署軟件系統。 協作需要溝通,但只溝通是不夠的。協作需要對工作目標達成協定,了解如何達到目標,并且知道協作工作的狀態。我將在下面更深入地介紹。 我曾說過,我們對協作的了解比創造力多,但我不確信在科學的意義上,對協作的研究已經像創造力那樣多了。我僅僅是說我們直觀地了解協作。每個在團隊中工作的人都了解協作是怎樣進行的。當我搜索關于協作和創造力的研究論文時,創造力的論文似乎更多。然而,二者緊密相通,并且從了解性質的觀點看有一些相同的特征。 創造力已經成為各種規程中許多研究和調查的焦點。心理學家試圖了解創造力的本質。有創造力的人如何想出點子?有創造力的人的工作風格是什么?我們能教人具有創造力嗎?社會科學家、計算機科學家,和其他人都參與了此項探索,因為它很重要。隨著全球化已經成為標準而不是偶然,一些國家將繁榮起來,因為它們可以交付比其他國家更便宜的服務,而一些將繁榮起來,因為它們是有創造力的。未來我相信我們將看到需要生產率、服務和產品的成本,及創造力相混合,來保持經濟的競爭力。這是巨大的挑戰,并且賭注是相當高的。 最近我讀到的關于該主題的文章是 Mihaly Csikszenthmihalyi 寫的。 1 Csikszenthmihalyi 說,了解創造力要分三個部分:
研究人員使用此框架來指導他們了解創造力及支持創造力的方法。我將在下面繼續說明。 協作和創造力這兩個概念是如何關聯的?我對它們的關系的看法如圖 1 所示。根據定義,協作涉及一個團隊,并且協作的工作是基于任務的,但經常有一些探索,例如極限編程中的“尖峰”。 2 我不確定的是,根據 Csikszenthmihalyi 所給出的組成,是否會稱這樣的工作為創造性的。創造性的工作即可以由個人做,也可以是基于團隊的,但主要是探索性的。 ![]() 圖 1:協作和創造力之間的關系 在軟件開發方面,大部分軟件應用程序是用來解決特殊問題的。因此典型的 IT 項目是基于任務的,并且處于圖 1 的上半部分中。開發軟件工具和其他內容的項目有類似的概況,但工作方式不同。一般個人或小組投入創造力來開發工具背后的核心思想。一旦探究了各種方法,并選定一個,項目就轉換為協作模式,團隊在此模式下構建產品。 3 協作的成功源于許多因素。一些最重要的是:
支持成功的協作應該支持這些因素。讓我們來看看工具是如何支持它們的。我將從最簡單且最老的開始,一直到如今我們使用的。 十多年來,幫助團隊識別任務以及任務分派是項目管理工具的一部分。對于非常簡單的項目,可以使用電子表格和一些宏命令。擁有大型團隊、必須集成的多個組件,以及長時間的開發周期的項目使用成熟,復雜的項目計劃工具。 項目管理工具稍微支持協作,但人們不會必然將其分類為協作支持工具。一個原因是這些工具沒有使得團隊成員很容易地 察覺到 隊友的活動。如果您是開發人員,并且您的項目使用成熟的項目管理工具,那么捫心自問,當您最后使用該工具時,您能知道另一個開發人員在做什么嗎?非常可能的答案是“從未”。 不能察覺是一個很重要的問題。一個好的協作工具會讓團隊成員很容易地了解同伴在做什么。這樣的工具還將把項目的整個進展告訴團隊甚至沒有工作的每一個人。這是生產力的問題。如果花費時間尋找所需信息,那么這些時間可以花在更重要的任務上,例如,實現新特性。同樣,如果花費時間和精力定位信息,那么人們不會定期訪問這些信息。人們只在出現危機時才訪問這些信息。此時這些信息雖然關鍵,但是是以響應式來使用的。 搶先地使用項目進展和任務分配信息是更有意義的。信息有更多價值。設想程序員被分派實現應用程序上的新特性。當她工作時,她發現系統的另一個部分將使用她正在實現的特性。她可以僅僅實現該特性,并且提交,但需要使用該特性的程序員將不得不調整其代碼。如果她可以快速地找出將利用其特性的人,那么她可以與該程序員一起合作,以最適合二者需求的方式實現該特性。這就是我所說的信息的提前使用的意思。 豐富的歷史信息有許多用處。對于協作,這些信息令團隊可以回顧項目,并且了解在哪里可以做出更好的選擇,或者回復到項目的先前版本,并走另一條路徑。許多年前,版本控制系統就已經提供用于獲取豐富的歷史信息的許多功能了。IBM ® Rational® ClearCase® 已經成為軟件配置管理(SCM)工具市場中的優質產品很長時間了。這樣的產品能夠分支、合并,及進行并行開發。這樣的產品擁有提供豐富歷史的基礎,但我們仍舊需要更多。 我們希望能夠及時回到可以看到項目全景的地方。當然該全景包含可以在版本控制系統中獲得的工件,但也包含從典型的版本控制系統中不那么容易獲得的信息。該信息可能包含電子郵件、網絡會議抄本和記錄,等等。這些信息還應該以鼓勵探究和協作的方式提出。 這就要求我們進行溝通。我們都知道,通常面對面或通過電話與某人交流比寫電子郵件更有效。當我們進行實時會談時,我們能夠更好地弄清問題并交流意圖。在當今高度分布的環境中,這不總是可能的,事實上人們在同一個地點的現象越來越少。我們希望在可以的時候盡可能同步地交流。但如果我們不能做到,我們需要有效地移步交流。 交流生成了開發項目的有價值工件 —— 團隊應該用于協作的信息。我們面臨的一個挑戰是,我們如何能夠在隨需的基礎上獲得交流并使團隊獲得信息?最近我參與了許多開始涉及此問題的 Worcester Polytechnic Institute(WPI)的學生項目。 上面的評論是十分概括的。現在我想要討論一下如今支持協作的工具類型。此列表不是詳盡的,但提供了一個如今專業人員可用的工具的適當示例。 在線協作社區和項目環境。團隊可以計劃項目并合作的在線社區的數量已經迅速增長了。其中一些,例如 sourceforge.net 和 Java community projects 是開源社區的兩個實例。 4 商業產品支持同樣的功能,并且更多支持想要管理自己的項目概要的組織。只要組織使用這些產品,那么它們就開始分布團隊的協作。 版本控制和源代碼管理系統。這些對任何團隊,分布的或集中的,都是必要的。以前類別中的大部分產品都包含這些產品或提供對這些產品的接口。 故障追蹤工具。雖然它們只提供異步的功能,但是這些工具是開發團隊另一個基本的需求。這種工具可以了解項目的健康程度(缺陷的數量)以及任務分配信息。 網絡會議工具。許多網絡會議工具是隨著互聯網和網絡技術發展為成熟、快速的通信媒介而發展的。人們在廣播和電視上聽說這樣的工具的廣告,并且在許多流行的雜志上看到關于它們的廣告。這些工具的功能各式各樣,但是它們的本質都是讓一組人進行啟用視頻、音頻,和共享的計算機桌面的虛擬會議。這些工具所提供的經驗上的質量依賴于許多因素,包括參與者接受這些工具并學習適當地使用的意愿。 IDE 中內嵌的協作功能。許多交互開發環境包含協作功能。Eclipse 平臺用許多插件,令 Eclipse 用戶能夠且更容易地協作。一個較成熟的項目和插件是 Mylyn 項目 5 。Mylyn 向程序設計人員的工作提供集中于任務的工具。它還與許多故障追蹤工具相集成。在 WPI 中,我們擁有 Webfoot 項目 6 ,它是向 Eclipse 用戶提供豐富的協作功能的進行中的項目。開發工具的一個很好的技術框架是 Eclipse Communication Framework 7 。該項目多年來用于向開發人員提供構建他們自己的工具的功能。它有一些實例應用程序,例如在最新的 Eclipse 版本中的實時共享的編輯器。 其他的 IDE 已經添加了許多 Eclipse 包含的功能。NetBeans IDE 曾經有一個非常好的共享編輯功能。其他工具提供更集中的功能,像 Smart Bear 的 Code Collaborator。 不幸的是,對于這些工具的互用沒有什么標準,這限制了開發團隊的選擇。整個團隊必需使用同樣的 IDE 以獲得協作功能的好處。 持續集成工具。持續集成工具最近幾年流行起來了。它們與 SCM 系統聯合,自動地觀察代碼存儲庫,并周期地或在有任何變更的時候構建系統(包括運行測試和打包工件)。它們還能夠通知整個團隊,或團隊中被選定的成員。它們經常提供可以立即看到當前的構建狀態的儀表盤。 我真的非常激動看到 IBM Rational 的 Jazz 平臺投放市場。 8 它將有效協作所需的許多功能放入一個平臺中。并且它構建于 Eclipse 平臺之上,因此您不需要了解許多新的工具。Rational Team Concert(RTC)產品是 Jazz 產品線中的第一個產品。我在 WPI 中用過早期版本,并且很高興使用它。設置和管理很簡單,并且在我和一些學生的測試中,證明它十分有用。我希望今年將其拿到我的課上,并且讓學生團隊使用它。 三個版本的 RTC 有一系列令人印象深刻的特性,如圖 2 所示。將其與我認為有必要的協作屬性相比較,您將看到十分匹配。 我特別喜歡 RTC 的地方是它提供的察覺功能,以及過程定制潛能。現在,團隊成員可以看到任意時間其他人在做什么,如果有問題提出,并且回答的人在線,那么程序員可以很容易地協作獲得答案并確保他們對任何問題都達成協定。在我看來,這是向前邁出的一大步。 在本文中,我沒有討論太多關于過程的內容。但是,不論寫不寫出來,每個團隊都有一個過程。RTC 交付一個現成的直截了當的敏捷過程。但該過程不用許多工作就可以定制。我還沒有多該過程進行過許多定制,但我期望今年給我的學生一個完整,簡單的過程。 如果您還不了解 RTC,那么我推薦您看看。前三個用戶可以免費得到 Express 編輯器。您可以感受一下我所談論的。 ![]() 圖 2:IBM Rational Team Concert 特性 我們正看到協作支持工具變革的開始。Jazz,雖然令人印象十分深刻,但僅僅是個開始。我尋找許多開始發布附加的協作功能的軟件工具廠商。我希望產生某個互通標準的合理集合,以便開發人員可以自由采用他們覺得最舒適且多產的工具,并且仍舊能夠與使用不同工具的團隊成員協作。 我期望對創造力的支持可以像協作支持同樣重要,越來越不易改變。我將在后面的文章中討論創造力支持。
[1] L.T. Cheng,C. De Souza,S. Hupfer et al.,“Building Collaboration into IDEs”,ACM Queue,第 1 卷,第 9 期,第 11 頁,2004 年。 [2] M. Csikszentmihalyi,Flow: The Psychology of Optimal Experience,New York:HarperCollins,1990 年。 [3] M. Csikszentmihalyi,Creativity: Flow and the Psychology of Discovery and Inventory,New York:HarperCollins,1996 年。 [4] M. Csikszentmihalyi,Finding Flow: The Psychology of Finding Engagement with Everyday Life,New York:Basic Books,1997 年。 [5] T. Hewett,M. Czerwinski,M. Terry 等人,“Creativity Support Tool Evaluation Methods and Metrics”,Creativity Support Tools,Washington,D.C.,2005 年,第 16 頁。 [6] B. Schneiderman,“Creativity Support Tools Accelerating Discovery and Innovation”, Communications of the ACM,第 50 卷,第 12 期,第 13 頁,2007 年。 [7] B. Schneiderman,G. Fischer,M. Czerwinski 等人,“Introduction to Workshop Report”,Creativity Support Tools,Washington,D.C.,2005 年,第 7 頁。 [8] B. Schneiderman 等人,“Report of Workshop on Creativity Support Tools”,http://www.cs.umd.edu/hcil/CST/Papers/creativitybook_final.pdf [2005 年 7 月 15 日]。 [9] B. Schneiderman 等人,“Creativity Support Tools: Report from a U.S. National Science Foundation Sponsored Workshop”, International Journal of Human-Computer Interaction,第 20 卷,第 2 期,第 17 頁,2006 年。 學習
獲得產品和技術
討論
|
本博客為學習交流用,凡未注明引用的均為本人作品,轉載請注明出處,如有版權問題請及時通知。由于博客時間倉促,錯誤之處敬請諒解,有任何意見可給我留言,愿共同學習進步。