Michael Feathers預言：在5年內，對特性團隊(Feature Team)是個錯誤的想法將達成共識。至少不會像現在這樣流行。

banq發表於2019-11-09

圍繞一個系統的某個區域的活躍的領域知識才是有儲存價值的基本單位，但是這容易被破壞隔離，領域的知識連續性很重要，DDD的有界上下文概念似乎是一個很好的基礎。

(特性團隊是跨專業的, 面向終端使用者交付完整價值的團隊，元件團隊Component Team, 比如計費團隊, 訂單團隊, 支付團隊)

我同意這一點。作為從事基礎設施軟體工作的人，我發現在結構化方面具有更大的價值：1）保護系統的概念完整性，尤其是防止蜘蛛網的有機增長，以及2）提供跨越系統邊界的明晰合同/承諾。

我認為特性團隊是不安的中間立場，因為您無法從元件團隊或真正的產品團隊獲得好處。

當您的產品是由高度可識別的功能組成且兩者之間有明確的過渡時，特性團隊才有意義。如果不是這樣，那麼它更多是一種敏捷的縮放技術，會導致失望。

以我的拙見，每當我們選擇搭腳手架的方式而不是從思維方式轉換來解決問題時，都會有一段蜜月期，我們認為我們將其正確處理了，然後大多數人轉身離開。但是仍然有一些人聲稱這種腳手架搭得有效，並將自己視為精英。

我認為，在5年的時間裡，軟體開發中的思想週期將再次開始，我們將回到ORM（幾乎只是瀑布而得名），以此類推，因為大多數開發人員必須再次學習一切。

公平地講，使用特性團隊的建議主要針對嚴格孤島的組織。我見過一個公司的功能和元件團隊混合在一起，效果很好。

特性團隊導致程式碼質量低下。不幸的是，程式碼質量低下的痛苦只有在一段時間之後才對管理者顯現出來，在此之前已經造成了損害。

特性團隊就像大型公司中的微型初創公司。

特性團隊曾經而且一直應該被視為一個好主意。該概念有助於“消除”非生產性的反饋迴圈。
 

相關文章