.NET Walker

有一個字叫做 target fixation，這個字不常見。 我在整理舊書的時候，從書架上掉出了一本書，target fixation是我在這本書上看到的。 不知道你有沒有過一種經驗，一開始學習騎車或開車時，由於太專注在要前往的方向，結果卻直接一頭撞上你想抵達的目標。這個字，差不多就是這意思 --> 由於過於專注在目標上，導致於駕駛者不自覺的增加了撞上目標的風險。 一般來說，它用在飛行器具、車輛的駕駛上，是一個專有名詞。但這本書"飛機上的27A"，把這個字用在人生。 你曾有過，太過於專注一個目標，導致於你忘了身邊其他的事情? 如果你是程式設計師、工程師，你一定有過這樣的經驗 --> 專注解決一個棘手的問題，似乎才過沒多久，結果天都黑了(或是天都亮了)。 --> 這現象有個專有名詞，這叫心流(Flow) 心流不是很好嗎? 當我們想專注的時候，是的。 但一直心流會很好嗎? 不。 你若有機會看到沉溺於賭局中，專注在機台或牌局當中的人，那也是一種心流。但，就算贏了賭局，往往也輸了整個人生。時間過去了，就再也不會回來，有時候，路過的美景，過去了就是過去了，若是過於專注在目標上，往往會讓你錯過身邊的風景。 我記得，我把這本書送給了一個好友，因為那時候我看到他全心投入工作中，犧牲了非常多個人生活的時間。這我是過來人，過去專注在工作、寫書、做系統、上課…不知不覺，十幾年過去了，目標達成了，但想想好像也犧牲了些路上的風景。 專注於目標很棒，但千萬別忽略了身邊的人與美景。 農曆新年前的最後一天，再次給自己這個提醒。

『導入敏捷最難的是什麼?』上課時同學這麼問。 『這問題，我可是很有經驗呢。』我心裡這麼想著，然後慢慢的回答… 導入敏捷最難的是…『組織總想在其他條件都不改變的狀況下，實現敏捷轉型。』 我常說:『人人擁抱敏捷，但真實狀況是…沒人想要改變。』 你說，不會啊，我們公司常常改變! 老闆總是朝令夕改…搞的大家無所適從。 我笑著說：『是啊，那是他改變你，不是改變他自己。況且，你不是也不喜歡別人常常改你的工作模式…對吧?』 總之組織從上到下，沒人喜歡『被改變』。 所以，導入敏捷當然可以…但，不能碰KPI、不能違反ISO、不能調整考績與獎金制度、不能改變合約簽訂方式、不能變更HR既定規則、不能調整休假與簽核流程、不能違反愚蠢的勞基法規法條、不能取消既有的公司會議(不管多麼無效)、不能改變組織結構、不能拆分部門與團隊…在所有外界環境都不改變的狀況下，要我們協助導入敏捷…幹的好。 這不是『難』，這根本是『為難』。 但我得說，這才是企業轉型的真實狀況。有興趣『談』轉型的老闆很多，有膽量豁出去的可算是鳳毛麟角，除非… 『除非什麼?』學生問。 除非…那公司差不多快掛了，死馬當活馬醫，這時候老闆可能會破釜沉舟，孤注一擲。但也往往能帶來最好的成效。 這也是大家常常看到，新創和小公司比較容易導入敏捷的關係。在大概超過百人左右的組織中，即便想要在一個小部門中導入敏捷，都很容易碰到與企業規範衝突的問題。 要知道，你可是在跟整個組織既有的習慣和文化對著幹，後台不夠硬，身段不夠軟，導入到最後，往往沒能改變組織，先陣亡的會是你自己。 『那怎麼辦?』另一位學員問。 『看起來很難，但也不是沒辦法。』我說『先準備好自己，別聽到台上講的精彩，一股熱血就勇往直前。也別亂找顧問，敏捷轉型不是小事。要幫企業實踐轉型，得長時間陪著企業一步步解決問題，身為顧問，你要非常清楚每一個工具、每一個activity想達成的目的，然後幫助企業選擇最適合的方式，量身訂做，趨吉避凶。』 好啦，先上課吧。先搞懂Scrum每一個角色和活動的意義，到時…才能真的幫上企業實現轉型。

  有時候在客戶端做顧問服務，也會有意想不到的事情發生。 先衝進來的是個二十多歲的工程師，臉上的表情忿忿不平。接著走進辦公室的是年紀稍長的專案經理，從服裝可以看的出來他的個性比較沉穩。   兩人似乎沒注意到我正在和這家公司的老總(其實也是我朋友)開會，年輕工程師迫不及待的發言，接著是專案經理的辯解。 由於事出突然，老總也沒把我當外人，示意員工可以把話講完，我也就在一旁稍微聽了一陣子。爭論的內容其實稀鬆平常，專案管理中的一些需求與規格上的認知差異。但雙方你來我往，談著談著議題升級到了彼此的誠信問題，接著各種往事舊帳出爐...讓我頗為訝異的部分是，才幾分鐘的時間，雙方可以如數家珍般的，把兩人之間的恩怨情仇迅速的陳述了一輪，彷彿是在進辦公室前早已經在心裡默背好了的講稿一般，可見積怨之深... 我在旁聽了一陣子，覺得其實也沒什麼大問題，雙方的論述都有道理。而且事情發展到最後，純粹只是立場不同的差異而已。倘若是換了角色，估計彼此都能夠理解對方的做法。但麻煩的是，討論到了後面全然是意氣之爭，大家言談中似乎早已經不在乎最終的結論是什麼了，而是執著於想爭出個『對錯』，工程師覺得專案經理總是頻繁的調整工作優先順序，開會時常常推翻了上周會議中才做出的決議。專案經理則覺得自己只是反映用戶端真實碰到的問題和需求，反過來指責工程師沒能設身處地為用戶著想... 聽起來似乎先前已經為了這些問題爭論非常多次，也耗費了不少的時間。既然立場不同，也談不下去，只好跑來這裡想得到一個仲裁。 我看了老總一眼，心想他怎麼會有精神去管這種瑣事? 果不其然，他耐心聽完之後，拿我當藉口，讓兩位員工先出去，說是等和我開完會之後，再來協助解決這個爭議。 我看著兩位員工步出辦公室，問他：『你打算怎麼解決?』他笑著說：『解決? 不，那才不是我該做的事。』說著， 一邊拿起電話，看起來是撥給那個專案經理。 只聽到他跟電話的另一端說：『Eric，你年紀比較大，Samuel是你的team member，你們合作這個案子也有半年了吧。』等對方應完話，他繼續說到：『我不會介入這個問題，我希望你去解決，我只給你一句話......』頓了頓之後，他說：『小朋友愛計較是非對錯，成年人則看重利弊得失。』『你身為PM，本來就必須周旋在客戶與內部團隊之間。試著成為橋梁，而不是變成問題的一部分。至於中間的分寸，得靠自己拿捏。』說完之...

人有見識、就不輕易發怒．寬恕人的過失、便是自己的榮耀( 箴言 19:11 ) 周末，去參加中學的同學會，結束之後大夥兒散場，因為老同學住在家裡附近，理所當然的搭他的順風車回去。就在準備上交流道的路口，後方一台B開頭的名車或許不耐等候，開始閃燈喇叭齊鳴。 我看到老同學瞥了後照鏡一眼，手反打入了低速檔，我立即把剛才忘了繫的安全帶扣好，心想接下來可要精彩了。要知道當年這位同學，可是率領我們一票人夜騎九拐十八彎的領頭狼，後來買了幾台名車之後，國道競速也時有所聞，即便人到中年，估計也是寶刀未老吧。 正當我身心狀態都預備好了，卻見老同學方向盤一個拐彎，把路讓給了後方的來車，只見後方BMW引擎喇叭輪胎聲大作，從我們車旁呼嘯而過。我心想，老同學這是身經百戰之姿啊，顯然是要讓對方輸得心服口服，所以打算從後方追趕是吧? 停了兩三秒…咦? 沒有。 偷瞄了老同學一眼? 嗯? 沒有反應。 『沒準備教訓對方一下嗎? 這不像你啊~』我忍不住開口揶揄一番。 『我現在開車可是心如止水，不動如山。』他笑著回答道。 『怎麼說? 是受了甚麼教訓嗎?』我一幅幸災樂禍樣。 結婚前，我女友常跟我說:『開車時幹麼跟其他車子比快比狠，除了逞一時情緒，還有什麼意義?』我當然聽在耳裡，沒放在心裡。 後來，有一年夏天，颱風剛過，路上很多被風吹倒的樹枝，當天急著要到公司，路還不很好走，開著開著，後面一台車也像是剛才那樣又是喇叭又是閃燈，我看了當然火大，立馬緊急煞車，停下來準備跟對方理論。 下車才走沒幾步，後方駕駛還沒來得及反應，我就發現他猛按喇叭的原因了… 原來我後保險桿勾到了一大串將近半個車身長的樹枝，顯然是被颱風吹斷的，似乎被我車子拖著跑了好一陣子。我一看當下沒了情緒，先把樹枝給拉開，然後跟對方駕駛打了個道謝的手勢。(原來後面的駕駛還是一位老太太) 回到車上，我一邊開車一邊思考，我想到的不是誤會了對方覺得不好意思(當然也有)，而是，我發現原來人的情緒可以變化的那麼快，前一秒鐘我還想下車理論個輸贏，但下一秒後我立刻沒了情緒，為何會有這差別? 我意識到，其實是我對事情的『認知』造成的。 我沒看到部分的事實(樹枝纏在保險桿上)，但卻看到了對方駕駛按喇叭和閃燈(這也是事實)，我自己把這行為 解釋成對方很不禮貌 ，就是要跟我輸贏。因為我這樣理解這件事，所以導致自己心情不好，衝動到下車打算講個道理，甚至...

凡事都可行，但不都有益處：凡事都可行，但不都造就人。(林前 10:23) 前陣子有位好友特別到我辦公室，跟我討論他最近想要做的某個軟體產品。他知道我過去這幾年有非常多產品開發(我想估計是失敗的)經驗，所以他說想跟我請益一番。 一如既往，只要人到了我辦公室，我肯定熱情接待、滔滔不絕、知無不言。談過了他的想法與企圖，也給了一些建議，茶過三巡，我也就不客氣地分享了我最近想做的另一個資訊服務，話還沒講完，他拍案大讚，說到：『David你這個案子會成，要不要做? 我有興趣。』 他的熱情讓我愣了一下，我有點猶豫地說，我還在思考一些問題，像是…為什麼我目前沒看到市場上有類似的服務? 台灣那家知名的網路商城P公司，該是最有資格做這個案子的，不管是倉儲、物流、和我這個案子最關鍵的庫存品，都一應俱全，我不太懂他們為什麼不做? 朋友說了一句話：『P公司太大了，他們什麼都能做。什麼都能做，就代表什麼都做不了。』 他話才說完，我就明白了。 (有時候跟頻道接近的朋友聊天就是有意思，話不用講太多，彼此一點就懂。) 我明白了朋友說的意思，但也看到了我自己的限制。 這一直以來是我的問題，我意識到這個問題，但卻始終沒有去面對。 前陣子流行『斜槓青年』，你可以在網路上找到這個字的意思。但我慢慢發現自己實在斜槓太多的領域了(而且也不是青年了)。過去這幾年，我寫書(手上正在寫一本)，做企業顧問(目前一家進行中，一家洽談中)，同時也帶人做軟體專案(目前三個案子進行中，好在差不多都是結案階段了)，我也喜歡上課(下個月開始預計有兩個排定的課程)，另外每周我給自己的目標是產出三到五篇的貼文、blog文章和數個教學影片檔，為了提供給線上課程和電子書… 然後，我還一直很想做產品。 雖然盡全力把每一個手上的任務做好，但很明顯的，我發現瓶頸在哪裡了。的確，瓶頸就在自己身上。 問題來了，我要割捨掉哪一塊? 我太明白多工與多重目標所帶來的陷阱和限制。回頭翻自己的貼文，還有底下這兩張照片呢： 但怎麼當要去面對這些問題的時候，自己也變得難以割捨了? 管理方法的道理和邏輯永遠是那麼鮮明，但執行的困難卻往往不是不懂這些，而是在情感上的拉扯和限制。 剛開始工作的第一年我就發現，除非自己選擇放下，否則手上的工作 永遠 不會有作完的那一天的。而當人(企業)能做的事情看似愈來愈多，就愈是得克制每一件事情(每一個目標)都想去做的衝動。 我記得從...

你一定看過底下這張圖，對吧。我得先說，這可能不是一篇政治正確的文章... 但我還是歡迎大家補充自己的看法... 有次上課時，有位擔任主管的學員在課程休息時間問我：『到底DevOps能對公司帶來什麼價值?(翻成白話就是…它真的有用嗎?)』這問題看起來不難回答，我腦袋裡立刻蹦出一堆答案，但…我要如何在30秒到1分鐘的時間內，讓學員有個本質上的概念呢? 前陣子我一直在思考這個問題，剛好這時候，我在FB上看到朋友貼來的一張圖，我猜你肯定也看過。 後來這張圖還出現了好幾個版本，基本上目的都一樣，就是揶揄客戶的不講理。也的確，這世界上沒有白吃的午餐，軟體開發和商業設計很像，同時要快、要好、又要便宜，天底下哪有這種好事? 正當我也想轉貼出去的時候，突然轉念一想，難道真的沒有可能讓成品的交付 又快、又好、又便宜 ? 如果有呢? 那實現出這個成果的企業，豈不是能夠領先其他競爭者一大截? 而且，如果這件事那麼不合理，為何幾乎每一個客戶都這麼要求呢? 甚至包含我自己。 前陣子我在印製一批教材的時候，我對印刷廠的要求似乎也是這麼的『不合理』，我希望它印製成本要低、品質當然不能拙劣、關鍵在於速度，由於訓練課程即將開始，我希望三天內可以完成…，回頭一想，我自己不就是那個傳說中的奧客嗎? 結果呢? 結果印刷廠還真的完成了(使命必達!)。不是應該不存在嗎? 為何印刷廠實現了這件事呢? 我不知道他們怎麼做到的，但我回想最近這十年印製教材的經驗，我發現，比起十年前，現在確實是又快、又便宜、品質也好上了一大截。是怎麼回事? 如何讓理當『不存在』的事情發生的? 這部份就不難理解了，我想是因為『產業升級』。最近這十年客製化小量印刷的技術不斷更迭(當然也是拜IT技術所賜)，許多只有一兩個員工的小印製店，靠著電腦和幾台印刷設備，就可以印製出媲美印刷大廠的成品品質，印製時間和成本還來的更低。 產業升級 ，讓過去被視為 不存在 的交集點發生了。 而DevOps根本就是軟體開發領域在最近十年中最大的『產業升級』。在DevOps中我們強調頻繁交付(速度要快)、我們強調程式碼自動測試、在CI/CD Pipeline中的系統安全弱點掃描(品質要好)、我們強調減少浪費、讓開發成本有機會可以降低(要便宜)，我們不正就是在實現過去認為不可能的事情嗎? 面對全球化的競爭，許多廠商正在改變，改變的不只是觀念思維，也包含開發方法、技術...

還記得我在研討會常講的那個故事嗎? 某次我老闆急著趕去會場，由於正在準備接下來會議的主講內容，手上拿著稿件低頭攔車，因為快要遲到，他跳上計程車後情急地說：『快…開快點。』卻忘了計程車駕駛壓根不是平時幫他駕車的司機，根本不可能知道他要去哪。 只見計程車司機二話不說猛踩油門車子狂飆了三個路口之後，我老闆才想到似乎有點不對，問計程車司機說：『我剛有跟你說要去哪嗎?』 司機驕傲地回答：『沒有，不過，我確實有開的很快，對吧?』 最近開始認真讀那本暢銷的OKR(先前是有看過一些介紹文章，但只能大致掌握基本概念)，不過讀著讀著又開始覺得，近代幾乎每一本實用的管理書籍，都曾在書中以不同的姿態告訴你 目標 有多重要，而『認真地』訂出目標幾乎是一切管理的根本。 不管是 柯維 的 與成功有約 系列、 高德拉特 的 目標 系列、最近我很喜歡的『執行力的修練』、管理大師 杜拉克 的演講或著作、坊間流行的KPI和OKR...每一種方法論其實都在跟我們說同一件事情... 『若你沒有認真的訂出目標，就什麼都別談。』 這個道理其實大家都懂，但環顧身邊，有認真訂出目標的人似乎還真的不多。 的確，我們每個人或多或少都有(過)目標，但我們面對自己的目標到底有多認真呢? 我依稀還記得20多年前我的管理學老師在課堂上說：『你絕對可以實現任何 (他強調任何) 你想實現的目標，只要你「現在」把它寫在紙上。』他說『關鍵不在於你訂的目標有多麼大，而是你到底有多認真，你到底有渴望實現這個目標，願意為它附上多大代價...』 當然，那天全班沒人理會他說的話，當下我甚至有點懷疑他自己到底相不相信自己現在在說什麼? 20多年後，我唯一後悔的是當時寫下的目標太小。 當年他說，有一個非常簡單的指標，能夠衡量出你對這個目標有多認真。 不，不是你有多慎重的把它記錄在高價的筆記本上，也不是你每天把它拿出來膜拜的次數有多少。而是…你身邊和你最親近的人當中(朋友、家人、同學同事...)，有多少人知道你的目標? 有多少人能在不需要提示的狀況下，就能清楚的說出你訂的目標，這些人愈多，你的目標實現的可能性愈大...，如果你身邊還沒有這樣的人，從今天開始，把你的目標寫在紙上，貼在你的書桌前、房門口、座位上…讓每一個你身邊的人，都知道你的目標是什麼… 不知道為什麼，他當年說的每一句話，我至今還記得相當清楚... 20...

今天在改一個以前自己寫的系統。 愈改愈覺得，當初怎麼會這樣設計的? 很多寫法實在看不下去，只好重構一番，把過去的一些設計和架構做些調整和改善。我猜，只要你是職業(不需要是專業)的開發者，肯定也曾有過這樣的經驗。 我們常常覺得過去的東西似乎還有可以改善的空間，所以，系統就這樣在修修補補之中度日。 曾經我覺得這樣子不行，所以花了一些時間認真學習各種pattern、架構設計、框架開發...等知識技能，想說從此之後，應該能高枕無憂，在開發時做出比較能夠長治久安的設計。 結果呢? 跟你猜的一樣，並沒有。系統還是在修修補補中度日。這到底是為什麼? 幾年之後我知道，原因很簡單，因為環境在變，技術在變，需求在變，我們活在一個多變的真實世界，然而我們能控制、能掌握的變數實在太少，少到所有的預先規劃和設計最後看起來都變得可笑。 所以，敏捷(Agile)不相信計畫(Plan)，甚至誇張一點說，敏捷不相信有完美的預先設計(Design)。 但注意，這不是完全不要設計，而是，不管當時看起來怎麼完美的設計，你都要有這個心理認知--『 日後它一定會變得不完美 』。不管你做了什麼樣精細的計畫(Plan)你都要知道，這計畫未來一定會走歪，只要你是活在一個充滿變數與未知的真實世界中。 你不相信? 或許你會問，那為何過去的年代，計畫似乎是有用的，甚至有人手上可以有好幾套劇本，事情的走向總是被掌握在足智多謀、細心計畫的智者手中? 那是因為過去的時代沒有現今的科技與技術，資訊的傳遞也不像現在這麼迅速，當時的世界給了人們一個假象，讓人誤以為自己可以掌握些什麼，能夠控制些什麼，能夠讓事情的走向依照計畫，或是運籌在股掌之間。 也確實，當你手上的資源越多、運算能力越強大，面對的問題越簡單、變數越少、時間越短，那預測和掌握未來的可能性不是不存在。 反之，當你手上的資源越少、變數越多、你就會發現對未來的掌握度趨近於零，事事依照計畫走的可能性根本不存在。 所以我們乾脆不要計劃了? 開發時也不用做任何架構設計? 對，也不對。 對的是這個想法，預先計畫和預先設計並不可靠，這意味著你不能完全倚賴它。 不對的是這個行為，你不能完全不做任何計劃或設計，你只是不該再像是以前那樣鉅細靡遺地去設計，並要求所有人照著劇本走，期待規劃好了就不會再改變。 會不會很矛盾? 對我來說完全不會，因為這就是人生。 ...

做軟體開發很多年之後，常碰到有人問我，軟體公司是怎麼估算一套軟體的價格的? 用開發的人天數來算嗎? No, No, No…『人天數』是一個非常標準的 錯誤答案 。 如果你是軟體開發商，軟體開發的『人天數』可能是你的成本，但絕對不會是報價/售價。 那報價/售價怎麼定呢? 讓我先問一個問題... 對於買方來說，什麼叫做『買貴了一套軟體』? 或者反過來問，什麼叫做『買了一套划算的軟體』? 不好回答? 想一想底下的例子... 如果軟體開發商花5個人月為買方(你的公司)客製化開發了一套系統，然後賣你500萬，對你來說，這貴不貴? 其實我們不知道。因為貴不貴是相對於這套軟體能為你帶來多少價值而定的? (而非開發商花了多少時間) 如果你花了500萬，系統上線後，能每個月為你帶來50萬的效益，那我覺得這500萬算很值了。但...如果系統上線了，一年後都沒法為你帶回幾十萬的效益，甚至還讓你虧錢(請相信我，類似上線後還虧/花大錢的案例你在資訊界隨便問都一票)，那不管這套軟體廠商是花十幾上百個月，對你來說這套系統都是買貴了，一點都不划算，應該說，這軟體一點意義都沒有。 如果你同意這個思維，大概就能理解，軟體開發的報價不該是用人天來算，況且，一個軟體開發高手跟一個會寫程式的菜鳥初學者，兩個人『一天』的產出差異恐怕可以達十倍以上，但你有看過人天報價level差異化到十倍的水準嗎?應該從來沒有吧。 那有沒有覺得很奇怪，如果軟體不該用人天來計價，那為何打從你第一天進到這個產業，一直到今天，都還是會常常聽到人月或人天這個計價單位呢?   有一種可能是，我們其實不怎麼知道(不會、不敢、或不願)去評估一套軟體系統的『價值(Value)』。 很難理解? 其實這就如同大部分的公司其實很難評估一個員工的產值一樣。 若當公司不知道該怎麼(或不願意)去衡量員工的產值時，往往就只好拿 其他看起來很公平客觀的數字 (例如出席狀況和上班工時)來決定員工的價值了。而這正是一種非常古老落後且糟糕的方式。 久而久之，當員工養成習慣用『在辦公室出現的時數』，甚至是加班時數、配合度…來彰顯自己價值時，其實也多半意味著，手上根本沒有一張漂亮的成績單，漂亮到可以拿出來凸顯自己的存在對公司的意義。常常有人說，準時上下班是最基本的，這話一體兩面，準時出現在辦公室確實真的就只是『最基本的』。 時代變化的很...

2019/1/26 敏捷思維、敏捷人生 之一 從敏捷的角度看這個世界是很有趣的。 年紀越大，越覺得在這個變動的時代中，計畫導向的人生原來根本不存在，小時候聽過很多傳記故事，描述某人從小立志如何如何，因為這個遠大的志向，少年時開始磨練自己，按部就班實現每一個計劃，然後一步步走向成功... 後來才發現，原來這些傳記故事大多是虛構，或是作者事後諸葛的加油添醋。真實世界中才沒那麼容易『按部就班』，意外總是比計畫來的擾亂人心。有心理學家說，成功者喜歡把事情合理化，認為自己的成就源自於規劃好有計畫的努力。然而，這世界上更努力的大有人在，常常只是運氣沒那麼好而已。 所以運氣比努力重要? 錯，千萬別誤會了。 事實是，未來很難計畫，我們沒有人知道明天會怎樣，先見之明往往只是事後諸葛。人生當中唯一能做的，就是努力過好每一天，至於其他的，交給上帝。 『被討厭的勇氣』書中描述阿德勒的價值觀，他認為過去已經消失，而未來則根本『不存在』，你真正擁有的，其實只有今天而已。為了過去懊悔沒有意義，為了未來擔憂不切實際，唯一有價值的，是拼命把你的今天過好。 『 我們唯一擁有的，就只有今天而已。 』這是多麼敏捷的思維啊。(居然出自百年前的思想家) 永遠聚焦在當下這個sprint，每一天，每一周...累積出每一個小小的Win(這不就是潛在可交付產品增量嘛!)，然後，你就有機會活出一個精采的人生。 過去失敗的sprint無須留戀，每個月給自己幾小時retrospective很夠了，然後move on。太遠的未來遙不可及，過多的計畫或擔心離目標越來越遠，只是折磨自己。 唯一不可放棄的是 現在 ，還在衝刺的你，必須專注在這個Sprint，只要你能過好每一天，對得起當前這一刻的自己，未來的人生也不會對不起你。 原來真正決定你人生的，不是計畫，不是機運，是活在當下這個Sprint的自己... ------- 註1: 在Scrum軟體開發方法論中，Sprint指的是一個迭代(iteration) 註2: 潛在可交付產品增量(potentially shippable product increment) 後記： 和大家討論Scrum、Agile、DevOps時，許多人常會提到幾位作者知名的著作，像是目標系列的高...