the DevOps journey (0) - 敏捷開發真和每個開發人員有關?

#不想看廢話,直接按這裡跳到重點

這年頭大多數人已經沒有耐心,已經很難看完一整篇長篇大論,因為這樣,這幾年我們寫blog的時候,幾乎都零零碎碎,這使得許多學員面對知識的掌握,也變得片片斷斷。

如果可以,我希望能夠把我們這幾年面對軟體開發方法,以及ALM/DevOps的一些經驗,有條理一點的整理出來,如果你有興趣,不妨嘗試慢慢的看看,如果實在已經不習慣看長篇文章,也可以挑有興趣的重點來讀。

開始一段新的旅程

這一系列的標題中有個字眼『journey』,第一次看到這個字…是在一場研討會,我忘了是TechEd還是Build,印象中研討會的主題是Metro Style App(現在應該不多人還記得這個名字了吧?),主講人用journey這個字眼來描述學習一種技術的過程,我覺得真TxD的太貼切了…

不知道你有沒有發現,最近五年,軟體開發的潮流根本就是一場journey,而且非常像是我最愛的影集Star Trek Voyager中的旅程。你該怎麼形容這段旅程呢? 圖乎其來? 充滿意外? 不僅如此,大夥摸著石頭過河…似乎根本沒人能告訴你往哪個方向才是對的,你也不知道怎麼走才會到終點…這差不多就是這部影集當中的旅程。

若用來描述最近五年軟體開發技術的發展,根本是整個貼切到不行,而且從Web、前端、行動裝置、開發方法、框架…幾乎都逃不過這場journey魔咒,所有的技術都是在途(on the road),一點都沒有發展成熟的跡象…

當然,如果旅程總是只為了看到終點倒也世俗了些,旅程的過程中還是有很多意外的小驚喜,以及足以令人回味的點滴,不管是你早已遺忘的Metro Style Application,或是充斥各種消耗型框架的所謂前端開發技術,又或者是我們要討論的這個主題 – ALM/DevOps。

關於開發方法的重要性

身為一個以寫程式起家的開發人員,就一個軟體開發人員的生命週期來看,我算是到了很老的時候,才願意承認軟體專案/產品的開發過程中,最重要的可能不是開發技術,而是開發方法。

技術能力的強度,是進入軟體(專案/產品)開發領域的入場券,它就是一塊敲門磚,技術能力的強度,決定了你敲門的力道。然而一但當門打開,你開始了一個專案,進入了一個團隊,參與了一個產品的研發,技術能力對成果的影響力,可能就開始慢慢式微了。請注意,個人技術能力可能會影響開發團隊產出的品質和數量,然而開發團隊產出的品質和數量卻很可能跟軟體專案的『成果』沒有絕對的正相關。

什麼意思? 我們看過太多技術能力很強的個人或團隊,但經手的專案或產品開發依舊是失敗的很徹底的。例子很多,不好一個一個舉。你可以盡其所能地回憶你自己參與過的專案,你應該會發現,團隊的技術能力決定了你能不能做某個案子(或產品),但開發方法和團隊的素養,則決定了案子做得好不好,能不能順利結案。

由於軟體開發與一般工程營造迥異的特性,使得軟體開發這件事情,並不單單的工程行為,也是創作行為…這導致,追求技術的極致,其實對軟體專案沒有絕對的幫助,技術能力一旦到了某一個點之後,對於整體專案的幫助就迅速下滑…

像是上面這張圖,技術能力到一個臨界點之後,再怎麼提升,對於軟體專案的價值與效益其實影響開始遞減。

怎麼觀察? 如果你身為PM或Team Leader,當你開始慢慢發現,手上專案所發生的問題/瓶頸,大多跟技術無關,而是跟時程、溝通、預估…等非技術因素有關的時候,就表示,你的團隊可以在技術能力提升上稍稍休息,而該開始補強一下開發方法和專案管理能力。

總的來說,我接觸到的年輕團隊,大多都是技術能力遠勝於專案管理能力,至於開發方法,則往往都還有很多的成長的空間。

正在糾結?到底要不要踏入敏捷開發?

如果要談論開發方法,這幾年你不可能避開『敏捷開發(Agile Development)』,相較於傳統的瀑布式開發,敏捷開發在意的是自適應性(Self-Adaptive這個字硬翻很怪,我覺得你可以把這個字想成『應變能力』),而傳統的瀑布式開發,在意的是『計畫導向』,簡單一句話,就是要你『stick to the plan』。

上課時,我會推薦學員一定要看Martin Fowler的這篇文章: http://martinfowler.com/articles/newMethodology.html

如果你需要中文翻譯,他位於:
http://www.jianshu.com/p/e042ed1d79b0

我假設你已經讀完了,我要說,這篇文章非常經典,字字珠璣,他解釋了為何這個時代的軟體專案,應該採用敏捷開發。

我覺得只需要扼要說明,請一邊參考底下這張圖。

最早期(1960年代),軟體開發是毫無章法,雜亂無章的情況,迫使技術團隊覺得應該要有一些制度,因此借鏡了傳統的工程營造之類的專案管理概念,一段時間的演進之後,建構了像是CMMI之類的軟體專案管理方式,但後來(最近10年)許多人慢慢發現,似乎並不可行…

不可行的原因出自於幾點:

  1. 傳統的專案管理和工程方法試圖把人當作可替換的資源,但軟體開發並非全然是施工(Implementation),還有創作的成分(而且非常高),每一個程式設計師的產能可能天差地遠完全不一樣,把開發人員視為可替換的資源根本是個錯誤的假設。
  2. 傳統計畫導向的開發方法相信,設計(Design)和實施(Implement)可以分離,甚至,設計需要比較高階的人力,而實施只要muscle就好。但敏捷開發認為,設計和實施無法分離,每一個開發動作都同時包含了設計和實施的成分在。
  3. 我們幾乎永遠不可能有確定的需求。因為完全一樣的程式碼(需求)你根本不用重寫,只需要copy一分(或買套裝軟體)就好,所以,每一個軟體專案幾乎肯定都是獨特的。再加上現今市場變化快速,需求的固定幾乎已經不可能。
  4. 從不確定的需求,衍生出,準確的預估幾乎是不可能實現的。因此,軟體開發沒有stick to the plan這回事。(那要怎麼辦呢? 後面再說)

因為上面這幾個與傳統工程之間的核心差異,導致軟體開發用工程方法、SOP、甘特圖來管理、期待他跟其他的工程施工一樣順利,似乎非常的不切實際。

除非你的需求永不變動、除非你每一個開發人員的產能完全相同,除非你有無窮盡的開發人員可以替換,否則,傳統的工程管理方法根本無法進行軟體開發的專案管理。

不知道你是否曾經好奇過,其實我們早已用工程方法(甘特圖、要徑法、CMMI、SOP…等)來管理軟體開發很多很多年,如果,這個方法是錯的,難道從來沒有人懷疑過? 難道從來沒人覺得工程方法怪怪的?

有,但很抱歉,過去,設計出這些管理方法的人,很可能自己根本都不寫程式。就像設計員工管理制度的HR/Manager,本身可能根本不是一般員工,這些制度的受益者/設計者,從來都不是制度的使用者…也因此,身為程式設計師的你,如果夠敏感,很可能早就覺得哪裡怪怪的,但,你無法改變,因為制度的設計者不是你。

一個新方法

然而,敏捷開發法的出現,和過去工程方法誕生的方式完全不同,敏捷開發的概念是由有實務開發經驗的開發人員所設計,這跟過去建構工程方法的管理階層,自己從來沒下來搬過磚塊的狀況有著很大的差別。

敏捷開發法的設計者認為,你不能把程式設計師看做資源,軟體開發的團隊,也根本不是傳統的施工團隊。如果真要比較,軟體開發團隊比較像是一組球隊(team),團隊中的成員每一個都有自己獨特的角色和任務,人人不可或缺,無法輕易替代。每一個球員的產值也大不相同,高低之間可能相差數十倍,無法相提並論或替換。

這是一個認知上的巨大差異,一旦當你把軟體開發團隊,從傳統工程(例如營造)的施工團隊,轉變成球場上的團隊,你會發現你的思維將會瞬間轉換。你將不再相信傳統的專案管理方法,你帶領團隊的方式也會大不相同。

DevOps/ALM/Agile與軟體專案管理

一旦你用一個全新的眼光看待軟體開發,你對於軟體開發的方式,採用的專案管理工具、做法,都將會跟以前有所不同。

也因此,我們這篇先談敏捷開發,然後接著,我們要來看,在這個思維底下,如何管理軟體專案,如何管理軟體生命週期,如何透過工具來實現DevOps…

如果你要惡補你的敏捷開發概念,請參考底下這本書:
http://www.books.com.tw/products/0010691328

下一篇,我們談時程預估與迭代的概念。

------------------------------
本系列文章索引位於 http://studyhost.blogspot.tw/2017/02/the-devops-journey-index.html

如果需要即時取得更多相關訊息,可按這裡加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

留言

這個網誌中的熱門文章

使用 Airtable 在小型需求上取代傳統資料庫

使用Semantic Kernel 建立自然語言請假系統

精彩(且驚人)的Semantic Kernel入門範例

在 LINE Bot 開發中使用Semantic Kernel建立自然語言請假系統

專業的價值...