2016-01-22 119 views
0

我們的開發團隊正在升級到TFS 2015,我們能夠從頭開始我們的工作項目跟蹤,所以我期待利用這一點重新組織我們目前的一些流程。TFS 2015多個產品的迭代組織

但是我想不出來組織在多個產品迭代一個合乎邏輯的方式,這裏就我們今天的所作所爲

    一些背景 - 我們有1個個小隊以3個開發人員,我們對3的所有工作不同的產品同時在桌面,網絡和移動是這三種產品,他們都是由同一客戶擁有密切相關
    - 我有TFS設置爲1大型團隊項目,因爲我讀過這是最好的方法組織工作而不是單獨的團隊項目
    - 每個產品都有不同的構建麻木呃所以我們可以識別不同的發行版本的每個產品

事情我已經嘗試了迭代組織:

    - 迭代每個產品(編號桌面/移動build1.1/build3.1網/ build4.1 )這是行不通的,因爲我只能將其中的一個設置爲「當前」,但實際上我們正在同時處理所有這3個問題
    - 單次迭代編號(root/build1.1)這對我們來說也是沒有意義的,因爲1.1只適用於其中一種產品,當我爲產品創建構建版本時,它們將具有與TFS不匹配的內部版本號。並非所有3款產品每次都會發布,因此即使我對所有3版本使用了單一版本號,在當前版本中未更新的產品的發佈版本號也會有差距。
    - 子迭代中,我可以將mobile/build3.1作爲desktop/build1.1的子項,但它不會在'Current'下顯示,所以我們不會直觀地看到當前版本將包含mobile3。 1項還
    - 我讀過,我們可以爲每個產品創建單獨的團隊,但我們必須切換儀表板才能看到每個產品的當前版本。這也感覺很奇怪,因爲它只是3個人一起工作的多個產品

我的目標是讓我們能夠看到每個不同的產品發佈號碼,其中包含當前項目分配給它在一個地方,任何人都可以建議一種組織這方面的方法?

回答

0

我不覺得迭代路徑是去這裏的路,也不是多個團隊。使用迭代路徑來跟蹤你的團隊衝刺並保持一個團隊,因爲你是一個小團隊。

幾天前有一個Similar question這是由傑西Houwing很好的回答。

標籤可能是最簡單的方法,但您可能會發現創建可以鏈接到待辦事項項目的自定義工作項類型(發佈)更好,或者可能僅僅是PBI上的自定義字段。