（對於那些還沒有聽說過的人來說，Pivotal Tracker「是一個簡單的基於故事的項目規劃工具，它允許團隊協作並即時應對現實世界的變化，它基於敏捷軟件開發方法，但它可以用於各種類型的項目。「）PivotalTracker最佳實踐
我們即將加入基於this outline by Rein Henrichs的工作流程，並對如何將產品組件分解爲項目的意見感到好奇。
我們已經試驗了一些標記，但似乎如果系統中有很多組件（照片查看器，視頻查看器，新聞源，通知服務），則單個項目可能會變得非常擁擠。
同時，對版本控制等，現在看來，這可能會更有意義就什麼都有了在一個項目無論是雜亂的。
有什麼想法？意見？註釋？謝謝。
記住Tracker是一個故事爲基礎的規劃工具，而不是基於任務的規劃工具。從客戶的角度來看，故事是否會影響照片查看器，通知服務或兩者都無關緊要。客戶有一些他們希望實施的故事（高層需求），他們對故事的成本進行了估計，並且他們有能力確定故事的優先順序。將組件分解成任務級別的問題。
更重要的是，對於同一個產品分成多個跟蹤器項目的最新報導將難以對客戶進行溝通，他們如何優先考慮的故事，或得到一個很好的估計何時可以完成的故事。
我們使用跟蹤器來跟蹤我們的故事，我們有我們自己的船上有我們跟蹤任務。我個人認爲跟蹤Tracker中的故事和任務會很有用，但該工具不支持它。
有趣。所以故事會有多重任務，並且團隊成員可以確定完成故事需要完成哪些任務。 鑑於你的回答，我正在給單元測試問題添加一條評論。 Lmk你的想法。 – 2009-05-07 14:30:01
這可能是最好有一個單一的項目來包含你的所有故事。這樣，整個團隊就有一個地方可以看到項目正在發生什麼，以及當前優先項目是什麼。如果你的故事足夠細分，以至於它們可以成爲Rein的過程中的特徵，那麼你的狀態很好！在一天結束時，擁有優先級的功能列表是所有開發團隊真正需要的。使用Tracker中的標籤進行過濾。他們工作得很好。在我看來，將單個產品分解爲多個依賴項目實際上會掩蓋信息並使得難以瞭解項目的真實狀態。
在Namshub的帖子的光這匹Tracker是爲故事（而不是任務或組件），如何將單元測試一般對應於故事？ （現在我們使用標籤「單元」來說故事應該有單元測試）..理想情況下所有故事都會有測試嗎？或者單元測試通常與組織項目的其他方式脫鉤。 – 2009-05-07 14:34:24