一千萬個為什麽

搜索

亞當·斯密與全面開發人員 - DevOps的生產力?



通過亞當斯密,分工可以使你的效率提高240倍以上(以18個步驟生產針腳為例)。

為什麽然後多技能角色需求如果實際上降低了生產力 - 或者史密斯錯了,為什麽呢?

搜索“全面開發者”仍然是谷歌的趨勢,但顯然比兩年前更慢:

enter image description here

=====

總而言之,一個完整的堆棧開發人員幾乎可以完成所有的價值鏈(如果我錯了,請糾正我):

  • 與客戶進行討論,並為他的部分工作細化可行的敏捷要求
  • 決定采用哪種架構,工具和組件 - 只需給他一個筆記本
  • 即可
  • 為前端,後端,ingration編寫代碼,這是跨設備兼容性的,並且不需要太多測試,或者包含它
  • 個人資料和景觀數據,使用Cloud AI/ML API提供高級功能
  • 編寫必需的IaC代碼並展開
  • 出現錯誤或銷售流程時致電
  • 了解安全相關設計,整體修補,遷移和現代化
  • 以簡化的方式記帳時間表以簡化雇主的發票
  • ...我忘記了什麽嗎?

UPD - “我們需要專業化的生產力,但我們不想要”極端分工“的孤立的世界觀(DevOps Guys,”DevOps,Adam Smith和通才的傳奇人物 ,2013-2016)

轉載註明原文: 亞當·斯密與全面開發人員 - DevOps的生產力?

一共有 6 個回答:

有兩種類型的工作:

    開發- 定義明確的工作,可以很容易地劃分為明確的階段,每個階段都可以自己學習和掌握,階段之間的切換不需要溝通。/p> 探索- 未定義的工作需要通過學習和實驗完成每個階段以及階段之間的切換,這需要大量的項目學習和狀態交流。

Adam Smith concerns himself wholly with exploitation and not at all with exploration. The work done in Research & Development departments of the industry is by its definition mostly exploration and so it is not covered in any way by Adam Smith.

但是我們已經看到,在後來的持續改進階段,這部分是部分剝削性的工作,CI/CD的應用可以帶來生產力方面的類似增益,這可能在某種程度上可能由某人非常富有想象力地追溯到亞當斯密。

亞當·斯密不需要考慮將信息從一個階段傳遞到另一個階段。這是任何重要IT項目的重要組成部分。因此,全面開發人員具有以下顯著優勢:

  • 他們不必與其他部門的任何人進行交流,以完成任務
  • 他們不必等待其他人去解決它
  • 在某一層與另一層之間的翻譯中,某些內容會丟失的可能性很小

有關信息傳遞在IT項目中的重要性的更多信息,請參閱Fred Brook的“神話人月”。

恕我直言,答案與規模和資源可用性有很大關系。

我相信亞當斯密的理論只能在大規模應用 - 整個國家/經濟體在原始背景下,或者在SW發展背景下,才能應用大型開發團隊。

在一個龐大的團隊中,雇用更專業的人力資源確實更有效:

噢,如果這些團隊需要高質量的架構師資源作為補充,那麽這些團隊才能發揮作用,而這些資源對於將產品分解成可以使用專業資源解決的小型專業任務來說必不可少。

在規模較小甚至一個人的團隊中(通常是初創公司,或者是大型組織中孤立的小團隊),使用這些資源並且仍然可以完成工作是無效甚至是不可能的:

  • 他們根本沒有預算/資源來聘用覆蓋整個產品開發所需的許多不同專業資源
  • 他們實際上在尋找/欣賞可以戴多個帽子的搖滾舞臺,並立即以極大的靈活性轉換角色,而不會造成延誤和額外的人力成本。

需要理解的一個重點是,分工並不總是意味著每一步都有不同的人。

我會在汽車制造廠開始自己的歷史,我坐在一個座椅組裝鏈上,以安全氣囊,皮革,頭枕等方式獲得全部座位,鏈條分成9個階段。我們正在研究這個鏈條。每個人一次只做一個階段,但是我們每個小時都會轉向下一階段以避免重復。工作日為8小時,所以我們每天都沒有登上舞臺。

這完全是一個分工,你在給定的時間只進行組裝的一個步驟,這並不妨礙你能夠完成全部組裝。

正如其他答案中所述,這與軟件開發有點不同,但我認為這揭示了為什麽Full Stack開發人員與分工不相互排斥,有人能夠處理應用程序的整個生命周期的能力不是需要一直這樣做。

一般來說,當我聽到FullStack開發人員時,我認為更多的人能夠同時編寫高效的後端代碼和良好的用戶界面,與Front and Back Dev相悖。

總之,我不認為亞當·斯密是錯的,但我認為他的制造業分工模式與軟件開發孤島之間存在著一些嚴重的差異。

首先,針工廠的例子(據我所知)僅僅是假設的;盡管大多數現代制造工廠可以追溯到這種分工,但我並不知道任何研究實際上已經在科學上測試了這一假設。

其次,史密斯主要關註制造材料商品;與物質生產相關的某些有形產出在軟件開發中沒有類似的類似物。例如,在制針時,物理尺寸作為功能要求是重要的;在軟件中沒有明顯的比較。這很重要,因為有形的物體可以通過精確的重復進行復制;軟件開發兩次都不是同一個問題。開發人員開發通用的方法來產生可預測的結果,但是你不會兩次編碼相同的問題。在堆棧中開發的任何組件都具有與物理組件不同的復雜性,並且這些復雜性具有超出有形測量(高度,重量,長度等)的相互作用。只要電線根據規格切割,引腳指針並不關心電線剪的工作方式。在軟件開發中,界限從未如此清楚

完全堆棧開發人員不需要自己完成所有的工作(他們不打算成為單個引腳制造者),但他們希望能夠理解堆棧的所有元素以及這些元素如何相互作用。一個完整的團隊應該由 T型人組成,他們專註於一個或多個領域,但了解頻譜(並且可能能夠在某個層面介入)。

我認為史密斯的工作在軟件開發中成立的地方在於上下文切換(或多任務處理領域);如果一個開發者負責所有的開發領域,將責任轉移到責任需要時間。在規模上,同一產品團隊中具有不同經歷的團隊成員之間的合作可以平衡上下文切換和復雜的交互。

我認為我是以下列責任組合為基礎的全面開發人員:

前端和後端編程

我可以在一定程度上進行UI更改:編寫HTML,CSS(作為Web開發人員),另一方面從數據庫向UI提供數據,在服務中提供它等。

我離開測試,架構和那些,旁邊的會議客戶可能會被添加到工作描述中。

對面</強>

相反,我的觀點是UI用戶和後端用戶的角色很嚴格。

結論</強>

我沒有看到像你提到的那樣完整的堆棧,更像是敏捷或雲端的幻想表達,在某些情況下只需提及吸引人們的註意力,真正的實現可能會有很大的不同。至少在Scrum和敏捷方面,我看到了很多變體,這些術語已經失去了意義。