程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> 更多編程語言 >> Rational >> 使用IBM Rational Team Concert V2管理Scrum項目,第1部分

使用IBM Rational Team Concert V2管理Scrum項目,第1部分

編輯:Rational

第1部分 創建項目、團隊和計劃

在超過一年多的時間裡,我們一直在使用 IBM® Rational Team Concert™ 來支持我們的 Scrum 團隊,享用它的特性,與它的缺點共存,並發展它的下一個版本。使用 IBM Rational Team Concert V2,Jazz 和 Rational Team Concert 團隊可以向 Scrum 和敏捷評估、規劃支持交付顯著的改進(更不要去提更加改進的 Web 客戶端以及許多其他新的特性)。

專業術語 scrum 起源於橄榄球運動,是 scrummage 或者 scrimmage 的簡稱。在軟件開發中,scrum 是敏捷開發過程中管理項目的方法。其目的是在盡可能最短的時間內,向投資者交付最高的商業價值。Scrum 過程可以幫助剩余的最有價值特性在接下來得到創建,它強調工作會在快要交付時得到完成。工作構建於兩到四周的沖刺,或者迭代,以及每個沖刺階段末尾生產的軟件。

為了學習怎樣管理您的 Scrum 項目和 IBM® Rational Team Concert™ ,您可以創建一個項目,然後在它的第一次迭代中繼續處理它。系統項目的數據來自 Mike Cohn 書籍中的擴展實例。Agile Estimating 以及 Planning(Prentice Hall,2005),它描述了 Bomb Shelter Studios 的 Scrum 團隊,假設他們正在處理一個名為 Havannah 的新電腦游戲。范例中的數據,是文章中所含的文件“Rational Team Concert scrum sample data”。

本文基於您已經在 jazz.net 上注冊過,而且已經根據其中的指導下載並安裝有軟件的假設。您需要了解 Rational Team Concert 客戶端可以在什麼地方鏈接到 IBM® Jazz™ 儲存庫。在對 Scrum 過程進行一個簡單地介紹之後,我們將會開始創建基於 Rational Team Concert scrum 的項目。

scrum 過程的概述

scrum 框架由以下相關的方面組成:

角色

產品所有者

Scrum 管理員

團隊成員

儀式(會集或者會議)

日常的 Scrum

沖刺規劃

沖刺評審

沖刺回顧

工件

積壓的產品

待辦沖刺

Burndown Chart

干擾因素列表

Scrum 項目中的需求通過積壓的產品項目來表達。這是 Scrum 團隊中最重要工件中的一個。它是項目所有預期工作或者特性的優先列表。產品所有者對維護該列表,以及隨著項目的發展和商業環境的變化校正優先級負責。理想條件下,Product Backlog 中的項目陳述於向投資者指示商業價值的項目中。

產品所有者對產品的成功負責。這個人負責定義特性以及工作日程,並對決定各種特性的商業價值負責。產品所有人會不斷精簡和重新設定 Product Backlog 的優先級。

scrum 管理員管理 Scrum 過程,確保 Scrum 操作得當了正確的執行,並且 Scrum 價值為所有的團隊成員所理解。他或者她通過消除不利因素的影響,避免團隊成員受到外部的干涉,來確保團隊保持較高的生產效率(至少在一次沖刺階段中是這樣)。

scrum 團隊應該是擁有各種技巧的多功能混合人才組成的團隊,以完成項目(例如:開發員、測試員、交流設計員以及程序編寫員)。團隊成員應該全身心的投入到 Scrum 團隊中,否則,會降低團隊其他成員的速度。

團隊會在每一次沖刺的開始階段開一次沖刺規劃會議。在這個會議上,產品所有者會闡述即將到來的沖刺最需要的特性,描述它們,這樣團隊才會明白接下來他們要做什麼。產品所有者和團隊會就沖刺階段的目標達成一致意見。它關注的一般是接下來兩到四周要做的工作。團隊會決定怎樣完成沖刺階段的目標,並將特性分解成若干個可以完成的任務。

任務的列表就成了所謂的代辦沖刺。代辦沖刺中的項目通過小時來評價,這樣團隊才能明白該項目是否能夠按時完成。如果沒有足夠的時間,特性可以從 Sprint Backlog 移至 Product Backlog。評估是作為團隊活動進行的,而不是由 Scrum 管理員或者產品所有者決定的。代辦沖刺代表了沖刺期間團隊需要完成的工作。

在日常 Scrum會議期間,團隊需要回答下列三個問題:

我昨天都干了些什麼?

今天我要做什麼?

發展過程中有什麼不利因素(如果有的話)?

這並不是一個狀態的會議,而不是規劃和承諾的會議。整個過程所花時間最多不應該超過 15 分鐘。關於每一個人在做些什麼、他們面臨什麼問題的規范討論,能夠消除其他會議的需要,並幫助團隊成員更有效地工作。

在每一次沖刺的結尾階段,團隊會沖刺評審會議階段展示所完成的工作。這是一種簡單和不規范的會議,任意感興趣的團隊都可以參加這個會議。它的目的是驗證工作軟件(或者其他有價值的工件,例如潛在產品結構的概述),並從參與者和投資者那裡得到關於工作軟件的回饋信息。

在沖刺評審之後,團隊會自發地召開沖刺回顧(有時也叫做 Reflection)。在這個會議期間,他們會討論關於項目什麼進展良好—以及什麼不好—。這個會議會導致迎接下一個沖刺階段所做工作的一些轉變,因為他們會不斷工作以提高團隊的實踐效率。既然 Rational Team Concert 對於團隊的過程調整是可以配置和適應的,那麼通過更改 Rational Team Concert 中的進程,這些會議可能會導致工作上的一些改進。

Product Backlog 中的項目會在沖刺規劃會議期間得到完成,它們成為積壓沖刺的一部分。Sprint Backlog 包含有與 Product Backlog 相關特性的特定任務。在沖刺期間,Sprint Backlog 中工作項目的狀態每日都會得到更新。更新的狀態使得生成 Sprint Burndown 表格變得可能。這種 burndown 表格在圖表中顯示了項目中剩余的工作量。它還含有一條“理想”線,以指示沖刺階段從開始到結束的平滑過渡。理想線指示了如果在沖刺的每一天工作都得到了完成,那麼工作將會怎樣發展。盡管實際的工作進展可能不會遵守這條線,顯著的偏移會導致人們的關注,特別是在實際進展繼續偏移理想條件時更是這樣。

當有不利因素阻礙工作的進一步發展時,Scrum 管理員可能會維護一個 Impediments List (或者 Blocks List),作為額外的 Scrum 工件。所有的工件應該位於可以使用它們的地方,並且所有的團隊成員都能看見它 。

Rational Team Concert Scrum Process 模板支持所有重要的 Scrum 角色、儀式以及工件。Rational Team Concert 通過基於 Eclipse 客戶端用戶界面(UI)以及 Web UI,提供了對這些特性的方便訪問方式。

通過使用 Scrum 方法來管理項目,您需要維持項目的工作描述,一般叫做 stories 和 tasks。盡管您可以簡單地把卡片放到公告牌上,使用軟件可能會更加合適,特別是當團隊成員分散在不同地理位置時更是這樣 。

Rational Team Concert 提供了一種簡單地方式來管理所有的需要,在一個項目區域中,您可以管理您的構建、源、計劃以及其他更多。該文關注於 Scrum 過程的規劃和管理。在執行第一步之後,鏈接儲存庫,以及為使用工具的人們定義用戶 IDs,我們解釋了在項目發布的迭代時期,怎樣創建 plans 和 work items 並管理它們。

創建 Rational Team Concert 儲存庫和用戶

在您准備查看 Rational Team Concert 和 Jazz Scrum Process 模板怎樣支持 Scrum 團隊之前,您需要處理基本的項目創建問題。

創建一個儲存庫鏈接

確保 Jazz 服務器已經啟動,而 Rational Team Concert 客戶端已經打開。

為了創建一個新的儲存庫鏈接,在 Team Artifacts 視圖中右鍵點擊 Repository Connections (見於圖 1),然後選擇 New > Jazz Repository Connection。

輸入 URI 以及用戶 ID 還有相應的密碼。

提示:

當您在本地系統上使用 Jazz 服務器的安裝文件時,例如,URI 可能會是 https://localhost:9443/jazz/,初始的用戶 ID 是 ADMIN 而密碼是 ADMIN(兩項都是區分大小寫的)。

注意:

注意“https”中的字母 S 是小寫的,它意味著 Jazz 使用了安全的鏈接。取決於您自己的浏覽器,如果您忘了包含“s”,那麼您將會遇到不可預料的情況。

圖 1. 創建一個新的儲存庫鏈接

點擊 Finish。

取決於 Jazz 服務器安裝的系統,當您第一次鏈接它的時候可能會花一定的時間,直到儲存庫鏈接得到創建為止。

添加或者導入用戶

接下來的步驟,是創建 Rational Team Concert 中的用戶。用戶屬於 Jazz 儲存庫,這樣他們可以參與超過一個 Project Area,並使用服務器上其他基於 Jazz 的工具。如果您使用外部的用戶儲存庫來配置 Jazz (例如您集成了 LDAP 服務器),那麼可以導入用戶,而不用創建用戶,就像工具欄中解釋的那樣。在這裡,讓我們假設您使用的是默認的 Tomcat 程序服務器,以及在新儲存庫中您需要創建的用戶。

為了創建新的用戶,您可以右鍵點擊儲存庫鏈接,然後選擇 New > User。

當決定是否導入用戶時,選擇 No(圖 2)。

圖 2. 創建一個新用戶

為第一個用戶輸入用戶信息。

因為我們遵循的是 Mike Cohn 的范例,所以 Sasha 是第一個用戶。

您可以選擇,如果有的話添加一張照片。

電子郵件地址是一個需要的區域,因為 Jazz 可以發送關於團隊活動的 e-mail 通知。對於 Sasha,輸入 [email protected]

用戶的初始密碼會自動設置成與用戶 ID 相同的值。

為用戶選擇合適的 Jazz 安全組。管理項目的用戶必須位於叫做 JazzAdmins 的儲存庫組中(在本例匯中,Sasha 必須成為一個 JazzAdmin;否則,他就不能執行所有需要的配置活動了)。

JazzUsers 在 Project Area 中擁有默認的許可權。它會允許用戶創建並添加至 Work 項目,以查看報告,並使用其他項目安全設置定義的其他特性了。

JazzAdmins 可以訪問與 Jazz 服務器和項目相關的各種設置了。

為用戶選擇合適類型的許可證。

Developer 許可證,創建或者部署過程模板的用戶需要它,以便創建 Project Areas 或者計劃,然後創建或者編輯附屬的頁面。開發員許可證適用於編寫代碼和運行構建的團隊成員。

Build 和 ClearCase Connector 許可證一般只分配給管理性的用戶了。

Contributor 許可證適用於所有的團隊成員,這些團隊成員只需要對儲存庫進行讀取訪問。使用 contributor 許可證,一個用戶才可以創建工作項。

圖 3 顯示了結果界面。

圖 3. 指定用戶細節信息

點擊 Save。

注意:

稍後,用戶需要配置他們的工作環境,並輸入他們的日程安排(在屏幕的底部查找),這樣他們可以花在項目上的時間就能得到合適的計算了。稍後我們將會顯示一個范例。

對於本例中使用的 Havannah 項目,需要按照相同的方式為 Sasha 添加更多的用戶。

添加其他名為 Allan、Delaney、Frank、Prasad 和 Rose 的其他用戶

向擁有 Developer 許可證的 JazzUsers 組分配用戶。

作為 ADMIN 用戶檢出。

作為默認的 ADMIN 用戶現在您已經完成了條目。Jazz 安全模型給與了這個用戶基本的管理員特權,而不是給定 Project Area 內特定的權利。例如,ADMIN 用戶不能在user cannot create and save new iteration plans in the Project Area 創建和保存新的迭代計劃,因為它是為 scrum 管理員或者產品所有者准備的。對於 ADMIN 用戶您可能不再需要儲存庫鏈接;因此,對於 Sasha 您可以再次使用它。

右鍵點擊儲存庫鏈接並選擇 Properties(圖 4)。

圖 4. 指定注冊屬性

更改 User ID 和 Password 區域以匹配 Sasha 的憑證(sasha 和 sasha,因為默認的密碼和用戶 ID 使用相同的值)。您還可以選擇(或者不選擇)“Remember my password”以及“Automatically log in at startup”復選框,如圖 5 所示。

圖 5. 指定注冊屬性

在您點擊 OK 時,您可以注冊到 Sasha,他是 Bomb Shelter Studio 的 scrum 管理員。

為您的項目和成員創建區域

創建一個 Project Area

接下來的一步,是創建一個 Project Area,它作為容器,容納了所有的計劃、工作項以及與創建項目相關的其他事情 。

為了創建一個新的 Project Area,右鍵點擊 Team Artifacts 視圖中的儲存庫鏈接,然後選擇 New > Project Area。

為項目輸入一個名字(本例中是 Havannah,然後點擊 Next。

當您首次創建 Project Area 時,您需要部署前面包裹的過程模板,所以點擊 Deploy Templates。可能需要一定的時間來完成。

在 Available Process Templates 下面,選擇 Scrum 模板並點擊 Finish(查看圖 6)。

圖 6. 通過使用 Scrum 模板來創建 Project Area

Project Area 在服務器上初始化需要花費一定的時間。當這個過程完成之後,您可以看到一個與圖 7 相似的界面。

圖 7. Havannah 項目的 Project Area

在 Team Artifacts 視圖的左列中,您可以查看新的 Project Area,以得到 Builds、Plans、Reports、Source Control (streams)以及 Work Items 的文件夾。本文只關注 Plans 。在 Project Area 編輯器中,有一個 Description 區域,它會提供關於項目的信息。

注意:

在 Project Area 中,添加附件還有一個部分。它是為 Scrum Process 模板准備的,並不是存放項目附件的合適地方。

添加成員並指定他們的角色

作為 Project Area 的創建人,您就是初始的管理員。但是,Scrum Process 模板內編輯項目結構的大多數許可證,屬於 Scrum 管理員和產品所有者。因此,您需要做的第一件事情,就是向項目添加成員,並設置他們的角色(至少對 Scrum 管理員和產品所有者來說是這樣)。一般來說,Project Area 層次的成員擁有管理責任。您需要向 Team Area 添加另一個團隊成員。

在本例中,Sasha 創建了 Project Area,這樣他成為該區域的初始管理員,並對 Project Area. Frank 作出任何更改,Havannah 產品所有者,是一個合適的 Project Area 層次的成員,所以現在添加它 。

點擊 Members 左邊的箭頭以展開這個面板。

點擊 Add 以啟動 Add Team Members 向導。

為了添加 Frank 作為產品所有者,您可以在用戶名字區域內輸入一個 f (字母 F)以搜索匹配的名字。因為 Frank 已經作為 Rational Team Concert 用戶添加,他的名字將會出現在 Matching Users 列表中。

點擊 Select 以將其移動到 Selected Users 列表。

然後點擊 Next。

選擇 Product Owner 角色,然後將其添加到 Assigned Roles 列表,然後點擊 Finish(見於圖 8)。

圖 8. 添加團隊成員

如圖 9 所示,Frank 是作為項目的產品所有者添加的。

圖 9. 向 Havannah 項目添加成員

保存 Project Area (使用 Project Area 編輯器右上角的 Save 按鈕或者 File > Save)。

在保存您的更改之後,將會出現一個新團隊成員的列表,詢問您是否想要通過 e-mail 來向他們發出邀請。如果您已經配置了 e-mail 支持(在您創建服務器時),並同意這一點,那麼項目的成員將會收到一封歡迎的電子郵件信息,以及對項目的鏈接信息和鏈接方式。

因為這裡用戶都是虛構的,所以取消所有的選擇,然後點擊 OK。(您還可以使用對話框中的 Cancel,因為它只會發送一封電子郵件。)

總結發布的日期限

接下來的一步,是為項目規劃時間限制,這意味著您要為發布和沖刺指定起始和截止日期。在您創建自己的 Project Area 時,根據您的需要調整日期。以後再選擇一個起始也是可以的。

提示:

更改項目您需要得到認證。創建項目的用戶擁有管理員權限,並作出上面描述的更改。在您創建自己的項目時,您必須確定,要麼您是 Project Area 的管理員,要麼您是 scrum 管理員或者產品所有者角色的成員之一。否則,當您試著更改時間限時,會遇到一個“許可證禁止”的錯誤。

在 Project Area 編輯器窗口的右邊,Timelines (見於圖 10)之下,您可以看到默認的占位符迭代,在您創建 Project Area 時,過程模板將會創建該迭代,其中包括了版本 1.0 之下的 Sprint 1 和 Sprint 2 。

選擇 Process Iterations 之下的 Release 1.0,並點擊 Edit Properties 以打開如圖 10 所示的 Edit Iteration 下拉菜單。

圖 10. 指定版本以及沖刺時間日期限

保持 Iteration Type 為默認值不變。

Identifier 必須是獨一無二的,但是您可以根據您的需要將其更改。

為發布設置起始和截止日期(見於 Note),確定復選框“A release is schedule for this iteration”被選中了,然後點擊 OK。

您可以為已存在的迭代按照相同的方式來編輯屬性。

找到自動分配給您的任務

有一些任務會自動創建,並分配給創建 Project Area 的人。為了列出這些任務,您可以選擇 Work Items > Shared Queries > Predefined,並運行 Open assigned to me 查詢。您可以完成這些任務以定制您的 Project Area。

注意:

因為工作追蹤十分的費時,所以日期基於您處理本例的時間。在今天或者未來的某一天開始發布和第一次迭代。為接下來的六周時間設置發布和截止時間。每一次沖刺至少需要延續兩周左右的時間(一般從周一到下周的周五,除去非工作日)。

注意:

Release 1.0 圖標和 Sprint 1 圖標中的小藍色三角形裝飾符,意味著它們是 當前的 Release 和 Iteration。

提示:

稍後您可以對 Project Area 作出一些更改。如果您想打開它,右鍵點擊它並選擇 Open(雙擊只會展開或者收縮它)。

Project Area 是可配置的。在 Process Configuration 項上,Project Configuration 下,有很多選項可以滿足您各方面的需要。隨著您對 Rational Team Concert 越來越熟悉,您將可能想讓您的團隊適應它(例如,Reflections 會議期間討論的結果)。過程定制對於使過程滿足您的需求方面,是一款強大的工具,而不僅僅是約束團隊成員的行為去適應過程。

圖 11. 項目配置

指定 Team Area 並添加成員

Jazz 技術可以使用多種時間限和子團隊來支持相對較大的團隊。在 Project Areas 內,有 Team Areas 可以組織團隊成員。只有 Team Area 成員有權分配有與其團隊相關的任務。就算例子中只有一個團隊,它仍然需要引入一些成員。

點擊左邊窗格中的 Team Organization 項。如果它沒有打開,那麼就使用 Window > Show View > Team Organization 來將其打開。

展開 Havannah 文件夾(在您創建 Project Area 時該文件夾會得到自動創建)。

當項目被分配給團隊 1 時默認的名字會分配給團隊。右鍵點擊 Team 1 並打開 Team Area 編輯器。

輸入 Havannah Team 作為團隊的名字。

添加 Allan,Delaney,Prasad,以及 Rose 作為團隊成員。當您向 Project Area 添加 Frank 時,按相同的方式進行操作。在 Add Team Members 向導中,您可以使用 *(星號)通配符來返回所有的成員(如果您使用的是集成的 LDAP 服務器就不要這樣做),並在分配 Team Member 角色之前,將其全部選中。

添加 Sasha Scrum Master 的角色,並且可以選擇,向他分配 Team Member 的角色,因為在 Rational Team Concert 中,scrum 管理員並不會自動被分配 Team Members 的角色。

點擊 Save。

圖 12. 向Team Area 添加成員

提示:

大型的團隊一般都有很多子團隊組成。您可以通過根據項目的規模,添加許多附加的子團隊來反映團隊的結構。

指定團隊成員的出勤情況

對於團隊成員工作負荷的計算問題,您可以調整團隊成員的出勤情況。也許某位團隊成員在外面擁有業務,或者在休假,因此限制了他的出勤率。可以在用戶的頁面上對其作出調整。一般來說,用戶會期望讓這個區域能反映他們當前的真實情況,但是因為它是計算 Team Load重要的一部分,所以我們將會在這裡介紹它。

如果您沒有看到它,那麼請點擊左邊窗格中的 Team Organization 項,並展開 Havannah folder 以及 Havannah team。

為 Rose 打開用戶編輯器。您可以雙擊一個用戶名以為該用戶打開細節信息。

Rose 此時對團隊的出勤率只有 75%。因此,點擊底部的 Work Environment 項,然後在 Work Assignment 部分中,點擊 Havannah Team 線以及 Change 選項(見於圖 3)。

默認條件下,如果一個用戶只被分配給了一個團隊,那麼他或她 100% 的時間(資源)都被分配給了該團隊。為了降低 Rose 的任務量,選擇任務並點擊 Change。將任務量降低到 75%(見於圖 13)。

點擊 OK。

這將會調整 Rose 可用的工作時間。

圖 13. 為某位用戶調整工作環境

她有一個即將到來的假期。切換至 Scheduled Absences,點擊列表右邊的 New 項,並為她的假期時間輸入一個描述和日期(見於圖 14)。

點擊 OK。

點擊 Save 以更新 Rose 的狀況信息。

圖 14. 為用戶輸入日程安排中的缺席情況

為項目創建 Product Backlog

Scrum 方法中最重要工件之一就是 Product Backlog。

為了構建它,切換至 Team Artifacts 視圖(查看圖 15 左上部),並在 Havannah 項目中,選擇 Release 1.0,右鍵點擊內容菜單,然後選擇 New > Plan。

提示:

您可能需要打開一個或者多個節點,以查看 Release 1.0 迭代。附加的版本和沖刺規劃(如果有的話)位於開發線之下(在本例中,是 Main Development),但是在 Plans 層次為了方便訪問,可以看到當前的版本和沖刺。

在打開的 New Plan 窗口中,輸入 Product Backlog 作為名字。

選擇 Product Backlog 作為 Plan Type。

對於剩余的 Team Members,Timeline,以及 Iteration,保持默認值不變。

點擊 Finish。

提示:

如果您不能保存計劃,那麼您可能需要切回並為 Sasha 的設置添加 Scrum Master 角色。

一個多頁面的編輯器將會為 Product Backlog 迭代計劃打開(見於圖 15)。

在 Overview 頁面上,您可以使用 wiki 形式的格式來輸入關於產品的信息。

編輯器視圖底部的 Attachments 區域(只是在頁面處於編輯模式下才可見),就是向該版本添加任意需求或者其他與版本相關通用文件的地方,這樣所有的團隊成員都能看到它們了。根據需要,頁面區域可以包含對 Web 站點或者外部文件存儲庫的鏈接。

點擊 Planned Items 項以開始添加積壓項。

圖 15. 編輯積壓

查看計劃有幾種方式,叫做 模式。在窗口的右邊,您可以指定怎樣對計劃中的項目分組,以及應該將什麼樣的項目排除出視圖。這些預定義的視圖,有 Backlog、Iterations、Teams、以及 Work Breakdown。您可以定義自己的視圖模式。如果您想這樣做,您可以使用右邊窗格中的 Edit | Copy 選項,它位於“View As”之下。其他的模式存儲在服務器上,其他的團隊成員也能使用這些模式,並對更改模式並保存後,將會影響到 Project Area 所有用戶的使用。

根據類型規劃計劃項目

對於 Rational Team Concert V1.0,計劃的項目可以根據 Owners,Categories,Tags,Planned Time,或者 Folders 來進行分類。版本 2.0 的特性功能更加強大。盡管早期分組的模式仍然可以為 V2.0 配置,但是使用以下這些新模式會更好:

Backlog

Iterations

Teams

Work Breakdown

用工作項填充 Product Backlog

在積壓的 Planned Items 項上,開始添加積壓項。對於 Scrum 項,產品積壓中的項目叫做 stories,如果它們很大的話,就叫做 epics(您可以查看 Mike Cohn 的書籍,User Stories Applied 或者 Agile Estimating and Planning,這兩本書在 Resources 中都有列出)。所謂的 事例就是產品中執行功能的描述,通常陳述於特性支持什麼樣的用戶角色以及它能提供什麼樣商業價值的術語中。一個合適描述的事例包括概括、特性討論的一些概括,以及 Product Owner 接受特性的狀況。在 Havannah 的范例中,所有的項目都叫做事例,所以您可以使用事例來填充積壓(簡單來說,本例中使用的大多數事例只包含了一個概括,所以不要把它和真實構築的事例混淆)。

將新項目的默認值設置成 Story。通過使用鍵盤快捷鍵 Ctrl+Enter,您可以快速輸入一個新的工作項。

右鍵點擊 Havannah Team 文件夾。

選擇 Add Work Item > Set Default > Story。

再次右鍵點擊 Havannah Team 文件夾,選擇 Add Work Item 然後選擇 Story (或者使用 Ctrl-Enter 快捷鍵)。

為新項目輸入總結,如圖 16 中下部界面所示。

圖 16. 積壓中的 Planned Items

根據產品所有者的需要添加所有的項目。

不時的點擊 Plan 項右上角的 Save 以保存您所做的工作。

在添加所有的事例之後,產品所有者接下來要做的,是為事例設置優先級。優先級屬性有 High、Medium 和 Low 三個值。您可以使用列表中嵌入下拉菜單來輕松分配優先級(見於圖 17)。

提示:

如果預定義的優先級並不適用於您的項目需求,那麼您可以在 Project Area 中輕松編輯可用優先級的列表。

您還可以在優先級內進行分級。通過拖拉項目然後在優先級分組內為 它們排序,來反映這種級別。系統將會通過拖拉操作而記住這種排序(或者使用 Alt+Cursor Up 和 Down 快捷鍵)。如果您拖拉了一個事例(例如一個級別為“中”的事例),到一個不同的分組,並放到不同優先級兩個事例之間,那麼 Rational Team Concert 將會自動分配優先級以適應它的前後事例的級別。

圖 17. 為工作項設置優先級

當團隊在為項目復雜性添加估計時,通過使用如圖 9 所示的下拉菜單來輸入(同樣見於 Mike Cohn 的書籍,User Stories Applied 或者 Agile Estimating and Planning 通用列於 Resources 中,因為關於估計和 Story Points 的討論已經超出了本文的闡述范圍)。

圖 18. 為工作項設置復雜性

Epics 和 Stories

默認條件下,Epics 和 Stories 是 Product Backlog 的工作項。如果您的團隊還想查看 Product Backlog 中的任務(或者一些其他類型的工作項,例如 Defect),那麼您可以添加該工作項類型作為 Project Area 配置中的 Top-Level Work Item Type:

從 Team Artifacts 視圖中打開 Project Area。

在 Process Configuration 項中,展開 Project Configuration、Configuration Data、Planning。

通過選中相應的復選框,來選擇 Top-Level Work Item Types 並添加 Tasks(或者其他的工作項類型)。

當然,如果我們只擁有 Story Summaries,那麼就不會有多少的 Product Backlog。

雙擊一個事例以打開它的編輯器(在本例中,如圖 19 所示,該事例聲稱“As a player, I can play against a weak engine that recognizes rings”)。

在 Description 區域內,提供關於事例預期情況的細節信息(在將 Story 添加致規劃時可以添加一個描述)。在這種情況下,它會引用(想象的)附屬於 Project Area 的文件。

項目的創建者會自動被分配該項目。如果您不需要該項目,那麼您可以點擊左下部 Quick Information 部分的 Subscribers 鏈接,並選擇 Unsubscribe Me。

圖 19. 項目的細節信息

點擊底部的 Acceptance Test 項目。由產品所有者或者團隊所有者添加接受測試,以作為事例成功完成或者滿足投資者預期需要的證明。

提示:

在構建列表的同時,處理添加細節的另一個好的方法,是打開迭代規劃編輯器中的 Preview 模式、點擊工具欄中的眼鏡圖標(見於圖 20),而編輯器將會分開顯示,以分兩邊展示迭代規劃和當前選中的項目。

圖 20. Previewing 項

提示:

如果您想要在積壓中按照層級結構組織和查看 Epics 及 Stories,那麼您就必須使用樹形視圖中顯示工作項的視圖模式。Work Breakdown 模式會以樹形視圖模式顯示工作項,但是您可以根據您的需要配置任意一個其他模式。

本文pdf附件

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved