接續同系列文章《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。
筆記與心得到此，再補一次其他文章的傳送門：
