我是王泰瑞

在工作上，我們每天都在解決問題，但怎麼去解，是一個微妙的東西。假如我們沒有看到全貌，就冒冒失失地衝上去處理，可能事倍功半，甚至讓問題變得更糟糕。道理大家都知道，但怎麼辦？說得清楚嗎？或許系統思考 (System Thinking) 可以幫忙？ 舉個例子 在系統思考裡面，有一派的做法是使用 CLD 圖 (Causal Loop Diagram)， 透過使用這個圖，能夠解釋問題跟解法， 也能夠釐清思維跟邏輯。我們來舉個例子： 假設你是某個專案的 keyman，可能是這個專案的大 PM，或是技術專家、技術經理或是一個 Leader 之類的。總之，就是這個專案不能沒有你的意思，要知道當 keyman 是很好的，很有存在感的。 如果有一天，專案不幸的進度不如預期，所以主管們決定需要你投入更多的時間救援這個專案，因為你是 keyman 啊，大家當然找你。 我們來看看這個問題跟解法之間的關係： 1. 我們有兩個變數，「進度」跟「你的工作量」，我們接下來要探討這兩個變數的關係： 2. 當「進度」不夠快，我們就讓你多做一些，來救援這個專案。在這個思維裡面，因為進度是 慢 的，所以你的工作量變得更 多 了 ，這個關係是負相關，因為一個少了，另一個就多了；而在 CLD 中，我們在箭頭上加入一個負號來代表這兩個變數的關係： 3. Keyman 做得多了，進度自然就趕上了。在這個思維裡面，因為你的工作量變 多 了，所以進度就變 好 了，這個關係是正相關，因為一個多了，另一個也就多了；在 CLD 中，我們在箭頭上加上一個正號來表示這種關係： 如此一來，專案進度就趕上了。 所以，專案進度不好的時候， 你假如是 Keyman，你要不要衝上去幫忙？當然要啊！ 但是，我們也知道，如果培養專案中其他的同仁的能力，讓他們來分擔工作，也能夠對專案有幫助，這個想法我們也可以來探討一下： 4. 首先在圖中加入一個變數：「其他同仁的能力與幫忙」： 5. 進度越 慢 的話，就 越讓 其他非 keyman 的 同仁來幫忙 ，這兩者的關係也是負相關： 6. 因為有能力的大家一起幫忙了，專案進度也就應該拉上來了，這是正相關的關係： 7. 但是非 Keyman 的同仁的幫忙，可能要比較長的時間才能對專案的進度有助益；另外，一般來說，他們的能力也需要一些時間才能培養起來。在 CLD 裏面，我們會畫兩槓來代表這個 需要一段時間...

前言：我想用幾篇文章來聊聊幾個敏捷、Scrum 常用到的英文字，當然我的英文沒那麼好，也完全不是 native speaker，所以我的解釋、我的翻譯都只是我的解釋、我的翻譯，大家看看即可，不用認真。 第一篇文章我想聊聊 emerge Emerge 可以先看 Cambridge dictionary 的定義:  emerge 假如只用 emerge 當 prompt，會給我這個圖： 也可以問問 chatGPT: 嘖嘖，這個字到底什麼意思？ 這個字跟緊急的、急診，沒有關係。如果你把它翻譯為緊急的，那你就錯了～ 這個字的意思，我覺得最好的翻譯是「 隨著時間慢慢出現的 」，其實這個字很棒，真的很有敏捷、很有迭代感，並且會跟著時間過去而修改、改善的感覺。但是在寫文章或是翻譯時，用九個中文字來翻譯 emerge，有的時候會太臭長，所以...這個字的確不好翻～～ 敏捷宣言 敏捷宣言在他的 12 個原則有提到 emerge 這個字： 繁體中文版，就翻譯成「來自」： OK啦，沒有錯，也不差。但我還是覺得，如果能翻譯成「最佳的架構、需求與設計，都是隨著時間過去，由自組織的團隊去逐漸長出來的。」好像好一些？ 嗯，你可能還是覺得很爛齁，不然你翻一個在留言區看看吧。 Scrum guide 2020 在 Scrum guide 2020 翻譯為「湧現的」，共有三個地方出現： 在念 scrum guide 的時候，如果你覺得這個字實在不好理解，試著用「隨著一個一個 sprint 過去，會逐漸浮現出來的 ____ (請填空) 」，然後配合前後文去看一看，應該會好一些。 身爲譯者之一，我很抱歉。 可是啊，翻譯這個東西啊很麻煩，比想像中的煩，上次 2016 年的版本，就被身邊的 PMP 同事說，Sprint 這個東西你這樣翻成「短衝」，很多 PMP, PMI-ACP 的教材跟考試都要改了，你齁～～～ 所以啊，很多認證考試會依據這個文件來出題，所以就不能翻的很長，也不能帶有譯者想強調的意思... 身爲譯者之一，我很抱歉。 總之 Emerge 是：隨著時間過去，一個一個冒出來、長出來的；像是以前玩六合彩的那些大人們，會去某些廟裡面盯著香灰，因為他們覺得隨著時間過去，明牌會逐漸從香灰中顯露出來，的這種感覺，就是我對 Emerge 這個字的感覺。 好像更臭長了...XD 參考參考即可，因為如同我在...

  Scrum is a game 根據 wiki，scrum 的起源是： 1986年， 竹內弘高  (Hirotaka Takeuchi) 和 野中郁次郎  (Ikujiro Nonaka) 在其1986年的《 哈佛商業評論 》文章「The New New Product Development Game」中，闡述了一種新的 整體性 的方法 ，該方法能夠提高商業 新產品開發 的速度和靈活性： [4] 這個 game，翻譯作「遊戲」，不，那太錯了，翻譯作「比賽」才對。 跟誰的比賽？自己？不，那太爛了也太八股了。 我覺得是跟時間的比賽，跟市場的比賽，跟商業的比賽。 由比賽出發，你的團隊的教練是？ 來講個（快講到爛的）比喻： 大聯盟的球隊，每隊教練有幾個？我們來列一下好了？ 我想得到的有：總教練，投手教練，內野教練，外野教練，跑壘教練（一壘旁邊有一個，三壘那邊有一個），可能還有體能教練，投捕教練，助理教練等等。 那你家旁邊的國小，裡面的棒球校隊，有幾個教練？ 通常只有一個吧，而且他可能還是體育老師兼任的。 那你的團隊有幾個教練？ 那你們是大聯盟等級的，還是旁邊國小的？ 那你呢？ 有人會說，不不不，我要的是梅西，或是C羅這種球員，他是能夠上場帶著大家一起贏球的，他不是穿著西裝站在場邊的。 是的，同意。那你團隊裡面有梅西這種球員齁？老闆願意用那種價碼找梅西來齁？而梅西也願意來齁？ Topgun mavericks（我指的是最新那一集），湯姆・克魯斯最後就不當教練了，自己飛給大家看，最後也親自上場帶著大家贏。 是的，同意。那你團隊裡面有湯姆・克魯斯齁？老闆願意用那種價碼找阿湯哥來齁？而阿湯哥也願意來齁？ 如果你屬意這種團隊，那我想問， 你團隊裡面花大錢找來的那一個人假設就是你，你，是梅西，是C羅，是湯姆・克魯斯，還是上將 潘鳳 ？一上場就被人家砍下來了？ 我清楚的知道我是潘鳳，但不錯了，武力一般來講也有 70 了？ 由比賽出發，你的團隊專業嗎？ 再說個常見的比喻吧。 我這輩子一直有個夢想，我想跟麥可喬丹單挑一次籃球，我當然知道我會輸他，不管是身體素質，不管是籃球上的經驗，我根本沒機會。 除了這些天賦之外，我想他是專業的，professional 的；而我當然是業餘的，amateur 的。 專業人士所受的訓練、看待他們所做的事情，都會用很高的標準，同...

 大家好，繼上次的 scrum master 的獨白以後，再來寫寫作為 agilist 的感想。 我在遇到問題的時候，常常會去尋找正確答案，這是學校教育教會我們的，甚至他也會教給我們怎麼樣去找出這樣的正確答案。 於是，好像有一種想法會慢慢地成形，那就是世界上有好人也有壞人，有對也有錯，有黑也有白。而我們必須在這兩個之間選一個。 我說不是這樣的， 在敏捷的世界裡，沒有絕對的好壞，沒有絕對的對錯，也沒有絕對的黑白。 在敏捷的世界裡，應該像是這樣的： 其實很多做法，很多安排，很多 你遇到的挫折，拉長時間來看，以整個團隊來看，甚至，是以整個公司來看，都沒有絕對的對錯，有的時候，We are on the right side of wrong, or wrong side of right. 很多我遇見的敏捷的朋友， 大部分都已經在一個敏捷的公司了， 少部分的朋友還在不那麼敏捷的公司，要馬就是苦苦的努力做一些事情想要改變現狀，要不然就是習慣了。 我可能命比較沒有那麼好， 從來沒有一開始就待在一間敏捷的公司過，所以有的時候我都會幫忙做一些想要變敏捷的事情。可是敏捷真的是對的嗎？是好的嗎？Not really. It depends. 很多的東西，我覺得在這次 2022 agile summit 的投影片都有了，投影片，我放在這裡了： https://www.slideshare.net/doyouknowsoftware/agilist-253555022 我的投影片就是字他媽的多，所以應該看得懂，我很多東西就不提了。以下重點摘錄： 1. Agile 啊，你可以說是心態，是生活態度，都對。但其實真的回去看看敏捷宣言吧～ 2. 你的敏捷跟我的敏捷跟他的敏捷真的不一樣！真的啦！ 3. 關於組織(公司或 BU 或部門) 導入敏捷，是必須扯到規模化的議題的。 一個方向是：學會敏捷，摸透敏捷以後，然後試著把它規模化，套到公司或是 BU 的架構裡面，可以，合理。但過程中就是會格格不入，很卡。這個推動敏捷的人，要把自己練得很強，要搞定上上下下左左右右的所有人，這個過程很痛苦，通常會讓這個人受盡委屈而自動離職，也就沒有後續了。通常這個方向會形成 LeSS, Nexus, 大的看板方法這些路線。 另一個方向是： 先看清楚現實面，組織架構就是長這樣，主管就是那樣子做管理，等等，反過來從...

先說個故事，我當兵時，是古早的國防役，跟科技替代役不同，我們是真的要服役三個月，然後被派到某公司或研究單位工作四年的那種。 有一次我們被叫去拔草，五個人一排，總共三排往前拔，要從這邊拔到那邊。 我那時候年輕啊，天氣又熱，我恰好又是第一個，我就亂拔一通，拔得特別快，反正後面還有兩個人會拔麻，先是這樣： 後來就這樣了： 這時候，班長出現了： 班長就喊停，叫我們休息一下，這時候他特別叫我過去立正站好，不是要罵我，反而是跟我 1 on 1: 「120 啊，你有唸書啊，你是大專學歷，是不是？」 『報告班長，是。』 「我跟你說，你拔這個草啊，這樣拔也是拔啦，沒錯啦，可是，你是有唸書的人，如果你拔草的時候，能往上想三層，你這個草就會不一樣了。」 『...?』 「聽不懂齁～你看喔，你往上想一層，就是我，我這個班長會怎麼看你拔這個草，啊這個草要拔成怎樣？再往上一層，排長會怎麼看你拔這個草，要拔成怎樣？再往上一層，連長咧？他會怎麼看你拔這個草，要拔成怎樣？」 『。』 「如果你能用這個角度去看你拔的草，你拔的草就會不一樣了，我這個班長也就會很輕鬆了，我也不會定你，你日子也會比較好過。」 這個往上想三層的哲學，一直在我心中。 謝謝那個有點胖胖的、臉方方的、很愛改車的班長，但我忘記他的名字了。 XDDD 順便說一下，我們國防役，士官長好像很少出現... 我想在職場，任何角色也都是一樣，大家都是領人薪水，假如你能往上想三層，去看你的工作該怎麼做，做成怎樣，比如說，你這個 code 該怎麼寫？這個 UI 要怎麼設計，這個功能要怎麼測試等等，其實很多事情都會更清楚的。 老實說，我上面三層的連長，肯定看不到我每隻草是怎麼拔的，他只會看到最後這片連集合場有沒有雜草；同樣的，你上面三層的主管，可能不會打你的考績，但是他看到的是最後大家的東西是能夠整合出的來的，是可以拿去換錢的。而這過程中，有好多問題要解決。 如果你能把自己的視角（Perspective）提升到那個高度，你就會不一樣了 你上面三層的主管，現在遇到什麼問題，他用什麼方法解決？你，能不能跳出來幫他解決？你用的方法是 PMP? CMMI? 如果你恰好要用 scrum 來幫助他解決問題呢？ 在這個情況下，Scrum 就是功夫了，他是真刀真槍的對決，在商業的世界裡的對決，是有人會死的，是攸關生死存亡的。你不能說，因為我的存在，讓我的團隊都變得更好了...

 主管啊，你領得多，做得事情當然要成正比，開的會議也要成正比，你當然應該忙啊。 是吧？ 是嗎？ 來用 主管很忙當關鍵字 google 一下：

啊～久久寫一次，一次寫一大篇 XDD 以前我上課在講敏捷測試或是實際在帶敏捷團隊的時候，常常被問到說，Sprint 這麼短， 一個禮拜或兩個禮拜就結束了，測試跟不上啊！是的，如何用測試確保品質，是很多測試人員進入 scrum 後遇到的常見問題。 我都會用這個當例子，我的師父也是這樣教我的： 假設1. 開發人員每個 Sprint 開發 5 個 PBI。 那麼測試人員在第一個 Sprint 需要測試五個 PBI。 很直覺麻，要確保 DoD 有符合麻。還是有人覺得開發出來的東西不用測試？ 那第二個 Sprint 呢？ 開發人員仍然開發出了五個 PBI，測試人員要測幾個？ 五個嗎？錯！ 應該要測 10 個，因為測試人員需要知道第一個 Sprint 的五個 PBI 有沒有被改壞啊。所以第二個 Sprint，測試人員要測 10 個 PBI。 第三個 Sprint 呢？ 理論上要測15個。 這兩個的關係我們可以做出以下的圖： 可是一個測試人員， 在一個 Sprint 內，肯定沒辦法這樣子測啊，總有個上限吧。於是，我們做了第二個假設： 假設2. 測試人員只有一個，他每個 Sprint 只吃得下 30 個 PBI 的測試。 在假設1, 跟假設2, 的情況下，現在我們的要解決的 問題是：在第七個 Sprint 之後， 測試人員會跟不上開發的腳步。 解法呢？ 我這邊提出一些解法給各位參考： 解法一： 大聲宣佈這種迭代式的開發是不能保證品質的，然後回瀑布式開發。 大家回到瀑布式的開發，抓出測試的時程，其中包括 system integration test 以及 user acceptance test，在這兩個階段都要做回歸測試。這段測試時間的長度，取決於這一次 release 的大小或是產品的複雜程度，通常會建議是半個月到兩個月不等的時間。 這個解法的好處是真的可以確保品質，讓測試人員把關，而且管理者(比如說 PM、主管)， 可以看得到測試時期的數字，比如說測試通過率等等。 壞處當然顯而易見的是，在測試時期會花掉一些時間，導致整個 schedule 往後，實務上的經驗是，通常在前面的計劃以及開發階段花去很多時間，擠壓到測試的時間，導致測試人員的時間壓力非常的大，甚至有可能造成開發部門跟測試部門之間的對立。 解法二： 使用自動化測試 讓測試人員撰寫自動化測試，讓每一個 Sprint 完成...