相信有那麼一天,我們將可以像畢凱艦長一樣用嘴巴叫所有主機做事!


Cheng Wei Chen



Agile Tour Taipei 2015 筆記與心得(一)| 從敏捷與精實看軟體開發的未來 - 李智樺 Ruddy Lee

這次特別報名參加了 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。

這裡強調了「看見的意義取決於你所獲得的資訊,及看見之後你所採取的行動。」

接續這個重點,講師又再用另一個範例來加強說明。

同樣是一段影片,這個範例的影片是可以被稱為 DevOps 起源的著名影片《10+ Deploys Per Day: Dev and Ops Cooperation at Flickr》,相信這影片當時有很多人看到,但只有 Patrick Debois 看了之後很有感覺,並接著辦了 DevOpsDays,所以你看看現在 DevOps 一詞在全世界有多紅,而 Patrick Debois 似乎變成了 DevOps 之父。

同樣都是看見,為什麼會產生這麼大的差異?於是講師也問了「是什麼造成我們看見一樣的東西卻得到不一樣的結果?」

(補一個插曲,講師在過程中有時會拋出問題,通常這時候會有些人主動回答,但講師卻說其實他並沒有要大家回答的意思。他說他當初第一年教書就被選為「最受歡迎的老師」,其中的原因就是「他自己提的問題,他自己會回答!」。關於這部分,我所觀察到的是「講師對現場情況的掌控能力」,我想有沒有人回答對他而言沒差,他都能將現場狀況轉為自己所用。)

造成結果不同的答案就是「抽象化」,也是前面飛機範例中提過的「看見全貌」。

我們需要的是「抽象化解題」的能力。而你會發現從「極度抽象」至「極度明確」之間,真正能有效解題的關鍵往往是落在「抽象」到「明確」之間。

同樣是一個要解決的問題,與其給你一堆說明文件,不如直接給你一個 User Story,如果覺得 User Story 還不夠好,那再進一步 User Story mapping 如何?(講師也大力推薦 User Story mapping)

抽象化可以減少複雜度,讓開發者只需專注在處理重要的部分。

這時候講師另外提到了 XPS viewer 這個工具,他認為這是個好工具,然後用它示範從單一張簡報拉遠變成預覽簡報的整體面貌,藉此比喻說明「局部->全貌」。

講師差不多講到這裡,接下來就因為時間不足所以沒繼續按著投影片講下去,而是直接跳到  P.62 稍作說明,接著再跳到 P.99 開始介紹「Q & A 看板」,並直接用一開始畫在白板上的「看板」來實際演練一次「Q & A 看板」。

第一場議程的筆記大致記錄到此,Ruddy 老師不愧是一流的金牌講師,豐富的資歷、穩健的台風。聆聽這一場議程就有如在看一場「表演」一樣,整個過程是非常享受的。可以體會到老師的經驗深厚,似乎有滿腹墨水怎麼講也講不完。享受如此愉快的表演果然會覺得時間飛快的流逝,若要說對這場議程感到不滿意的地方大概就是無法聽見講師將簡報每一頁都一一說完,以及未能聽到個人原本非常期待的「Agile 與 DevOps」的內容。又特別是在寫此篇文章的同時,看到講師事後釋出的完整簡報,更是令人感到非常可惜!實在好想聽見 Ruddy 老師將它全部講完啊!

題外話:有別於上次採用「上、中、下」來切分文章,這次決定改用「一、二、三⋯⋯」來切分,因為恐怕不知要花多久的日子才能將所有的筆記與心得整理完畢,就讓我透過這個方式來代表我決定拖稿一陣子的堅固決心!

此系列文章傳送門:



沒有留言:

張貼留言

不歡迎留言打廣告,所以有進行留言管理,敬請見諒。