避免二次系統綜合徵的提示

最近我看到我們的開發團隊在計劃下一個版本的產品時越來越接近'second system syndrome'類型的想法。雖然我全部都是爲了改進和消除過去的一些錯誤，但我不希望看到我們陷入無止境的重寫和永不發射任何東西。避免二次系統綜合徵的提示

是否有一個很好的設計/開發方法，可以幫助構建更好的版本2.0，同時避免出現第二個系統場景？

來源

2010-02-17 Wally Lawless

「我不想看到我們停留在無止境的重寫和永不發射任何東西。「

這就是爲什麼人們使用Scrum。

定義要構建的東西的積壓。
確定優先級，以便導致釋放的東西是第一位的。應該固定的是第二。
執行sprint以獲得發佈。執行發佈衝刺。

來源

2010-02-17 14:59:09

感謝您的回答，我選擇它是正確的，因爲它簡潔明瞭，但可以讓工作流程順利進行。 – 2010-06-16 13:34:05

Scrum不會阻止您創建「第二個系統」。它只是管理你的工作流程。「二系綜合症」主要是一個架構問題。（此外，我不喜歡Scrum）。 – Rolf 2014-01-15 13:49:17

專注於系統架構應該有助於

具有支持子系統
已經記載設計決策之間的「鬆散耦合」（避免重新散列先前打漿路徑）

因此記錄的界面，而不打算用於所有出交換，目前的系統可以通過更合適的接口進行「升級」，以幫助未來的發展。

的另一個好方法重點：分配$$$人物每個特徵和相應優先;-)

總之，只是我的2分錢小費

來源

2010-02-17 14:56:44 jldupont

難道不是這個問題 - 很容易過分關注重構架構系統，而不是爲2.0完成增強/錯誤修復？ – 2010-02-17 14:58:07

+1「記錄的解決方案」（好吧，實際上你說的是文件化的設計決定......）。可以通過不知道如何處理實際系統來實現「第二個系統」。 – Rolf 2014-01-15 13:50:27

嘗試專注於短的交付週期，即強迫自己每隔幾周或每月向用戶提供一些有形和有用的東西。根據客戶的價值優先考慮任務。這樣，您總能獲得滿足用戶需求的可用功能應用程序，而如果您願意的話，您可以通過小步驟重構體系結構（如果您可以證明對它的需求 - 也就是對管理層/客戶，而不是隻是隊友！）。

如果您有一套穩定的自動（單元/集成）測試的構建過程，它會有很大幫助。

敏捷開發方法如Scrum這樣做，他們是熱烈推薦。但當然，在團隊中適應這種方法並不總是很容易，甚至不可能。即使你不能，你仍然可以把它的元素應用到你的項目中（也許甚至不需要公開提及「敏捷」或「Scrum」）;-)

來源

2010-02-17 15:02:20

得到至少寫過一個人三個系統來領導這個項目。

來源

2010-02-17 15:05:34 Nat

+1聘請已成功構建類似解決方案的人在我的十大最佳項目管理實踐中處於領先地位。 – 2010-02-17 15:21:24

除理想情況外，您希望有人編寫了同一個系統的三次迭代。有人寫了三個「第二系統」，甚至三個「第一系統」，可能並不是你想要的。 – 2016-05-04 03:40:42

確保您儘可能好地記錄了要求。顯而易見，您還需要管理進入需求的內容以避免過度設計，固定範圍有助於防止開發人員跑出想法或鍍金需要完成的任務，並且有助於防止管理層或客戶引入範圍蔓延。定義所有要求以及如何處理範圍更改。我所有的開發週期都很短（確保你正在編寫測試）和敏捷方法學，但這兩者都不能防禦二次綜合徵系統。在某些方面，如果您在短暫衝刺的情況下不停地查看整體圖片，則可以更輕鬆地繼續添加功能。使用敏捷實踐來構建最簡單的工作，然後儘可能簡單地添加其他需求。記住YAGNI，因爲當你第二次構建一個系統的時候，那就是當你最有可能建立你確定需要的東西的時候，某些事情會使系統「可擴展」，所以永遠不需要第三個版本。這是最好的意圖，但通往地獄之路等等。

來源

2010-02-17 15:12:26 Tom

Upvoting因爲驚訝，更多的答案不提YAGNI。在我看來，限制重寫範圍的關鍵是在排除功能和/或支持功能之間找到一個平衡，這些功能一方面不是立即需要以滿足硬性要求，而不是「繪畫自己進入了一個角落'，關於在以後的日子裏增加功能支持的可能性。即。最優重寫是一個精簡的核心實現，但與「可能」最小的「重構距離」可以在不增加冗餘複雜度的情況下實現。 – jlmt 2016-01-24 17:09:19

我上投·洛答案，並希望多增加一些建議：

交付工作的產品給客戶儘可能頻繁地。持續幾周到兩個月的迭代是理想的。像Scrum這樣的敏捷方法可以很好地適應這一點。
使用FogBugz進行功能和錯誤跟蹤。它的功能對於敏捷項目非常實用。根據發佈和優先級，FogBugz允許輕鬆優先化。如果您的團隊爲每項任務輸入估計的工作量，您也可以使用它來計算合理的發貨日期。
根據80/20 rule優先考慮您將開發哪些功能（20％的功能將在80％的時間內使用）以及最差的降壓功能。這有助於保持系統儘可能簡單，有助於防止feature bloat，並節省開發和測試時間。
當您確定問題的優先級時，對新功能和錯誤給予類似的考慮。 the Joel Test的一點是「在編寫新代碼之前是否修復錯誤？」。在大多數商店中，這不會發生，但不要事後調試系統。此外，保留舊系統的工作副本以與在新系統上發現錯誤時進行比較。
也是維護和必要時重寫現有代碼所需工作量的因素。如果你還沒有這樣做，給團隊一些時間來編寫他們覺得很難改變的整個文件。如果系統代碼第一次難以維護，這隻會變得更糟，導致您的團隊花更多時間在新功能上。

來源

2010-02-17 15:24:44 David

我已經經歷了雙方作爲客戶/贊助商和開發團隊的一部分的第二個系統綜合徵。

問題的根本原因在於團隊鎖定了第2版的烏托邦願景，例如希望使新軟件「靈活」。在這種情況下，所有東西都被抽象爲第n層。例如，不是代表真實世界實體的數據對象，而是創建一個可以表示任何東西的通用「項目」對象。一個有缺陷的想法是，我們可以在軟件中構建如此多的靈活性以預測未來的需求，非程序員將能夠配置新的功能。通常，諸如「靈活性」之類的一個目標掩蓋了所得到的軟件無法工作的努力。

對可用性，性能，可擴展性，功能，可維護性和靈活性目標的均衡實際考慮可以使團隊重返現實。如果......應該被禁止出現在團隊的詞彙表中，那就太好了。 Scrum積壓是一個好工具，應該聽到團隊經常說......「讓我們積壓起來......我們不需要那個版本2.」

來源

2011-06-01 15:06:43

它永遠無法完全避免。但謹慎可以緩解這個問題。您應根據定義系統成功的重要參數（最稀缺的資源）制定一些拇指規則。例如，減少潛在的錯誤數量可能會直接降低運營成本（支持中心的潛在服務呼叫）。但是在其他所有系統中情況可能並非如此。另一個例子，在某些情況下，CPU，內存和其他資源的稀少使用可能會有所幫助，但是可能會有環境可能會大量使用它們。

所以，簡單地避免「誘惑」，找準稀缺的資源（時間，精力，金錢$等），只考慮那些超過閾值執行。[F（S1，S2 ...）>閾值]

儘管迭代式發展，我會強調如何處理技術債務。
鏈接，都與此有關：
Tech Debts: Effort Vs Time
Tech Debt Quadrant

來源

2011-10-30 06:44:22 Lokeshwer

你不能接近第二系統綜合症。要麼你在裏面，要麼你遠離它。你會知道你在什麼時候，但只有在浪費了大量資源之後。

提示是：瞭解它（所以基本上我們已經得到了覆蓋）。知道什麼是「第二個系統」是非常寶貴的信息，甚至有更多的經驗。我想我們都有一些經驗，希望是溫和的。

這些知識經常會讓你思考三次，你會發現一個解決方案，而不冒險進入第二系統的陷阱。 PS：還知道如何使用您當前的系統，其中包括可能記錄的解決方案和其他文檔。

來源

2014-01-15 13:47:02 Rolf

避免二次系統綜合徵的提示

回答

相關問題