我是王泰瑞

記得當初小時候，會跟朋友玩一個遊戲，兩個人對看，先眨眼睛的就輸了。我記得每次我都做一些鬼臉，弄的對方笑出來，他就輸了。後來都變成誰先笑誰就輸了～ 小時候麻～  

我的答案是「要」。但可以依照 Context 不同而不同。

3/19 我們又辦了一次敏捷與 scrum 的內訓，這一次比較特別，我們對外開放報名，邀請了 14 位朋友一起參加。 敏捷在 91APP 也做了一年多了，不敢說一切都很好，但終究是有點小小成果。這一次不再是我一個人獨自講完一天的課了，有 fufu 跟林琪幫我分擔掉兩個大主題，頓時感到輕鬆很多～～

今天 Ruddy 老師又轉過來，問我一些事情，我覺得整個討論過程蠻有價值的，以下節錄。

Ruddy 老師今天轉頭來問我這題。 最近 devops 好流行，我們的團隊也把開發跟維運慢慢地交給同一個 feature team 做，可是就會有個問題出現啦～Code 越寫越多，要維運的東西也越來越多，可是工程師們開發能量有限，維運的多了，開發的就少了，開發速度就慢了。 所以一天一天就會變成這樣：

最近有些小事值得紀錄一下，但… 我最反骨了，點餐都點滑蛋牛肉飯的，我偏偏： 用不值得記的大事開始   最近，公司又上了一些新聞媒體，當然是好事啦，比如說：

不知道為什麼，我最近越來越不喜歡跟人談敏捷了，今天想聊一下棒球，順便講一下學東西的三個境界～ 這是 wiki 的解釋： 守破離 image from:  http://www.aikidotakemusu.org/en/articles/saito-senseis-method-6    

前幾天看到 Vince 哥的文章： 【文思不藏私】@Scrum 是萬靈丹嗎？ ，覺得心有戚戚焉，順便再補充一下小弟的看法。 Scrum 是萬靈丹嗎？當然不是。在有前提的情況下。 如同 Vince 哥的文章提到的那本書：「Scrum 用一半的時間做兩倍的事」，對我來說，這本書就是 scrum 入門的書，是科普類的，對於想認識 scrum 的人來說，它的確是一本可以唸的書，購買連結在這邊： https://www.tenlong.com.tw/products/9789863207146

scrum 是由 Ken Schwaber 與 Jeff Sutherland 發明的，而在他們寫的 scrum guide 裡面，並沒有提到 deadline 該怎麼處理，所以我用這篇來說一下小弟我對 deadline 在 scrum 裡面的想法。

之前在上課的時候，常常會跟學員說，要小心不要讓你的 project 掉入”區域最佳值”，做法是什麼什麼什麼什麼 (太長，先略過)。 下面這篇文章寫得更詳細了，比我說的更好，所以丟上來跟大家分享.. :) ̨

在 擁抱改變 這篇文章中，我稍微聊到了傳統專案做法中，抓時程的方法。 我打算用這篇文章來稍微聊一下在scrum中，對"估計"這件事情的看法。  先來玩個小遊戲好了。請大家看下面這張圖：  (圖片出處：http://hdw.eweb4.com/out/440195.html) 好了嗎？開始囉~  -------------------------------------------------------------------------------------- 第一題  請估計紅色圈圈的大樓跟綠色圈圈的大樓的高度，單位請用公分，沒錯，是cm。 第二題  請估計紅色圈圈的大樓跟綠色圈圈的大樓的高度，這次請把地下停車場的深度一起估進去。 單位一樣是公分。 第三題  請問，畫紅色圈圈的大樓是綠色圈圈的大樓的 幾倍 高？  包含地下停車場呢？紅色框框的大樓是綠色框框的大樓的 幾倍 高？  好的，玩完了。  -------------------------------------------------------------------------------------- 哪一種估計比較難？假如你找十個人玩這個遊戲，哪一題的答案會比較一致？ 這個遊戲我第一次玩的時候，也很驚訝，希望在電腦前的你也有同樣的震撼。 我自己的感覺是： 1. 用無意義的單位來估計，是無意義的。 用公分來估計大樓的高度，就好比用(人-天)來估計軟體feature或bug的loading一樣。 假設，一個bug估計需要10人-天，我找5個人來，assign這群人這個bug，兩天以後，這個bug就解掉了嗎？那如果我找100個人來呢？ 2. 絕對 vs 相對 在傳統的做法裡面，總會有一個人跳出來說： 以我過去的經驗跟目前專案成員的能力，我估計這個專案至少需要四個月的時間。 說這個話的人可能是PM，可能是資深的工程師、架構師之類的，糟糕一點的話，可能會是業務，總之是個說話有份量的人。於是，他說了，老闆就聽了，團隊也聽了。然後大家再抓一下debug的時間，再抓一下buffer ，於是經過一番討價還價...

確定大方向，修改小目標 scrum 是以經驗法則(Empirical)為主的開發方法，在開發過程中，每個sprint做出來的potentially shippable有可能很棒棒，也有可能評價不高。所以跟打橄欖球一樣，每一次進攻、推進的路線、節奏跟戰術必須要一直修正，最後，才能達陣得分。 雁子南飛 在certified scrum master的課程上，老師(至少我那位老師)用的例子是雁子往南遷徙過冬，那些鳥其實只是要找到符合三個條件的地方： 夠溫暖 夠安全 食物夠多 於是，它們每天早上起飛，黃昏降落。每天它們都在觀察(Inspect)四周環境，是不是夠溫暖、夠安全跟有沒有足夠的食物，然後它們做出決定(adapt)，看是要繼續往南飛，還是就在當地過冬。 假如不透明，這些雁子就不知道他們飛到哪裡了，是不是夠溫暖、夠安全跟有沒有足夠的食物。 很有道理吧，不透明怎麼知道飛到哪裡了？怎麼知道自己是不是飛到北京，明天就變成北京烤鴨了？ ...好啦，我知道雁不是鴨，但大家懂我的意思吧。   In scrum framework... 在 上一篇文章中 ，聊到了三個方向的透明度： 主管對下屬 下屬對主管 同事之間 有了這三個方向的透明，基本上團隊會在對的方向跟士氣上做事，然後，這一篇再繼續講一下透明的重要，尤其是在scrum框架下。 scrum框架規定了很多個會議，要這些會議發揮到最大的功效大家就要做到三個方向的透明。還記得sprint planning meeting嗎？假如團隊不敢跟PO說，我覺得妳這些東西我們一個sprint做不完，那最後一定是喇掉。還記得daily stand up meeting嗎？假如不好好sync，別人的東西可能會跟你的打架，又要浪費時間去修。還記得sprint review meeting嗎？假如PO或是其他stakeholder不好意思把覺得怪怪的地方說出來，那最後成品也是喇掉。還記得retrospective嗎？假如大家不敢指出彼此做得不好的地方，最後團隊也是在互相忍耐而不會進步。  有話就要大聲說阿。 scrum框架的每一個會議都是在蒐集feedback，讓整個團隊能inspect，因為大家都不是笨蛋，不是白痴，大家會想出一些方法(adapt)慢慢...

對於台灣的團隊來說，在導入agile, scrum的過程，會遇到以下幾個問題，先大略寫一下，以後有空再詳述。 1. 公司內的政治問題 比如說，有設計部門，有App team，有framework team，有BSP team，有QA team，要跟這些部門的老闆以及他們的老闆說："我們來玩scrum吧，從你的部門拉兩個人給我"，那是多難的一件事。 2. Waterfall的遺毒 其實去上CSM的課程就有講到， Tyranny of Waterfall，大家都在Waterfall模式下作太久了，根本轉不過來。 3. 每個人都在尋找標準答案 在台灣，從小的教育就是教我們找出標準答案，但出了社會上了班，根本都沒有標準答案了，只有好與更好，覺得做事方法、流程等等不對勁了，自己要想辦法反映、解決或改變，要自己去做而不是老闆交代了才做，但很多軟體從業人員自己都沒有這種認知。 4. Rock Star 心態 台灣人大概是工作狂吧，大家都覺得把部門的工作攬在自己一個人身上，是很強的，很受尊敬的，但真的不是的！各位，你們需要的是一個團隊，是一群在錄音室裡面默默的、不求出名的、願意努力的反覆的把音樂做得很好的一群樂手。 5. PM是偉大的存在 事實上在 scrum框架 裡面，PM們，你們根本沒有工作，你們要扛起更大的責任同時下放更多的決策給你的團隊，這樣的角色叫做Product Owner (PO)。 曾經有人跟我說，PO跟PM只是名稱不一樣，只是玩文字遊戲而已，但其實不是的，PO領導著團隊，也被團隊領導．而不是："我是PO，所以你要聽我的"。 很多台灣公司，在裁員的時候，都先砍QA、然後RD、然後HR，PM是很少被砍的，但其實在做軟體的時候，PM的工作是最容易被取代的，假如PM一直以為自己高高在上，沒有辦法把自己的心態降下來，為團隊服務的話，那這樣的PM，說真的，應該優先被砍。 Conclusion 導入agile或是scrum的時候，心態的改變是很重要的，在好的scrum team裡面，大家會很快樂、很有士氣，每個人都可以專注在自己的事情上，那是多棒的境界！但是心態改不過來的話，自然會報著否定的態度來看這一切事情， 指著別人說，你那個scrum方法根本亂七八糟，怎麼可能work，最後還是回到老...