Scrum的意義

2015/06/13 19:16-19:57

圖片來源在此

Scrum是軟體敏捷開發法中的其中一個方法，這個字在橄欖球之中，是爭球的意思，翻成中文有個更貼切的名詞「鬥牛」。

在美式足球的活動裡，同一個隊伍裡面的人目標都必須一致 ---「爭球」，橄欖球彈跳的方向通常很難預測，隱喻在軟體開發的活動中，顧客的需求通常也很難在專案初期就規畫得很完整，需求改變就如同橄欖球的彈跳班難以預測。

在Scrum裡的所有活動，都有規範一個固定長短的時間，時間到活動就應該立即結束，猶如橄欖球比賽，假設比賽結束的那一瞬間，隊伍A 53分，隊伍B 55分，那就是隊伍B獲勝，

隊伍A總不可能說：「再給我五分鐘我就可以把球放進得分區！」←開發軟體的時候，每當死線逼近，我好像都會這樣說XDD

這星期的軟體生命週期，Teddy把Scrum重新拿起來介紹了一番，

Teddy：「Scrum有哪些地方還沒講過的？」

班上同學們：「這學期到現在還沒有介紹過Scrum是什麼，只有看過一個15分鐘的短片」

Teddy：「蝦米！？這學期都沒有講過Scrum。所以你們也不知道整個學期在做什麼，這就代表不用懂Scrum也可以玩得很好。」

Scrum有股神奇的魔力，只要按照它的遊戲規則走，就能暴露出問題所在，所以它又有「照妖鏡」的美名。


情境模擬：

你是Scrum Master，正在一家公司導入Scrum，團隊的開發人員們每天都加班到半夜12點，他們開始抱怨Scrum害他們加班，因此認為Scrum是個爛東西，你是Scrum Master，遇到這種情況，你會怎麼辦？

霸氣回應：「你們加班，就是在隱藏問題！！！」

謎之聲：「其實加班.....是為了解決問題」




Scrum讓我知道原來還有這麼多的問題在等著我要去解決。只有更好，沒有最好

行為的藝術：52個非受迫性行為偏誤

2015/06/06 11:23-12:18

最近上Teddy的課時，他常常在課堂上幫<思考的藝術>和<行為的藝術>打廣告，雖然Teddy每次都講不出書的全名XD，但有定期收看搞笑談軟功部落格的鄉民們一定可以對上頻率。

這兩本書是圖書館的暢借書，兩本書都需要排隊，從三月底開始排隊排到四月底終於拿到了行為的藝術，從5月11日開始看，目前看到第134頁。

這本書共有52個主題，每個主題占4頁的篇幅，很好讀，作者在每個主題的一開始先呈現出一、兩個生活實例與主題互相呼應，然後在每個主題的結尾做結論，結論不一定有標準答案，有時候會以反問的方式，例如「你現在知道該怎麼做了吧？」。

今天來分享一下我認為很棒的幾個主題：

1. p.22 -> 「因為」是不可或缺的。這個詞語是人際關係的潤滑劑，所以，讓我們盡情使用它吧！
2. p.26 -> 人的意志力像電池一樣，可透過休息、放鬆補充意志力。假設今天有一個很重要的報告，最好選擇剛充電完的時段報告。
3. p.42 -> 胡說八道可以掩蓋無知。世界是複雜的，人們必須花費許多心思才能理解一個觀點，在你有這樣的體悟之前，最好奉行馬克‧吐溫的話：「如果無話可說，就閉上嘴巴。」簡潔是漫漫長路的終點，而不是起點。
4. p.50 -> 試著與最少的資訊共存，才能做出更好的決定。不需要知道的事即便知道了，還是沒有價值。
5. p.98 -> 不要接受任何不請自來的的建議、盡可能遠離不良的廣告來源、盡量回憶你熟悉的每一個觀點來源。這個工程十分浩大，也會使你的思維變慢，但會讓你更加清晰。
6. p.114 -> 如果事實與理論相違背，請立即丟棄你的理論。更重要的是，不要試著去等待一個「更好」的理論，這可能需要兩千年。
7. p.134 -> 你永遠記得第一次見到你終生伴侶的那一刻，那有如照片般深印在腦海中，但你必須假設其中有一半得細節可能是錯誤的。

讀閒書進度緩慢前進中...

一年前的我在旅行-勇氣11班 Day 3

2015/05/30 15:02-16:10


第一站  愜意又親切的鄉鎮-田尾

今天依然很早起床，7:30...準時開走，我們要從田尾舒宿走道社頭火車站！
本來想要順路吃早餐，殊不知越走越偏僻，身邊只有一望無際的花園。

在路上遇到一位阿嬤，我隨口跟阿嬤打招呼，阿嬤親切地強迫我們去她家吃早餐XD

第二站 二水

到了二水，剛好是中餐時間，隨地向路人問了當地著名美食，打聽到下面這家

究竟有多好吃呢？看下面這張

接著去離火車站很遠很遠的庄外花園，單程走路大概要40分鐘，

他們的米麵包很有名，店內提供DIY，但是要先預約。

回來的時候已經疲累不堪，隨意向經過的車輛舉出招牌手勢「大拇指」，第一輛經過的車就肯讓我們搭便車回火車站，運氣無敵好啊！

離火車抵達還有半小時，在火車站附近小晃，想不到也有不少裝置藝術

第三站 龍泉

是個小站，沒有火車站剪票台


猜猜這是啥？

猜對了嗎？是火龍果

馬路被樹蔭所包覆，是個美麗的綠色隧道

第四站 石榴

馬路很大條，沒有半台車

連小孩都直接在馬路中央跑來跑去

石榴車站是個特別的車站和一般的火車站不太一樣，外表與日式平房頗像 (剛好沒拍只好貼連結@@)

第五站 今日落腳處 - 嘉義

距離畢業剩下兩天！！

管理流程的重要性

2015/5/23 17:45-18:23

這週四上北科大的「軟體與生命週期」，Teddy重現C. C. Agile Sprint#18，搭配「達摩特效」把Pattern比喻得栩栩如生。

在介紹時，Teddy講了一個故事讓我印象深刻。

有一個實驗，實驗內容大概是這樣：

電椅上有個人，受試者須調整電流強度，強度從小漸漸調到最大，觀察電椅上的人反應。

電椅上坐著的其實是演員，椅子上沒有任何的電流，受試者調整電流時，演員會演的像是被電。

實驗開始了，受試者將電椅通了電流，剛開始電椅上的人還可以挺住這小電流，和受試者也還有說有笑；受試者持續地將電流變強，演員開始發出慘叫聲，哭求受試者別再繼續通電；但大部分的受試者，為了達成任務，並未打算停止實驗，直到電椅上的人被電到毫無動靜，受試者才驚覺自己電死人。

後來在網路查了一下和<電椅大風吹>很像，有興趣的朋友們可以去看看


壞的流程，可以讓好人變壞人

軟體工程中的MVP

2015/5/16 21:18-21:54

又到了一週一度的發網誌時間，沒想到最近流行的感冒毫無預警地降臨在我身上，乖乖的把醫生的藥都吃完了身體還是不給面子，其實想繼續睡連網誌打懶得打了XD

在北科大的軟體生命週期期中考，考了一題"什麼是Minimum Viable Product？"，在考前我是有上Wiki隨便看了下它的定義，看完之後印象也沒有很深，就字面上的意思"最小可行性產品"解釋，就是----UI做得不用做得太漂亮，東西能動比較重要。然後再衍伸一下，就變成以最小成本驗證產品所帶來的價值。

但是這題我只對了一半XD。

MVP大師云：「通常在開始做一個產品之前，都會有一個願景，假設這個產品會帶來某種很大很大的價值，在真正製作軟體的過程中，隨著每次的產出，驗證它是不是真的和之前的假設一樣帶來很大很大的價值，就像做實驗一樣，一直循環著學習→產出→驗證。」

要一直循環到什麼時候呢？我想到兩個答案：

1. 把公司錢燒光的時候

2. 驗證價值的結果差到不能在差 (這時候就該轉換跑道了，再ㄍㄧㄥ下去傷錢又傷肝)

突然發現以後用Google查觀念時，用圖片查詢的結果比較容易消化

[再來一本書] 習慣的力量

2015/05/09 21:29-22:35


最近終於又讀完了一本書<習慣的力量>，再打這篇網誌的時候，瞪了螢幕五分鐘不知道該怎麼把我的圖書心得分享給各位(迷之音：不會是書不好看吧！)。

會看這本書其實是因為在北科大修課軟體生命週期，我們這組的想要做出一個能讓人養成習慣的App，Erica很熱心地提供很多意見，還順便推薦了這本書，於是在學校圖書館撿到這本書。

作者將習慣從一個迴路開始解釋，這個迴路從這本書的第一章節一直強調到最後一章節

每個習慣，都遵循著這個迴路，我們因為一個暗示，開始了我的慣常行為(或稱習慣行為)，最後得到獎賞。

作者透過科學家的各種實驗證實，人不可能消除舊有的習慣，只能用新的習慣替換舊的習慣。要換掉舊有的習慣，得先找到暗示和獎賞。同樣的暗示和獎賞，可以用不同的慣常行為去取代。

在書中的最後一個篇幅，有個教大家換掉習慣的實戰步驟：

1. 找出慣常行為

2. 用各種獎賞進行實驗

3. 將暗示隔離出來

4. 制定計畫


書中在這邊舉了一個例子：

有一位上班族，每天下午都會買咖啡和餅乾，這樣的行為導致體重急遽增加，他想戒掉下午茶，這應該能幫他控制體重。

1. 找出慣常行為

每天下午喝下午茶配餅乾

2. 用獎賞做實驗

每當進行完慣常行為後，就寫下第一時間想到的三個詞，可以是情緒、感覺或是對自己的想法。

寫下之後，設定15分鐘的鬧鐘，15分鐘過後，就問自己是否還有吃餅乾的衝動。

3. 隔離暗示

要發現暗示比較困難一些，因為暗示的形式有很多種，作者將暗示整理成五種

當衝動出現時，就寫下這五項東西。

書中記錄了三天的暗示，發現每到下午三點多的時候，習慣衝動就會湧現，吃完餅乾之後覺得放鬆。

4. 制定計畫

於是他制定了一個計劃

這樣做了之後，還真的就沒有吃餅乾的衝動，不過剛開始時，有些時候因為工作太忙，舊癮還是會復發。

-----

直接看結論似乎會覺得很唬爛，但你看完這本書，保證你會想試試看。

先來養成運動的習慣吧XD

Scrum初體驗(6) - 守住最後防線

2015/5/1 8:44-9:01

在上一集中，提到我們在Sprint中修改Story，我一直覺得怪怪的。
因為在Scrum中，不建議我們在Sprint中插入緊急的工作，所以我像得了強迫症似的強力反對團隊這樣做。

忍了一個星期之後，終於有機會見道到Scrum大師解惑。

我: 「Scrum大師，我的團隊有罪。我團隊擅自在Sprint中修改Story。我知道Scrum中建議我們不要這麼做，團隊都還沒完全了解Scrum就擅自靈活地變化。是不是應該要求團隊先全面了解Scrum之後，再開始靈活變化會比較好呢？」

Scrum大師 : 「你覺得團隊什麼時候才能完全了解Scrum？」

我 : 「不知道...」

Scrum大師 : 「在Sprint中，當然可以修改Story，這樣的情況發生少數幾次是正常的，但是如果每個Sprint都有這種情況出現，那就要看看是哪裡出了問題。」

原來走我火入魔的是我