一千萬個為什麽

搜索

什麽是減少神話人月的影響的方法?



Brooks's law: Adding manpower to a late software project makes it later.

在他的書“沒有銀彈 - 軟件工程的本質和意外”中,弗雷德裏克布魯克斯定義了神話人月

布魯克斯的假設是,復雜的編程項目不能完美地分割成離散的任務,可以在工作人員之間沒有進行通信的情況下進行工作,並且不需要建立一組復雜的相互關系任務和工作人員

自1982年以來,我們確實向前邁進,並在緩解這個問題方面積累了一些經驗。您在工作中成功應用的一些解決方案是為項目添加資源而不會產生更多問題。

轉載註明原文: 什麽是減少神話人月的影響的方法?

一共有 3 個回答:

什麽是MMM

首先,我想解釋布魯克法則的背景。他在1975年創造了什麽假設?

人月是一個假想的工作單位,代表一個人在一個月內完成的工作;布魯克斯的法律指出,衡量人工月的有用工作是不可能的。

源代碼: https://en.wikipedia.org/wiki/The_Mythical_Man-Month

早在今天,復雜的編程項目就意味著龐大的龐大系統。布魯克斯聲稱,這些不能被完美地分割成離散的任務,不需要開發人員之間的溝通,也不需要在任務和執行任務的人之間建立一系列復雜的相互關系。

這在高度內聚的軟件巨無霸中是非常真實的。無論做了多少解耦,仍需要巨大的龐然大物強制新程序員學習巨石所需的時間。並且增加的通信開銷將消耗可用時間的不斷增加的量。

但它真的必須這樣嗎?我們是否必須編寫龐然大物並將通信渠道保存到 n(n-1)/ 2 其中 n 是開發人員的數量?

我們知道有幾家公司有成千上萬的開發人員在從事大型項目的工作......而且它確實有效。所以自1975年以來肯定會有一些變化。


緩解MMM的可能性

2015年,PuppetLabs和IT Revolution發布了 2015年DevOps報告狀態<�一>。在該報告中,他們專註於高績效組織與非高績效組織之間的區別。

高績效組織顯示出一些意想不到的特性。例如,他們在開發過程中具有最好的項目到期日期表現。運營中最佳的運營穩定性和可靠性。以及最好的安全和合規記錄。

報告中突出的一件令人驚訝的事情是每日部署指標。但不僅僅是每天的部署,他們還測量了部署/日/開發人員,以及在高性能組織中添加更多開發人員與非高性能組織的效果。

這是該報告中的圖表 -

Deployments per Day per Developer

雖然低績效組織與神話人月的假設保持一致。高性能組織可以根據開發人員數量線性調整部署/日/開發的數量。

Gene Kim在 DevOpsDays London 2016 發表的精彩演講談到了這些發現。


如何操作

首先,如何成為一個高績效的組織?有幾本書談論這個問題,在這個答案中沒有足夠的空間,所以我只會鏈接到它們。

對於軟件和IT組織而言,成為高績效企業的關鍵因素之一是:<�註重質量和速度。

例如,Ward Cunningham 解釋技術債務,因為我們允許將所有事情解決。這被管理層接受,因為它總是帶著一個承諾,即在有時間的時候它將會被修復。

時間不夠,技術債務變得越來越糟。

這些導致技術債務增長的因素是什麽?

  • 舊版代碼
  • 手動配置環境
  • 手動測試
  • 手動部署

傳統代碼正如Michael Feathers在有效地使用遺留代碼中所定義的,是任何代碼,沒有自動化測試。

任何時候使用快捷鍵都可以使代碼生產;這些債務永久性地維持了債務。然後部署的過程變得越來越長。

Gene在他的演講中講述了一個長達六周的部署公司的故事。涉及成千上萬的極其容易出錯的繁瑣步驟,捆綁了400人,而且他們每年會這樣做四次。

DevOps的原則之一是可靠性來自更頻繁地部署更小的部署。


示例</強>

這兩個演示文稿展示了亞馬遜為減少部署代碼到生產所需的時間而做的所有事情。

據Gene介紹,這些高績效企業中唯一隨時間而改變的就是開發人員的數量。所以從亞馬遜的例子來說,你可以說在四年內他們增加了十次,只是增加了更多的人。


這意味著在某些條件下,正確的架構,正確的技術實踐,正確的文化規範,開發人員生產力可隨著開發人員數量的增加而擴展。 DevOps絕對是這一切的中心。

我所做的(這只是主觀的)如下:

當經理考慮到期日期希望增加人員到我的團隊中以縮短所需時間並且看起來在MMM下時,我首先與他或她討論為什麽這可能是不好的。我最喜歡的比喻是提醒他們,如果一個女人可以在九個月內生下一個嬰兒,九個女人在一個月內就不會有一個嬰兒,但他們在九個月內將會有九個嬰兒。時間不縮短,只是並行處理更好。

當我們的團隊被迫做出決定時,我們通常會嘗試進一步劃分一些任務,而當這不可能時,我們通常依靠配對編程,其中一個程序員負責打字,另一個負責編碼(並定期切換)。

編寫代碼本身速度較慢,但​​由於寫作過程中不可避免地進行了審閱,所以在測試時缺少錯誤/缺失和錯誤。我覺得整體代碼質量也好一點,但我沒有指標來支持這一說法。

僅從CI的角度來講,增加一個項目開發人員的數量通常意味著更多的人在同一個分支中工作。

傳統的CI系統在這方面有一個可擴展性問題:破壞/回歸/阻塞的可能性增加,減慢了整合速度,並導致較小的團隊中斷並轉移到子部門(即進一步減速)。請參閱如何針對大型項目實現持續集成規模/團隊?。這符合神話人月的概念。

我在回答這個問題時提出的解決方案是一個高度可擴展的CI系統,可以實現真正的CI遷移 - 為整個更大的團隊(甚至是龐大的團隊)提供單一分支/主幹集成。

通過使用相同頁面中的每個人,使用相同的自動化工具/流程以及CI系統內部自動化的絕大多數QA驗證,在團隊成員之間切換角色並將註意力集中起來變得更加容易。整個開發過程變得更流暢,更可預測,更輕松​​。

在這樣的環境中引進新人,讓他們的工作更加簡單,因為簡單地從更有經驗的團隊成員那裏減輕難度較大的任務,從而可以承擔更難的任務。

我相信,所有這些都可以看作是舒緩神話人月概念效應。