利用基礎軟件架構打造敏捷（Agile）團隊 為（DevOps）做準備 - (一)

前言

在最近這幾年，『敏捷』一詞，幾乎成為軟體開發領域的罩門，企業內部軟體發部門成功的例子不少，但是失敗的例子幾乎也是隨處可以聽到，真的只是就像人家說的，因為『成功經驗』無法被複製？所以，有些人無法成功，但….？真的只是這樣嗎？

混亂的年代

在最近這幾年，您是否也有感覺到幾件事情，在軟體技術蓬勃發展的現代，各種流程開發的方法如雨後春筍般不斷湧現，從早期的 Waterfall 還有 SDLC/RUP/AUP/XP，或是近代的 Agile／Scrum／Kanban／LeSS 等等…每天都有新的框架 Framework 出現（尤其前端更是如此），軟體工程師不斷地追求新技術，似乎，不持續的學新技術，就會跟不上這個世界，某種程度來說，不能說不對，但是若陷入工具的迴圈裏面，那可能會浪費許多寶貴的時間。在專案裡面使用不適當的套件，可能會埋入一些隱憂，未來可能生成其他的技術債，浪費團隊的時間。

在軟體技術市場、需求、市場多變現代，我們在為我們的產品、與團隊選擇一個符合市場需求、使用者需求、團隊 Skills、客戶環境、考量未來乘載量、甚至需要搭配設計面、使用哪一種軟體架構的設計方法，這些都會是考量因子，

敏捷不是沒有門檻

『軟體開發沒有銀彈』這件事，我已經在各個不同的企業端提過數次，以我自身的經驗也深深地認為，其實敏捷是有門檻的，怎麼說呢？在國外，真的導入敏捷成功的團隊，其實，團隊成員本身都已經沒技術上的問題，或者，應該這樣說，就是本身對於軟體開發架構、實作技術、Design Pattern，甚至舉凡包括版本控制系統 Version Control 的使用（延伸閱讀：關於團隊使用 VSTS/TFS 原始碼控管的 - 三兩事）、個人的工作管理、各種 Work Items 的 Tracing Tool，專案管理工具的使用等，更不要說團隊開發共同規範其實都已經以一定的水準了，而他們推行敏捷，純粹只是要解決『人』的問題而已。

而所謂的『人』的問題，不外乎就是，『溝通』、如何有效的溝通？團隊間的協同工作，各成員主動的管理風險、彼此之間的信任、並且團隊成員有一定的靈活度，這得從文化著手，

當你團隊的技術到達某一定的門檻之後、再談敏捷

由上圖（一）所示，企業或開發團隊要進行敏捷時的軟體架構 與 人之間的關係，圖中所要表達的是，當你要進行敏捷（文化）時，您得在基礎架構規範、也就是，即便團隊之間溝通合作不良、但是個人技術能力非常強，軟體的開發已經幾乎具備『高度可延展性』、『擴充性』、『團隊的共同規範』，但是…. 團隊內的協同工作、成員的主動性、不是那麼理想！若想要朝向團隊的自主性、學習與成長、並能從經驗中學習，推行敏捷的文化，就會是一個理想的建議、可以前進的一個方向。

倘若，反之，在你的團隊內架構設計方式沒有一定的規範、軟體開發總是陷入無窮的技術債之中、而沒有一致的開發方法，更不用說基本的延展性與擴充性。如果有上述狀況，那麼，我必須說，敏捷對您的幫助並不大，因為左邊圖（一）中紅色圓圈內的『軟體開發架構』我認為是軟體開發的基礎，因此，絕對沒有那種導入敏捷之後，OOAD 系統分析設計方法、或者 Modeling Driven 或 UML 就沒有用了的說法，因為，這些都只是『（基礎）中的（基礎）而已』。

後記：

同樣的，在邁向 DevOps 之路之前，開發團隊得先是個敏捷的團隊，否則，DevOps 除了文化外、他更是場運動，在動起來之前，您可能要先思考動不動得起來。

鳳凰專案 共同作者 Gene Kim, 曾說過：

待續…