組織架構適配下的敏捷開發

摘要： 本文將會討論如何協調公司內各個工程師團隊之間的合作，從而高效地保持系統的彈性和靈活性，以滿足敏捷開發的需求。本文選自《Node.js微服務》。

　　如果一個公司采用微服務來構建軟件系統，那么每個干系人都需要參與決策。
　　微服務是一次重大的范式轉換。通常，大型組織傾向于使用相當傳統的方式來構建軟件系統。每個重大發布需要經歷數月的研發周期，之后需要一個完備的質量保證階段以及數小時的部署階段。
　　當一個公司選擇使用面向微服務的架構時，方法論就會發生完全的改變：每個小團隊負責各自的小功能點，包括它們的構建、測試和部署。每個團隊各司其職，并且能夠處理好各自負責的單一事項（一個微服務，或更確切地說是數個微服務），每個團隊成員將熟練掌握構建軟件系統的相關技術與領域知識。
　　這通常被稱為跨職能團隊。這是一個由少數人組成的工作單元，他們都具備了構建高質量軟件組件的能力。
　　有一點值得注意的是，團隊成員應當掌握必要的領域知識來理解業務需求。
　　在我的職業生涯中，大多數導致公司失敗的主要問題不外乎以下這點（就我個人觀點而言）。首先，有一種觀點認為開發者是“堆磚器”，即可以在沒有提前溝通的情況下卻依然能神奇地理解業務流。而且，還有觀點認為，如果一個開發者一周可以完成X 量級的工作，那么10 個開發者一周就可以交付10X 量級的產量。這些觀點都是錯誤的。
　　為了保持高效以及考慮到康威定律在改變業務流程方面對系統的影響，構建微服務的跨職能團隊中的成員必須熟練掌握（不僅僅是了解）相關領域知識。
　　每當談及微服務的組織架構適配時，自治才是關鍵因素。為了保證構建微服務的敏捷性，每個團隊都必須保持自治，這也意味著要確保技術的自主選擇權，如下所示：

• 使用的語言。

• 代碼規范。

• 解決問題的模式。

• 各類工具的選擇，比如軟件的構建、測試、調試及部署工具。

這是非常重要的部分，因為這是我們需要定義公司如何構建軟件，并且可能會引入工程問題的部分。
　　舉個例子，我們來看看代碼規范問題，如下所示：

• 我們需要在所有團隊內都保持統一的代碼規范嗎？

• 我們應該讓每個團隊都有各自的代碼規范嗎？

一般來說，我偏好于“80%準則”：80%的完美度已經足以涵蓋100%的使用場景。這意味著放寬代碼規范（也適用于其他領域），以及允許一定程度的不完美或者個性化，都有助于減少團隊間的摩擦，也能讓工程師能夠盡快關注到那些極少數的重要準則，比如日志策略以及異常處理。
　　如果你的代碼規范過于復雜，那么在某個團隊想要向其他團隊的微服務提交代碼時就會遇到很多阻力（切記，一個團隊擁有自己的服務，但是其他團隊的成員也可以對這個服務做出貢獻）。
　　本文選自《Node.js微服務》，點此鏈接可在博文視點官網查看此書。
　　　　　　　　　　　　　　　　　　　　　

　　想及時獲得更多精彩文章，可在微信中搜索“博文視點”或者掃描下方二維碼并關注。