Agile Tour Taipei 2015 筆記與心得(三)| 從 Agile 到 Lean Startup:趨勢的軟體開發之旅 - Jason L Lin

接續同系列文章《Agile Tour Taipei 2015 筆記與心得》,本文繼續記錄 Agile Tour Taipei 2015 上午第三場議程「從Agile到Lean Startup:趨勢的軟體開發之旅 - Jason L Lin」的筆記與心得。

從Agile到Lean Startup:趨勢的軟體開發之旅 - Jason L Lin

講師的簡報已經釋出,可以由此瀏覽。

第三場議程是由趨勢科技 SQA/SEPG 部門的林立仁為大家分享。講者在自我介紹時特別強調了 SQA/SEPG 部門,根據講者所言趨勢科技很重視軟體開發方法,因此 SEPG 部門的工作之一就是將一些優良的軟體開發實踐帶入公司之中。

趨勢科技推動這些實踐主要是由 Bottom-up 的方式進行,企業文化鼓勵員工做中學並勇敢嘗試錯誤。這種鼓勵學習、容許犯錯的企業文化不知道會戳中多少困在傳統企業文化的開發者?據說趨勢仍然有在徵人,有興趣者不妨可以考慮看看。

(提供一個對照組,上次在 iThome DevOps 2015 研討會中,Yahoo 就提到 Yahoo 推動 CD 時的方式就是 Top-down。)

簡報的前面兩頁是公司簡介,不過講者在提到「經營理念」時,特別強調了「自我提升、保持創新領先地位」,用這一點呼應為何趨勢會在企業內部大力推動導入 Agile 與 Lean statup及前面自我介紹提到企業內部會成立 SEPG 部門。一再的強調趨勢實在是一間鼓勵學習、創新的公司。

接著作為前情提要,講者先快速地介紹趨勢科技導入 Agile 的歷史,主要有幾個重點:

  • 從 2007 年開始嘗試導入。
  • 接著 Bottom-up 遍地開花。
  • 目前已正式成為公司開發者的必讀準則。(但非強制遵守)
  • 現在全公司約 60% 的專案有採用 Agile。

既然趨勢科技已經大幅度的導入 Agile 了,那麼是什麼原因導致趨勢科技仍需要接著導入 Lean startup 呢?主要是因為有下面幾個新的問題與挑戰:

  • 軟體開發週期越來越快。 (特別現在又是手機 App 的時代。)
  • 公司內的雜音。 (講者列舉了許多的例子,不過可以簡單歸納,這些雜音多半都是與產品的「價值」相關的聲音。)
  • 組織隔閡。 (在整個開發流程中,開發團隊被隔絕在外,無法取得客戶的回饋。)
  • 面臨的挑戰。 (參閱簡報 P.10 的圖表。這裡講的是產品的生命週期有四個階段,一間企業大多數的產品會落在成長平緩且獲利高區域,但這樣的產品下一階段就會進入沒落的階段。而企業最缺也最需要的是成長快速且獲利高的產品,但該去哪裡找出這些產品呢?)

為了面對這些問題與挑戰,特別是第四點「企業要去哪裡找出更多成長快速且獲利高的產品?」,因此我們就需要 Lean startup!

在正式進入趨勢科技的 Lean startup 之旅前,講師很精闢說明 Agile 與 Lean startup 的差別,以下用我自己的話來說明,大家則可以參閱簡報 P.12

  • 什麼時候使用 Agile ? 就是你知道產品的需求為何,但是你不知道如何解決,這時你可以使用 Agile 幫助你務實地解決問題。
  • 那何時要使用 Lean startup? 則是你連產品在哪裡、產品是什麼都不知道,這時就需要 Lean startup 上場,幫你找出產品需求。 在 Lean startup 中進入產品開發階段時,就輪到 Agile 上場協助產品開發。

在介紹 Lean startup 時,講師也稍微提到目前 Agile 已經有許多的工具可以運用,但相較於 Agile, Lean startup 目前仍較缺少這些可實際運行的工具或框架,主要偏重在提倡「概念」及概念所帶來的啟發 。

介紹完 Lean startup 之後,講師接著分享了兩個趨勢科技的 Lean startup 成功經驗。講師提到趨勢科技內部為了鼓勵創新,進行過許多相關的精創活動與內部實驗,當然絕大多數是失敗的案例,畢竟創新並不容易。但假如你的提案獲得高層認可,就能獲得些微資源讓你繼續在公司內的精創專案。而公司則會一段時間再來檢視你的成果,決定是否要讓此專案繼續。

第一個成功經驗是有關「Mobile App Virtualization」的產品,其中我覺得最有趣的地方是該團隊在初期僅先做出 Concierge MVP 而已。Concierge MVP 並非有真正開發 MVP 產品,它是一個假的 MVP,純粹只是要用來驗證概念。接著再類似 Dropbox 一樣,先製作 Video MVP,最後才是真正有進入開發的 online MVP。

第二個成功經驗是與「Home Network Security」相關的產品,這裡的做法與第一個案例不同,這一組的做法是先進行「Product Value Validation」,進行了數個循環之後,確定了產品價值才進入「MVP Validation」開始動手打造 MVP。

兩個案例的做法乍看不太一樣,但其實在概念上是相同的,都是先驗證概念,後續再來實作 MVP。

接著從簡報 P.20 開始後面滿滿都是重點,但因為議程時間不足,所以講師只能將速度加快,甚至稍微超時,但依然不足將每一頁簡報詳細說明,這一點實在是很可惜,不過據說 Agile Tour Taipei 2015 針對上午的 Keynote 都有錄影,目前已釋出前兩場的錄影,沒機會參與者後續可以透過錄影來補課複習。

簡報 P.20 的經驗分享很重要,這裡提到了「驗證」的重要性,包含了早一點讓「Marketing & Sales」的意見加入與「避免無效的驗證」。因為 Startup 是一種「Feature-driven 的商業模式」,所以一定要一再「驗證」,藉此確認前進的方向是否正確。而同時我們也知道若時間拖得越久「風險」與「浪費」也就越高。

另一個重點則是講師一再提到的「Technology Adoption Lifecycle」中「Early Adopters」的那個斷層。能否跨越這個斷層也是 startup 產品能否成功的關鍵,而這就需要透過「Fast Business Validation Process」來幫助。

最後 P.21 ~ P.28 我覺得是簡報中的精華,你可以看到趨勢科技在導入 Lean startup 之後,集合其失敗與成功案例而來的經驗與工具分享,如果有意要實踐 Lean startup 很值得參考,該區分成幾個階段、每個階段的重點為何、一些重要的思維⋯⋯等,像是在 P.23 就詳細說明了「Fast Business Validation Process」。

心得

這一場議程對我而言最大的收獲是再次詳細的認識了 Lean startup 及 Agile 在 Lean startup 中的位置。同時藉著趨勢科技分享的成功經驗讓聽眾可以將案例與 Lean startup 的重要概念做對照,有助於加深對 Lean startup 的認識。

簡報最後幾頁的精華則是相當的實用,雖然短期內並沒有要進行 startup 或開發新產品,但能多認識這些有用的概念與工具當然是多多益善,而且就如本文前面就已提過,簡報中的精華內容對有意要實踐 Lean startup 者,是很值得參考閱讀的資料。

最後因為對於 Lean startup 有更多認識,連帶的也更能體會為何在 DevOps 中會融入 Lean 的概念,以及更多人開始將 Lean 拉出來強調它的重要性,改用 CALMS 而非 CAMS 來介紹 DevOps。

筆記與心得到此,再補一次其他文章的傳送門:

轉貼本文時禁止修改,禁止商業使用,並且必須註明來自「艦長,你有事嗎?」原創作者 Cheng Wei Chen,及附上原文連結。

工商服務

更多文章