在一個巨型的 Git Repo 當中，底下依專案分了許多專案資料夾，
參考下圖。
而今天發生了一件事情，我需要更新某幾個子專案的 POCO 的 .tt 檔，
這裡不說明 POCO 是什麼；簡單的說，有的專案會有 .tt 檔，
有的專案會沒有，而每個專案的資料夾結構又不一定相同，
所以要找出這些 .tt 是有點麻煩的，另外我的目標並不是 .tt 檔，
而是所在的專案，再用 IDE 開啟進行修改，
為此我需要列出專案資料夾
用 Command Line 取得 Repo 資料夾內包含.tt 檔案的專案資料夾名稱
1 | D:\Repo\Taiwan\******.******.Repofolder |
1 | Name |
總覺得寫得有點又臭又長，希望有更好的作法可以提供給我，
不限於 powershell 就算是 Linux 的語法也可以讓我參考一下。
(fin)
Visual Studio 的 Test Explorer 在跑測試，
如果遇到失敗，會直接中斷，
比如說有 2000 個測試案例 跑到第 1300 個時測試失敗就會中斷
剩下的 700 個案例會不執行直接略過。
並不是一跑到錯誤就會中斷測試，而是跑了 3 個失敗後中斷測試，
另外執行的測試專案，是使用 SpecRun.Runner 撰寫 Cucumber 語法跑 BDD 測試。
當使用測試專案使用 SpecRun.Runner，預設 stopAfterFailures 是 3，
所以 3 個失敗就會略過。
正常的測試都是會全跑完的。因為 Test Framework 標示 Test Method 的部份，
都是幫你內建 Try/Catch 攔下所有 Exception 的。
MsTest 的 [TestMethod] 或是 NUnit 的[Test](XUnit 是 [Fact])，其實就是層 Wrapper
你在方法裡面寫的內容，只要有引發 Exception 的例外，
都會被這層 Wrapper 攔下來，轉成測試結果的內容。
測試專案根目錄應該有一份 Default.srprofile 檔，如下
將 stopAfterFailures 調整至適當的值(ex:500)，將會顯示所有失敗測試。
本案例開啟後，實際失敗的測試有 37 個
1 | <Execution stopAfterFailures="3" testThreadCount="1" testSchedulingMode="Sequential" /> |
特別感謝 91、Green、余小章的協助
(fin)
記得設定 TimeBox
Scrum 是經驗法則，可以拿已經作過投點的 Item 作為比較基準。
如果有未知與風險，當下不要過度鑽入細節。
你可以
決議與會議之外。先讓人看見問題與目標，與可能的方向。
SM 應該更關注決定的過程，而非決定的本身。
O↓ 事實(每個人看到的都不一樣)
↑R 感受(相同的事實不同的人不同的感受) → 往複 OR ，取得共識(有共識才透明)
Interpretive 意義與價值觀
Decisional 決定
看情境
Agile 適合應付變化，而目前的世界變化很大。
不要為了 Scrum 而 Scrum 。
那樣會變成盲從，看見你的需要，務實的變革。
找到核心的問題，然後問 「怎麼作 ?」
學員回答後，老師常常會說「這是一個方法」，然後給予回饋。
這句話的潛台詞是「還有其它的方法」。
Scrum 對團隊的要求其實蠻高的，
但是我們不需要端到端的工程師，而是團隊。
巴士因子可以是個判斷指標。
另外限制理論[求補充]告訴我們瓶頸會跑來跑去，所以要持續觀注與改善。
這個點數的增長不合理，而且還是以時數點數，
沒有任何東西可以讓一天變成 48 小時(喔…有人說，加班可以讓 8 小時變 16 小時)
持續觀注，如果失敗了就讓它失敗吧…
但是要失敗的有意義。
11/23 團隊作的工作量實際上達到 254/3xx (Commit 3xx，完成 254。)，
sprint 是成功的，但是 Velocity 是失準的。
小心得:
- 所謂的 Commit 如果不是對自已 Commit 起不了激勵作用,
如果 Team 與 PO 不認為「我們是一個 Team」，而還是分 PMO 與 R&D
那麼 Commit 就會變成畫押背鍋的儀式。- 氣象報告失準怎麼辦，颱風沒來大家都開心嗎？(從 100→254，是效率大爆發，還是浮報點數了？)
正視真正的問題是「你沒有 PO」
現實中有遇到類似的狀況，
執行的當下會列出所有的優缺點，再作選擇。
作完之後問自已，再作一次你會怎麼選擇 ?
在 DoD 應該可以解決這個問題，如果現況不會有問題，為什麼要作?
先作 Task 有列出來東西我覺得基本上是對的。
SM 的問題是「認為該作，但是沒有技術 Know How 所以不知道該列什麼?」
那還沒有跑 Scrum 前如何評量這個項目的效果呢?
至少在 Scrum 中我認為可以透過 Velocity 作為指標。
也可以透過 DoD 決定品質的程度(ex:)。
另外，重構不是重作，
重構應該是時時發生的，寫測試可以讓這件事被量化，
難以測試的代碼本身就有一定的壞味道(工程實踐與遇到的困難就以後再寫了…)。
在 Scrum 中,
PO 觀注 Why ,觀注產品價值 ,觀注市場與策略
Team 可以決定怎麼作，與 PO 討論理解為什麼要這麼作，
並不是所謂的「需求來就作」，而把 PMO 的角色拿掉，
是為了減少隔閤，讓團隊更接近商務端。
聽起來這個情境，Team 與 PO 仍有抗拒心理…
Team(1+1+1+1…) x SM (0.9 or 1.1) = 生產力
讓 SM 成為乘數，而不要成為加數
小地雷:如果乘數小於 1(如何評量 SM 指數?)
業務/老闆會說，我才不管什麼開發方法，
作出來就好了(黑貓白貓能抓老鼠就是好貓…)
很務實，但是很傷害團隊…，不要有機會讓團隊聽到這種話
(fin)
情境
團隊反應沒有時間 Code Review / 寫 Unit Test，
Pair Programming 隨你便，上級的反應說「有，最好」結果，「都沒有」
心態致勝? 還是自以為勝 ？
成就感從何而來 ?
受雇階極一定要被激勵才能作好事嗎 ?
雇主與雇員的本質上的不同
當會議吃掉了所有的時間…
你很重要，Why ？ What ？ How ？ 或只是暗示你 TTL(Time to leave)
planning for all day half day
CSM 心得第二篇寫到 Sprint Backlog , 越寫看到越多實踐「怪怪的」地方…
Team sol:
為什麼無法跟團隊成員說明自已的想法，原因還是出自於不信任？
每個人（含主管）在面對什麼？ 或許知道了也幫不上…
還有「主管」這種思維，不是一種文化不敏捷的味道；
表示著你還需要被管理，才知道該作什麼。
L●●:整合線上線下讓客戶更容易銷售產品，消費者有更好體驗
A●● 等 3 人:賺錢 x3
T●●:作出讓客戶達到業績的產品
A●●:改善現有線上電商的使用環境與體驗
R●●:開發良好的軟體改善客戶與使用者的體驗
小結:第一時間大部份是賺錢，或是不知道。少數第一時間說出來的，
又各不相同，每個人的目標不同，真的能有「使命感」？真的會有「成就感」？
沒有共識，何來透明？
（fin)
補充
我在 C 社是下午 5:30 執行 Daily Scrum，在 N 社是早上 10:30。
個人比較喜歡 C 社的作法，但有可能是被制約了，因為那是我第一個跑 Scrum 的團隊。
主觀的比較一下優缺點
| 優點 | 缺點 | |
|---|---|---|
| 下午執行的 | 站立完就可以下班了。 | 站立講不清楚就會拖到下班，人性會選擇甘脆不講。 |
| 一早來就可以根據昨天的站立進行開發。 | 第二天一來忘了昨天說什麼了啦 | |
| 上午執行的 | 站完就可以開始一天的工作。 | 10:30 站立就會有人 10:30 才進公司，提早來反而沒人問(但是安靜) |
| 剛站完比較不會忘 | 如果有會後討論，一不小心就中午了呢(一 ω 一) |
「每個人的觀點都是對的；但不完全是對的。」
上面這句話，要兩句同時看才完整。
盲人摸象的啟示，沒有人錯；但組合起來就不是大象。
不論那隻大象是你的團隊、組織、公司或是這個社會。
專案開始之初，首重看見全貌。看見全貌之後，確認自己在哪裡! — Ruddy Lee(李智樺) N 社敏捷教練
幸福的秘密,就是去欣賞世界上所有的奇特景觀,但不要忘記了湯匙裡的油。 — 牧羊少年奇幻之旅
為什麼 Scrum 的設計上只有一個 PO ，這讓下決定變得簡單；但實務上這件事不容易。
在 C 社期間與 Boss 的距離較短(公司規模小)， 但是 Boss 也是喜歡透過一個 PM 來作代理人，在 N 社公司規模更大，PMO 基本上是個巨型團隊，即使是 PO 仍需要與其它部門確認、核可、討論才能決定。不論大小，在工作實務上仍然像個 PM 或是窗口與代理人。
好的 Product Backlog ，可以協助團隊 Refinement
User Story 的目的是用來達溝通的，
溝通最大的目的在於分享觀點與學習，不要僅僅流於形式。實務上 Refinement 隨時會發生，關鍵的成員討論並決策。
而且不難實現，隨時 Refinement 是第一線的開發人員很自然的思維與生態。
PO 在場的話更好，但是不是必要的。特別要記得設定 Time Box，避免討論多與實踐。
這裡有關一些 User Story Mapping 的東西，我不清楚故不作說明，未來再作補充。
我們可以把 Y 軸的分群當作一個一個 Feature，很明顯我們不需要把每件事作到 100% ，那樣太慢而且沒有意義。
我們應該先完成 X 軸最上方一列的 Items ，要儘可能的簡單，
完成一個完整可動的骨架。
它的圖形會如下；
它不代表要被交付，它只完成了一個最簡單的閉環，能提供最基本的回饋(不需來自真正的客戶)。
當完成了 Walking Skeleton ，在這個基礎上我們可以填加其它的增量，應該在前 1~2 Sprint 就完成它。
Scrum Master 應該與 PO 一起找到 Walking Skeleton，在一個 Release 前 1/3 的時間就應該完成 Walking Skeleton。未必要 Release 它，因為它很可能是相當粗糙的，但是儘早完成可以幫助團隊降低風險，而且完成後 Value 的選擇將可視化，同時也完成了基本的 Architecture 。
當然所有部份都不完整，但是可以隨著時間逐漸完成。有些項目我們可能永遠不會作，因為不符成本。另外如果一個完整的 Walking Skeleton 無法在一個 Sprint 裡完成，請選擇 Risk 高的優先作。
對每個 Item 估點數，請參考 Planning 的部份；但是點數對客戶與老闆其實沒有辦法理解，最重要轉換成時間。關鍵還是 Velocity ，這是團隊的戰鬥力，假設總共的點數估計為 50 點，團隊每個 Sprint 可以完成 10 點，團隊就需要 5 個 Sprint，以一個 Sprint 2 周來算，這樣就可以向客戶或老闆承諾 10 周的時間。
這裡的例子有點不懂，正常的 Scrum 估時只會專注在一個 Sprint，而 Product Back Log 如果沒有被估點的話，如何換算成點數？更如何向客戶或老闆提供這樣的數據？
估時很適用 Fibonacci 數列，F: 1、2、3、5 、8、13、21、…，很多的工具都有提供，主要以相對大小來比較對一件事情的看法。此外，不要因此被工具限制住了，比如說團隊無法在 8 跟 13 之間，就選擇個中間值吧，「?」也是一張重要的牌，這代表未知、混沌與風險。可以在所有的 Item 中挑選一個的當作基礎，每比較完一個項目，也再次作為比較基礎。「40」、「100」這樣的大牌也有其意義，這意味著 Item 過大，可以再作分解。
較成熟的團隊，也可以拿過去曾經估計過的 Items 作為一組「Reference Pool」，通常不需要估到很精準。
這樣的估計方法，需求的 Items 類型是不是需要很穩定 ？舉例來說，我們的產品如果包含 App、Web 與 Desktop ，團隊成員的 Skill Set 又很小，某些類型的工作只能由少數人開發，隨著 Sprint 有時候需要作 App、有時候需要作 Web；有時候兩者都需要作，這樣的估時算穩定嗎 ？
這是不是表示說 Scrum Team 所需要的團隊組成其實很高？又或是我需要將產品拆成 App、Web 不過這樣不就又回到 Component Team 了 ？那在導入 Scrum 的初期，人員的挑選要找通材，或是學習能力極強的人？
The perfect is the enemy of the good
Task 也可以應用 Walking Skeleton 的方式切割，儘早讓整合測試發生，不用一步到位。如果有外部相依，可以考慮先用 Stubbing 的方式隔開，這可能會讓「整合測試」不完整 。
用 Walking Skeleton 的方式開發，QA 會反映沒有什麼好測試的，Sprint 的初期 QA 都在寫測項，等待 RD 完成開發，最後幾天拼命測試。如果先開發 Walking Skeleton QA 會反應這樣的測試並不完整？而 PO 會反應這樣的東西沒有商業價值。
(fin)
雖然實施部分的 Scrum 是可能的，但結果並不是 Scrum。Scrum，
只有在完整的時候才會存在，也才能有效的成為其他技巧、方法論、和實務發揮的運作舞臺。
— Scrum Guide 結語**
有 Size (大、中、小) 或點數(Story Point、Planning Poker)等方法，
實務上都使用點數較多，原因是多個項目的加總，在比較時點數較有感覺。
參考下例：
Sprint 1 有 4 個 Item，Size 是分別是大、大、中、小。點數分別是 13、13、5、2。
Sprint 2 有 5 個 Item，Size 是分別是大、中、中、中、小。點數分別是 13、8、8、5、1。
| Sprint | Size | 點數 |
|---|---|---|
| Sprint 1 | 2 大、1 中、1 小 | 13+13+5+2 = 33 |
| Sprint 2 | 1 大、3 中、1 小 | 13+8+8+5+1 = 35 |
Velocity-Driven 或 Commitment-Driven 哪個比較好呢？
大多數的 Scrum Master 恐怕會跟你說團隊決定。
兩者的差異點在哪裡呢 ？ Scrum 是立基於經驗導向的流程控制理論
Velocity 有數據佐証，較為客觀；但是 Team members 與 Backlog Item 其實都是會變動的(理想上當然是穩定更好)，
如果 PO 與 Team 的互信足夠， Commitment 其實也可以符合經驗導向，比如說：「 我的 Develop Team 平均每個 Sprint 裡面可以交付 90% 的 Item。」
換句話說還是團隊決定，但是彈性是很大的，或許 Develop Team 有信心時使用 Commitment ，而團隊缺乏信心時或許可以用過往的 Velocity 作為標準。
這是用來估計而非報告，不要混為一談；Scrum 在乎的是結果，而非時間。
只管相對大小，ex: Task A 與 Task B，由 Alice 與 Bob 領走可能會如下呈現
Sprint Backlog
Tasks to turn product backlog into working product functionality.
Tasks are estimated in hours , usually 1-8 .
Team with more than 8 hours are broken down later .
Team members sign up for tasks , they aren’t assigned .
Estimated work remaining is updated daily .
Any team member can add, delete or change the Sprint Backlog work for the Sprint emerges
If work unclear, define a Sprint Backlog with a larger amount of time break it down later .
Update work remaining as more is known, as items are worked
PO 在 Sprint 中一直塞東西是不是一種不信任團隊的壞味道？
Team 毫無反應，就只是個接 Task 的 Team 是不是也是一種不信任？
我對 OKR 與 Sprint Goal 的認知。
不難理解為什麼 RD 會覺得干我屁事，又沒加薪也沒獎金，。
看了兩本書、用口說說就能讓人激勵人心太不且實際了
比如說：作功德，最後反而會讓第一線人當成幹話，幹話聽多了失去信任就更糟糕了。
適當的領取 Item，過多的 Item 進去，只會在 Sprint 結束時，有一堆半成品。
而半成品在面對(市場)變化，失去產品的彈性。
軟體(代碼)的優化與重構只作一半，算不算是半成品？
軟體隨著架構或相依的套件升級或補丁，在 Sprint 期間通常會有必要升級或是改變寫法。
最後就變成下圖，擁有各種版本的 Code Base。
這會拖慢開發速度，讓新進成員難以理解，也難以用 Code Review 或自動化 Tool 解決，
目前比較理想的解法是 Pair-Programming 與時時重構。可是，PO 願意花費這個時間去調整嗎？
可以用 Veloctiy 變低當作參考嗎？Veloctiy 變低的原因有很多種。
又或者由 Team 自行決定？
Team 要能自組織要多久時間呢 ？「不是拿掉主管，團隊就能自組織」;
如果是跨 Team 共同開發的產品又該如何？
Arch 的調整需要更其它或上層的團隊允可(這也會占用不少時間)
把產品拆掉變成多個服務？讓團隊成為服務 Owner ？
拆成服務又需要多久時間呢？
組織架構調整？當對 PO 來說，這是沒有商業價值的事。，實務上該怎麼作？或該怎麼量化呢？
註記：或許這只是個過度理想化的偽議題，畢竟「凡存在，必合理」。
(fin)
如下，請忽略文字
上圖使用 Item 作為 y 軸單位 ，下圖使用 Task 作為 y 軸單位，
上圖直到最後一天，才瞬間完成所有 Item ，我稱之為跳崖式
下圖是在 Sprint 的過程中，Task 增加了，有可能是亂入也有可能是建立 Task 時不準確，我稱之為登山式。
上圖的例子還算是樂觀的，畢竟最後 Sprint 都完成了，實務上更多是 Sprint Failed 。
我在 C 公司時是使用 Task ， N 公司是使用 Item ，在 N 公司與 Scrum Master 討論都建議使用 Item 繪製，
最主要立論都在於 Item 才有價值，而 Task 只細部的工作項而已。但對於我的角色而言(Team Member)，
能看見 Task 起伏很重要，往上爬待表 Task 變多了，可能的原因有插件、未預期的項目等…，可以作。一個大原則， PO 看 Item，Team 看 Task。
Product Backlog 使用 Item 沒有問題，因為是 PO 在看的。
Sprint Backlog 可以兩種都用，Task 燃盡圖可以看見 Task 的增加，或許使用 Kanban 就足夠了。重點是，看見後要作什麼 ？
如上圖右下，在 Scrum 的角色中，PO 觀注 WHY & WHAT ； Team 觀注 WHAT & HOW ； 而 Scrum Master 觀注的點
上圖中間的部份，則是我個人猜想，世界上大部份事情都可以被拆成 3+1；
恰巧這個 Context 符合我的猜想，就是市場、產品、錢，那個 1 我沒想到就順手先畫了下來。
PO 觀注產品，目的要儘快的丟到市場去作測試，而達到盈利(錢)的目標。所以他要思考市場反應背後的原因(WHY)，
設想策略，提供產品(WHAT)，最後才會 Break Down 成一個個 Product Log 再進到 Scrum 的循環之中，
當團隊成功的交付了可發佈的產品，PO 才有了武器去市場作戰，才有機會取得回饋。
如果你有杰出的工程團隊、最好的開發工具、運用正確的工程實踐(TDD、Code Review、Pair Programming etc…)、、
對 Business Domain 與 Tech Domain 有深入理解 ,開發時不受干擾，並且擁有足夠的資源
太理想了嗎 ？
- 在現實的考量中如何堅持開發者的良好實踐？
- 在缺乏實踐的環境如何導入？
- 在缺乏經驗的情況下如何學習 ？
- 在焦油坑中如何實踐 ？
- 你有說「不」的勇氣嗎？
回過頭來，如何定義完成，在 Scrum 的框架中對完成保留了很大的空間，PO 與 Team 的角度可能不儘相同，
所以由團隊來定義，模糊的空間很大。
同樣的定義用來指導開發團隊，讓團隊知道在短衝計劃會議中可以選擇多少產品待辦事項。
每一個短衝的目的是交付潛在可發佈的功能增量，而這些功能符合 Scrum 團隊目前對 「完成」之定義。
由 PO 主導的 DoD 會由商務與 PO 個人績效導向(如果有的話)，而工程上的重要實踐往往會被犧牲，
一方面是團隊成員對專業的堅持度不夠，一方面或許整體公司的開發文化就是如此。這些事項是不是該落入 Task 之中 呢？
- Retro 後產生的 Action Item
- 教育訓練
UnDone 的工作項目有很多，這意味著半成品(浪費)。
Undone 的項目可是五花八門包羅萬像的，技術債、文件製作、修復錯誤等…，只要不符合完成的定義，是不是都算 Undone 呢 ？
但是有的時候的 Sprint Goal 是需要欠下一些債的，這中間是一個取捨與權衡的，所以記得保持透明；
你或許需要一個 Undone Sprint 來消弭這些 Undone Task。
注意 Undone 是會影響開發速率的，在 Scrum 之中開發速率應該是個關鍵指標，
不論你用 KPI、MBO 或 OKR 都應該觀注這個指標。
而速率是由經驗法則測得。當然有時為了快速交付，有些暫解是在所難免，要小心LeBlanc’s Law，
這些債務除了團隊反應之外，更可以透過觀察速率指標，評估適當的時機消除與改善。
在 Time、Cost 與 Scope 都被鎖死的情況下，結果往往是犧牲了品質。舉例說明： 這個東西 11 月底要，不能 Delay ，交由你們作(不準增加開發成本)，功能我全都要。
品質的犧牲我竟然相對覺得還好…更可怕的是，「管理者」為了滿足那個鐵三角，而作出一些虛妄狡詐之事。
不僅僅是犧牲了品質，更給了高層錯誤訊息，甚至形成惡性循環，讓領導者作出錯誤判斷，更進一步的損耗品質。
最後成本提高、時間拉長與交付範圍不得不縮小，這不僅僅是鐵三角崩潰，連透明度與互信與也會失去。
Scrum Team 的成員組成有個前提，團隊具備完成端到端的開發的所有技能。
如果產品所需的 Skill Set 很大，巴士因子就容易過低；
比如說一個七人的團隊，要製作一個包含 Web、App(包含 iOS 、 Android )的產品。
人力與能力配置假設如下，而且 DoD 的定義為所有載具的交付，那麼這個團隊的風險極高 ； 實際的經驗會變成 Mini Water Fall。
這也意味著每當工作移轉到某個職能的負責人身上，當下就形成瓶頸。
| Alice | Bob | Carol | Dave | Eve | Frank | Grace |
|---|---|---|---|---|---|---|
| UI/UX | Front-End | Back-End | iOS | Android | DBA | Tester |
讓我們換個情境來說明，同樣的七個人，如果每個具備的 Skill Set 彼此能夠互相援助，巴士因子就提高了，而工作分配會更容易些，
較不易形成個人瓶頸(當然還是有可能，比如說這個 Sprint 的 Items 都落在 DBA 身上之類 …)，很明顯這樣的團隊組成更能適應變化。
| Alice | Bob | Carol | Dave | Eve | Frank | Grace |
|---|---|---|---|---|---|---|
| UI/UX | Front-End | Back-End | iOS | Android | DBA | Tester |
| Tester | Back-End | Front-End | Android | iOS | Front-End | Back-End |
| UI/UX | iOS | Tester | Back-End | Android |
上面的團隊很理想，在人力市場上卻很難得到你想要的牌，所以才需要訓練，但是要花時間。
但在開花結果之前會發生什麼事呢 ？
人員可能會離職、團隊會異動、團隊中有成員認為專精勝於通才(強調一下，這沒有對錯，只是價值觀的不同)
(以上為 Day 1， 不保証有 Day 2)
(fin)
一個大的迷宮裡面有許多乳酪，
四個角色「哈哈」、「猶豫」、「好鼻鼠」、「飛腿鼠」
「哈哈」是主角，它們在迷宮裡找乳酪，
每個人喜歡的乳酪都不相同，一開始他們找到了一個大乳酪站，
但是隨著時間過去，乳酪消失了，
「好鼻鼠」、「飛腿鼠」很快的離開尋找新的乳酪，
「哈哈」與「猶豫」在原處停留了一陣子，
最後「哈哈」終於啟程去尋找乳酪的心路歷程…
「哈哈」是主角，
「猶豫」代表過去的自已，
「好鼻鼠」、「飛腿鼠」分別代表兩種成功的人，
一種是有敏銳的嗅覺，能快速找到「乳酪」所在的方向
另一種是行動派，能快速嘗試迷宮的各個走道。
迷宮意謂著這個世界，乳酪讓人生成功與幸福的事物。
是的，乳酪是會改變的，就像是人生的目標也會改變，
不論是人生的階段的不同，或是市場的變化或是單純心境的改變。
你的乳酪就是會改變。
我想起「牧羊少年奇幻之旅」的商人，他永遠不會去麥加(假的乳酪)，反而期待著去麥加
才是他真正的乳酪。真實的生活上也是這樣，我們會訂定很多目標，
但是許多目標不是你真正熱情所在，反而訂目標這個行為會成為安慰自已的碎屑乳酪，
訂目標多容易不是嗎？比起實踐它。
最近在看另一本書「OKR 工作法」，裡面也有提到訂定目標(乳酪)的原則。
我只談第一點，但在工作上很少有目標讓自已能振奮起來的，
缺乏獎勵是其一，不合個人目標是其二，說一套作一套是其三。
當然我相信有的幸運兒會工作與個人目標契合的，
缺乏獎勵在台灣是常態，但我認為獎勵只是特效藥，
最糟糕的是說一套作一套，目前有點陷入這樣的困境了。
我的乳酪究竟是什麼呢 ?
不要停在沒有乳酪的地方，但是離開的時機很關鍵啊…
這個小寓言仍然是很樂觀的，完全沒有描述在尋找乳酪的路上餓死情境。
我的乳酪究竟是什麼呢 ?
「有了乳酪，你就會快樂」
「乳酪對你愈重要，你就愈想擁有它」
「如果你不改變自已，你就會被淘汰」
「如果你對未來無所謂畏懼的話，你會怎麼作?」
「雖然比較晚才開始，但也比從來都沒有開始要好得多了!」
「要常常嗅一嗅乳酪的氣味，如此你才會知道它何時開始變質!」
「往新的方向移動能幫助你找到新乳酪!」
「當你擺脫了自已的恐懼，你就會感到無比的暢快和舒適!」
「在還沒有享用乳酪前，先想像我正在享用那些乳酪，這會幫助我快點找到乳酪!」
「你愈找放棄舊乳酪，你就會愈快找到新乳酪!」
「進入迷宮裡尋找新的乳酪，比繼續停留在已經沒有乳酪的地方要安全得多了!」
「食古不化的想法，不會幫助你找到新的乳酪。」
「當你覺得你會發現並享受新的乳酪時，你就會改變你的路徑。」
「及早注意事情的小變化，就能幫助提早適應即將到來的大變化。」
變化是會發生的
預期改變的到來
觀察變化
迅速地適應變化
改變自已
享受自已的改變
隨時準備好迅速地適應改變並再度享用美味的乳酪
(fin)
好久沒有作 hexo 更新了，
本身這個 Blog 就是透過 hexo 與 Github 建置的 。
眨眼也過了兩年，文筆仍然很差;
說真的有很大的資訊焦慮，文章的內容也不夠充實，
很多觀點無法忠實的記錄下來，更無法連貫成線;
自已還要多方努力與學習。
如前面所說，這個 Blog 是透過 Github 作存放的空間，
雖然 Github 最近被 Microsoft 收購了;
不過它仍是開發人員最常使用的代碼托管服務與社群，
而且微軟近年轉型相同成功 –— 未來會怎麼樣我們可以觀察後再下定論。
Github 一直以來都有一個很棒的功能，
GitHub’s security alerts for vulnerable dependencies
它能夠對你的 Repo 提供安全警告，
如下圖，這是對我的個人 Blog 所使用的框架 Hexo 的相依性安全警告，
這封信說明了 lodash 這個套件的版本存在著高風險的資安問題，
建議升級套件以解決這個問題。
使用 npm update , 這個命令會更新專案的 package 到最新版本
1 | npm update |
可能會看到類似以下的結果，同時提示你可以使用 npm audit fix 更新有風險的 package 以修複這些漏洞
1 | npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\nunjucks\node_modules\fsevents): |
(fin)
1 | USE NationalDB |
MAXsp_executesql1 | USE NationalDB |
(fin)