在得到「欠筆記文欠過年」的成就之後，硬是擠出一個下午的時間，終於整理完 Agile Tour Taipei 2015 最後一場議程的筆記，壓軸場當然是非同小可，是由絕無冷場的 91 哥為大家帶來「Scrum Estimation Model」這個題目。
同系列所有文章可以點此連結前往《Agile Tour Taipei 2015 筆記與心得》 因為欠筆記文欠太久，91 哥早已將他分享的內容整理成兩篇文章：
Scrum Estimation - 如何估算專案時程 Scrum Estimation - Scrum Estimation Model 既然講者都已經把內容寫成文章了，所以老實說我有沒有寫這篇筆記文好像也沒差，那本文就此結束吧。（揍飛） 筆記文由此開始，在一開場 91 哥就直接先用他自己今天的簡報總頁數當作範例，點出本場主題的三大關鍵重點「範圍」、「 時程」與「速率」。
範圍 = 簡報總頁數 時程 = 演講可用的時間 速率 = 每分鐘要講幾頁（才能不超時將內容講完） 基本上這是簡單的數學計算，由「範圍」除以「時程」可得出「速率」，反之你也可以由「範圍」除以「速率」得出「時程」，又或是由「時程」與「速率」得出「範圍」，總之這三個重點是彼此互相關聯的。 但實際上講者講話的速率有限，不可能提升至預期的速率，因此勢必只能延後結束時間或減少簡報頁數。這個開場白其實直接就比喻了專案執行的情況，因為專案執行時也同樣是在「範圍」、「 時程」與「速率」中不斷地協調。 透過開場白 91 哥很快的在聽眾們的心中埋下了「範圍」、「時程」與「速率」的基本概念，整場分享即是完全圍繞著這三大關鍵。
接著 91 哥繼續用「兩個人決定步行前往探視朋友的一段旅程」比喻說明了在專案執行中常見會導致「專案延誤」的意外狀況。
在這個小故事中一樣有「範圍」、「 時程」與「速率」：
範圍 = 交通距離 時程 = 與朋友約定的到達時間 速率 = 一天要移動多少距離 於是隨著小故事的發展，每一天都有不同的意外，但因為「範圍 = 交通距離」是無法變更的（但有可能會錯估），於是故事主角每天都在「 時程」與「速率」中不斷的協調與修正，嘗試要完成這趟旅程。旅程中就發生了各種突發狀況，例如： 錯估交通距離 = 錯估專案範圍 受傷導致行進速度變慢 = 開發速率下降 打電話通知朋友會晚幾天到達 = 嘗試延後 Due Time ⋯⋯等等 藉此案例 91哥再次強調這場分享就是一直圍繞在「範圍」、「時程」與「速率」這三個重點打轉，換句話說這場分享重點就是在講 Burn Down Chart 燃盡圖。 那「範圍」到底是啥？範圍就是專案要完成的工作項目有哪些，你的 product backlog 有多少，估算出來的 story point 有多少。...
接續同系列文章《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 呢？主要是因為有下面幾個新的問題與挑戰：...
接續上篇文章《Agile Tour Taipei 2015 筆記與心得 (一)》，本文繼續記錄 Agile Tour Taipei 2015 上午第二場議程的筆記與心得：
如何在組織內有效引領敏捷變革 - Richard Hsiao, 蕭存喻
這場議程是屬於「經驗分享型」的內容，講者將過去的經驗歸納重點後，將過程中遭遇的狀況與經驗談一一向大家分享。整場簡報的主軸即是講者所處的團隊如何逐步引入 Agile 的心路歷程。
講師的簡報已經公佈上網，可以直接線上瀏覽。 同時 Agile Tour Taipei 2015 已經釋出錄影。
首先講者用一個問題及一張圖作為開場帶出主題「組織在引入敏捷時常見的阻礙爲何？」
這問題的答案有很多，有來自上層或下層的不同的阻礙，例如常見的阻礙有「如何說服老闆接受 Agile？」或「如何說服工程師開始寫測試？」⋯⋯，當然還有更複雜的阻礙。講師則利用簡報 P.3 的圖片作為說明。
圖片中的 X 軸代表的是 Autonomy 由低至高、Y 軸代表的是 Alignment 一樣是低至高。
那麼你的團隊是屬於哪一個象限呢？是左上角的象限，需要由上層下達明確的指令，團隊才能準確的依據指令行動；或是右上角的象限，同時具備高度 Alignment 與 Autonomy，上層只要提需出問題，團隊即能展現高度自治完成任務。又不幸的是左下角，上層與團隊是一整個渾沌的狀態？
以此開場之後，講師延伸提到了當年他有了一個機會可以開始在團隊中引入 Agile，而這個經驗帶來的第一個心得是「危機就是轉機」，但有一個重要前提是「你需要證明給其他人看」。
「危機就是轉機」這句話大家都能朗朗上口，可是現實社會並沒有這麼簡單。「轉機」來到不等於後面全都會一帆風順，等著看你落水的人比比皆是。所以「轉機」只是一個開始，讓你有機會能取得權責來解決問題。只有在你真正解決了問題，你才能贏得別人的信任，為自己開創新局。
接著講師開始分享過去團隊引入 Agile 的實際經歷，共分成三個階段。細節我就不多描述，因為閱讀簡報就足以說明其中 7~8 成的內容。
第一階段：
這是滿常聽見的一種團隊窘境。團隊處於將要發展並力求表現之時，卻遇到專案進展不順及新主管的介入干擾，面對此窘境想要有所突破，因此決定引入 Agile 嘗試帶來新的火花。
當然團隊不可能立馬全面 Agile，所以在此階段先從可運行的最小實踐開始，先嘗試在團隊中導入了一個 Scrum 看版與 Daily Scrum 會議。
而第一階段最寶貴的經驗是「透明度」！
Scrum 不是萬靈丹，不會因為導入 Scrum 就能讓已經延期的專案忽然變得準時。重要的是導入 Scrum 之後讓一切的資訊變得「透明」，在資訊公開且交流順暢的狀況之下，團隊都能了解明白目前的現狀，這有助建立團隊彼此（包含上層與下層之間）的信任。
第二階段：...