Agile Tour Taipei 2017 筆記

RojerChen.2019.02.08

草稿放著放著就放了超過一年了,想說要找一下 2017 年的照片卻怎麼也找不著,2017 年很認著擔任聽眾,照片沒拍幾張,只好拿 2018 年擔任志工拍的照片來放了 XD 以下的內容為 2017 年的筆記。


Agile Tour Taipei 2018 台北敏捷之旅

※活動筆記

1.閃電秀

  • 居然有閃電秀,但是閃電秀不拔線就不閃電了
  • 各講者的時間好像不太一樣
  • 時間充分利用,台上講課、台下放飯
  • 贊助商優先
  • 其實應該改名為工商服務時間
  • 既然是工商服務時間,公司名稱、業務、職缺就趕緊介紹一下

2.活動整體

  • 活動背板、贊助商、打卡拍照小道具
  • 可愛吉祥物
  • 現場問題看板
  • 季準哥活動回顧
  • 午餐、下午茶、咖啡、啤酒、餅乾吃飽飽
  • 啤酒贊助商、叫車APP,兩個放在一起還蠻搭配的

3.拍照

沒有注意到有在徵志工,如果有發現的話我應該會去應徵拍照志工,當天看了現場環境後的一點筆記。
  • 閃燈必備
  • 肥皂盒感覺效用不高,應該還是要用跳燈或直打,或是用碗公
  • 如果是跳燈,天花板並非辦公室天花板,而是一堆詭異雜物,可能也有點困難。
  • 場地不大,合照可以不用廣角
  • 需要長焦段恆定鏡頭 (35-100 F2.8 M43)
  • 需要大光圈定焦鏡

※課程筆記

1.Agile In Transition and In Business World

自從商周報導敏捷相關的新聞後,敏捷變成一種口號與流行,但是公司導敏捷往往是半吊子的方式,轉型只是部分轉型而不是全部轉型,這樣子往往會轉型失敗。

錯誤的 KPI 容易導致錯誤的結果,就好比公司的 KPI 計算 BUG 修復的數量,程式碼行數

注重流程效率 > 產能效率,重視人的價值而非產出的數量

right people brings right approach, start small then expand

Agile Contract
1.Fixed time
2.Fixed cost
3.Fixed Quality
4.The only variable is scope

每次的 iteration 都是可用且有效地交付,只要客戶接收都應該跟客戶收錢/客戶付錢 (這感覺算是一般專案中分的一期、二期、三期之類大的里程碑)。

如果客戶中途解約,收取剩餘尾款的20%,可再與客戶議價。

很喜歡講者最後投影片的這句話。


2.敏捷商業分析

講者是專業的講師,所以聽這堂課很有回學校當學生的感覺,內容主要在闡述用敏捷的手法來進行商業分析,對於商業分析的部分我感覺著墨甚少,算是我覺得比較可惜的地方。

需求 -> 方案 -> 價值

需求:與公司策略是否相符合
價值:對公司、對客戶、對團隊

接收第一線的回饋

敏捷思維是做得少但是做的對,這正是我要的就是敏捷思維。

3.UX in the Jungle - 如何應用敏捷實務設計出好玩的桌上遊戲

講者很幽默有趣的介紹這款桌遊是怎麼設計出來的,從點子的發起、遊戲的設計、試玩與調整,雖然內容有趣但是實際執行起來應該是不少辛酸血淚的,上班只能做正事,設計這個只能找其他時間弄,除此之外一個星期還有兩次的 iteration ,感覺有點蠟燭兩頭燒啊!

『我光用想的就超好玩的!』

當你設計桌遊有這種想法時,

恭喜你,你的成功率高達 3%!

遊戲除了有趣、好玩之外還要具有目標,你希望玩家玩了之後可以獲得些甚麼。

waterfall 與 agile 的差異在哪?用下圖說明可能不是那麼正確。因為在下圖的下方中,不應該一開始是滑板然後是滑板車、腳踏車,這應該是 pivot 而不是 agile,因為滑板、腳踏車、機車分別是不同的客群,你的客戶要的是汽車,你應該一開始給的是長得像車子但是不能動,然後才慢慢具備相關的功能。



相較之下,下面這張圖就比較恰當。

MVP_v2

何謂 MVP?Minumum Viable Product? A product with just enough features to satisfy early customers, and to provide feedback for future product development.

有時候我們可能認為只要把基本功能完成就算達到 MVP 了,只要具備 Functionality 就算達成 MVP 了,但是所謂的 MVP 應該還是具備一定的 Reiability、Usability 與 Desirability。



4.高效溝通 - 揭開促進團隊效能的密碼

這是我今天最喜歡的一堂課,只可惜時間的關係 Percy 老師只分享到兩個實務上的案例,其中一個案例是使用敏捷來執行公家機關的專案,其中最精采的部分就是適時的運用暗黑兵法讓客戶願意動起來、自行討論、設計畫面、調整系統流程,這樣的效果 PM、SA 設計流程後再來跟客戶開會還要好的百萬倍。

1.遠離溝通三寶:筆電、平板與手機。
2.關鍵時刻故意犯錯,讓客戶指證,讓客戶動起來
3.暗黑兵法


5.Get better at Refactoring

在聽這場的時候很自然地就想到 91,雖然台風與口條沒有 91 這麼厲害與清楚,但是 20 多分鐘的 live demo 程式碼重構實在是相當精彩,講者配合熟練的快速鍵很快的調整一個個項目,如果不專心一個閃神很快就會不知道講者在幹嘛的。

1.先寫好單元測試再來重構。
2.將前後端的物件命名一致,避免不要的腦力消耗
3.修正函式的功能名稱,讓你一眼就可以看出這個功能在做甚麼
4.運用 IDE 工具來協助重購
5.經由練習來培養 bad code smell 的嗅覺,以下為講者分享的練習網址

https://github.com/stanlylau/tictactoe_csharp
https://github.com/stanlylau/refactoring-kata
https://github.com/stanlylau/trivia-csharp
https://github.com/emilybache/Tennis-Refactoring-Kata
https://github.com/emilybache/GildedRose-Refactoring-Kata

[ASP.NET]重構之路系列(91)

    Blogger Comment

0 意見: