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

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

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

• 使用的語言。
• 代碼規範。
• 解決問題的模式。
• 各種工具的選擇，好比軟件的構建、測試、調試及部署工具。

這是很是重要的部分，由於這是咱們須要定義公司如何構建軟件，而且可能會引入工程問題的部分。
　　舉個例子，咱們來看看代碼規範問題，以下所示：

• 咱們須要在全部團隊內都保持統一的代碼規範嗎？
• 咱們應該讓每一個團隊都有各自的代碼規範嗎？

通常來講，我偏好於「80%準則」：80%的完美度已經足以涵蓋100%的使用場景。這意味着放寬代碼規範（也適用於其餘領域），以及容許必定程度的不完美或者個性化，都有助於減小團隊間的摩擦，也能讓工程師可以儘快關注到那些極少數的重要準則，好比日誌策略以及異常處理。
　　若是你的代碼規範過於複雜，那麼在某個團隊想要向其餘團隊的微服務提交代碼時就會遇到不少阻力（切記，一個團隊擁有本身的服務，可是其餘團隊的成員也能夠對這個服務作出貢獻）。
　　本文選自《Node.js微服務》，點此連接可在博文視點官網查看此書。
　　　　　　　　　　　　　　　　　　　　　

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