一千萬個為什麽

搜索

IT員工在DevOps時代的規模 - DevOps團隊如何以及何時擴大規模?



鑒於DevOps使IT人員能夠實現縮減規模並在所有自動化中實現更多功能,那麽對此有何限制?

也就是說,什麽是經驗法則 - 如果可能存在的話 - 你會知道你需要更多的人,盡管 Robotic Process Automation )?

註意:這是關於整個IT部門的人員規模與您的業務規模,結構和功能完全相關(單個團隊的規模由雙比薩團隊概念)。

轉載註明原文: IT員工在DevOps時代的規模 - DevOps團隊如何以及何時擴大規模?

一共有 1 個回答:

恕我直言,直接並立即將其團隊從DevOps轉換中獲得的收益用於縮小團隊向下並不是一個好主意。充其量你只會失去團隊在未來做任何改進的動力。但很有可能你會失去該隊的大部分/全部人才。

代替:

  • 允許團隊欣賞他們經歷的艱難轉變帶來的好處,以便他們將這個詞傳播給其他團隊,這些團隊必須經歷(或已經在努力)轉型
  • 專註於以更快的速度提供更優質的產品/服務 - 擁有同一團隊 - 現在可以進行轉型。
  • 在很多情況下,您的企業將因轉型而加速 - 很快您將更有可能需要雇用員工 - 恕我直言,最好是使用您已有的經驗,而不是培訓新員工。
  • 允許自願減員為你工作,並有效縮小規模。

但通常DevOps轉換不會發生得足以讓上述選擇得到滿足:)

現在放大向上/向外

理想情況下,DevOps轉型應該大大提高了您的SW開發和交付流程的可預測性。您應該能夠以很高的精度分辨您現有團隊的能力:您的當前團隊在特定時間內完成的某種質量的SW /服務的數量。

When you need more stuff done, or done better/faster than the current team's capacity you need to scale the team up/out. The exact details come from whatever process/methodology you use for your day-to-day activities, probably some agile variant (see also Does my organization need adopt Agile Soft. Dev. before adopting DevOps?)

How - apparently easy: hire more people to handle the overflowing activities. If you're worried about how fast you can get them onboard and actually handling that overflow work at the expected rates: start hiring earlier, based on projections.

然而,現實可能比這更難一點。擴展軟件產品/服務或支持它的開發過程和工具並不一定是直接的,即使是由DevOps授權的組織也是如此。

我最喜歡的例子之一是最差的DevOps鏈接涉及可擴展性:持續集成。如果CI構建失敗,則不能進行傳遞/部署(有時會破壞CD上下文中的“連續”術語)。

僅僅因為某個團隊很高興地使用CI來獲得體面的結果,並不意味著如果團隊規模增加一倍就會發生同樣的情況。不,結果可能是毀滅性的 - 交付過程可能會陷入停頓(在極端情況下)。我正在嘗試在傳統CI系統中的擁塞中對此進行解釋(免責聲明:)我是擁有參考頁面並提供解決方案的公司的創始人)。

例如,可以使用版本控制系統(VCS):由於存儲在存儲庫中的軟件會隨著其更改歷史的發展而變化,從而推動VCS系統的限制,有時超出可接受的性能水平。切換到更具擴展性的VCS系統或將代碼分割成多個存儲庫可能是解決問題的一種方法。

但是,隨著所提供的軟件產品/服務的發展,支持它們的開發流程和工具的發展基本上就是成熟的DevOps團隊所做的。在團隊擴大/縮小戰略時,他們也需要考慮。

考慮到這一點,如何的確可以減少到只增加團隊規模以涵蓋執行上述策略所需的額外工作量。