在得到「欠筆記文欠過年」的成就之後，硬是擠出一個下午的時間，終於整理完 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 下午的議程筆記與心得。
下午選擇的是 Track 2，當時在午飯時間苦惱了一陣子，雖然一度很受到 Track 1「How to apply Agile to Growth Hack - Someda Takashi, 染田貴志」的議題吸引想要先聽 Track 1 再換場 Track 2，但 Track 2 的場地視野不佳、座位也少，考慮到換場一定搶不到好位子，因此最後整個下午都留在 Track 2。
邁向 Scrum of scrums - 杜秉穎
講者簡報已經釋出，可以前往線上觀看。
下午第一場是「邁向 Scrum of scrums - 杜秉穎」，但必須要先自首，因為精神不佳，在這場議程中一度陷入昏迷，所以記錄到的內容超少。
這場議程在劇情上是接續上午「如何在組織內有效引領敏捷變革 - 蕭存喻」的案例，也就是遊戲橘子內部的敏捷變革經驗分享。
首先講者向聽眾問了幾個問題：
團隊類型？ 是新創、公司自開發產品、接外包或其他。 團隊規模？ 5 ~ 50 以上是落在哪一個區間。 開發方法或流程？ 是 Waterfall、Being Agile、Doing Agile或自以為 Agile。 透過問題開場之後，講者開始進入正題，前面的題目也是講者在爲自己鋪梗，因為講者所處的團隊正是經歷由小變大與持續引入敏捷變革的過程。
在他們持續引入的中途遇到了一個狀況，即是乍看之下「團隊好像很 Agile」，感覺該做的都有做 (testing、CI、CD)，但隱約還是感覺有些問題，例如會議時間很長、沒效率且難以達成共識、對 sprint failed 好像沒感覺又好像很害怕。因此驅使他們決定新一波的敏捷改革。...
接續同系列文章《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 之後讓一切的資訊變得「透明」，在資訊公開且交流順暢的狀況之下，團隊都能了解明白目前的現狀，這有助建立團隊彼此（包含上層與下層之間）的信任。
第二階段：...
這次特別報名參加了 Agile Tour Taipei 2015，要來補充一下 Agile 與 Lean 相關知識，兩天的活動包含了議程與 Workshop。不過因為 Workshop 正好辦在週日，雖然有幾個感興趣的活動，最後也只能放棄無法參加。
議程從上午 9 點直到下午 4 點半，上午只有一條 Track，但下午則分為兩條 Track。偏偏下午兩條 Track 都有想聽的題目，被迫要有所取捨，導致在中午午餐時間，我在內心演了好久的內心戲，掙扎許久最後選擇了 Track 2。
首先是第一場議程的筆記與心得：
從敏捷與精實看軟體開發的未來 - 李智樺 Ruddy Lee
講師簡報已經釋出，強烈建議務必要閱讀學習。(立即瀏覽) 同時 Agile Tour Taipei 2015 已經釋出本議程的錄影。
首場議程是由金牌講師 Ruddy Lee 擔任，在議程正式開始之前，講師就已經提前開始與聽眾們有著許多的互動，講師一開始就直接開始在白板上畫出「看板」，並請工作人員拿出便利貼開始整場傳遞，邀請聽眾可以寫下任何與 Scrum 相關的問題貼在白板上。
老實說在那個當下，我一度覺得自己是不是走錯場子？今天不是來聽議程的嗎？怎麼彷彿走到 Scrum Master 教育訓練場。而事實上講師所有的舉動，其實都是在默默的鋪梗，當簡報進行到後半之時，就會恍然大悟，原來白板上的「看板」就是簡報內提到的「Q &A 看板」。
在開場中講師有提到一個我覺得很重要的觀念，意思大約如下：
「敏捷其實並不是一個強調『快速』的開發方法，它是用來處理複雜問題的方法，因為它是一個務實的方法。而正因為它能有效地處理複雜的問題，彷彿很快就能解決問題，因此造成大家覺得它很快！」
我覺得這一個觀念的重要性在於讓人對於「敏捷」建立正確的態度，因為真正重要的需求是什麼？應該是「解決問題」，而敏捷提供你一套方法來有效的「解決複雜的問題」。當你可以一再地「務實且有效地解決複雜的問題」，並且定期不斷的「持續改善」，那麼自然你的效率也就越來越「快」！
接著進入議程的主軸，整場議程主要環繞在「看見」這兩個字。首先講師連續用了幾個範例來讓聽眾體會「看見」，強調人們經常需要看見，看了之後才有感覺，才會產生聯想。
例如單車登山的照片，往往你會看見的照片有兩種，一種是車手順利上山，在山頂上的勝利姿勢，另一種是車隊在半路中努力克服陡坡的奮鬥過程。但實際上的情況卻不是如此美好，事實是山頂或山路上可能是車滿為患，車手在登山過程中經常被卡在車陣之中。你所看到照片不過是一個過度美化的結果，所以「看見」不只是看表象，更要能看見「真諦」。
繼續更多「看見」的例子。
同樣是飛機窗外的景致，但是去程與回程帶給人的聯想是不同的。你若在去程飛機上，看到窗外的景色，恐怕你的聯想是：
「下飛機後要先去哪邊 checkin，接著要去哪邊與客戶碰面，然後⋯⋯」
若是回程飛機，恐怕你所想的則是：
「終於可以放鬆休息了，想念家中的妻小⋯⋯」
同樣類似的景致，但能產生的聯想卻是大不同。
飛機的舉例還延伸講到另一個重點，就是「抽象化」。當面對問題時我們要將問題「抽象化」，就像飛機越飛向高空，則地表物體顯得越來越小，你就能看到更多的「全貌」；這就如同由「極度明確」往「極度抽象」的方向前進，當飛到一定高度之後，你會發現問題就只是地表上的一個小點而已。
接著下一個「看見」的範例是一段影片。
講師播放了這幾天被許多內容農場瘋傳的影片《CANAL+ Football - Cameramen》 不過這裡當然不只是為了博君一笑，講師其實是要借用影片中表現的「因為有賣力的攝影師所以我們才能在電視上看到精彩的足球轉播。」這個概念，來類比「看板與專案」之間的關係。
不同於影片，下一個「看見」的範例是一個故事。
講師提到他曾收過一封 E-mail，有位年輕人請他看一下某個網站，但當年的他並沒有任何的感覺，因此遲遲沒有回覆對方，然而多年之後現在這個網站是人人都在用的 Google。...