字號: 小 中 大 | 推薦給好友 上一篇 | 下一篇

敏捷 RUP：來自實戰中的經驗

發布: 2008-10-31 16:14 | 作者: Mark Lines 等 | 來源: 測試時代采編 | 查看: 88次 | 進入軟件測試論壇討論

如何開發一個協作的團隊文化

如果說同處一地的項目團隊能夠有助于培養協作精神的話，那么對于分布式的團隊來說，就很難體會到這一點了。

工具的使用可以有助于我們對這一問題的解決。最明顯的就是溝通援助，例如：即時消息、電話、視頻會議和虛擬工作空間等。然而，這些工具所能提供的價值是有限的，除非每個終端的工作人員對于同其他人員的交流都感到非常舒服。

每個人都知道，如果以前曾經見過面并且建立起某種類型的聯系的話，打電話同別人溝通是最容易的了。上面所提到的其他許多溝通工具也大概如此，它們建議一種相對并不明顯的“溝通工具”——一種使得團隊成員能夠面對面交流的傳輸模式。

盡管到很遠的地方出差無論從時間還是從預算的角度來說對于一個項目都是一筆非常大的開銷，但是建立溝通、信任和知識共享的好處卻是巨大的。然而，遠距離的彼此交換也并不是正確的解決方案，所以說我們需要找到這兩者之間的平衡點。

如何保持方法和交付的一致性

除了具有協作性的團隊和有效溝通的文化之后，交付項目的工作就成為了下一個我們需要解決的問題�！皞�體和交互超過處理過程和工具”這一價值對于敏捷團隊來說十分重要，一種定義好的處理過程語言和框架確實能夠為分布式團隊中的個體和交互作用提供幫助。

RUP 提供了一種軟件開發語言的過程處理框架，一種標準的統一建模語言（UML）符號，以及一種將選中的處理過程實踐和一支完整的項目團隊連接起來的方法。在沒有一種共同的軟件開發語言的情況下，用于活動、交付或者角色的術語或者描述的局部變更將會導致團隊成員在職責和期望上的困惑。正是出于這些原因，許多機構決定投資培訓它們的員工，為他們提供這種共同的語言�？梢酝ㄟ^多種方式達到這一效果。

簡單的培訓能夠為員工提供基本的語言和符號知識，但是并不能提供使用和交流中所必不可少的技巧。供所有人所遵循和使用的額外的標準和模板能夠提供一致性，但是無法鼓勵交互作用。

最好的方法是請一位指導專家參與到項目之中，使用能夠很容易地被項目的出資方和觀察著所翻譯和理解的共同語言來鼓勵所有個體之間的交互作用。這位指導專家還將有助于將處理過程框架裁剪為同項目所涉及的其他機構一致的樣子。

所以，如果我們要使用一種類似 RUP 的處理過程架構，就還需要根據環境進行裁剪�？梢酝ㄟ^記錄 RUP Development Case 中的一套一致性的方法來達到這一效果。但是通過 IBM Rational Method Composer 使用，這種處理過程裁剪能夠以 HTML 被更加正式的描述和發布給任何一個團隊成員。

如何管理共享工作產品的開發

盡管一個引入了共同語言和方法的被定義的處理過程有助于分布式團隊的活動，但是需要執行的工作量和復雜度仍然是巨大的。特別是當分布式團隊必須同時共享和處理同一個交付的時候更是如此。

一支團隊無法實時對項目進行回顧和協作的缺陷也會影響項目的質量并且減慢處理過程。團隊必須找到一些方式來確保他們的輸出能夠隨時被其他團隊成員訪問到�；蛟S這樣會使分享工作同開發工作一樣耗費精力，但是如果項目團隊要做到協作、保持質量和快速的驅動處理過程，那么這就是唯一的一種方法。

達到這一效果的一種最簡單的方式就是創建一個共同的中央文件庫，每個人定期地將他們的工作上傳到這里，同整個團隊分享。當然這個庫需要被很好的組織和管理，但是它確實起到了人員之間共享的作用。然而，由于每個人是分別執行活動來發布自己的工作，所以在花費時間開發之后，還存在其他人不那么自愿進行調整的問題。所以我們需要一種更聰明的加工方法。這就是 IBM Rational 解決方案為分布式的團隊提供的極好支持的一個場景。其中包括這些例子：

• IBM Rational ClearCase® 和 IBM Rational ClearQuest® —— Configuration Management （配置管理）和 Change Management （變更管理）庫能夠分布于多個站點，或者通過 HTTP 來訪問，使得團隊中每個成員能夠訪問所有工作產品以及他們進行創造和修改的原因。
• IBM Rational Software Modeler 和 IBM Rational Software Architect —— 捕獲單個模型中的 UML 圖表，它同 ClearCase 的完全綜合能夠使同一個模型集中的并發的分布式工作變得有效。
• IBM Rational RequisitePro® —— 管理一個共同庫中的項目需求，可以追溯該模型，并且通過 Eclipse IDE 或者一個 HTTP 客戶端對其進行訪問。

這些解決方案都已經存在一段時間了，但是 Jazz 項目這種 IBM Research 和 IBM Rational 之間的協作又為分布式團隊開發出了新的解決方案。Jazz 所交付的第一個方案就通過提供一個分布式的變更和配置管理解決方案，為項目工作產品的管理提供了機制。然而，Rational Team Concert 還將溝通工具、集成處理過程支持工具和從 Rational Method Composer 中所捕獲的方法的處理過程設定的功能性綜合在一起。

敏捷的、分布式的，并且是 RUP 的

在分布式的但是敏捷的項目團隊的幫助下，當我們已經建立處理過程和工具的需要之后，仍然存在一個問題：在這些解決方案中的投資成本、在它們使用過程中的潛在項目開銷、以及項目協作和成功交付的風險，能否被證明對于那些分處異地的團隊來說在業務層面上是值得的呢？

通常的答案都是“是的”，這是因為同處一地的成本和問題都是十分嚴重的。（如果答案是“不是”的話，那么可能會需要某些嚴重的業務改變�。┧�以，上面所提供的聯合處理過程和工具解決方案對于大多數機構來說肯定是很有幫助的。

分別思考

世界上許多結構正在將一種敏捷的方法用于 RUP，這三篇文章為這種做法提供了很高的見解。盡管敏捷社區中的許多人不愿意承認這一點，但是 RUP 確實普及了許多概念，例如：迭代開發、在每一次迭代中交付工作軟件、將測試貫穿于整個開發周期之中，等等。進一步地，RUP 全面地闡述了開發問題，其中包括為了開發系統您所必須解決的許多“小”問題。好的 RUP 就是敏捷的，不過，好的 Agile 就是……RUP 么？

文章來源于領測軟件測試網 http://www.kjueaiud.com/