我們是否錯誤地使用了TFS 2010？

Question

我們的團隊是TFS2010的新成員。從歷史上看，我們使用了我們自己的業務需求矩陣（追溯矩陣）Excel電子表格。它具有以下典型列：

要求ID |項目|規則組| |業務規則|類型...等

我們的業務規則列讀取類似如下：

• 「系統將提供允許演員來搜索研究的一種手段。」
• 「系統應提供允許演員搜索項目的方法。」
• 「系統應爲入站包生成移動活動。」
• 「要導入條形碼清單，系統應在每個樣本佔位符中包含代碼，說明樣本是由條形碼清單創建的。」

由於我們行業對於文檔，審覈等方面的嚴格要求，我們選擇使用MSMI作爲CMMI而不是MSF作爲我們的流程模板選擇。

我們已經進行了許多關於如何將「我們的工作方式」實施到TFS 2010世界的最佳方式的討論。我們的問題的癥結似乎歸結爲以下幾點：

• 好像我們應該遵循的要求之間的「父/子」的關係 - >任務的實施選項卡。然而，這意味着我們有一個的任務，每要求（這似乎是多餘的和過於精細的）。
• 我們希望將任務看作不太細化的東西（即「開發出站控制檯屏幕」。）
• 我們希望開發人員能夠查看分配給他們的任務，並輕鬆查看要求（功能和非功能）與這些任務相關聯。
• 可追溯性是一個高優先級，但是，我們並不一定需要它非常細化（直到實際的代碼行）。正如我們所看到的那樣，這樣做會使發展非常繁瑣而且適得其反。我們希望在這方面取得明智的平衡。

我們的方法是否真的像方孔似的圓形？或者，我們只是誤解/錯過了什麼？我們覺得我們對各種工作項目類型有很好的理解。

要增加更多的上下文，我們的理解是，「特性」類型的需求是更精細的需求（如功能，非功能，QoS）的「父」。我們瞭解，需求類型的情景類似於用例。

因此，我們認爲，TFS 2010以下層次結構：

• 需求（功能）
• 需求（功能）
• 任務

顯然，對我們來說問題是，雖然我們想要Requ的父母/子女關係在某些方面的需求/任務......我們幾乎同時看到需要將任務作爲需求的父項。

我們相信我們可以跳過實施選項卡（以及它實施的父/子關係）......並只使用所有鏈接選項卡。這使得我們可以更靈活地通過其他鏈接類型（例如「相關」或「影響/受影響者」）將需求和任務相關聯......但是，那裏的大問題在於它打破了TFS 2010內置報告（特別是關於跟蹤需求進度/小時數）。

任何洞察力是讚賞。

Answer 1

聽起來好像您需要自定義TFS附帶的開箱即用過程模板。

說實話，我認爲每個人都應該定製模板，以確保他們獲得適合他們流程的工具，而不是改變他們的流程以適應工具。

我不確定您是否知道某些可用的自定義選項，因此我只會提及在爲我的公司定製TFS時使用的一些自定義選項。

您可以edit流程模板中出現的任何工作項類型。 您可以執行很多自定義操作，例如，在我們公司，我們只希望測試組中的人員能夠關閉錯誤，所以我們在關閉狀態的所有轉換中都加入了該限制。

您可以根據需要添加轉場，狀態，字段，選項卡等。

如果您需要一個新的工作項目，您可以從現有工作項目類型的空白或基本項目創建一個新工作項目，從現有類型創建一個新工作項目，export工作項目類型，編輯xml以更改將名稱命名爲新類型，然後導入它。

您對不同工作項目類型之間關係的擔憂應通過創建自定義link types來解決，然後將它們包含在新的template中。

您似乎對您要遵循的流程有很好的理解，我認爲您需要定製TFS以匹配該流程。

執行這麼多定製的一個缺點是標準報告不會爲您提供很多有用的信息。這將需要你的團隊寫一些新的報告。如果這可以滿足您的需求，您還可以在excel中做一些很好的報告。

HTH

Answer 2

我想你將不得不在這裏採用定製的方法。選擇對您而言很重要的報告和指標，作爲您對TFS的要求。從那裏，設計工作項目之間的聯繫，讓您獲得報告和指標。此外，你可能已經知道這一點，但是WI的任務確實有一個紀律領域，允許它不僅僅用於開發。祝你好運！

Answer 3

首先，歡迎TFS的世界。 :)

你的工作方式沒有錯。您列出的層次結構很好，TFS將支持您需要的任何一組工作項類型（WIT）和關係（鏈接）。該實施標籤，所有其他選項卡，顯示與其他鬥智鬥勇的關係僅僅是過濾你的類型與鬥智鬥勇的整個列表（即要求的實現選項卡顯示類型要求或所有工作項目任務，並有一個父母/子女關係）。

接下來的內容是，您應該考慮您的流程需要什麼工件（WIT），以及它們應該如何協同工作，並根據需要定製流程模板。

這樣做相對簡單，特別是當您使用屬於Team Foundation Power Tools的過程編輯器時。如果要修改鏈接頁面，則全部在佈局部分工作項目類型中完成。

關於需求和任務之間的關係問題：我總是將需求視爲的定義，用戶/客戶需要什麼。要求應該更加面向外部，描述需求，目標和預期效果（以及副作用）。這些任務更加內在，並且應該告訴開發者他（她）應該如何去實現上述目標。

考慮到這一點，我總是傾向於讓開發人員僅在任務上工作。此外，任務應始終來自需求（或錯誤，或更改請求等）。由於需求而沒有提出的任務可能表明，這項工作既沒有必要也沒有很好的計劃。

希望這會有所幫助， Assaf。