scrum和重構

如果scrum中的一切都是關於用戶可以看到的功能性東西，那麼真的有什麼地方可以重構與任何新的功能需求無關的代碼？scrum和重構

2010-03-16 zachary

這是一個編程問題？或者你只是因參加Scrum而感到沮喪？ – RubyDubee 2010-03-16 16:47:21

我認爲這不像Scrum那樣與項目管理理念有很大關係。

無論項目是否使用Scrum，許多項目經理都不喜歡開發人員將時間花在諸如代碼重構或重構等「不必要」的事情上，而這些「不必要」的事情並未直接推進其中一項突出的功能需求。這不是像正常發展那樣的「產生結果的工作」，而是「阻止後來延遲結果的工作」。鑑於用於Sprint的典型短時間線，好處往往難以看出，幾乎不可能量化。

保持代碼的可維護性需要成爲燒錄列表中的一項（如果使用Scrum）。它與新發展一樣重要。雖然它可能看起來不像「對用戶可見」的東西，但忽視它會增加你的技術債務。在技術債務堆積得足夠多以至於您的代碼缺乏可維護性降低開發速度的道路上，新功能開發的延遲將會對客戶可見。

這都是管理/哲學問題。與其將重構和可維護性增強視爲不影響客戶的「額外」工作，它應該被視爲時間投入，以防止顧客可見的延遲（以及潛在的錯誤）。開發人員有時可以比管理人員更清楚地看到這些好處;如果您的經理不理解忽略可維護性的缺點，您可能想要抓住其他幾個開發人員並與您的經理聊天。

來源

2010-03-16 17:34:59 bta

我想你可能是在談論大規模重構，而不是在整個紅綠重構週期中要做的持續重構。

我的做法是這樣的，如果重構一箇舊功能可以更容易地添加一個新功能，那麼繼續做下去。但是在某些方面你是對的，如果某個特定單位沒有改變的壓力（即它完全完成並且不會再改變，並且不會影響其他模塊），那麼就沒有實際需要重構。不過，我很少發現一個相當完整的模塊。

來源

2010-03-16 16:49:24

我認爲有一個公平的案例可以用於技術債務重構，其中維護代碼的努力/成本影響與重構它的成本一樣高或甚至更高，以改善質量或更好地/正確地工作 - 特別是爲了提高可維護性。

例如：如果軟件如此有問題，您將失去客戶或金錢，您會盡快採取行動解決問題。有人可能會認爲這是它自己的業務需求，但它通常不會放在前臺和中心在中小型開發項目上，而不是側重於創建應用程序的技術，而不是應用程序的質量對底線的影響。

來源

2010-03-16 17:07:47

如果一切Scrum是所有關於功能性的東西，用戶可以看到（...）

任何項目和方法應約產生商業價值，你很少做的事情只是爲了在商業環境中獲得樂趣。話雖如此，我認爲Scrum（以及其他敏捷方法）的質量是一種不會長期影響速度的方法，並最終實現超高生產力。因此，我認爲典型的「完成定義」應該包括諸如「不增加技術債務」（把你的質量標準放在那裏）。如果您認爲新功能會影響應重構的現有代碼，請在估算中包含此成本（或在您的產品待辦事項中創建一個重構項目），並向產品負責人解釋相關事宜。因爲最後，產品負責人需要確定項目的優先順序，並決定是否可以暫時犧牲質量（如果您的企業因爲不發佈功能而死亡，那麼重構現有代碼有什麼意義？）。但是他必須意識到這不是一個長期戰略，否則他會殺死球隊的速度。

來源

2010-03-16 18:34:37

如果您可以通過使用當前代碼集識別問題/風險來完成其他任務來證明它的合理性，並且這是一個更好的最終結果，那就去做吧。但是不要過分熱衷並且縮短時間表/預算。

來源

2010-03-16 20:13:02 Kevin

BTA：不管項目是否使用Scrum的與否，許多項目經理不喜歡開發商像代碼重構或重組「不必要」的東西浪費時間不直接推動優秀的功能之一要求。

絕對值得注意的觀察;我的解決方案如下：

執行常規代碼評論。每個代碼審查應該建議採取行動來改進代碼中的缺陷。
現在需要提高代碼質量的作業。將這些構建到衝刺中，並以與其他任何工作相同的方式跟蹤它們。

如果你的經理需要更多的說服力，鑄「維護者」作爲用戶，並描述了一些用戶故事爲他們 - 然後「功能」事情像「代碼與XML文檔註釋完全註釋」和'代碼不會產生任何ReSharper警告'

來源

2013-02-22 13:02:04

回答

相關問題