【51CTO精選譯文】項目越來越大，軟件開發越來越復雜，管理者有時會感覺自己需要通過更加復雜的管理方法來解決這一問題。然而這被證明是不成功的。Lott先生是一位擁有30余年軟件開發經驗的程序員、DBA、項目管理以及軟件架構師，近日撰寫了一篇博文描述了自己解決復雜問題的一些經驗。51CTO開發頻道將此博文翻譯，內容如下。

有人總喜歡拿“軟件危機”說事。我們無法足夠快、足夠低成本或足夠好的開發軟件。我同意埃德斯加·狄克斯特拉(Edsger Wybe Dijkstra)的觀點，軟件開發確實非常非常復雜。那么我的結論是否指軟件成本緣于其復雜性？不，我認為軟件成本高的原因來自于使用了錯誤的行為來管理軟件的高成本。

控制的誤解

人們關于控制的最大誤解當屬項目計劃。我認為，軟件開發項目管理工具，尤其是微軟的Project，是我們犯下的最大錯誤。至于證據，大家可以了解一下敏捷開發方法。敏捷開發的一個關鍵元素是削減(或消除)軟件開發相關的項目管理愚蠢行為。

我認為，軟件開發工程一般都非常復雜，一個大的MPP文件并不能削減其復雜性，也不會有助于任何人理解其復雜性。我認為，我們不應該嘗試征服這種復雜性，那是一種非常愚蠢的行為。如果你發現自己需要一個非常復雜的文檔來征服許多非常復雜的復雜性，你正在犯錯。

簡潔性說明

我認為，用戶開發經歷非常有用，因為它們將軟件開發的復雜性簡化為我們可以清楚表達和記憶的東西。這讓我們更有機會去裂解它。

如果用例要求一個大的復雜文檔，我們可能正在錯過本質的東西。它應該有一個簡潔、易記和非常容易寫到便箋條上的總結。它可以有一個詳細的技術性附錄。但它必須有一個簡潔、易于表達清楚的總結。

如果你無法輕松的解釋清楚用例，就說明它有些過于復雜了。

架構

一個架構圖可能非常有幫助。作為地基的架構必須是經過反復分析后確保是正確的。你必須絕對自信它的可行性。就如同任何數學方面的分析，你需要圖標和公式，而且你需要展示你的工作。

架構不需要故弄玄虛，而需要務實。一些簡潔的公式(便于記憶)再加上合理的解析，效果會好的多。

工作分解結構(WBS)問題

#T#我發現，具有復雜工作分解架構的項目又多加了一層復雜性和無用的管理。軟件的成本非常高，那么讓我們嘗試通過增加管理來削減我們的成本。但是，這種為削減人力而增加人力的做法并沒有實際意義。

與其浪費時間增加工作量，還不如確定一個人選，由其實現更有效的決策和保持開發進度保持正常。

更多的推出局部解決方案，這比每周狀態報告更具價值。在理解詳細設計過程方面，更多的與產品擁有者交流，比一個精心編寫的計劃更有價值。

反駁項目管理的辯解

我們或許會這樣為項目管理辯護：通過消除“障礙”或“低效”，它可以讓軟件開發過程更高效。我也曾經相信這些，但現在我的觀點變了。

讓我們一起看一些項目管理可能會消除的那些所謂障礙：

◆用戶參與。更確切的說，無需用戶參與。我認為項目管理這種做法除了傷害用戶外沒有其它效果。如果用戶不通過積極回答問題或檢查近期結果來幫助軟件開發，那么開發出來的軟件不會創造任何價值。現在就停止工作，發現哪些事情是用戶真正需要的。

◆技術資源。協調技術資源(數據庫管理員的、系統管理員的、獨立測試者的等)并不需要一個復雜的計劃、狀態會議或報告。它只需相關人士之間的幾個電話。簡單直接而有效。

◆決策。項目經理不是產品所有者，也不是用戶，也不是技術專業人員，不會理解軟件開發過程中的危險所在。實際上，他們只是在一場他們無法完全理解的會話中擔當一個服務者的角色。如果他們能夠做到不去承擔不屬于自己的任務而堅持服務理念，這也不錯。

我不明白我們為何僅僅把重點放在IT項目管理上。敏捷開發人士的觀點是正確的。通過真正削減成本和復雜性的做法來削減成本和復雜性，而不是通過增加管理。

原文：The Problem With Software Development is...  作者：slott