在對開發過程施加嚴格管理的公司中使用SCRUM？

Question

我們公司必須遵守嚴格的SOX/Cobit協議。這意味着在我們所做的一切背後都有一個巨大的紙質痕跡，沒有人可以開始編碼，直到簽署正確的文檔。這意味着在開始編碼之前，您必須等待更改規格，軟件規格和體系結構文檔（至少）簽名。同樣的過程遵循任何增強（這是軟件開發的一個自然部分）。很顯然，SCRUM背後的想法並不適用。

當前我們遵循Rational Unified Process（RUP）中定義的SDLC。它也包含一個迭代過程（初始/精化/構造/轉換/重複），但我們想要嘗試用SCRUM替換該過程。

嚴格治理的公司切換到SCRUM是否可行？有沒有人有案例研究，說明它是如何在類似環境中成功實施的？

Answer 1

我曾經爲一家在SOX瘋狂的邊緣搖搖欲墜的公司工作，同時仍然保持相當敏捷的開發流程。擁有知識豐富的管理人員願意爲文書工作提供幫助。我們做了幾件事情來說服SOX審計人員，我們的電子流程不僅僅是替代品，而是比他們的文書工作更好。

• 我們使用SSH的特殊功能鎖定了對代碼存儲庫的訪問，以便只有管理員才能訪問原始文件。這阻止了任何開發人員進行任何手帕倉庫操作來隱藏更改。雖然我們並不擔心這種情況發生，但它使SOX審計員感到高興，他們接受版本控制系統作爲安全更改日誌，而不是讓我們在紙面上提交（不是玩笑）差異。

• 我們將大部分文書工作委託給習慣了手工完成重複任務的QA部門。 :)

• 我們的在線任務管理器中的安全性增加了。每一次改變都必須有一個與之相關的任務。我們的任務管理器中的任務只能由少數幾個經理之一在系統內「簽字」之前完成。在實踐中，這意味着讓管理人員在網頁表單中勾選一個框。

• 我們將權限從分期到生產轉移到質量保證部門。再次，在實踐中，這意味着告訴QA中的某人運行腳本。作爲一種副作用，它幫助我們的生產推送過程更快更簡單。

• 通過使用開發，分段和生產分支，我們可以在開發和分期分支上自由工作，因爲他們無法訪問生產數據庫，只需要所有文書工作以便進行生產變更。

值得一提的是，雖然是爲了讓我們的工作做了一些事情，我們在桌子底下確實，在大多數情況下，我們取得了負責SOX的人遵守知道多少的。它是一種產生影響完成工作並與他們合作以平衡他們的SOX偏執狂和我們的效率。我們發現他們真正想要的是什麼，並提供更有效的替代方案（如安全版本控制而不是紙質差異）。我們不是圍繞一個破碎的系統開展工作，而是在開發人員和QA之間建立一個戰場，我們努力改進系統。

Answer 2

我已經在這個環境中的項目中做得更成功了，做得更隱蔽一些。在我正在管理的項目中，在這樣的環境中，我通常會試圖阻礙實習生全職工作。實習生的工作是填寫所有的文學作品和垃圾，讓我們仿效一個過程，同時在後臺讓我的開發人員繼續工作，並推進項目。在內部，我使用了嚴格的基於Scrum的方法。我的項目以100％的成功率結束，而成功項目的企業平均值約爲20-30％。

使用我自己的意見風險自負。

就SOx合規BS而言，他們是不是已經把它扔掉了呢？

Answer 3

我看不出爲什麼您認爲文檔和正式流程不適合敏捷。

如果您知道如何正確執行RUP，那麼您可以更輕鬆地執行SCRUM，因爲您已經有了足夠的自律而不會成爲牛仔。

沒有人說你做SCRUM時不能做適當的文件。這些文檔DO增加了一些價值 - 當你遵循敏捷過程時，它們並不是完全必要的，所以大多數團隊都不這樣做。

如果您認爲這些文檔是您的可交付成果，請將它們添加到迭代範圍中，將重要的內容寫入它們以便它們對您的團隊有用 - 它們是一種間接費用，但它們也具有價值，特別是對於長期項目，或者當你有一個大的和/或分佈式的團隊時。

RUP迭代不強制使用瀑布模型 - 它們只是強調其中某些學科的指導方針，但RUP中的適當迭代將所有活動混合在一起。考慮到精化階段是一個正常的敏捷階段，有一些尖峯，你將無法分辨出差異。

它爲我們提供的文檔的工作方式是使用Wiki獲取這樣的信息並將其內容導出到稍後可能簽出的Word文件。

這些文件可以通過審查，但他們不需要維護，團隊去Wiki的信息。