Potioneer's Essays

❻ 如何衡量敏捷對於軟體研發效能的利益？

這段孟子與梁惠王的對話，原文是：「王何必曰利？亦有仁義而已矣！王曰『何以利吾國』，大夫曰『何以利吾家』，士庶人曰『何以利吾身』，上下交征利，而國危矣！」 ↩︎

變動的時代，為什麼工作分解技能更是必備？

Tue, 14 Nov 2023 20:00:00 +0800

很多人認為，在變動較少的舊時代 ¹，一次到位的工作規劃、工作分解是必備技能，但是到了現在這個變動頻仍、朝令夕改、隕石滿天飛的時代，做再多工作分解的規劃只是不切實際的浪費。

你怎麼看？

我反而認為，正是因為變動頻仍，就更需要及早進行工作分解。只不過這種工作分解，不是舊時代那種一次到位的無差別分解，而是要能夠區分近光燈與遠光燈的不同層次，也就是敏捷陣營所講究的 “granularity gradient"。

這個論點，我曾在去年的兩場導讀會，透過兩本書，作為公司內推動敏捷轉型的心態導正。² 最近我發現，這類誤解仍然普遍存在於敏捷轉型的業界，因此特地將去年那兩場導讀會的觀點稍作整理，誌於此文。

Generated by ChatGPT4 + DALL·E 3

少量多樣現象與影響

這個時代，「少量多樣」已是既成事實。在時間與事情上的「專注」，似乎越來越是奢求。

在職場上，我們越來越難擁有一整段專屬於個人的時間去專心做一件事。我們總是不時被打斷，不時有插單進來，這些時機與事情的正當性似乎也很難被質疑。隨著職位升高，這現象似乎也隨之加劇。

放大到團隊，甚至公司組織，亦然。隨著業務規模擴大，利害關係人數量及種類越來越多，這現象似乎也隨之加劇。

少量多樣的新現實，對習慣大批量做事的個人而言，不容易進入「心流」(flow)：

這是一個現實的問題，尤其我們在職場與家庭裡面，都免不了會被打斷的工作狀態。這時候，我們是要堅持自己一定非要有三、四個小時的完整時間才能進入心流狀態，才能完成工作？還是我們必須想一個工作方式，可以適應這種必須被打斷，一定會分段完成的工作呢？

— From: 《時間管理的 30 道難題》

對習慣大批量行事的組織而言，則會牽動到即時生產、換模換線的作業方式、甚至商業模式的巨變，可謂之「灰犀牛」衝擊：

大多數的灰犀牛可能早在三個月前、兩年前就已經存在且默默進逼，是我們故意疏忽、固執己見、視若無睹。對食品業來說，消費市場走向「少量多樣」就是一頭兩噸重的灰犀牛，因為過去汽車業走過、科技電子業走過，食品業又怎能避免？

— From: 《豐田精實管理的翻轉獲利秘密》

總括來說，「少量多樣」帶來效率及效能的挑戰，對於人類是 context switch，對於機器設備則是換線換模。反之，若是能夠克服這一點，就能因應少量多樣的時代趨勢，化危機為轉機，成為個人及企業的競爭優勢。

機器設備非我所長，相關的人機料法環細節，請參閱《豐田精實管理的翻轉獲利秘密》。 ³ 接下來我只繼續探討人類的 context switch 課題。

少量多樣的關鍵課題

對人類來說，過度 context switch 會增加暖機以求進入狀況的時間比例，也會損耗心智注意力，阻礙心流形成。

讓我們先接受一個事實吧：context switch 是無法完全逃避的現實。那麼，接下來的關鍵課題就是：如何做好 context switch 的準備，以降低暖機的佔比，減少心智注意力的損耗。

《時間管理的 30 道難題》第 4.5 節對這課題有很深刻的洞見：

我們應該要把工作方式設計成「可以被打斷」的工作流程。

想像一下：如果工作流程被設計成本質上就是「可以被打斷」（我不想太激進的說「歡迎被打斷」或「擁抱被打斷」），也就是說，如果在這新的工作流程裡，context switch 既不會過度增加暖機佔比，也不會過度損耗我們的心智注意力，那該有多好！

要怎麼做到？可分為兩個層面。

在個人修練層面，運用近年流行的「番茄鐘工作法」來練習短時間專注。

在工作設計層面，則是作者的招牌主張「子彈行動清單」：

我們應該要把工作方式設計成「可以被打斷」的工作流程——讓工作本身拆解成行動清單。這樣一來，任何時候被打斷，我會知道接下來下一個可以進行的步驟是什麼，以及前面做完了什麼步驟任務，不再是一個模糊成一團的任務。

可以分段成行動清單，其實可以幫助我們更快進入心流。因為如果一個任務，我不知道它明確的步驟是什麼，不知道怎麼開始，不知道這個步驟的下一個步驟是什麼，腦袋會一直在煩惱，一直在焦慮，一直在思考，一直在做確認。這時候我們大腦負擔很多決策選擇，特別容易疲勞、容易混亂。於是，我反而需要花更多時間去進入心流。

如果這個任務，我可以拆解出行動清單，我看到非常明確的步驟，那我的注意力就可以非常專注在下一個步驟就好。

有趣的是，儘管作者的「子彈行動清單」是在講個人的時間管理，並不是在講 Scrum 的 Sprint Planning，但精神及步驟卻若合符節，所以我很喜歡引用《時間管理的 30 道難題》第 3 章作為我的敏捷工作坊培訓素材。

因此，總結來說，面對 context switch 的關鍵做法是：

短時間專注：以個人來說，就是「番茄鐘工作法」；以 Scrum 來說，就是習慣 Sprint 週期內五大活動的節奏。
「可以被打斷」的工作流程：以個人或團隊來說，就是將工作分解至可行動的清單。

事前做好工作分解，幫助我們面對 context switch，更有餘裕應付插單。

延伸的好處

把工作方式設計成「可以被打斷」的工作流程，不僅消極的可以避免被 context switch 拖累，甚至還可以積極的善用這項優勢。譬如說，在少量多樣時代，有機會達到 Lean 所追求的「平準化」目標狀態，在市場波動時仍能保有較佳的資源調度能力：

將每日所需生產量的落差予以平均，謀求生產量的變動縮小。

— From: 《豐田精實管理的翻轉獲利秘密》

「平準化」不只是在汽車業、科技電子業、食品業有用，在知識工作場景也很管用。譬如說 Ailin 最近在〈識別出遠距團隊的 bad smell〉演講中提到，遠距團隊協作時，將任務分解成容易 multiplex 運作的形式，較能因應非同步的工作型態，也有較佳的依存關係：

From: Ailin〈識別出遠距團隊的 bad smell〉

「平準化」是非常敏捷的目標狀態，這也呼應了我在〈Timebox 是死胡同嗎？〉一文的論點。以「少量多樣」方式運作的團隊越多，工作分解得越落實，彼此之間的 dependency 就越有機會迅速解決，這樣才大規模敏捷得起來：

granularity 愈小，也愈有將它 fit in 到相關團隊 upcoming sprints 的可能性；尤其當對方團隊也是 short timebox 風格，就更容易 fit in 進去——這是 opportunity。

所以，在這變動的時代，工作分解技能不僅是個人必備，更是敏捷團隊必備的工作基因。在實踐敏捷時，千萬不要輕忽這個基本功。

【敏捷的工作分解方法】系列

❻ 變動的時代，為什麼工作分解技能更是必備？

其實舊時代並不是變動較少，而是舊時代想不出比較好的方法去處理變動，於是就只能祭出種種禁止變動的規定：合約、契約、規格書。 ↩︎
請見【職涯躍升書系導讀會，Part 2：高效團隊的工作方法】。 ↩︎
《豐田精實管理的翻轉獲利秘密》提到：「對於製造端來說，就出現幾項重點要克服：①產線小批生產的效率，②換線速度、清機速度，③新產品的品質良品條件，④生管對庫存的掌握度。」 ↩︎

Agile Success Recipes: Example Agendas for Efficient Scrum Ceremonies

Fri, 03 Nov 2023 20:00:00 +0800

If you’re new to leading Scrum events, knowing what to do can be tough. Having a set agenda can make things easier for you and your team. It helps everyone know what to expect.

I’ve got my own agendas that work for me, but it’s a good idea to get different takes. Why not ask ChatGPT to suggest some? The examples you’ll see here came from ChatGPT 4 and were adapted by me. Use them as a guide and tweak them to fit what your team needs.

Generated by ChatGPT4 + DALL·E 3

Planning

A Scrum Planning Meeting is an essential event in the Sprint cycle, where the team collaborates to define what can be delivered in the upcoming sprint and how that work will be achieved. Here’s a detailed agenda for a 2-hour Scrum Planning Meeting:

① Sprint Goals Setting

Length: 15 minutes

Purpose: To define the overarching goals of the upcoming sprint.

Steps:

Product Owner presents the top items in the product backlog.
Team discusses how these items contribute to the product goal.
Team collaborates to formulate Sprint Goals that align with the Product Goal.

Output: Defined Sprint Goals that are agreed upon by the team.

Length: 30 minutes

Purpose: To refine and prioritize the backlog items that can help achieve the Sprint Goals.

Steps:

Product Owner discusses the priority of backlog items.
Developers asks clarifying questions and discusses dependencies.
Team collectively decides on the items to bring into the Sprint, based on priority and capacity.

Output: A prioritized list of backlog items for the Sprint.

③ Task Identification

Length: 30 minutes

Purpose: To break down backlog items into actionable tasks.

Steps:

For each backlog item, the team discusses what needs to be done and its Acceptance Criteria.
Developers volunteer for tasks or tasks are assigned based on expertise.
Each task is estimated (usually in hours).

Output: A list of detailed tasks with initial estimates and assignees.

④ Sprint Capacity Planning

Length: 20 minutes

Purpose: To confirm the team’s capacity and ensure the Sprint is realistic.

Steps:

Each team member discusses their availability and potential impediments.
Team evaluates historical velocity and capacity for the new sprint.
Adjust the Sprint backlog, if necessary, based on capacity discussions.

Output: An adjusted Sprint backlog that matches the team’s capacity.

⑤ Risk Identification and Mitigation

Length: 15 minutes

Purpose: To identify potential risks and plan for mitigation.

Steps:

Brainstorming possible risks that could impact the Sprint.
Discussion of risk severity and probability.
Development of a basic risk mitigation strategy for the highest priority risks.

Output: A list of identified risks with a basic mitigation plan.

⑥ Definition of Done (DoD) Review

Length: 10 minutes

Purpose: To ensure everyone has a clear understanding of what “Done” means for a Sprint item.

Steps:

Review the Definition of Done criteria.
Discuss any updates needed to the DoD based on previous sprint retrospectives.
Confirm everyone’s understanding and agreement.

Output: A confirmed Definition of Done for the current Sprint.

⑦ Closing and Commitment

Length: 10 minutes

Purpose: To finalize the plan and obtain commitment from each team member.

Steps:

Recap the Sprint Goals, Sprint backlog, risks, and DoD.
Each team member verbally commits to the Sprint and their respective tasks.
Address any final concerns or questions.

Output: The team’s commitment to the Sprint Plan and clarity on the next steps.

Total Duration: 2 hours

By the end of this meeting, the Scrum team should have a clear understanding of what they are aiming to achieve in the upcoming sprint, a plan for how to get there, and a commitment to the sprint objectives. The meeting’s success is contingent on active participation from all team members and clear communication from the Product Owner and the Scrum Master.

A Product Backlog Refinement (PBR) meeting is where the Scrum Team reviews items on the Product Backlog to ensure they are appropriately prioritized and detailed enough for future sprints. Here’s an agenda for a 2-hour Product Backlog Refinement meeting:

① Review of Current Backlog Status

Length: 15 minutes

Purpose: To give the team an overview of the current state of the Product Backlog.

Steps:

Product Owner provides a quick recap of the current priorities.
Quick review of the progress made since the last refinement session.
Highlight any new market/customer insights that may impact the backlog.

Output: Shared understanding of the starting point for refinement.

② High-Priority Items Deep Dive

Length: 40 minutes

Purpose: To discuss and refine the highest-priority backlog items.

Steps:

Product Owner presents the top items needing refinement.
Developers discuss each item’s requirements, asking questions for clarification.
Refinement of Acceptance Criteria for each item.
Preliminary estimation of effort if ready for estimation.

Output: Refined high-priority backlog items with clear Acceptance Criteria.

③ Estimation Session

Length: 30 minutes

Purpose: To estimate the effort required for the refined backlog items.

Steps:

Quick review of estimation techniques (e.g., story points, T-shirt sizes).
Team engages in estimating effort using chosen technique (e.g., Planning Poker).
Discussion and agreement on estimates; re-estimation if needed.

Output: Estimated efforts for the refined backlog items.

④ Mid-to-Low Priority Items Review

Length: 20 minutes

Purpose: To assess and refine mid-to-low priority items for future sprints.

Steps:

Briefly review each item and decide whether it should stay in the backlog.
Update or provide a rough estimation of the items based on new insights.
Re-prioritize items, if necessary, based on the team’s discussions.

Output: An updated and re-prioritized mid-to-low priority backlog segment.

⑤ Story Splitting and Dependency Analysis

Length: 15 minutes

Purpose: To break down complex items and identify dependencies.

Steps:

Identify large user stories that can be split into smaller, more manageable ones.
Discuss and document any dependencies between backlog items.
Agree on an approach for handling identified dependencies.

Output: A list of smaller user stories and a map of item dependencies.

⑥ Backlog Health Check and Clean-up

Length: 15 minutes

Purpose: To remove or update outdated items and ensure the backlog remains relevant and manageable.

Steps:

Review low-priority items for relevance and potential removal.
Discuss any items that haven’t moved in a long time (backlog stagnation).
Decide on next steps for each outdated item (e.g., keep, transform, or remove).

Output: A refined and clean backlog free from outdated or irrelevant items.

⑦ Wrap-up and Action Items

Length: 15 minutes

Purpose: To summarize the session and outline next steps.

Steps:

Recap the decisions made during the session.
Assign any action items for further clarification or research.
Confirm the date for the next refinement session.

Output: A clear set of action items and a timeline for completion.

Total Duration: 2 hours

The purpose of this meeting is to ensure that the Product Backlog is continuously updated to reflect the project’s current needs and to prepare for upcoming Sprint Planning. It’s important for the Product Owner to facilitate the meeting, with the Scrum Master ensuring that the team stays on track and that each item on the agenda is given adequate time for discussion.

Review

The Sprint Review meeting is held at the end of each Sprint to inspect the increment and adapt the Product Backlog if needed. Here’s an agenda for a 1-hour Sprint Review meeting:

① Sprint Overview

Length: 5 minutes

Purpose: To provide a quick recap of the Sprint goals and context for the work completed.

Steps:

The Scrum Master or Product Owner summarizes the goals and main objectives of the Sprint.
A brief overview of the Sprint deliverables is provided.

Output: A clear context for stakeholders and the team about what was intended for the Sprint.

② Demonstration of Done Work

Length: 25 minutes

Purpose: To showcase the work that has been completed during the Sprint.

Steps:

The Developers presents the completed work and how it meets the “Definition of Done”.
Stakeholders are given the opportunity to see the product increment in action.

Output: A demonstrated increment of the product that is potentially shippable.

③ Product Backlog Review and Adaptation

Length: 10 minutes

Purpose: To discuss changes in the Product Backlog based on the Sprint’s outcomes.

Steps:

The Product Owner discusses the current state of the Product Backlog and any changes due to the Sprint.
A brief review of upcoming items on the backlog is made.

Output: An updated Product Backlog that reflects the outcomes of the Sprint and any new information.

④ Stakeholder Feedback and Discussion

Length: 15 minutes

Purpose: To receive feedback from stakeholders and discuss what is next.

Steps:

Stakeholders provide feedback on the increment and discuss additional needs or changes.
Open discussion between the team and stakeholders to understand the feedback’s implications.

Output: Valuable feedback from stakeholders that can be turned into actionable backlog items.

⑤ Wrap-Up and Closing

Length: 5 minutes

Purpose: To conclude the meeting, summarize the outcomes, and discuss next steps.

Steps:

Summarize the feedback and key points from the demonstration.
Agree on any immediate action items or follow-up meetings if necessary.
The Scrum Master ensures everyone is clear about the outcomes of the Review.

Output: A clear conclusion to the Sprint Review, with agreed-upon action items and follow-ups.

Total Duration: 1 hour

In the Sprint Review, the focus is on collaboration and feedback. It is not a one-sided presentation but an interactive session involving the Scrum Team and stakeholders. The goal is to provide a platform for open communication, foster transparency, and create a shared understanding of where the product is and where it is headed. The Scrum Master facilitates the event to ensure it is productive and stays within the timebox.

Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. Here’s an agenda for a structured 1-hour Sprint Retrospective:

① Setting the Stage

Length: 5 minutes

Purpose: To establish a focus for the Retrospective and ensure that everyone is mentally prepared to engage.

Steps:

The Scrum Master opens the meeting with a brief introduction and objectives of the Retrospective.
A short icebreaker or check-in to get the team comfortable sharing their thoughts.

Output: A team that is ready to engage in open and honest discussion.

② Gather Data

Length: 15 minutes

Purpose: To create a shared picture of what happened during the Sprint from different perspectives.

Steps:

Team members list highlights and lowlights of the Sprint, noting achievements and challenges.
Use of timelines, histograms, or sprint burndown charts to visualize the Sprint data.

Output: An overview of the Sprint’s events, data, and emotional journey.

③ Generate Insights

Length: 15 minutes

Purpose: To understand the ‘why’ behind successes and challenges.

Steps:

Discussion around the gathered data to identify patterns and root causes of issues.
Use techniques like ‘5 Whys’ or ‘Fishbone diagram’ to explore causes and effects.

Output: Identified key areas of improvement and reasons behind the Sprint’s dynamics.

④ Decide What to Do

Length: 15 minutes

Purpose: To agree on actionable commitments that address the identified improvements.

Steps:

Brainstorm potential solutions or improvements.
Prioritize the ideas and decide on a manageable number of items to take action on.
Formulate action items with clear owners and deadlines.

Output: A list of actionable improvements for the next Sprint with defined responsibilities.

⑤ Closing the Retrospective

Length: 10 minutes

Purpose: To summarize the meeting and ensure a clear way forward.

Steps:

Review the agreed-upon action items and ensure everyone is clear on their next steps.
Quick roundtable for each member to express their feelings about the Retrospective.
The Scrum Master thanks the team, possibly with some motivational closing words.

Output: Confirmation of the Retrospective’s action plan and team buy-in.

Total Duration: 1 hour

The Retrospective should foster an atmosphere of transparency and trust, encouraging all team members to share their views constructively. It’s important to focus on continuous improvement and not on placing blame. The Scrum Master’s role is to facilitate this process, ensuring the meeting remains positive and productive.

As we wrap up this guide on Scrum ceremonies, remember that the agendas and examples provided are starting points—tools to be refined as you grow in your role and as your team evolves. Embrace the flexibility of Scrum, and don’t shy away from customizing these frameworks to better fit the unique rhythms of your team’s workflow. Your journey as a Scrum Master is about facilitating progress and fostering collaboration, and with these tailored agendas, you’re well-equipped to steer your team towards continuous improvement and success. Keep iterating, keep learning, and most importantly, keep your team engaged. Here’s to the productive sprints ahead!

'Essence of Scrum' Series

❺ Agile Success Recipes: Example Agendas for Efficient Scrum Ceremonies

[Code Review 碎碎念] 簡化巢狀條件判斷式

Thu, 12 Oct 2023 20:00:00 +0800

讀別人的程式是一件苦差事，不僅需要具備對應的領域知識，也得了解對方的程式書寫邏輯與風格。因此，為了讓程式碼容易被人理解，整潔程式碼是必須持續精進的技藝。

在 code review 進行實質審查之前，我喜歡先做一點點形式審查，尤其是某些 code smell，臭味暴風半徑大到甚至連領域知識的外行人都聞得到。

我很常遇到不必要的巢狀迴圈或條件判斷式。經驗告訴我，除非真的是要設計出什麼高大尚的演算法或者刷題，否則，這有相當大的機率是需要進一步 refactor 的。

像以下這段程式，即使我故意把領域知識相關細節用 conditionXX 馬賽克掉了，你還是可以明顯聞到 bad smell：迴圈 + 條件判斷式，ABCDEF 深達 6 層，你能夠很快捕捉到箇中邏輯嗎？

# condition placeholders
condition1 = condition2 = condition3 = condition4 = condition5 = condition6 = lambda x : True

data = [
    # area code -> city name
    { 201: 'Jersey City', 206: 'Seattle' },
    { 212: 'New York', 213: 'Los Angeles' },
    { 226: 'London', 236: 'Vancouver' }
]

def demo1():
    for item in data:    # A
        if condition1(item):    # B1
            for pair in item.items():  # C
                print(pair)
                if condition2(pair):      # D
                    if condition3(pair):     # E
                        if condition4(pair):    # F1
                            print('CASE 1')
                        elif condition5(pair):  # F2
                            print('CASE 2')
        else:    # B2
            print('CASE 3')

再往下看之前，請先自己嘗試 refactor 看看。

頭重腳輕

通常我會先針對頭重腳輕的 if-else 開刀。

頭重腳輕的 if-else 有什麼問題呢？請試著將以下的程式讀到第 4 行，然後稍作暫停：

01:     if condition1(item):
02:         # ...
03:         # ...
04:         # many lines of code... (頭重)
05:         # ...
06:         # ...
07:         # ...
...
20:     else:
21:         # only 1 line of code (腳輕)

此刻，儘管你才讀到第 4 行，但應該會有個懸念：「究竟 if 的另一隻腳 else 會是什麼？」可是你要一直往下讀到第 20 行，謎底才會揭曉。

這種懸念，有個心理學名詞：Zeigarnik effect（常譯為齊加尼克效應、蔡加尼克效應）。

這種懸念，會增加我們的認知負荷，瓜分我們的專注力————閱讀程式碼，是最需要專注力的。

如果換個順序，頭輕腳重，就可以盡早排除懸念，因為懸念早在你讀到第 3 行就已結束：

01:     if not condition1(item):
02:         # only 1 line of code (頭輕)
03:     else:
04:         # ...
05:         # ...
06:         # many lines of code... (腳重)
07:         # ...
08:         # ...
09:         # ...

將這一招套用在本文一開頭的範例程式，可以改寫成：

def demo2():
    for item in data:    # A
        if not condition1(item):    # B1 + B2
            print('CASE 3')
            continue

        for pair in item.items():   # C
            print(pair)
            if condition2(pair):    # D
                if condition3(pair):    # E
                    if condition4(pair):    # F1
                        print('CASE 1')
                    elif condition5(pair):  # F2
                        print('CASE 2')

這一招，在 Refactoring 書中叫做 “Replace Nested Conditional with Guard Clauses”。 ¹

整併

連續的巢狀 if，往往給讀者一種「這裡一定藏著很複雜的邏輯」的感覺————或者錯覺。如有可能，應該嘗試用 and 及 or 加以整併。

像前面的範例程式，如果繼續將 condition2 & condition3 整併，巢狀深度降低了，是不是更易讀呢？

def demo3():
    for item in data:    # A
        if not condition1(item):    # B1 + B2
            print('CASE 3')
            continue

        for pair in item.items():   # C
            print(pair)
            if condition2(pair) and condition3(pair):    # D + E
                if condition4(pair):    # F1
                    print('CASE 1')
                elif condition5(pair):  # F2
                    print('CASE 2')

如果行有餘力，甚至還可以替整併起來的條件判斷式取個有意義的名字（function 或 lambda 或 method），程式碼就更具有自我詮釋的功能：

def demo4():
    for item in data:    # A
        if not condition1(item):    # B1 + B2
            print('CASE 3')
            continue

        for pair in item.items():   # C
            print(pair)
            if condition6(pair):    # D + E
                if condition4(pair):    # F1
                    print('CASE 1')
                elif condition5(pair):  # F2
                    print('CASE 2')

這一招，在 Refactoring 書中叫做 “Consolidate Conditional Expression”。 ²

Refactor 到這裡，如果你還不滿意，還可以再套用一次 “Replace Nested Conditional with Guard Clauses” 手法：

def demo5():
    for item in data:    # A
        if not condition1(item):    # B1 + B2
            print('CASE 3')
            continue

        for pair in item.items():   # C
            print(pair)
            if not condition6(pair):    # D + E
                continue
            if condition4(pair):    # F1
                print('CASE 1')
            elif condition5(pair):  # F2
                print('CASE 2')

需不需要做到這地步？

看情況。反正整段程式的邏輯結構已經很清晰易讀了，cyclomatic complexity 也已經降得很低了：

% radon cc -s demo.py
demo.py
    F 11:0 demo1 - B (8)
    F 26:0 demo2 - B (8)
    F 42:0 demo3 - B (8)
    F 57:0 demo4 - B (7)
    F 72:0 demo5 - B (7)

ChatGPT 怎麼說

聽說 ChatGPT 都快要取代程式設計師了，我們就來看看 ChatGPT 會怎麼 refactor 第一段程式。

Prompt: Refactor the following Python code with less nested structure.

大體上方向是對的，只是在 condition3 ~ condition5 的地方疑似因為 Python 縮排判斷錯誤。

嗯，大家真的要加油了，不要輸給 ChatGPT 呀。

如果你手邊沒有 Refactoring 這本書，可參考以下兩篇文章學習 “Replace Nested Conditional with Guard Clauses” 手法：文章 1 & 文章 2 ↩︎
如果你手邊沒有 Refactoring 這本書，可參考以下兩篇文章學習 “Consolidate Conditional Expression” 手法：文章 1 & 文章 2。 ↩︎

Timebox 是死胡同嗎？

Tue, 10 Oct 2023 10:00:00 +0800

許多敏捷手法都奠基於 timebox。那麼，為什麼有人會認為 timebox 路線是死胡同呢？有此論點的人，偏偏又是敏捷圈的重量級人物呢。

看板方法之父 David J. Anderson 在新書 Discovering Kanban 第 15 章對於 Scrum 之類基於 timebox 的方法有頗露骨的批評（光從標題 “The Tyranny of the Ever-Decreasing Timebox” 就看得出來）。正好好友 Derek 在〈《Discovering Kanban》心得：Scrum 可能沒有你想像的那麼美好〉一文整理了這一章的摘要與閱讀心得，在網路上也引發一些討論 ¹，我便趁此機會細讀這一章。

這一章論點非常深刻。但讀著讀著，總覺得作者道出的結論 “time-constrained sprints are an evolutionary cul-de-sac, a dead end”，與我直接或間接所知的業界實踐現況，並不相符。我猜想：會不會是某個推論環節出了些問題？

因此，我嘗試用系統思考角度去梳理相關論述。我試圖用更清晰的因果關係秀出 timebox 路線被點名的痛點，以及常見的因應之道。至於這痛點是否真的已被解決了，則留待讀者思考，不在此文的探討範圍。

目標相同，途徑各異

首先，David J. Anderson 是贊同 small batch 小批量的。他明確指出小批量的三大優點：

the advantages of smaller batches—higher quality, more frequent interaction between customers and the delivery organization, and potential gains from earlier delivery of valuable work (also known as the avoidance of opportunity cost of delay)

他接著指出，欲達小批量的目標，有兩種常見的途徑，一個是 timebox，另一個是 WIP limit：

There are two ways to constrain the batch size of work: Constraining the amount of time available to do the work, resulting in scoping to small numbers of requests that can be completed in the given time; or simply constraining the number of work items, constraining the size of the batch of requests, also known as WIP constraints.

此處姑且小結一下，David J. Anderson 是贊同 small batch 的（至少在整本書我還沒找到反對的段落），但主張透過 WIP limit 的方式達到小批量，反對透過 timebox 的方式達到小批量。

他認為 timebox 劣於 WIP 的地方是：

This switch from a time constraint to a WIP constraint free you from the tyranny of the timebox and it’s three dysfunctions of upfront analysis, excessive and costly estimation, and heavy-weight dependency management.

接下來我們就來看看他反對 timebox 的理由。

Timebox 會浪費力氣在削足適履上？

David J. Anderson 認為，timebox 愈短，就愈是需要花力氣在 backlog item 的事前分析上，以「削足適履」進去 timebox：

smaller timeboxes create three types of pressure that are often difficult to cope with and adjust to: First, smaller batches require an ever more detailed approach to requirements analysis and development—the need to write ever more fine-grained user stories that can be completed within the smaller time window. Second, an ever more accurate approach to estimation is needed so that a realistic commitment can be made; with smaller time windows, greater precision is required in estimation.

The shorter the time box, the more upfront effort is required to estimate whether the work will fit into the available time.

這段話的確指出了一部份實質存在的驅動力量，但並非全部。實務上，如果 Scrum 做得夠確實，在經驗主義的引領下，timebox 會逐漸趨於穩定態：

Timebox 會趨於平衡迴路

因此，如果還需要做過多的 up-front estimation，那一定是做錯了 Scrum Planning & Refinement。

David J. Anderson 又進一步評論道：

there is still, after twenty-plus years of Agile, little or no solid guidance on writing fine-grained, consistently small user stories.

這與我直接或間接所知的業界實踐現況，並不完全相符。至少我看到許多成功運用 Mike Cohn 大師提出的 SPIDR 法的例子。

Timebox 會鼓勵低交付價值？

David J. Anderson 認為，timebox 愈短，就只能交付出被削足適履出來的小碎片，這是難以被用戶察覺到交付價值的：

small-scale requirements may not be meaningful to the customer—they may not enable value. This means that if one small requirement has a peer relationship to others, they all must be delivered together in order to release value.

This type of breakdown defeats the purpose of the ever-smaller timeboxes and creates a false sense of agility when, in fact, customer value and quality are not improving; perhaps even the opposite is true.

這段話的確指出了一部份實質存在的驅動力量，但並非全部。實務上，如果 Scrum 做得夠確實，在 Scrum Planning 及 Review 時，用戶有充分機會了解如此拆解的目的，並實質參與拆解的活動。因此，在經驗主義的引領下，timebox 與交付價值之間會逐漸趨於穩定態：

Timebox 與交付價值之間會趨於平衡迴路

事實上，從上圖可知，不只是 timebox，就連 David J. Anderson 認可的「小批量」也一樣會面臨「低交付價值」的挑戰。因此，Kanban 的淵源——Lean 陣營，即使主張小批量、one-piece flow，但對於 batch size 是否可以無限制壓縮到最小，也是持保留態度的。像《流的傳承》就提到，大野耐一主張 batch size ≥ 5。

Timebox 會讓 Dependency 更惡化？

David J. Anderson 認為，timebox 愈短，dependency 造成 sprint fail 的機率也隨之增加：

What if a story in our sprint backlog gets blocked because of a dependency? That might prevent it from completing on time. Hence, the shorter the sprint timebox, the greater the need to identify dependencies up front.

Fine-grained requirements analysis coupled to short timeboxed sprints introduces a dependency management problem to Agile methodologies. If a piece of work will be affected by dependencies, such dependencies need to be tracked and managed between teams and multiple sprint backlogs and potentially across sprint boundaries.

這段話的確指出了一部份實質存在的驅動力量，但並非全部。假設 dependency 條件不變，timebox 愈短，一點點的 dependency 擾動帶來的影響的確可能較大——這是 threat。可是相對的，granularity 愈小，也愈有將它 fit in 到相關團隊 upcoming sprints 的可能性；尤其當對方團隊也是 short timebox 風格，就更容易 fit in 進去——這是 opportunity。 ²

Threat 與 opportunity，一加一減，綜合起來的效應是好是壞，還很難說。

Granuality 與 dependency 的關係是？

實務上，如果 Scrum 做得夠確實，在跨團隊 Refinement & Planning 時，已經有辨識、拆解、對齊、協調 dependency 的事情在檯面上或檯面下發生了，而且不只是消極地為了處理 dependency，更是積極地處理交付價值。

事實上，這也是各家各派大規模 Scrum 框架最核心的挑戰與賣點。至於這議題是否真的已被解決了，則留待讀者思考，不在此文的探討範圍。

timebox 的 CLD 全圖

Kanban 又是怎麼處理 dependency 的？

David J. Anderson 也承認 dependency 是個普遍現象，他也沒有神奇魔法可以讓 Kanban 免於 dependency：

Dependencies are a fact of life in all but very small-scale software development or mediocre development done by largely dilettante generalists.

Kanban 又是怎麼處理 dependency 的呢？從以下文字可以歸結出 global transparency 及 learning to coordinate/cooperate 這兩個方向：

Let dependencies happen as you discover them, create visibility onto them, and actively track them. Use a service-oriented approach and define workflow kanban boards (and systems) that encourage cooperation across functions. Don’t reorganize into cross-functional teams or attempt to design out dependencies from your product architecture; instead, start where you are and learn to be proficient at coordinating shared services.

這段主張，我的理解是，服務導向的看板，通常會是更縱向 end to end，也更橫向 cross functional。如果做得確實，理論上 dependency 會更早浮現，也更早讓縱向橫向的人一起面對，一起 ad hoc 處理或是 systematically 處理。

看到這裡，心中不禁想到：timebox 路線不也是如此嗎？

個人總結

至此，我個人認為，timebox 與 WIP limit 兩種途徑，長期的目標狀態「小批量」其實很類似，只是選擇的途徑不同，造成哪個要先關注、哪個可以等到成熟度提升之後自然就會去關注的不同優先順序。

兩者的差異並沒有想像中的大，雙方只是切入的角度不同，但核心要素是很接近的；尤其是繼續精進時，會發現共同點越來越多，相互取經是司空見慣。

所以我在課程中，總愛用《神之雫》的最終章來比喻兩者的關係。

Derek 這篇文章，在 Facebook 引發一些討論，請見 link 1 & link 2。 ↩︎
關於這議題，我在後續的文章〈變動的時代，為什麼工作分解技能更是必備？〉有更深入的探討。 ↩︎

從 Code Review 的小事看到大事

Wed, 13 Sep 2023 20:00:00 +0800

前言

我很喜歡 Java 大師 Joshua Bloch 在《編程的頂尖對話》所說的：

即使是想把一個很小的程式寫對也是非常難的。

認為自己程式沒有 bug 就是在愚弄自己。程式肯定有 bug，（只是）多數情況下，程式裡的 bug 夠少，足以使其完成任務。

是的，100% 正確的程式或許很難達成，或許連定義起來都很困難，但我們還是得努力趨近它，讓我們工作更有成就感，更有信心能夠交付價值，也更少因不慎流出去的瑕疵而疲於奔命。

Joshua Bloch 緊接著又說：

既然寫正確的程式那麼困難，我們就應該盡力取得幫助。所以，能減少 bug 的所有東西都是好的。這就是我是靜態型別和靜態分析的信徒的原因。

是的，我們需要動員許多力量，取得許多幫助，才能夠趨近於正確的程式。可動員的許多力量當中，無疑的 code review 是重要的基礎，可惜的是，許多團隊連這基礎都還有諸多可改善之處，這也限縮了團隊能進一步發揮的價值。

Code review 乍看之下是小事，但若認真探討起來還真是不小。在我多年輔導各種成熟度團隊的經驗中，有六個基於 code review 以及衍生出來的議題可深入探討：

基本信念：品質來自正確地做事
掌握基本功與領域知識
凝聚團隊公約的共識
嘗試更好的協同理解技巧
讓進步看得見
支持長久研發的措施

如果你所在的團隊已經啟動 Scrum 或 Kanban 研發流程，恭喜你，你們已經有很好的流程基礎可在這六大議題上面精進，只需要正確實施（玩真的！）你們所採用的敏捷流程。文中我會大量連結到 Scrum 及 Kanban 的要素。請確實「守」你們該守的流程，不要驟然「破」或「離」。

全文很長，如果你是現役的程式設計師，可先讀①②以瞭解 engineering disciplines；如果你是 team lead，可先讀③④以瞭解團隊動力；如果你是管理層，可先讀⑤⑥，尤其是⑤關於管理面的施力點。

① 基本信念：品質來自正確地做事

Code review，甚至任何一種 review，都源自一個單純的理由：多一個人來確保品質。

品質是計畫、設計和內建而來的，不是靠檢驗出來的。換言之，品質來自正確地做事。

怎樣才叫做「正確地做事」？

談「正確地做事」之前，先確定我們擁有共同的基本信念。

Collective ownership

Odd-e 三位專家在 2023-08-31 晚上有一場很精彩的 webinar【高效 Scrum 團隊所需的能力】。在 1h:03m:36s 聊到「工程能力」時，有一句語重心長的話：「所有跟 eXtreme Programming 相關的工程能力都很重要。」

eXtreme Programming (XP) 第一版與第二版提到許多工程實踐，此刻我想特別點出 “collective ownership” 這一條：

Collective Ownership encourages everyone to contribute new ideas to all segments of the project. No one person becomes a bottleneck for changes.

In practice collective ownership is actually more reliable than putting a single person in charge of watching specific classes. Especially since a person may leave the project at any time.

積極面來說，collective ownership 可善用集體智慧提升設計品質，可促成知識共享，消極面則可降低公車指數 (bus factor)。 ¹

萬一連 “collective ownership” 都不是團隊想要追求的境界，或許這個團隊從一開始的組成階段 (team forming) 就有問題了；我建議，解決了之後，再談以下的議題吧。否則，連「共同持有」的心態都沒有，還有什麼動機要去 review 別人的 code 呢？

Four-eyes principle

Code review 的出發點很單純：多一個人來確保品質，也就是說「不要只靠自己的兩隻眼睛，要再加上別人的兩隻眼睛，總共要用四隻眼睛來確保品質。」

Four-eyes principle 雖然既古老又原始，但管用，因此就連聯合國及歐盟這麼先進的國際性組織都仍在使用。

再引述一次 Joshua Block 的話：「既然寫正確的程式那麼困難，我們就應該盡力取得幫助。」

就算我們不想時時刻刻都像 XP 主張的 pair programming（甚至更激進的 mob programming），但至少在關鍵時刻，尤其是在 design review 及 code review 的時刻，就該好好善用這種原始方式取得幫助。

每當有「現在可不可以暫時跳過 four eyes？」的衝動，或許該換個角度思考「現在有沒有方法讓 four eyes 更有效率且不犧牲品質？」

Working backwards

「逆向工作法」或「以終為始」是很有威力的心法。用在敏捷開發上，就是熟知的 user story “INVEST” 原則當中的 V (Valuable) 及 T (Testable)：

Valuable - 品質的起頭：這個 user story 是為了交付什麼價值？是為了誰？
Testable - 品質的末端：該怎麼確定這個 user story 已經做完了 (done)？該怎麼驗收？

雖然前面曾提到「品質不是靠檢驗出來的」，但若能在一開頭就設想末端的檢驗標準，甚至設計出可讓將來更容易確實檢驗的結構，就是「內建品質」的精神——這就是敏捷實踐者常講的 “acceptance criteria” 及 “test-driven/behavior-driven design” 的用意。

Code review 就是讓 four eyes 共同檢視 Valuable 及 Testable 的好時機，喔，不，甚至早在 Sprint Planning 或 Refinement 時就應該來 review 了——現在不是流行凡事都要 “shift left” 嗎？

品質不是白吃的午餐

品質是計畫、設計和內建而來的。

計畫與設計出內建品質，是需要時間、精力、技能的。孕育出 collective ownership、four eyes、working backwards 的意識及紀律，也是需要時間、精力、技能的。

畢竟品質不是白吃的午餐。

在推銷這些進步理念時，讓團隊想像藉由「追求高品質」將會帶來的效益，或是以具體事證呈現因為「漠視低品質」而正在且將會持續深陷的痛苦泥淖，讓團隊做出選擇，願意投資時間、精力、技能在品質改進上。

你能舉出「不好好進行 code review」最終會引發的災難嗎？這樣的災難是大家願意承擔的嗎？用這個來鞏固大家願意投資在品質上面的動機吧。

② 掌握基本功與領域知識

不可諱言，code review 要做得好，不是大聲嚷嚷精神喊話就會自動美夢成真，是需要自我提升能力的，尤其是研發基本功與領域知識。

不過，以下提到的這些能力，就算不談 code review，也是工程師本來就該自我提升的。

所以，結論是：請把它們當成是必修課吧，這會讓你成為更稱職的軟體研發工程師。

Clean code

Turing Award 得主 C.A.R. Hoare 有一段經典名言：

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

單純到「顯然沒有缺陷」 vs. 複雜到「沒有明顯的缺陷」，你願意選擇哪一種？

寫出 clean code，可說是程式設計師的職業道德。坊間早有 clean code 及 refactoring 相關的經典書籍，網路上也有一大堆相關文章，請花點時間自我充實吧。

Guideline

除了 clean code 技能之外，我們還需要一些讓程式變得更好的 code review 指導方針。

讓我們向 Google 取經吧 ²。Google 在 “What to look for in a code review” 一文建議了一些 review 的重點：

Design
Functionality
Complexity
Tests
Naming
Comments
Style
Consistency
Documentation
Every line
Context
Good things

《軟體測試實務：業界成功案例與高效實踐（第一冊）》第四章也建議了一些 code review 的重點：

是否有明顯的邏輯錯誤？
有無遵循既有的程式碼編寫規範？
邏輯的測試保護足夠嗎？
有完整實現需求嗎？

如果是在 DevOps 合一的團隊，甚至還會 review 一些 design for observability 的要點。以上都很值得放在團隊的 Definition of Done 或 PR/MR template。

注意事項洋洋灑灑，每當有「現在可不可以暫時跳過？」的衝動時，或許該換個角度自問：「此刻若不好好 review 這些地方，我能承擔抄捷徑的後果嗎？」

Small batch

敏捷陣營推崇小批量開發：小批量的東西容易估算，容易寫，容易理解，容易測試，容易部署，容易取得回饋，容易歸因。

DevOps 陣營也推崇小批量。Google 在 “DevOps process: Working in small batches” 一文說道：

Working in small batches is one of a set of capabilities that drive higher software delivery and organizational performance. These capabilities were discovered by the DORA State of DevOps research program, an independent, academically rigorous investigation into the practices and capabilities that drive high performance.

如果不是因為技術問題無法小批量提交 PR/MR，而是因為上游的 backlog item 就是如此大，或許團隊可以嘗試在 Sprint Planning 或 Refinement 時套用 SPIDR 法來拆解過大的 backlog item。

Domain knowledge

如果身處教育資源不那麼完備的團隊，想要養成領域知識，得自助加上人助：

自助：盡量回到學生時期的好學心態，並盡量掌握有效率的學習方法。尤其是近年來流行的卡片盒筆記法，很值得一試。
人助：尋求協助，並設法將學到的東西反饋到團隊的公共資產：文件、簡報、錄影、自動化測試，造福你的左右鄰兵，也造福後人。

Context

即使有了領域知識，但論及理解需求，又是另外一回事了。

理解需求，除了老生常談的敏感度、傾聽與提問技巧之外，敏捷圈發展出來的 Specification by Example 技術，很值得大家嘗試。

而且，既然都已經口頭問出來這些實例了，何妨順便用驗收測試予以固化？

Config

現代軟體不能只顧好核心業務邏輯，還得處理全球化、客製化、混合雲、多租戶等外圍需求，要能透過 feature flag 動態即時切換，甚至還要能讓用戶自助服務。

組態管理比以往重要許多，複雜度不亞於程式碼管理，有時甚至超過。

程式碼的管理，有 git flow、GitHub flow、GitLab flow 等流行的作法，那麼，組態管理呢？

對於 legacy 系統，盤點既有組態，給予合適的現狀描述，至少是第一步。考古之餘，別忘了反饋到團隊的公共資產上。

③ 凝聚團隊公約的共識

Code review 是兩個人之間的活動，一個是 reviewer，另一個是 reviewee。喔，其實更常見的情況是，reviewer 要寫成複數 “reviewers”。

Code review 不只是兩個人之間的活動，更是團隊的活動。

Marcus Buckingham 在〈隱藏版團隊力量大 (Power of Hidden Teams)〉一文提到團隊的力量 ³：

大多數工作實際上都是團隊進行的工作。團隊是你工作經驗的現實。你的責任似乎連結到其他人的責任；你的長處似乎能與其他人的長處互補；你的左右都有人幫你留意，讓你保持自信，對你的工作給予回應，分享你對「好」的想法，在你看起來快要承受不住時伸出援手，並在你陷入困境時給予意見。這種團隊體驗的品質，正是你工作體驗的品質。

你的團隊體驗會促進很多事情：你在工作時的生產力；你在工作時是否感到快樂；你有多少創意、創新和復原力；以及你選擇留在公司多久。換句話說，在你的工作上，優秀的團隊和團隊合作不是「有了也不錯」的事物，而是必須要擁有。

現代軟體研發是一個群體的事業， ~~有人就有江湖~~ 有人就有協作的議題。Code review 既然是團隊的活動，免不了也會有 ~~江湖的議題~~ 協作的議題。

若你的團隊已經啟動 Scrum，以下都是很值得在 retrospective 充分探討的好議題，讓團隊公約成為團隊協作的助力。

過與不及的拿捏

Code review 的尺度，該鬆還是該緊？

「太鬆」當然並非我們樂見，但「太緊」呢？

如果團隊對於鬆與緊的尺度難以達到共識，不妨聽聽看 Google 怎麼說。

Google 在 “What to look for in a code review” 一文提出他們認為最起碼的品質標準是：

Don’t accept CLs (change lists) that degrade the code health of the system.

在業界，我們常暱稱它是「童子軍規則」(The Boy Scout Rule)：「離開營地前，讓營地比使用前更加乾淨。Always leave the campground cleaner than you found it.」

至於尺度太緊的問題，Google 在 “The Standard of code review” 一文提出他們的看法：

In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect. That is the senior principle among all of the code review guidelines.

儘管 Google 是菁英薈萃之地，但關於這一點倒是滿務實的，不會追求完美主義。

Cadence

很多人怕 code review 會打斷別人的工作節奏，也怕自己的節奏被打斷。因此我常常看到看板上面擠壓許多有待 review 的 PR/MR，我輔導過的團隊，也幾乎都會在 retrospective 提出這項熱門議題。

聽聽看 Google 怎麼說。"Speed of Code Reviews" 一文主張：

If you are not in the middle of a focused task, you should do a code review shortly after it comes in. One business day is the maximum time it should take to respond to a code review request.

可見 Google 很務實地將焦點放在 flow 上面：若無特殊理由，要以團隊目標為重。

《軟體測試實務：業界成功案例與高效實踐（第一冊）》第四章則提出團隊一起 code review 的常見做法，以避免個別人士零零星星被打斷：

除了找另一個團隊成員協助 code review 外，在多數團隊成員不熟悉相關程式碼時，我們也會有 mob code review，去加強知識擴散的效果。

鑑於此種需要專心投入的特質，有些團隊會直接定時進行 mob code review（例如：每日 daily meeting 之後或是下班之前），以避免當前工作被打斷。

大家可以參考這些業界常見的做法，改善自己團隊的 code review 節奏。

Process

敏捷路線不太鼓勵過多 top-down 的流程約束，更希望團隊基於經驗主義自行湧現出合適的流程。我鼓勵團隊挑選感興趣的部份實踐看看，並在 retrospective 充分反思。

如果你是走 Scrum 路線，請善用 Definition of Done 作為品質共識。像《軟體測試實務：業界成功案例與高效實踐（第一冊）》第四章就提到：

有些團隊甚至在他們的實體或 Jira 的 Scrum board 上，將 code review 強制設為必需通過的一個階段，未 code review 過的任務就不算完成。

列入 Definition of Done 還有一個好處：code review 就不再是隱藏成本，而是正大光明的 task，需要被規劃，需要被估點，也需要認真投入。

如果你是走 Kanban 路線，可考慮新增一個名叫 “code review” 的 column，並設下 WIP 及 policy。接下來，你會驚訝地發現 code review 的 flow 是多麼順暢⋯⋯或是不順暢。請善用 Kanban 視覺化的威力。

④ 嘗試更好的協同理解技巧

在理想世界中，我們程式要實作的任務很單純，所需的背景知識大家都有，程式碼寫得清晰易懂，PR/MR 也充分交代 reviewer 需注意的事項。這種情況下，reviewer 或許只需要動動眼、動動滑鼠、動動腦，就能善盡 code review 責任。

理想世界不常發生，是吧？

真實世界中，要實作的任務不那麼單純，所需的背景知識不見得大家都有，程式碼埋藏一些神祕邏輯，如果我們繼續仰賴低頻寬的程式碼溝通方式，會讓 reviewer 只能根據眼前所見的浮面資訊進行浮面的 review，最終只能算是表面工夫的 review，輸出低品質的程式。

因此，整個團隊都需要學習更好的協同理解技巧：放大溝通頻寬，尋求深度資訊。

放大溝通頻寬

一對一的溝通頻寬太低了，有必要的話，集體一起 code review 吧。

程式碼的溝通頻寬太低了，大家可以善用嘴巴，善用白板、螢幕（如果你們坐在附近）、投影機（如果需要多人一起看）、遠距會議軟體（如果是異地辦公的團隊）。

《軟體測試實務：業界成功案例與高效實踐（第一冊）》第四章就介紹過這種大絕招：

除了找另一個團隊成員協助 code review 外，在多數團隊成員不熟悉相關程式碼時，我們也會有 mob code review，去加強知識擴散的效果。

如果連這種大絕招都無效，或許團隊成員彼此落差實在太大，需要長期治療。

尋求深度資訊

避免 reviewer 只能根據浮面資訊進行浮面的 review，團隊需要提供更多深度資訊以協助 reviewer。

我從 “GitHub pull request template” 摘錄一些有助於 code review 的資訊，可做為大家的出發點：

Ticket number and link
How has this been tested?
- Please describe the tests that you ran to verify your design. Provide instructions so we can reproduce.
- Please also list any relevant details for your test configuration.
Checklist:
- I have commented my code, particularly in hard-to-understand areas
- I have made corresponding changes to the documentation
- I have added tests that prove my fix is effective or that my feature works
- New and existing unit tests pass locally with my changes
Screenshots (if appropriate)

我還曾經身處於有這種內規的團隊：「沒看到 unit test 的報表，就不予以 code review。」很硬！但那卻是我非常享受程式設計的一段經歷。

⑤ 讓進步看得見

Code review 的目的，是善用集體智慧提升設計品質，促成知識共享，讓我們工作更有成就感，更有信心能夠交付價值，也更少因不慎流出去的瑕疵而疲於奔命。

直接的效益是：提升品質，降低風險，間接的效益是：提升團隊的長期生產力，進而縮短上市時間，提升客戶滿意度。

這些效益都是偏向企業內部流程的構面，甚至是學習與成長的構面，偏向落後指標，且都不容易直接衡量。若以系統思考角度來說，這些效益有很明顯的滯延現象，短期內甚至還可能不利，急功近利的人，很容易因此落入「捨本逐末」(shifting the burden) 及「目標侵蝕」(eroding goals) 的陷阱。

認清根本解具有滯延現象，且選擇正面對決之後，才能接下去探討如何衡量成效。

這篇從 code review 出發的文章，一路看到這裡，大家應該很清楚，對於提升品質、降低風險、提升團隊生產力⋯⋯這些我們想要的成效，code review 只是手法之一，單獨只有這一個手法是無益的，勢必得搭配衍生的配套措施。因此，code review 的成效也不宜單獨看待，需連同其他配套措施一起衡量才比較實際。

不同的團隊，成熟度各異，管理者需要正視不同的現況，擬定不同的改進措施、衡量方式及目標狀態，並且要分階段。

譬如說，以領先指標來看：

推動 collective ownership 的同時，可嘗試衡量 Scrum 五大活動參與度、PR 參與度、Sprint Backlog Items 分工多元性。
推動 working backwards 的同時，可嘗試衡量 Sprint Backlog Items 的 acceptance test 完備度、design for observability 完備度、test 涵蓋率。
推動 clean code 的同時，可嘗試衡量原始碼品質指標，並搭載於 CI 系統。

以落後指標來看：

關注 flow cadence 的同時，可嘗試衡量看板的 cumulative flow diagram。
關注最終交付品質的同時，可嘗試衡量 change failure rate——這正好是 DORA (DevOps Research and Assessment) 四大指標其中之一。⁴

最後，即使我們已經盡其所能把關品質，但很不幸 defect 仍然流了出去造成影響，亡羊補牢之餘，我們也需要關注 regression test 是否落實：

針對已流出去造成影響的 defect，可嘗試衡量 regression test 涵蓋率。

⑥ 支持長久研發的措施

個人具備正確的品質基本信念，掌握了基本功與領域知識，團隊擁有公約共識，也掌握了更好的協同理解技巧，接下來就是這個大哉問了：周圍的環境，是否可以促成 code review 及相關的關鍵行為？

事

品質不是白吃的午餐，計畫與設計出內建品質，是需要時間、精力、技能的。

如果整個團隊已經開始嘗試用更好的方法進行 code review 及相關活動，但仍然受阻於事情太多、時間太少，或許這就要回到 Product Backlog Items 的基本問題了。請團隊試著問問自己幾個問題：

即使可能有複數個上游來源，但團隊是否最後只會有一份透明化的 Product Backlog？
團隊是認真看待 Product Backlog 的嗎？
PO 是根據什麼原則管理 Product Backlog 的？
團隊 Sprint Planning 及 Refinement 是如何進行的？
品質、flow 相關議題在 Retrospective 裡面是如何被討論的？
Retrospective 是玩真的嗎？

思考過一輪，應該可以更好的區隔出：究竟是外面的問題，還是自己的問題。針對前者，再去尋求協助。

物

想讓 PR/MR template 所要求的種種事項具體發揮效用，需要自動化環境的支持，尤其是與 CI/CD 高度連動的環境。

這是得持續投入的基礎建設，沒有捷徑。

人

Code review 及相關的配套措施，需要有一定的技術能力。

大規模敏捷框架 LeSS 在探討 “technical excellence” 時，有一段語重心長的話：

There is no magic to them, most people are able to learn them. However, most people are not aware of these after they graduated from university and hence, your organization will need to invest in these, usually via coaching.

簡單的說，自立自強固然可行，但若有好的前輩或教練親自帶領，將會事半功倍。

這就是團隊裡資深同仁的責任了。我期許你們能在③④提到的種種團隊協作活動中，以身作則，起示範作用。把整個團隊的水平提升到某個地步，有團隊整體戰力當你的後盾，也才能夠發揮更大的價值。

結語

品質改善具有滯延現象，需要正確思路與堅定決心，才能避免捨本逐末與目標侵蝕的陷阱。

本文探討從 code review 出發並衍生出來的六大議題，也建議一些可供個人、團隊、組織開始嘗試推動的事項。

提升品質，不必然意味著降低研發效率。讓我們持續學習與探索如何聰明地做事。

關於「公車指數」(bus factor)，可參考以下兩篇文章：〈少一個差很多：算算團隊的公車指數〉、〈你的團隊「合作無間」嗎？嘗試用「公車指數」衡量現況吧！〉。 ↩︎
建議大家讀讀 Google 公開的 Google Engineering Practices Documentation，最近也有保哥的中譯版。 ↩︎
如果你無法閱讀全文，也可收聽這一集 podcast：〈員工投入程度來自… 這個隱藏因素，你發現了嗎？〉 ↩︎
關於 DORA 四大指標，可參考 “Are you an Elite DevOps performer? Find out with the Four Key Project” 一文，更詳細的說明，請參考《Accelerate：精益軟體與 DevOps 背後的科學》一書。 ↩︎

很簡單的 Story，也要拆分出 Tasks 嗎？

Sat, 26 Aug 2023 18:00:00 +0800

Scrum 已經夠精簡了，但很多人還是因為嫌麻煩、省時間，就省略原本預定該做的事情。

雖然在 2020 之前的 The Scrum Guide 並沒有規定 Sprint Planning 要分為 Part 1 & Part 2 ¹，但這可說是 Scrum 圈公認的最佳實踐。²

如果團隊已經成熟到能以自己的方式把 Sprint Planning 做好做滿，其實也未必非得硬性劃分 Part 1 & Part 2（畢竟 Scrum 推崇基於經驗主義的自組織、自管理）。最怕的是，不明白劃分 Part 1 & Part 2 的好處，不明白 Part 2 的重點及產出，甚至單純只因「嫌麻煩」、「省時間」，就省略原本預定該在 Part 2 進行的活動，往往會導致 sprint 進行途中出現種種問題。

很多問題，追根究柢，就是當初沒有認真進行 Part 2。

在 Part 2 中，有一個重要的步驟是將 Sprint Backlog Items 拆分出較小、較具體的 tasks ³ ——常被團隊輕看的步驟。我姑且不搬出專案管理的大道理 ⁴ ，純粹以 Scrum 日常經驗來反思「很簡單的 story，也要拆分出 tasks 嗎？」這個提問。

對自己：避免低估

工程師常會低估 story 所需耗費的時間資源。可能是刻意低估（迎合上意、打腫臉充胖子⋯⋯），也可能是不自覺的低估。前者當然不可取，後者雖然是無心之舉，但仍會造成 sprint fail 的風險，若無法道德勸說大家警覺，就得訴諸制度流程來避免。

將 story 拆分出較小、較具體的 tasks，其實就是切換至一個較為深入的視角來審視 story 的執行計畫。拆分出來的 tasks，不僅可當成 checklist 避免自己掛一漏萬，更可忠實反映 story 的複雜度——我常常看到團隊在真正嘗試將 story 拆分出好多張 tasks 便利貼之後，才回頭修改當初對於 story 的估點，而且往往是增加點數。

我很喜歡 Mike Cohn 大師在 User Stories Applied 所舉的 “Everything takes four hours” 例子：

In one episode the husband is being pestered by his wife to go shopping for a couch. She insists the trip will take only an hour. He tells her that “Everything in the world takes four hours. You gotta go there, you gotta do whatever, eat, talk about where you should have eaten, and then come home. That’s four hours minimum.”

This isn’t a bad rule of thumb for software development and is a perfect example of how projects get in trouble when they don’t distinguish between ideal time and elapsed time.

如果你堅持「這個 story 很簡單，根本不必浪費時間拆分出 tasks」，那麼，請想想 “Everything takes four hours” 這句話。

對團隊：製造流動感

讓 Daily Scrum 無趣的方法有很多，常見的病徵是：某一張卡片，日復一日就是一直停留在某一欄 (column)，沒有前進。

某Ａ問：「這張卡片，停留在這一欄好像已經好幾天了⋯⋯請問它怎麼了？」

答：「啊，就是還在進行中，還沒做完呀。」

某Ｂ問：「好幾天都一直停留在這裡，我怎麼知道它到底有沒有任何進展呀？」

答：「啊，就是還在進行中呀⋯⋯你懷疑我喔？」

團隊需要製造任務的流動感，以區隔「沒有流動的幻覺」與「真實的 blocker」兩種情況。

Scrum 的團隊未必會採用 Kanban 陣營的做法，但 Kanban 的 flow 觀念及視覺化手法很值得 Scrum 團隊借鏡。將 story 拆分出較小、較具體的 tasks，其實就是切換至一個較具流動感的視角來審視 story 的執行狀況。當你憑著每一天每一天 Daily Scrum 的視覺印象，懷疑某張 story 似乎停滯不前，或是憑著 burndown chart ⁵ 的量化資料，懷疑整個 sprint 似乎偏離理想斜線，那麼，在進入「blocker 問題解決模式」之前，請先試著檢查看看當初 tasks 拆分是否確實。

怎樣才能夠拆分出具有「流動感」的 tasks 呢？請參考我在〈工作分解講座‧閱讀材料〉文末的建議：

努力將 task 切到不超過 2 個工作天的程度。

當 Tasks 已經變成無趣的例行公事時

Ｃ問：「萬一我們每次將 story 拆分出來的 tasks 都長得一模一樣，還有必要浪費這些時間嗎？」

我：「請舉例。」

Ｃ：「就拿這一張 Story F 來說吧，我們會拆出這幾張 tasks：(1) Design Logic，(2) Design Schema，(3) Coding，(4) PR，(5) Deploy。」

Ｃ：「對其他那幾張 Story G、H、I 來說，其實也都是一樣的手順。每次都要同樣的複製貼上複製貼上，滿浪費青春的⋯⋯」

如果團隊面對的產品，真的如同這位Ｃ所說，在 tasks 層次的手順幾乎已經了無新意，那麼，在不犧牲前面講的「對自己：避免低估」及「對團隊：製造流動感」兩大好處的前提下，我會建議團隊：或許可試著將樸素的 Scrum task board 轉換成較精緻的 Kanban board，把例行手順變成 Kanban column。

「很簡單的 Story，也要拆分出 Tasks 嗎？」

你認為呢？

【敏捷的工作分解方法】系列

❺ 很簡單的 Story，也要拆分出 Tasks 嗎？

很簡單的 Story，也要拆分出 Tasks 嗎？

以前的 The Scrum Guide 對於 Sprint Planning 執行細節著墨不多。但 2020 版的新內容，開始強調「將 SBI 拆分出 work items」這環節，圈點出 3 個核心主題：Why、What、How，只是並沒有道出 Part 1～3 之類的「步驟」、「流程」字眼。儘管如此，Scrum 陣營還是愛用習之有年的 Part 1 & Part 2 字眼來劃分 Sprint Planning 的階段，本篇文章亦遵照此一慣例。 ↩︎
對於 Sprint Planning 是否要分成兩部曲，請參考 Teddy 的文章〈談談 Sprint Planning Meeting〉。 ↩︎
像 LeSS 就說："Sprint Planning Two focuses on creating a plan of work to get to ‘done’ for each item. The items and plan of action or tasks comprise the Sprint Backlog." ↩︎
如果想從更宏觀的角度看待「工作分解」，請參考〈工作分解講座‧閱讀材料〉一文。 ↩︎
Scrum 陣營常見的 burndown chart 有兩種，請參考〈燃盡圖 (Burndown) 簡單說〉一文。 ↩︎

敏捷的工作分解方法

Sat, 26 Aug 2023 00:00:00 +0000

One-Week Sprint 的節奏

工作分解講座・閱讀材料

事情做一半，等於沒完成：淺談敏捷的里程碑設定

以「蜘蛛法」拆分過於龐大的 User Story

透過自己的雙手，掌握那不變的容器技術核心——《Docker 實戰 6 堂課》推薦序

Sat, 19 Aug 2023 20:00:00 +0800

我在 2015 年～2017 年間，開了 8 次【Docker 建置實戰講堂】一日課程。在那個大眾對於 Docker 還矇矇懂懂的年代，我就堅持不用貌似較簡便的 Docker Desktop，而是大膽採用 Vagrant + VirtualBox 作為統一的授課環境，讓學員儘早習慣在 Linux 平台上探索 Docker 的底層與應用。

所以，當我在 2022 年 iThome 鐵人賽看到小賴的參賽作品【那些關於 docker 你知道與不知道的事】中，是以 AWS EC2 的 Ubuntu instance 作為實作環境，現在更出版新書《Docker 實戰 6 堂課：56 個實驗動手做，掌握 Linux 容器核心技術》，就非常高興。畢竟，從最擬真的角度切入，才能夠透過自己的雙手，掌握那不變的容器技術核心。

《Docker 實戰 6 堂課：56 個實驗動手做，掌握 Linux 容器核心技術》

很多人會問：現在都已經是 Kubernetes 當道的年代，我們還需要學習落伍的 Docker 嗎？還需要用這麼刻苦的方法學習落伍的 Docker 嗎？

既然 Kubernetes 正當紅，我們就從功利一點的角度來看這議題吧。Kubernetes 的三大認證考試 (CKA, CKAD, CKS) 中，不乏一堆上機實境題；如果你不懂得容器的底層技術：process、layer、namespace、network，將很難在現場上機時迅速精準排除問題——而且是用最傳統的終端機命令列方式進行。

既然這麼當紅的 Kubernetes 都要求你必須熟練這麼刻苦的方式，那麼，你為什麼不先從較單純的 Docker 容器環境下手呢？

小賴這本書有三大特點：底層知識，動手實驗，熱血工程魂。

特色一：底層知識

容器世界有許多神奇的特效，尤其是不同對象、不同層次的「資源隔離性」。透過本書，你可以親自看到 process、layer、namespace、network 這些磚頭是如何一步步撐起容器的華廈。

掌握這些「資源隔離性」的基礎知識，將來再看到 Kubernetes 的種種設計，必有會心一笑的熟悉感。

特色二：動手實驗

底層知識很枯燥，甚至抽象。透過動手實作，能具體看到這些要素活生生運作起來，而不是一堆死板板要你生吞硬背的理論。

作者以 AWS EC2 的 Linux instance 作為實驗環境，比起多數人採用 Windows 或 Mac 的 Docker Desktop 作為實驗環境，更能忠實反映容器的行為及底層狀況。更重要的是，及早領略在這種環境之下的操作及除錯經驗，未來在真實生產環境之下的操作、性能調教、除錯任務，自然駕輕就熟。

正如小賴所說：「親自動手做實驗與觀察，應該是工程師最基本的素養。」

特色三：熱血工程魂

由 Docker 起頭，至 Kubernetes 發揚光大，容器生態圈的技術，雖然貌似複雜，但藉由生態圈的卓越工藝，已經將複雜技術下放到凡間，只要你有心，都可以在本機端或雲端建置出堪用的實驗環境供你探索。

剩下的問題就是：你是否保有熱血工程魂？

我很喜歡小賴講的這段話：「那種『知道更多了』的感覺，根本就是工程師的鴉片，讓人難以抵抗。」

容器生態圈蓬勃發展，我們更需要小賴這本書，帶我們透過自己的雙手，掌握那不變的容器技術核心。希望大家藉由這本書，拾起熱血工程魂，重視底層知識，樂於動手實驗，在容器世界游刃有餘。

　　　　　　—— 敏捷魔藥師　葉秉哲 (William Yeh)　2023-08-19

書籍／課程推薦

Sat, 19 Aug 2023 00:00:00 +0000

敏捷

被 Yves 啟發的敏捷轉型之旅 —— 《敏捷管理生存指南：不是快，而是適者生存》推薦文

經理人視角的敏捷通識課 —— 【高效產出：突破資源限制的敏捷管理術】推薦文

管理

軟體研發者的隨身職涯教練 —— 《經理人之道》推薦序

值得你看門道的好書 —— 《獨角獸專案》推薦序

技術

透過自己的雙手，掌握那不變的容器技術核心 —— 《Docker 實戰 6 堂課》推薦序

讓 GitLab 成為數位轉型的重要推手 —— 《和艦長一起 30 天玩轉 GitLab》推薦序

換個 Design for Ops 的腦袋 —— 《SRE 工作現場直擊》推薦序

Coursera 上面的 GCP 課程

Tue, 25 Apr 2023 22:00:00 +0800

為了在公司內推動 GCP 認證考試，必須先推動大家勤修 GCP 課程；為了推動大家勤修 GCP 課程，我得先帶頭示範。因此，我最近在 Coursera 修了許多 GCP 認證考試相關課程 ¹，感觸很深：就算不考照，用這些課程補完一些知識，還是很值得的。

這些課程深度與廣度兼具，又有搭配實作演習，有系統地吸收，會比雜亂搜尋文件的碎片化學習來得踏實。

即使以俗氣的 C/P 值角度來說，這些課程也是物超所值的。像以下這門放在 Coursera 的課：

Google Cloud Big Data and Machine Learning Fundamentals

大家知道嗎？這樣的課，用同樣的 Google 原廠教材，改用國語發音 live 授課，在外頭可是喊價超過一萬元新台幣的。

我根據自己這些日子勤修課程的小經驗，推薦幾門有廣度有深度的課，讓想要對雲端環境有更廣更深認識的人參考。我大致將這些課程分類如下：

非技術的通識類
GCP 技術：共通核心
GCP 技術：K8s
Dev
DevOps & SRE
ML & Big Data

非技術的通識類

這類課程比較軟性，適合讓非技術底子出身的人也有機會體會雲端帶來的可能性。非技術人擁有雲端的基礎認知，與技術人的對話也才能更同調。

系列／Google Cloud Digital Leader Training Professional Certificate

Digital Transformation with Google Cloud
Innovating with Data and Google Cloud
Infrastructure and Application Modernization with Google Cloud
Understanding Google Cloud Security and Operations

系列／Digital Transformation Using AI/ML with Google Cloud (秀肌肉)

Business Transformation with Google Cloud
Infrastructure and Application Modernization with Google Cloud
Managing Machine Learning Projects with Google Cloud

其中，像 Managing Machine Learning Projects with Google Cloud 這門課提到最適合 ML 發揮的領域，是 “Challenging & Clear” 的問題：

最適合 ML 發揮的領域

這是不是與最近因為 ChatGPT 而颳起的 prompt engineering 風潮，有異曲同工之妙呢？

系列／Organizational Change and Culture for Adopting Google Cloud Specialization (秀肌肉)

Business Transformation with Google Cloud
Infrastructure and Application Modernization with Google Cloud
Managing Change when Moving to Google Cloud
Developing a Google SRE Culture

看到 Google 居然把 Developing a Google SRE Culture 招牌課程放到這裡，可見 Google 有多重視推廣 SRE 這理念了。

GCP 技術：共通核心

這類課程比較枯燥，但這是技術基礎，再枯燥也得撐過去。而且這類課程，是後續許多專項課程 (specialization) 都會涵蓋到的共同基礎，打好基礎，很容易繼續擴增廣度。

系列／Architecting with Google Compute Engine Specialization (秀肌肉)

Reliable Google Cloud Infrastructure: Design and Process
Elastic Google Cloud Infrastructure: Scaling and Automation
Google Cloud Fundamentals: Core Infrastructure
Essential Google Cloud Infrastructure: Core Services
Essential Google Cloud Infrastructure: Foundation

雖然此專項課程宣稱 “this program will also provide sample questions similar to those on the exam”，但好像未必有 100% 涵蓋到 “Associate Cloud Engineer” 應考前該知道的細節。

系列／Preparing for Google Cloud Certification: Cloud Engineer (秀肌肉)

Elastic Google Cloud Infrastructure: Scaling and Automation
Google Cloud Fundamentals: Core Infrastructure
Architecting with Google Kubernetes Engine: Foundations
Essential Google Cloud Infrastructure: Core Services
Essential Google Cloud Infrastructure: Foundation
Preparing for Your Associate Cloud Engineer Journey

系列／Preparing for Google Cloud Certification: Cloud Architect Professional Certificate

Google Cloud Fundamentals: Core Infrastructure
Essential Google Cloud Infrastructure: Foundation
Essential Google Cloud Infrastructure: Core Services
Elastic Google Cloud Infrastructure: Scaling and Automation
Reliable Google Cloud Infrastructure: Design and Process
Architecting with Google Kubernetes Engine: Foundations
Preparing for your Professional Cloud Architect Journey

三大系列洋洋灑灑，狀似龐大，但其實課程重疊度極高，就當成是一再複習加深印象吧。

GCP 技術：K8s

系列／Architecting with Google Kubernetes Engine Specialization (秀肌肉)

Google Cloud Fundamentals: Core Infrastructure
Architecting with Google Kubernetes Engine: Foundations
Architecting with Google Kubernetes Engine: Workloads
Architecting with Google Kubernetes Engine: Production

這專項課程，與 Udemy 三門 CKA/CKAD/CKS 認證考試課程相比，還算實用，可互補。

Dev

很多課程似乎都鎖定在 serverless 方案，因此，先把這張圖記下來（引述自 Application Development with Cloud Run 課程）：

GCP 的 serverless 方案

系列／Preparing for Google Cloud Certification: Cloud Developer (秀肌肉)

Securing and Integrating Components of your Application
Getting Started with Google Kubernetes Engine
Application Development with Cloud Run
App Deployment, Debugging, and Performance
Google Cloud Fundamentals: Core Infrastructure
Getting Started With Application Development

比較令我驚訝的是，最後一門課 Getting Started With Application Development 花了很多篇幅在講 Cloud Run，尤其是講它的 networking & security 設定，卻讓人覺得這個 serverless 方案沒有想像中那麼無腦即可使用。

Developing Applications with Cloud Functions on Google Cloud

身為 GCP serverless 另一員大將 Cloud Functions，值得好好掌握。

Service Orchestration and Choreography on Google Cloud

難得在 GCP 課程上看到這主題，很值得照著他的範例把玩一遍。

DevOps & SRE

系列／Preparing for Google Cloud Certification: Cloud DevOps Engineer (秀肌肉)

Logging, Monitoring and Observability in Google Cloud
Reliable Google Cloud Infrastructure: Design and Process
Getting Started with Google Kubernetes Engine
Google Cloud Fundamentals: Core Infrastructure
Developing a Google SRE Culture

Site Reliability Engineering: Measuring and Managing Reliability

這門課滿特別的，把 SRE 的 SLI/SLO 講得很仔細。譬如說，面對複雜系統，是否該臚列很多很多的 SLI？課程如是說：

You should aim to only have one to three SLIs covering each user journey, even if your system and user journeys are relatively complex.

我發現，在 OKR & OGSM 講究的精簡指標觀念，在 SRE 裡面也是。所以，不要以為落落長的指標才是好的。

ML & Big Data

這系列重頭戲，我還在苦苦追趕，請恕我此刻暫時無法寫出什麼心得。 :)

系列／Data Engineering, Big Data, and Machine Learning on GCP Specialization

Google Cloud Big Data and Machine Learning Fundamentals
Modernizing Data Lakes and Data Warehouses with Google Cloud
Building Batch Data Pipelines on Google Cloud
Building Resilient Streaming Analytics Systems on Google Cloud
Smart Analytics, Machine Learning, and AI on Google Cloud

系列／Machine Learning on Google Cloud Specialization

How Google does Machine Learning
Launching into Machine Learning
TensorFlow on Google Cloud
Feature Engineering
Machine Learning in the Enterprise

其中，像 How Google does Machine Learning 這門課提到的 “Responsible AI Development” 議題，值此生成式 AI (AIGC) 火熱的時刻，讀起來格外有感。

系列／Advanced Machine Learning on Google Cloud Specialization

Production Machine Learning Systems
Computer Vision Fundamentals with Google Cloud
Natural Language Processing on Google Cloud
Recommendation Systems on Google Cloud
Machine Learning in the Enterprise

系列／Customer Experiences with Contact Center AI - Dialogflow ES Specialization & Customer Experiences with Contact Center AI - Dialogflow CX Specialization

把玩一下聊天機器人吧。

以上就是我個人偏食的菜單，希望給大家一些啟發，好好善用這個深度與廣度兼具的大補帖吧。

對 GCP 認證考試相關課程感興趣的，可參考 “Google Cloud Certification: 2023 Guide” 一文。 ↩︎

Distroless Image 牛刀小試

Wed, 15 Feb 2023 22:00:00 +0800

距離上次重度探討「極簡化容器」已經快六年多了¹。這議題，以前可能只是某些人技術上的興趣，現在則可能是必要。

原因是：Docker Inc 的一些措施，讓人不得不慎重考慮替代方案。

搬家的必要

這陣子容器世界起了不少變化，除了眾所周知的「Docker Desktop 要收費了」規定 ²，另一個較少被提及影響是 Docker Hub 的緊縮政策：

Image CI 緊縮：Docker Hub 取消免費用戶的 automated builds 功能。 ³
Image pull 緊縮：Docker Hub 開始對未付費者施以較嚴格的限流措施。 ⁴

於是，未付費的人，不僅在使用 Docker Hub 時會受到管制，還會波及產製 image 的 CI pipeline，不時會遇到這樣的 “toomanyrequests” 限流警告：

Docker Hub 的 toomanyrequests 限流警告

要避開這限制，治標方法是：

架設 image proxy。 ⁵
註冊 Docker Hub 帳號，將帳密寫進 CI pipeline 裡，以獲得稍微寬鬆一點點的 rate limit 門檻。

治本方法，則得從兩方面著手：

Image 要從 Docker Hub 搬遷到 ghcr.io 之類的地方。
直接引用的 base image(s) 也必須從 Docker Hub 換成 gcr.io 或 ghcr.io 之類的地方。

其中 (1) 很簡單，只要會 CI pipeline 即可辦到，像 GitHub Action 就有許多現成的元件可用。

至於 (2) 則比較麻煩。當然啦，對於玩過「極簡化容器」技術的人來說，這也只是小事一樁。

Distroless image

以前玩 minimal image 的人，是以 alpine 系列為大宗，只要不介意背後用的是 musl libc，這可以產生非常 “minimal” 的 image。近來 Google 的 “distroless” images 則提供 glibc 偏好者的另一種選擇，儘管它不算是 “minimal”，但也稱得上是 “small-enough”。

曾經我也是追求 minimal docker image 的一族 ¹，現在我只求 small-enough 就好。畢竟對大多數應用場景來說，像以下這兩個 image，一個約 8 MB，一個約 29 MB，差異其實是可以忽略不計的：

Image	Size (MB)	Base
docker.io/williamyeh/wrk:4.0.2	8.347	alpine3
ghcr.io/william-yeh/wrk:4.2.0	28.76	gcr.io/distroless/cc-debian11

兩種 image 的 layers

可是，若以資安角度來看，8.347 MB 的 image 被挑出許多漏洞，這很顛覆「alpine 又小又安全」的既定印象：

以 Alpine 的 musl 生態系產製的 image 被偵測出許多資安漏洞

反觀 28.76 MB 的 image 卻比較安全，這也很顛覆「glibc 系列不安全」的既定印象：

以 Debian 的 glibc 生態系產製的 image 資安漏洞反而較少

因此，我會建議，對大多數應用程式來說，選擇 Google 的 distroless 路線，可以省下許多與 alpine 相容性搏鬥的精力，又可以享受到許多好處：

有 Google 在維護。
Base image 的所在地 gcr.io 沒有限流問題。
透過 multi-stage builds 機制，沿用既有工具鏈即可輕鬆製作。

對於 distroless 感興趣的，請參考 “What’s Inside Of a Distroless Container Image: Taking a Deeper Look” 這篇文章。

詳見〈為什麼要追求極簡化的 Docker image？〉一文。 ↩︎ ↩︎
Docker Desktop 新規定：只要公司超過 250 人，或是年營收超過美金千萬，就必須付費。根據 Docker FAQs 文件所載：“Docker Desktop requires a paid, per-user subscription for organizations with more than 250 employees or more than $10 million in annual revenue per our terms of service. [..] The updated terms for Docker Desktop were effective August 31, 2021, with a grace period until January 31, 2022.” ↩︎
根據 Docker Hub “Set up Automated Builds” 文件所載：“The Automated Builds feature is available for Docker Pro, Team, and Business users. Upgrade now to automatically build and push your images.” ↩︎
根據 Docker Hub “Download rate limit” 文件所載：“For anonymous users, the rate limit is set to 100 pulls per 6 hours per IP address. For authenticated users, it’s 200 pulls per 6 hour period. Users with a paid Docker subscription get up to 5000 pulls per day.” ↩︎
其實有規模的組織，本來就應該自行架設 image proxy，以做好 artifact management。對這主題感興趣的，請參考 “Mitigate the Docker Dilemma with a Proxy Cache” 一文。 ↩︎

WSL Image 匯出與匯入

Thu, 09 Feb 2023 22:00:00 +0800

經過一番辛苦調教，總算把 WSL 調整成可推廣到團隊使用的地步。下一步就是要輸出成 WSL 公版。

謹以此文記錄匯出與匯入 WSL 映像檔的步驟與除雷經驗。

前置作業：查看已安裝的軟體清單

在匯出成公版之前，先查看已安裝了哪些軟體：

# 查看已用 apt install 安裝了哪些軟體
% apt list --installed

# 查看已用 brew install 安裝了哪些軟體
% brew list

# 查看手動下載安裝了哪些軟體
% ls -al /usr/local/bin

前置作業：清理內容

在匯出成公版之前，記得先清理一下機敏資料。譬如：

檢視一下 ~/.ssh
檢視一下 ~/.kube
檢視一下 ~/.gitconfig
檢視一下其他重要的 dotfiles

也記得清理一下足跡：

清理一下 ~/.*_history
清理一下 /var/log

前置作業：預設登入用戶

踩雷經驗：匯出再匯入 WSL 映像檔之後，再登入的身分會是 root。

為了避免此事發生，請在匯出映像檔之前，先編輯 WSL 設定檔 /etc/wsl.conf 如下：

[user]
default=預設的登入帳號名稱

匯出映像檔

先在 PowerShell 查看一下現在系統裡有哪些 WSL 設置：

wsl -l -v
---
  NAME            STATE           VERSION
* Ubuntu          Running         2
  Ubuntu-22.04    Stopped         2

假設 Ubuntu 就是我們想要匯出的標的，請輸入以下命令：

# 停止 "Ubuntu" 個體
wsl -t Ubuntu

# 將 "Ubuntu" 個體匯出至 "my-image.vhdx" 映像檔
wsl  --export Ubuntu  --vhd my-image.vhdx

映像檔可能很大。建議對它產生一份 hash，以供比對。¹

匯入映像檔

假設我們想從 my-image.vhdx 映像檔匯入到一個名為 dev 的 WSL 個體，請輸入以下指令：

# 將 "my-image.vhdx" 映像檔匯入到名為 "dev" 的 WSL 個體，
# 並在 C:\WslDisk 建立虛擬硬碟
wsl --import dev  C:\WslDisk  my-image.vhdx  --vhd

# 看看是否匯入成功
wsl -l -v
---
  NAME            STATE           VERSION
* Ubuntu          Stopped         2
  dev             Stopped         2
  Ubuntu-22.04    Stopped         2

你在 Windows Terminal 應該可以看到多了一個名為 dev 的終端機選項：

測試

既然是要給研發團隊用的公版，自然要登入看看是否一切正常。就以這陣子在實驗的 Laravel Sail 環境為例 ²：

如果有問題，就得卸載這份有瑕疵的 WSL 個體，回到源頭繼續修改：

# 停止 "dev" 個體
wsl -t dev

# 卸載 "dev" 個體
wsl --unregister dev

如果還有預設登入帳號的問題

在前置作業時，曾經透過 WSL 設定檔 /etc/wsl.conf 避免預設登入帳號變成 root 的問題。如果此法無效，請根據這份建議，用 Windows 登錄編輯程式 regedit.exe 去修改 Windows registry：

Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss\{某一個}
Name: DefaultUid
Type: 請切換成「十進位數字」
Data: 請設成 1000 （十進位數字）

萬一還無效，請參考 “How to set default user for manually installed WSL distro?” 一文的討論。

在 Windows 可透過 certutil 或 Get-FileHash 指令取得檔案的 hash 值。詳見 “5 Ways to Generate and Verify MD5 SHA Checksum of Any File in Windows 10” 一文。 ↩︎
詳見〈用 Podman 執行 Laravel + Sail〉一文。 ↩︎

用 Podman 執行 Laravel + Sail

Tue, 07 Feb 2023 22:00:00 +0800

從 Docker Desktop 換到 Podman ¹ ，開始需要處理某些相容性問題。有些問題不見得是 Podman 的錯，但既然遇到了，就順手記錄一下除雷經驗。

此文記錄一下在 Podman 執行 Laravel 9 欽定開發環境 Sail 的步驟。

前置作業：安裝 Podman

如果你是 Linux 用戶，請依照 Podman 官方文件所載步驟安裝 Podman。

如果你是 Windows 用戶，請根據〈WSL2 + Podman + K3s 組合技〉一文安裝 WSL2 + Podman。

如果你是 Mac 用戶，請先用 brew install podman 來安裝。但據說 multipass + Podman 方案更好，我會再找時間實驗。

前置作業：Podman daemon mode

Laravel 的 Sail 需要用到 Docker Compose，而且它的 docker-compose.yml 又寫得⋯⋯很需要是以 daemon mode 運作的 container engine。

所以，請根據〈Podman Tips〉一文的步驟，啟動一個 daemon mode 的 Podman。

前置作業：解決 Composer 連線問題

有些人在透過 Composer 安裝套件的過程中，會出現 repo.packagist.org 連線 timeout 的問題：

curl error 28 while downloading https://repo.packagist.org/packages.json:
    Connection timed out after 10000 milliseconds

請參考這篇解法，將 repo.packagist.org 的 IPv4 位址直接寫死到 /etc/hosts：

% dig +short repo.packagist.org

% echo "`dig +short repo.packagist.org` repo.packagist.org" >> /etc/hosts

如果你是身處 WSL2 環境，也請順便編輯一下 WSL 的設定檔 /etc/wsl.conf 以避免設定消失：

[network]
# Disable auto-gen /etc/hosts
generateHosts = false

安裝 Sail

請依照 Laravel 官方文件所載步驟，安裝一整套 PHP + Composer + Laravel + Sail + blah blah blah 本地開發環境，也順便建立一個名為 “example-app” 的新專案：

% curl -s "https://laravel.build/example-app" | bash

修改 Sail 產生的專案設定

透過 Laravel + Sail 產生的專案，預設會跑在 port 80。我建議修改到其他 unprivileged port 以減少問題。

請在專案的 .env 檔案添加這一行：

APP_PORT=3001

透過 Laravel + Sail 產生的專案，storage 目錄可能會有存取權限的問題。請參考這篇解法：

% chmod o+w ./storage/ -R

或是保守一點：

% chmod o+w ./storage/logs/       -R
% chmod o+w ./framework/cache/    -R
% chmod o+w ./framework/sessions/ -R
% chmod o+w ./framework/views/    -R

執行 Sail

請依照 Laravel 官方文件所載步驟，執行 “example-app” 專案：

% cd example-app

% ./vendor/bin/sail up

如果一切順利，可以用瀏覽器看到 http://localhost:3001/ 順利執行：

也順便看看整個 Laravel 產生的本地開發環境含有哪些東西：

僅以這篇文章示範，只要懂得排雷，Podman 足以勝任 Docker Desktop 的角色。

詳見〈WSL2 + Podman + K3s 組合技〉一文。 ↩︎

Podman Tips

Tue, 07 Feb 2023 20:00:00 +0800

從 Docker Desktop 換成 Podman，有些習慣必須做些小調整。此文記錄一些常用的小技巧。

Image tree

很久很久以前，我們可以用 docker images --tree 來看 image layer 的層次關係。此功能選項被後來某一版 Docker 廢除了，於是就有一些替代方案來做這件事：

可惜的是，這些工具都假設現在是處於「有一個 daemon 跑在 DOCKER_HOST」的環境（畢竟這是 Docker 的老規矩）。如果我們不想為此而刻意以 daemon 模式啟動 Podman，可透過 Podman 的 image tree 指令來檢視 image：

% podman image tree python:3.9.16

Daemon mode

儘管 daemonless 的好處很多，但很多舊世界的工具，會假設現在是處於「有一個 container engine daemon 跑在 DOCKER_HOST」的環境。因此，有時候我們得故意讓 Podman 以 daemon mode 運行。

臨時性實驗

我們先啟動一個 rootless Podman process：

% podman system service -t 0

另開一個終端機視窗，設置 DOCKER_HOST 環境變數：

% podman info --format={{".Host.RemoteSocket.Path"}}

% export DOCKER_HOST=unix://$(podman info --format={{".Host.RemoteSocket.Path"}})

現在，我們可以在這個終端機實驗看看那些舊世界的工具是否可以正常運作。就以前面提到的 dive 為例吧！

% dive python:3.9.16

便利性設置

如果一切正常，我們可以寫一個 /usr/local/bin/start-podman-service.sh 程式以簡化啟用流程：

#!/bin/bash

FILE=/var/run/docker.sock
if [ ! -f "$FILE" ]; then
    sudo ln -s /run/user/$(id -u)/podman/podman.sock $FILE
fi

echo "Starting podman as server... Ctrl-C to stop."

exec podman system service -t 0

在不需要時，按下 Ctrl+C 即可關閉，非常方便。

持久性設置

如果你想透過 systemd 來管理，請參考 K3d 團隊提供的 Using Podman instead of Docker 這篇文章。

WSL2 + Podman + K3s 組合技

Mon, 06 Feb 2023 22:00:00 +0800

距離上次重度使用 WSL 已經快四年了。四年來 WSL 世界起了一些變化：

WSL 已經演進到第二版。
以前還會為了要搭配 Cmder 或者 WSLtty 而大費周章，現在則被 Windows Terminal 解決了大部分問題，使用體驗也開始接近 Mac 的 iTerm2。

容器世界也起了很大的變化：

Docker Desktop 新規定：只要公司超過 250 人，或是年營收超過美金千萬，就必須付費。¹ Docker Hub 也開始對未付費者施以較嚴格的限流措施。 ²
Kubernetes 從 1.24 起停止支援 dockershim。 ³
RedHat 釋出的 Podman，挾其完全免費、daemonless、rootless、pod 的特性，開始吸引對 Docker 起異心的人。

因此，我也趁此機會更新這方面的資訊，以免費的組合技，在 Windows 上盡量復刻 Mac 的容器體驗：

以 WSL 2 與 IDE 的整合，兼顧命令列與 GUI 體驗。
以 Podman 取代 Docker Desktop 的 container engine。
以 K3s 取代 Docker Desktop 的 Kubernetes。

註：如果不想以 WSL 2 為工作環境 (1)，單純只想要一個 Desktop Desktop 替代方案 (2 + 3) 的人，可以直接選用 Rancher Desktop，就不必往下看了。

WSL 2

請依照保哥的文章〈介紹好用工具：從 Microsoft Store 安裝 WSL 1.0 版〉進行以下步驟：

更新 Windows 版本（譬如說，Windows 10 請更新至 22H2 以上，並確定套用過 KB5020030 patch）。
安裝 WSL。
更新 WSL 版本：wsl --update。
查看 WSL 版本：wsl --version。

如果一切順利，應該會看到類似以下的畫面：

請確定 WSL 版本是 1.0.3.0 以上，否則接下來可能會遇到一堆稀奇古怪的問題。 ⁴

接下來，請繼續透過 WSL 安裝 Linux：

安裝一個 Linux distribution。
第一次執行 WSL，並設定 Linux 的帳號密碼。

建議編輯一下 WSL 的設定檔 /etc/wsl.conf：

[boot]
systemd=true

[network]
# Disable auto-gen /etc/resolv.conf
generateResolvConf = false

# Disable auto-gen /etc/hosts
# @see https://github.com/composer/packagist/issues/950#issuecomment-424913225
generateHosts = false

如果要避免 WSL 占用過多系統資源，可編輯 Windows 的 $env:USERPROFILE\.wslconfig 檔案如下：

[wsl2]
memory=4GB
processors=2

如果要讓 Windows 慣用的 IDE 能夠與 WSL 合作順暢，請參考相關的設定：

VS Code 需要安裝 WSL extension。
JetBrains 的工具，各有對應的文件說明，像 GoLand 可直接使用，PHPStorm 則需透過 PHP remote interpreters plugin。

Zsh + Oh My ZSH + Homebrew

在 WSL 中安裝 zsh 及 oh-my-zsh：

% sudo apt-get install zsh

% sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

將 zsh 設為內定 shell：

% chsh -s $(which zsh)

如果你的 zsh theme 含有許多特殊的符號字元，請順便安裝 Powerline 系列字型。

Mac 族群一向愛用 Homebrew。既然它也搬到 Linux 世界了，就來安裝吧！

% sudo apt-get install build-essential curl file git
% sh -c "$(curl -fsSL https://raw.githubusercontent.com/Linuxbrew/install/master/install.sh)"

% # 請記得要遵照安裝畫面出現的步驟做最後的設定！

Podman

透過 WSL 安裝好 Linux 之後，其實我們大可在裡面安裝純粹的 Docker Engine](https://docs.docker.com/engine/install/)，即過去俗稱的 CE 版 (community edition) 或 Moby，它採用 Apache License 2.0 授權，不會有 Docker Desktop 的收費問題。

不過，我還是想玩玩具有 daemonless & rootless 特性的替代方案：Podman。

安裝

請依照 Podman 官方文件所載步驟安裝 Podman。譬如說，如果 WSL 的 distribution 是 Ubuntu 22.04.1 LTS，可如此安裝：

% sudo apt update
% sudo apt -y install podman

或是直接透過 Homebrew 安裝。好處是容易更新版本，缺點是安裝較慢：

% sudo apt install uidmap
% brew install podman

設定

Podman 是 daemonless + rootless 的架構。如果你希望讓 container 能夠自由綁定 port 80 以利本地開發，可以考慮在 /etc/sysctl.conf 添加設定：

net.ipv4.ip_unprivileged_port_start=80

還有一個選擇性步驟。如果你希望讓 image 不會被綁在 docker.io/library/ 這個預設的 registry，可以考慮在 /etc/containers/registries.conf 添加設定 ⁵ ：

unqualified-search-registries=[
  "registry.access.redhat.com", "registry.fedoraproject.org",
  "quay.io",
  "gcr.io",
  "ghcr.io",
  "docker.io"
]

便利性

為了讓 Podman 能盡量沿用過往 Docker 的使用習慣，建議在 $HOME/.bashrc 添加 alias：

alias docker='podman'

如果遇到 alias 也無法避開的問題，建議索性放一個 /usr/local/bin/docker 檔案：

#!/bin/bash

exec podman "$@"

Podman play kube

Podman 有一個介於 Docker 與 Kubernetes 之間的功能：pod。如果懂得善用，在許多情況下可以取代 Docker Compose，也做為邁向 Kubernetes 的踏腳石。

譬如說，如果我們稍加修改 Kubernetes 官網的 pod 範例 simple-pod.yaml：

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
    - name: nginx
      image: docker.io/library/nginx:1.14.2
      ports:
        - containerPort: 80
          hostPort: 8080     # add this line

接下來就可用 podman play kube 指令在 WSL 啟用這個 nginx-pod：

% sudo podman play kube simple-pod.yaml

如果一切順利，就可以在 WSL 裡面看到 nginx pod 成功執行：

% podman pod ps
POD ID        NAME        STATUS      CREATED            INFRA ID      # OF CONTAINERS
46be4ed3a73f  nginx-pod   Degraded    About an hour ago  93d658fa1939  2

% wget -O - localhost:8080

也可以在 Windows host 用瀏覽器看到 nginx 順利執行：

Podman Compose

Kubernetes 生態圈有一大堆媲美 Docker Compose 便利性的工具（譬如我愛用的 Skaffold）。不過，如果你實在太想念 Docker Compose，有兩種做法：

➀ 可直接沿用舊的 Docker Compose，但是需要將 Podman 啟動成 daemon ⁶ 。

Docker Compose 的安裝方法：

% sudo curl -SL https://github.com/docker/compose/releases/download/v2.15.1/docker-compose-linux-x86_64 -o /usr/local/bin/docker-compose

% sudo chmod +x /usr/local/bin/docker-compose

➁ 如果不需顧及相容性，不妨試試 Podman 陣營端出的替代品 Podman Compose。

對於 Podman Compose 感興趣的，請參考以下文章：

K3s

K3s 是由 Rancher Labs 貢獻給 CNCF 的輕量級 Kubernetes 開源方案，很適合應用程式開發者使用，作為 Docker Desktop 內建 Kubernetes 的替代方案。

請依照 K3s 官方文件所載步驟安裝： ⁷

% curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" sh -

為了讓其他 Kubernetes 相關工具順利運作，建議在 $HOME/.bashrc 添加 KUBECONFIG 環境變數：

export KUBECONFIG="~/.kube/config:/etc/rancher/k3s/k3s.yaml"

K9s

K9s 是很方便的 Kubernetes 終端機工具，請依照官方文件所載步驟安裝：

% brew install derailed/k9s/k9s

現在，我們可以用 k9s 指令查看剛剛安裝好的最陽春的 K3s 環境到底跑了哪些東西：

全部看一遍

截至目前為止，我們安裝好了 Podman 及 K3s，也利用 Podman 啟動一個 nginx pod。現在，讓我們看看整個 WSL 系統的 process tree：

整個 process tree 非常扁平，是不是跟以前 Docker Desktop 的版本很不一樣呢？

希望這篇文章，能夠讓你更放心擺脫 Docker Desktop。

根據 Docker FAQs 文件所載：“Docker Desktop requires a paid, per-user subscription for organizations with more than 250 employees or more than $10 million in annual revenue per our terms of service. [..] The updated terms for Docker Desktop were effective August 31, 2021, with a grace period until January 31, 2022.” ↩︎
根據 Docker Hub Download rate limit 文件所載：“For anonymous users, the rate limit is set to 100 pulls per 6 hours per IP address. For authenticated users, it’s 200 pulls per 6 hour period. Users with a paid Docker subscription get up to 5000 pulls per day.” ↩︎
關於 Kubernetes 1.24 停止支援 dockershim 的始末，請見 Updated: Dockershim Removal FAQ 這份文件。 ↩︎
譬如說在 “Systemd support is now available in WSL!” 一文就提到，如果 WSL 版本過舊，甚至連 Linux systemd 功能都會有問題。 ↩︎
關於 registries.conf 的更多設定內容，請見 How to manage Linux container registries 一文。 ↩︎
關於將 Podman 以 daemon mode 運作的具體步驟，請參考〈Podman Tips〉一文。 ↩︎
大部份的人會依照 K3s 首頁所載的步驟 curl -sfL https://get.k3s.io | sh - 來安裝 K3s，但這樣安裝好的 K3s 常會需要動用 sudo 才能執行相關指令。我認為，與其事後再用 k3s permission denied when using kubectl 所介紹的方法調整設定，不如從一開始就以不需動用 sudo 的方式安裝。 ↩︎

2022 個人回顧

Sun, 18 Dec 2022 22:00:00 +0800

去年年終回顧文中，我曾半戲謔說道：自己好像都在消費之前外商經驗的戰備存糧。

今年，這份感受更加明顯，甚至連台商新創經驗都動用到了。

到了年終，又開始要做個總回顧，再對來年許願。去除一些不便揭露的事情，以下是簡單的回顧。

補血課程

這一年，由於 COVID-19 因素，參加的實體或線上 Live 課程，就只有這兩場：

Team Kanban Practitioner：由我邀請老師來授課的。原本我只是安排給其他主管同仁去上課，後來索性自己也加入共學，後續的跟進措施較能落實。
TTT 二日課程：由公司舉辦的。原本我打算安排給其他種子教師同仁去上課，後來索性自己也加入共學，不僅後續的跟進措施較能落實，也藉此自我補齊相關基礎——畢竟自己在 2018 年上的【體驗式課程的遊戲設計與操作實務】三日課程，可說是一下子就跳級到進階版了，我想回頭再親身體驗一下基礎版。

TTT 試教 (2022-12-14)

公開演講及授課

今年，由於 COVID-19 因素，再加上自覺已經過了能夠恣意跑趴出沒社群活動的人生階段，婉拒許多邀約，只接了一場公開工作坊：

敏捷轉型：目標管理工作坊

敏捷轉型：目標管理工作坊 (2022-08-31)

反之，如果是在公司的上班時間、用公司的場地舉辦活動，安排起來較有餘裕，也就順勢辦了好幾場。像我的招牌課程【Agile Workshop / 敏捷原理與團隊塑造】及後續跟進的種種專題工作坊，次數已經難以計算。

Agile Workshop 一日版

關於我的 Agile Workshop，除了當年某個公開班可以開出豪邁的二日版，後來都只能客製化組裝出一日版。好在經過多年錘鍊，已經模組化到能夠彈性端出 1 hr、2 hrs、4 hrs、8 hrs、12 hrs、16 hrs 不同套餐，能將 Impact Mapping、Kanban、Scrum 都實彈演練到一個地步，積木玩到了，電影也看到了。

順便推出一個 20 分鐘快速介紹 Scrum 的影片，以後就可以叫學員先看完影片再來上課：

內部導讀會

去年年終回顧文中，我曾許願要「每個月辦一場 2hr 導讀會」。

原本只是一個單純的動機：

我開始每個月一次，每次兩小時的【職涯躍升書系導讀會】，讓公司同仁自由報名，希望藉由這種草根性的軟性活動，另闢一條 bottom-up 的改革路徑。畢竟，深遠持久的影響，不能少掉「喚醒基層意識」這環節。

我也想藉此機會刻意練習「金字塔原理」一整年（是的，我以金字塔原理來進行每一場導讀會）。

沒想到才舉辦了一次，就遇到疫情攪局，分流上班，活動得移往線上進行，大大考驗我線上引導活動的能力。為此，努力師法福哥【線上教學防疫補給包】及 Miro-Miro on the Wall webinar 的經驗，順利完成了好幾場，甚至連《克服團隊領導的五大障礙》介紹的「Personal History Exercise」如此心理層面的活動都能夠在線上進行，讓我鬆了一口氣，私房工具箱又增添一項利器。

《克服團隊領導的五大障礙》導讀會

一整年下來，不知不覺也導讀了這麼多本：

每重讀一次，形同再次自我療癒了一次。畢竟，改革者、先行者是孤獨的。

或許會被認為我在散發所謂的「有毒思想」，但只要看到還有一些人能被啟發思考，那就值得了。

內部培訓：主管的修練

我很愛用「讀書會」這一招，甚至把它當成另一種培訓形式。像當年我在Ｇ公司辦的【主管的修練／讀書會】就是這樣進行的。

這陣子我又祭出這一招，舉辦七次內部培訓：

俗話說，小孩子的成長不能等。

同樣的，主管梯隊的成長也不能等。

因為不能等，所以，我就主動起個頭吧。

我將於九月開辦【主管的修練】課程，總共七堂，每次 2 小時。課程將探討初階中階主管的六大課題：領導與管理思維、參與式決策、人才管理教育和支持、溝通與衝突化解、團隊績效的考核標準、團隊文化和核心信念。

因為是我起的頭，所以，請容我任性地設下【主管的修練】課程的總規定：

① 課程以個案研討形式為主，有大量課堂討論，學員需要依照進度先行閱讀指定讀物。能配合的，再考慮參加。

② 有些個案討論有隱私性考量，為促成坦誠討論，參與者需宣誓對現場討論內容保密 (咦)。

如果你無法配合這些規定，請不要勉強參加，請選擇你能夠接受的其他培訓機會。

為了維持課程品質，此課程人數上限為 24。

如果課程反應不錯，明年還會擇期再開新梯次，所以這次向隅者不必擔心。如果課程反應不佳，就不值得再開新的梯次，所以這次向隅者也沒什麼損失。

我也將每堂課一開頭的導讀部份錄影下來，以後再舉辦時，時間就可以節省下來，直接進入互動討論環節，畢竟這才是最精華的部份——這門課有趣的地方，就是思辨：

有同事笑著說：跟著我的這一年，是他脫離學生身分之後，讀書最密集的時光。

這也是我舉辦這些活動背後想要傳達的訊息：要多讀書，看看外面世界；離開穴居人的世界，成為現代人。

【主管的修練】部份回饋。

內部 Memo

忙碌的一年，除了動嘴動手的活動之外，我也寫了許多內部 memo，最高紀錄一週寫了三篇，可惜多半都不能在此刻對外公開。能公開的只有：

重要的事情，似乎還是免不了要 over communication，不能冀望看一次或聽一次就明白。寫下來，有助於一再端出來複習覆述。畢竟 Ray Dalio 在《原則》說過：

要知道，幾乎所有「眼前情況」都只是「情景再現」。找出是哪一種「情景」，然後應用深思熟慮的原則加以處理，這將讓你大量減少必須決定的數量，並引領你做出更好的決定。

你若是不斷以這種方式思考，就會成為一個卓越的有原則思考者。

我打趣說：一年來寫的內部 memo，將來搞不好可以集結出書。

邀請專家進行教育訓練

改革者、先行者是孤獨的。

只是一味苦口婆心勸說大家放下成見、擁抱改變、試著與世界潮流同步，會被認為只是一己的固執偏見。因此，我邀請外面世界的先進過來現身說法，讓局中人驚覺：這個書呆子說的話是真的，外面世界真的就是這樣運作的。

邀請專家的專題講座計有：

遠距工作的甘苦談與訣竅 (by Ailin Liou)
敏捷組織下之人才培育 (by Tess Fang)
17Live SRE 從無到有心法 (by Sammy Lin)
MaiCoin SRE 演進經驗分享 (by Smalltown)
Titansoft 的 Craftsmanship 精進之旅 (by Eviler)
那些年我們做過的 DevOps Pipeline (by 艦長)

邀請專家的實體或線上課程計有：

Git 版本控管實戰：新手進階篇 (by 保哥)
專案管理第一次就上手 (by Rex)
如何寫出人人有共識的需求：範例描述需求篇 (by David Ko)
ES6 + React (by 龍哥、奶綠茶)
Team Kanban Practitioner (by 柳丁)
單元測試 (by 某低調大神)
GCP Onboarding Courses
產品數據分析與關鍵指標設計 (by Hans)

感謝許多業界朋友賣我面子，尤其是在疫情期間仍然排除萬難給予精彩的分享，在此獻上敬意。

外面的世界

2022 這一整年回顧起來，我好像花了極大精力在傳教佈道：用課程、導讀會、文章，甚至到了有點雞婆的地步。

巧合的是，這正好與我所屬教會的 2022 年度命名相暗合：

「主的靈在我身上，因為祂用膏膏我，叫我傳福音給貧窮的人，差遣我報告被擄的得釋放，瞎眼的得看見，叫那受壓制的得自由。」 (路 4:18)

傳教佈道，需要傻勁。

以我來說吧，每次聽到有人漠視外面世界的先進們熬煉了一、二十年才得出的進步觀念，就會想到《海賊王》裡蒙布朗・諾蘭德的這段話：

From: One Piece, Vol. 31, Episode 289

外面的世界當然不見得是好的，不見得是匹配的，也不見得永遠是對的；不過，就如同我在某篇 memo 所說：

我們不是預言家，無法鐵口直斷像「在 VUCA 時代，feature team 優於 component team」這種觀點的壽命究竟有多長，不過，如果我們的智慧，沒有國際專案管理學會 (PMI) 高，沒有大型敏捷框架 LeSS 高，沒有 DevOps 大師高，那麼，試著放下舊的成見，試著瞭解一下 feature team 的論述，試著與世界潮流同步吧——尤其在我們還沒有與世界潮流碰撞的實力與實績。

Scrum 培訓：全局觀 (2022-11-17)

早一點與世界接軌，早一點主動與世界接軌，總比被迫與世界接軌來得從容——我們非要等到黑船來航才痛定思痛進行明治維新嗎？

未央歌

記得年初自己 OGSM 的 O 是這麽寫的：

建設 Focus, Flow, Joy 的研發環境，以支持企業目標。

計劃趕不上變化。只能把缺憾還諸天地。

2023 許願

2023 年，希望自己能做到：

~~每個月辦一場 2hr 導讀會~~ 換個形式，進行專題式的系列講座。
繼續更深度的本質修練。
繼續增進商務英語聽說能力。
開放冒險選項。

就醬。

Poster - Agile Girls

職涯躍升書系導讀會，Part 3：職場心理：觀點、期待、渴望

Tue, 29 Nov 2022 20:00:00 +0800

2022 年一月起，我開始每個月一次，每次兩小時的【職涯躍升書系導讀會】。前六個月著眼於喚醒個人及團隊的成長意識，接下來兩個月著眼於高效團隊的工作方法，最近三個月則著眼於心理層面，尤其是觀點、期待、渴望。

這三個月的選書如下：

① 薩提爾教練模式
② 為什麼上班這麼累？其實是你心累
③ 兩本與 Accountability 有關的書：QBQ ＆當責

以下列出這三場導讀會的介紹文案。

薩提爾教練模式

Dear all,

回顧過去，我認為，對我個人職涯影響最大的書籍有三，其一是形塑我職涯升級打怪路線圖的書《三年後，你的工作還在嗎？》（已於 2022/02 導讀會探討過），其二是我的管理啟蒙書《目標》，其三則是這次要介紹的書《薩提爾教練模式》。

《薩提爾教練模式》影響我的地方有三。

① 心理學。職場是由「人」構成的，對「人」瞭解愈透徹，愈能在職場這樣的賽局中游刃有餘或趨吉避凶。

這本書早在 2015 年就很有創意地（可能也是全球首創）將家族治療領域赫赫有名的薩提爾 (Satir) 方法轉化運用到職場領域，是既前衛又前瞻的混搭。被這本書啟蒙之後，促使我 2017 年親自去上了整整九天的薩提爾方法培訓，在許多層面徹底改變了我。

談職場心理的書很多，但從薩提爾如此深層的角度切入，此書可說是濫觴。之後，陸陸續續在許皓宜、周慕姿、錢慧如、汪士瑋等人的職場書籍或課程中，就開始看到這種混搭的例子。

② 引導。團隊是由「人」緊密構成的，對於協作需求愈高的團隊（尤其是 Scrum），愈需要對於團體動力的深刻瞭解，才能夠在適當的時機、以適當的力度去引導團隊。

透過這本書提到的薩提爾模式，有助於辨識團體動力，辨識可用來引導團隊的施力點：感受、觀點、期待、渴望——這些都是 Scrum retrospective meeting 的私房法寶。

③ 教練。如同我在〈2021 個人回顧〉一文的感慨：

「有人教導基本動作嗎？」

「每個人都各打各的，完全不團結。」

「球隊的教練到底在搞什麼？」

其實，中高階主管也極需要 coaching。

《薩提爾教練模式》這本書，就是極佳的教練指引。

如果你也認為，在職場上，有需要在心理學、引導、教練這三方面精進，邀請你好好讀讀《薩提爾教練模式》這本書。

為什麼上班這麼累？其實是你心累

Dear all,

繼九月份導讀會選書《薩提爾教練模式》之後，我決定十月份再度選擇一本職場心理學的書與大家分享：許皓宜的《為什麼上班這麼累？其實是你心累》。

為什麼連續兩次都要與心理學有關呢？因為在過去數個月以來，旁觀同仁之間的大小內外碰撞，普遍出現一個阿德勒式的感慨：

所有煩惱，都是人際關係的煩惱。

此外，在八月及九月《時間管理的 30 道難題》及《領導的黃金法則》這兩本書的討論現場，也都出現一個普遍的靈魂叩問：

我不知道我真正要的是什麼。

這些靈魂叩問，恐怕不是訴諸催眠式的激勵，或心靈雞湯式的轉念，就能夠得到解答。

面對這些問題，許皓宜老師在《為什麼上班這麼累？其實是你心累》書中的分析是：

為何工作這麼累？其實不是工作本身的問題，而是我們的心「迷路」了的問題。換句話說，那種「疲累」的感覺，與其說是「工作」帶給我們的，不如說是「心態」（心的狀態）影響我們的。

請容我用此刻對心理學的理解來描述「累」的意義：它是一種心靈的呼喚，告訴我們得要停下腳步（不是停下工作），去看看自己內在空間受到什麼擠壓。

這本書，用十一個角度，帶讀者重新回到自己的內心，自己的工作初心，甚至面對自己的內在小孩，與他對話。

這本書，有大約三十幾則故事，很好讀。也請你在閱讀之前，試著打開塵封已久的真心去讀，讓薩提爾、榮格、阿德勒、佛洛伊德，幫你重塑心理資本 (psychological capital)。

你有多久沒有找個靜謐的所在，打開塵封已久的真心呢？

試試看吧。

兩本與 Accountability 有關的書

Dear all,

自從去年十一月來到這裡，我常常必須提醒自己，要用另外一種方法對自己說話。

面對工程議題，我不能一直抱怨說：「都什麼年代了，這裡的人怎麼如此亂用 Git 呀？」

我必須停下來，試著對自己發問：「是的，現況糟透了。我還能做些什麼，以取得我想要的成果？」

面對這問句，我開始發想：「最佳做法，是請專家來上課。」

不過，疫情期間，怎麼請專家來上課？

面對這問題，我不能一直抱怨說：「因為疫情攪局，沒辦法找專家來教大家 Git，因此，以 Git 為樞紐的 DevOps 起手式，乃至於後續種種的 CI/CD 大構想，也只能延到疫情降溫之後再說了。」

我必須停下來，試著再一次對自己發問：「是的，現況糟透了。我還能做些什麼，以取得我想要的成果？」

面對這問句，我開始發想：「是否可以請專家進行線上教學？就算效果可能不如實體課程，但總是往前推進了一步，勝於原地踏步。」

於是，我與保哥通話，也才有之後三個梯次的 Git 線上教學，在 2022 年三月，終於讓 Git 變成整個技術部同仁的共同工程語言。

面對專案管理議題，我不能一直抱怨說：「都什麼年代了，這裡的人怎麼如此亂用 WBS 呀？怎麼都不好好分析利害關係人呀？怎麼都不談談風險呀？怎麼都只會報流水帳，一點都不會專業地做進度追蹤與回報呀？」

我必須停下來，試著對自己發問：「是的，現況糟透了。那麼，我現在還能夠做些什麼？」

面對這問句，我開始發想：「最佳做法，是請專家來上課。」

不過，疫情期間，怎麼請專家來上課？

面對這問題，我不能一直抱怨說：「因為疫情攪局，沒辦法找專家來教大家正確的專案管理入門觀念，因此，以 WBS 為樞紐的專案管理起手式，乃至於後續種種的敏捷大構想，也只能延到疫情降溫之後再說了。」

我必須停下來，試著再一次對自己發問：「是的，現況糟透了。那麼，我現在還能夠做些什麼？」

面對這問句，我開始發想：「是否可以請專家進行線上教學？就算效果可能不如實體課程，但總是往前推進了一步，勝於原地踏步。」

於是，我與大人學聯繫，在線上進行課程對焦討論，也才有之後兩個梯次的【專案管理第一次就上手】線上教學，在 2022 年四月，終於讓「專案管理問題清單」變成整個技術部資深同仁的共同語言。

以上第一組問句，出自《當責，從停止抱怨開始》，第二組問句，出自《QBQ！問題背後的問題》。

《當責，從停止抱怨開始》說，不要一直停在水平線下 (below the line) 的被害者循環 (victim cycle)。《QBQ！問題背後的問題》說，每個人都有自由做出更好的決定，並且為自己的決定負責，不要一直抱持受害者心態 (victim thinking)。

這兩本書介紹的一些 power questions，可以替薩提爾冰山模型當中「觀點」與「期待」環節擴增更多的探索選項，也是很好用的教練對話觸媒。

《當責，從停止抱怨開始》這本書對應的訓練課程 Accountability Builder，是我待過的某一家公司「主管兩年培訓計畫」的必修課程；《QBQ！問題背後的問題》則是我待過的另一家公司新人訓練的必備讀物。

我不能一直抱怨說：「都什麼節骨眼了，這裡的人怎麼這麼沒有 accountability 心態呀？也沒有對應的培訓課程？」

我必須停下來，試著對自己發問：「是的，現況糟透了。那麼，我現在還能夠做些什麼？」

於是，就有了這一場導讀會，一次兩本。

希望大家藉由這兩本書，辨識自己何時落在水平線下，走出受害者循環，走上當責步驟 SOSD：

See It 正視現實
Own It 承擔責任
Solve It 解決問題
Do It 著手完成

願這當責步驟成為我們大家的共同語言。

【職涯躍升書系導讀會】系列

❶ Part 1: 喚醒個人及團隊的成長意識 (計 6 冊)

❷ Part 2: 高效團隊的工作方法 (計 2 冊)

❸ Part 3: 職場心理：觀點、期待、渴望 (計 3 冊)

職涯躍升書系導讀會

Tue, 29 Nov 2022 00:00:00 +0000

❶ Part 1: 喚醒個人及團隊的成長意識 (計 6 冊)

❷ Part 2: 高效團隊的工作方法 (計 2 冊)

❸ Part 3: 職場心理：觀點、期待、渴望 (計 3 冊)

以「蜘蛛法」拆分過於龐大的 User Story

Tue, 01 Nov 2022 17:00:00 +0800

（改寫自公司內部 memo）

Hi all guys,

剛從傳統瀑布式專案管理風格轉換到敏捷風格的團隊，最常遇到第二個卡關之處是：如何將 User Story 拆分到足以在一個 sprint 內完成的顆粒度？

如果玩過我帶的「在幾分鐘以內出門」(“get out of the door in a few minutes”) 活動 ¹，或許可藉由喚起這段活動的體驗來得到拆分大故事的靈感。如果還想進一步知道更具體的步驟，我推薦大家試試 Mike Cohn 大師提出的 SPIDR 法。

SPIDR 是 Spikes, Paths, Interfaces, Data, Rules 的頭字語，音近 “spider” 蜘蛛，可以戲稱為「蜘蛛法」。它指導我們從五個角度嘗試拆分過於龐大的 User Story：

Spikes: 拆分出探索性、實驗性的先遣任務。
Paths: 拆分出不同的使用路徑。
Interfaces: 拆分出不同的介面、軟體、設備、環境。
Data: 拆分出不同的資料來源或類型。
Rules: 拆分出不同鬆緊程度的商業邏輯。

就以這個龐大的 User Story 為例：

As a 商家，I want to 在既有的商家後台，以不同的商品分類或時間區間來檢視我家商品的種種銷售數據圖表，so that I can 對銷售行為作更即時的調整。

這麼大的 User Story，很難放在一個 sprint 裡面實現。

我們可以試著用 SPIDR 當中的 “Spikes” 角度來拆分：

As a 商家，I want to 在既有的商家後台，先針對人工餵入的 1,000 筆假資料，試試看能否把整個流程串起來，以不同的商品分類或時間區間來檢視我家商品的種種銷售數據圖表，so that I can 確定這對我想從事的「對銷售行為作更即時的調整」會有幫助。

我們可以試著用 SPIDR 當中的 “Paths” 角度來拆分：

As a 商家，I want to 在既有的商家後台，以不同的商品分類來檢視我家商品的種種銷售數據圖表，so that I can 對銷售行為作更即時的調整。
As a 商家，I want to 在既有的商家後台，以不同的時間區間來檢視我家商品的種種銷售數據圖表，so that I can 對銷售行為作更即時的調整。

我們可以試著用 SPIDR 當中的 “Interfaces” 角度來拆分：

As a 商家，I want to 在試算表檔案中，以不同的商品分類或時間區間來檢視我家商品的種種銷售數據圖表，so that I can 對銷售行為作更即時的調整。

我們可以試著用 SPIDR 當中的 “Data” 角度來拆分：

As a 商家，I want to 在既有的商家後台，針對 3C 商品來檢視銷售直方圖，so that I can 對銷售行為作更即時的調整。
As a 商家，I want to 在既有的商家後台，針對 3C 商品來檢視訪客 PV，so that I can 對銷售行為作更即時的調整。
As a 商家，I want to 在既有的商家後台，針對日用品來檢視成交率，so that I can 對銷售行為作更即時的調整。

我們可以試著用 SPIDR 當中的 “Rules” 角度來拆分：

As a 商家，I want to 在既有的商家後台，以日為單位來檢視我家商品的種種銷售數據圖表，so that I can 對銷售行為作更即時的調整。
As a 商家，I want to 在既有的商家後台，以周為單位來檢視我家商品的種種銷售數據圖表，so that I can 對銷售行為作更即時的調整。
As a 商家，I want to 在既有的商家後台，以「商品分類」及「時間區間」複合條件來檢視我家商品的種種銷售數據圖表，so that I can 對銷售行為作更即時的調整。

透過 SPIDR 蜘蛛法，我們一下子就得到這麼多拆分大故事的切入點。前後對照一下，是不是覺得這些細分的 User Stories 變得更具體更有把握了呢？

以我的經驗來說，把 SPIDR 法練熟，足以應付大多數情況。如果你還想嘗試更多方法，請讀讀我 N 年前寫的〈工作分解講座・閱讀材料〉一文。

【敏捷的工作分解方法】系列

❹ 以「蜘蛛法」拆分過於龐大的 User Story

「在幾分鐘以內出門」(“get out of the door in a few minutes”) 是出自 User Story Mapping 第五章的經典活動。 ↩︎

事情做一半，等於沒完成：淺談敏捷的里程碑設定

Mon, 31 Oct 2022 17:00:00 +0800

（改寫自公司內部 memo）

Hi all guys,

剛從傳統瀑布式專案管理風格轉換到敏捷風格的團隊，最常遇到第一個卡關之處是：如何以敏捷的角度設定里程碑？

最近在協助兩個 Scrum teams 進行 Sprint Planning 時，我都會用以下角度提出挑戰性提問：

能否將 User Stories 拆分到：可以在一個 sprint 結束時，端出利害關係人可以據以給出建設性回饋的 end-to-end 成果？

這需要創意，需要練習，需要提升規劃能力，需要提升工程能力，需要時時用挑戰性提問提醒自己。但或許更重要的是：大家需要打從心裡認清且認同這樣做的理由。

理由之一是：精實生產。

七大浪費

7/22 舉辦過的《豐田精實管理的翻轉獲利秘密》導讀會有介紹過，馳名世界的豐田生產 (Toyota Production System) 當中有一個基本信念：「降低浪費，就能提升效率。」另一本書《豐田物語》也如是說：

From: 《豐田物語》

豐田生產會從降低七大浪費著手：

Inventory：庫存、在製品。以軟體研發而言，規格書、wireframe、schema、test case⋯⋯任何無法真正迅速 go to production 轉換成實質價值的中間產物，都是 inventory。
Waiting：等待。
Defects：不良品。
Over-production：過量生產。
Motion：動作。
Transportation：搬運。以軟體研發而言，「人的 transportation」就是換手、接棒、工作交接，「物的 transportation」就是工單傳遞、簽呈傳遞、規格書傳遞、契約書傳遞。
Over-processing：過度加工。

這七大浪費當中，有幾點可以直接對應到敏捷的里程碑設定心法，值得我們時時拿來作為挑戰性提問，時時自我提醒：我們在 Sprint Planning 所規劃的里程碑、進程、作法，是否一不小心就會出現以下幾種浪費？

Inventory：在 Sprint Review 當場可以端得出來的成果，真的都是可以 on production 的東西嗎？抑或只是一個又一個的在製品，徒然製造一堆 inventory？
Waiting：在 Sprint Backlog Items 的每一個細分的 tasks，彼此之間是否有無謂的 waiting 或 dependency？
Transportation：在 Sprint Backlog Items 的每一個細分的 tasks，彼此之間是否有無謂的「人」與「物」（在製品）的 transportation？

若出現無法立即轉換成實質價值的浪費，就該針對這些 User Stories 再予以拆分，或是對執行方式再予以重組——這是我們該發揮創意、練習、提升規劃能力、提升工程能力的地方。

「降低浪費，就能提升效率。」

「已完成」

最後，我再摘錄 Scrum 之父 Jeff Sutherland 在《Scrum：用一半的時間做兩倍的事》第五章〈浪費是一種罪〉的相關內容作為補充。關鍵句在此：

在每一輪或是每段衝刺，團隊都要努力完成幾件事，但是「已完成」意謂著能提供給客戶使用的完整功能。

如果你有大批有價值的資源綁在沒有傳遞出價值的東西上，這些資源就無法用來做其他的事。

在 Sprint Planning 或是在設定專案里程碑時，請時時記得上面的提醒。

當大家致力於「降低浪費」的自我要求，同時也就等於開始實踐 Agile Manifesto 背後的十二原則：

原則一：Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
原則三：Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
原則七：Working software is the primary measure of progress.
原則八：Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
原則十：Simplicity–the art of maximizing the amount of work not done–is essential.

大家加油！

【敏捷的工作分解方法】系列

❸ 事情做一半，等於沒完成：淺談敏捷的里程碑設定

Essence of Scrum: Product Backlog Refinement

User Story 釋疑：真的要遵守嗎？

Sat, 08 Oct 2022 10:30:00 +0800

（改寫自公司內部 memo）

Hi all guys,

最近我會對有意導入 Scrum 的任務小組個別進行一整天的 Agile Workshop。這些小組都有一項課前作業：請先準備團隊在三個月以內會進行的 User Stories 清單／陳述。

眾所周知，user story 有一個經典句型：

As a {XXX user persona}, I want to {do YYY} so that {ZZZ result or benefit}.

有同仁問道：有些 user story 不容易以「“user” 視角」來寫。怎麼辦？真的要這麼嚴格遵守 user story 格式嗎？

譬如說，以下兩個 autocomplete 任務，要怎麼轉寫成 user story？

Autocomplete 要能承受 100 rps。
Autocomplete 要優先置入廣告關鍵字。

我的建議是：如果能夠，就盡量努力嘗試；如果不能勉強，就不要勉強。

我先從後者講起。

如果不能勉強，就不要勉強

Story 有很多種，“user story” 只是其中一種。就連大師 Mike Cohn 在 User Stories Applied 也承認：「產品 backlog 中，有面向客戶的任務，也有技術類的任務。」

事實上，整篇 The Scrum Guide 文件都沒有提及 “user story” 一詞，甚至連 “story” 一詞都沒有。所以 Scrum.org 有一篇文章 “Myth 4: In Scrum, the Product Backlog has to consist out of User Stories” 主張在 backlog 中放入 technical tasks 是完全正常的，大師 Roman Pichler 在 “10 Tips for Writing Good User Stories” 一文也說：

User stories are not good for capturing technical requirements. If you need to describe what an architectural element like a component or service should do, then write technical stories or—which is my preference—use a modeling language like UML.

簡言之，如果將它轉寫成 user 視角的 story 真的有困難，那麼，不一定非得死守著 “user story” 這種視角。

如果能夠，就盡量努力嘗試

不過，如果你堅持用 “user” 視角來寫 user story，會有更大的收穫。

這是有根據的。

從企業管理觀點來看，彼得．杜拉克在 The Practice of Management 開宗明義提到：「關於企業的目的，只有一個正確而有效的定義：『創造顧客』(create and keep a customer)。企業是什麼，是由顧客來決定的。」

從敏捷觀點來看，User Story Mapping 提到：「我們要量測的是你建造的東西對人們達成目標的方式產生什麼影響。先針對具體的商業目標、客戶和使用者，然後是他們的目標排定優先順序，最後才針對功能。你的任務不是實現需求，而是改變世界。」

綜上所述，如果你能夠盡量以 “user” 視角來審視這些 story 對於他們達成目標的方式產生什麼影響，相較於僅以單一視角（獲利？利潤？）魯莽地提出需求、設計功能，你會有更周全的思考、更多樣的替代選項。

From: The Practice of Management

上週有上過 Hans【產品數據分析與關鍵指標設計】課程的同仁，不妨回想一下老師提醒的「從商業與用戶的角度去做解讀」心法。沒上過的，請在我的 Agile Workshop 玩一場 Impact Mapping 變形版，就會知道了。

有了這種觀念，再讀大師 Mike Cohn 在 User Stories Applied 所主張的「切蛋糕」口訣，就順理成章了：

優秀用戶故事準則：每個故事都提供某種程度的完整 end-to-end 功能，稱之為「切蛋糕」(slicing the cake)。儘管不十分完美，即使只提供部分功能，但只要發布的功能可以跑，就可以放心地把應用程式發布給用戶使用。

該怎麼改寫？

理論說完了，回到現實：一開頭列的兩個 autocomplete 任務，要怎麼轉寫成 user story？

⓵ Autocomplete 要能承受 100 rps。

先以工程角度來評估這項 non-functional requirement (NFR)。如果並不難實現，那麼，就不必特別為它另寫一張獨立的 story，直接將它填寫到正常 story 裡面的「驗收條件」一欄即可。

如果仍待進一步評估，那就用一張 “As a service owner, I want to make sure that…” 這種風格的 user story 去陳述，或者乾脆撇開形式，直接用 technical story 去陳述這項純工程純技術的任務即可，不必役於物。

⓶ Autocomplete 要優先置入廣告關鍵字。

我們可以試著用一些 power questions 來輔助思考。

譬如說，將彼得．杜拉克的名言「企業是什麼，是由顧客來決定的」改編一下，請試著回答：「在顧客眼中，這功能是什麼？」

As a search service user, I want to see keyword suggestions prioritized by advertising spending when I use the autocomplete feature so that I can… {achieve what?}

萬一寫到這裡就寫不下去了，那麼，此刻，或許該暫停一下，用 User Story Mapping 的名言思考一下：「你建造的東西，對人們達成目標的方式產生什麼影響？」

As a search service user, I want to see keyword suggestions prioritized by advertising spending when I use the autocomplete feature so that I can… {get an awesome impact or… awful impact?}

萬一又寫不下去了，那麼，請改用 Impact Mapping 的角度去反思：這功能若實現了，誰會是這功能的受益者，以及⋯⋯潛在的受害者？

As a buyers of digital advertising inventory, I want to increase ad exposure to users’ autocomplete journey so that …
As a search service user, I want to …

一旦嘗試從這幾個 user 視角去改寫 story，你會發現，原本的「Autocomplete 要優先置入廣告關鍵字」任務陳述有多麼粗糙。

你可以嘗試的 Power Questions

限制帶來自由。如有可能，請盡可能嘗試用正統的 User Story 來審視你的任務。

也請盡量試著用一些 power questions 來輔助思考：

「在顧客眼中，這功能是什麼？」
「你建造的東西，對人們達成目標的方式產生什麼影響？」
「是否可以像『切蛋糕』那樣寫用戶故事？」

職涯躍升書系導讀會，Part 2：高效團隊的工作方法

Sat, 20 Aug 2022 10:00:00 +0800

2022 年一月起，我開始每個月一次，每次兩小時的【職涯躍升書系導讀會】。前六個月著眼於喚醒個人及團隊的成長意識，接下來兩個月則著眼於高效團隊的工作方法。

這兩個月的導讀會，都鎖定在 Agile 相關書籍上——儘管單純從書籍名稱上面都看不出來會與「敏捷」有關。選書如下：

以下列出這兩場導讀會的介紹文案。

豐田精實管理的翻轉獲利秘密

Dear all,

最近一些同仁開始上 Kanban 課程，我想，也該是時候引介大家讀一讀這類書籍了。

接下來兩次導讀會，都會鎖定在 Agile 相關書籍上——儘管單純從書籍名稱上面都看不出來會與「敏捷」有關。

首先登場的是《豐田精實管理的翻轉獲利秘密》。

原諒我又要講古了。記得 2016 年我密謀在Ｇ公司推動 Agile & DevOps 轉型之前，私底下先做了一些思想溯源。畢竟，身為 INTJ，智性上的滿足是不容妥協的——我不滿足於只是「守」著使用手冊般的 “thou shalt…” 敘述，我還需要知道背後的原理及演變歷史。

眾所周知，Agile & DevOps 其中一支重要源頭是 Toyota 引以為傲的「Lean 精實思想」。因此，當年我從《精實革命》、《流的傳承》、《豐田形學》、《學習觀察》這幾本書消化吸收 Lean 思想，雖然費力，但對於 Agile & DevOps 背後的原理更了然於心，也更能面對現實世界的變化球。畢竟，即使我們不嚷嚷著要推動 Agile & DevOps，但 Lean 思想的核心要點，仍然是非常具有普遍性的，值得精熟。

再功利一點講，許多人對於 Agile 的想像是「用一半的時間做兩倍的事」，問題是，真的有這麼神效嗎？關於這問題，我引述憲哥在《豐田精實管理的翻轉獲利秘密》推薦序所說：

精實管理，是提升效率的顯學。

所以，如果導入敏捷的初衷是「用一半的時間做兩倍的事」，那麼，從「精實思想」這一源頭切入，或許更能直接符合期待——但我可沒說這會比較容易。

Lean 思想雖然具有普遍性，但某些地方卻是反直覺的，需要以實際活動或模擬活動去體驗（記得嗎？我的【敏捷原理與團隊塑造】工作坊，就有一個這樣的小活動）。我也一直試圖尋找更淺易的 Lean 思想入門書，作為課後跟進的輔助讀物。

多年後終於找到了。江守智這本《豐田精實管理的翻轉獲利秘密》，儘管不是針對軟體研發產業，但如果你慧眼獨具，自然會發現「雖世殊事異，所以興懷，其致一也」。正如此書第 53 頁所說：

「轉化」是過去十年內我在顧問生涯中所獲得的最重要能力。因為隨著看的企業越多，就會發現大家所在乎所努力的方向其實都很相似。因此，如果說要向標竿學習，那麼這些績優企業如何應對這些通則性問題，就是一個值得參考的地方。

我甚至可以說：好好吸收並轉化這本書所詮釋的 Lean，將可讓 Agile 的執行更有底氣，而不致淪為花拳繡腿。

時間管理的 30 道難題

Dear all,

七月八月的兩次導讀會，都鎖定在 Agile 相關書籍上——儘管單純從書籍名稱上面都看不出來會與「敏捷」有關。

兩個月，兩本書，分別對應到當前敏捷的兩大門派：Kanban 與 Scrum。

七月份導讀會的選書《豐田精實管理的翻轉獲利秘密》談的是 Kanban 背後的「Lean 精實思想」，八月份導讀會的選書《時間管理的 30 道難題》則在探討個人的時間管理，以及（根據相同的原理）團隊的時間管理：目標選擇術、子彈行動力、時間掌控權、流程改進法——有慧眼的人會看出，其實這與 Scrum 的 4+1 活動，雷同程度極高。

Scrum 之所以常被戲稱為「照妖鏡」的原因是，它如實照見出團隊工作流程、技能、默契的盲點（這是 Scrum 經驗主義三支柱當中的 transparency），以及團隊是否有勇氣（這是 Scrum 五大核心價值觀之一）面對事實去進行持續改善（這是 Scrum 經驗主義三支柱當中的 adaptation）。

Scrum 團隊若拒絕面對殘酷的真相，半途而廢比例是非常高的。所以有的經典說「大道以多歧亡羊，學者以多方喪生」，有的經典說「你們要從窄門進去；因為通向滅亡的門是大的，路是寬的，從那裡進去的人也多。」

假使團隊真的有勇氣走向持續改善的道路，那麼，該朝什麼方向改善呢？

我認為，《時間管理的 30 道難題》這本書探討的個人的時間管理，以及（根據相同的原理）團隊的時間管理，是非常好的起點。跑 Scrum 的人，從這本書必會找到許多改善團隊運作的線索——這是 Scrum 4+1 活動的基本功。

就算你不跑 Scrum，這本書也一樣能夠改善個人的工作效能——這是專業工作者的職場基本功。

【職涯躍升書系導讀會】系列

❶ Part 1: 喚醒個人及團隊的成長意識 (計 6 冊)

❷ Part 2: 高效團隊的工作方法 (計 2 冊)

❸ Part 3: 職場心理：觀點、期待、渴望 (計 3 冊)

請掌握「對高層簡報」的技術及習慣

Thu, 04 Aug 2022 19:00:00 +0800

（改寫自公司內部 memo）

Dear all guys,

最近協助一些同仁潤飾簡報，尤其是對高層的簡報，有一個常見的問題，值得特別為文給大家一點建議。

我們在三月份導讀會《不懂這些，別想加薪》就已經探討過，對高層的寫作與簡報，要盡量掌握「金字塔原理」：結論先行，論證隨後。

鑑於有些人沒參加這場導讀會，以下僅說明三大重點：① 一般的溝通原理，② 對高層的溝通原理，③ 對高層的溝通方法。

一般的溝通原理

一般的寫作與簡報，高效人士會 working backwards，先從這個自我提問開始：「我期望在這一場溝通之後，能夠得到的效果或反應是什麼？」

在三月份導讀會中，我曾引述《邏輯思考的技術》的概念圖，將「期望得到的反應」分成三種：

理解
決策的結果、意見、建議等回饋
行動

不同的期望，會影響整份寫作與簡報的動線及力道。

“溝通的基本原理"

對高層的溝通原理

對高層的寫作與簡報，除了依循前述的一般溝通原理之外，還需要對於「高層」這種生物有某種理解，才能投其所好。

「高層」這種生物，是怎麼樣的生物？

在《不懂這些，別想加薪》書中是這麼說的：

你可能聽過或學過許多演講技巧，例如要有令人難忘的開場白、要有力量甚至誇張的手勢、要說故事、要有抑揚頓挫的音調等，這些演講技巧都很好，可是當面對高階主管進行有時間壓力的高層決策會議時，卻極有可能毀了這場簡報，因為這一群聽眾十分特殊，所以簡報內容、表達方式與吸引方式，都要不同於一般的簡報。

他們通常習慣掌控全局、缺乏耐心，咄咄逼人又令人恐懼。簡單說，他們是一群極度不容易對付的聽眾！

因此對高層簡報必須大幅減少一堆平常演講的花招，而要展現迅速清晰簡潔的資訊，以利進行決策。

換言之，如果你能夠在高層面前展現出 ①重點摘要，②下一步行動，③請示這三方面的組織力及表達力，不僅是體貼這種日理萬機的生物，更是在這種生物面前留下專業的印象——你應該明白這意味著什麼。

對高層的溝通方法

第一招，就如同《不懂這些，別想加薪》書中所說的：

Source: 《不懂這些，別想加薪》

第二招，就是我在導讀會介紹過的「金字塔原理」：

金字塔原理，是工作者邁向專業形象的敲門磚試金石。如有可能，請大家多多自我要求，必會有所得。就像我在導讀會引述勝間和代的說法：

Source: 《新・知識生產術》

如果還想認真學習金字塔原理，請見此書單。

專案管理／專案組合管理當中，不必然需要公開透明的地方

Mon, 01 Aug 2022 17:00:00 +0800

（改寫自公司內部 memo）

（Target audience: 有「專案管理」職責的人）

Hi all,

隨著愈來愈多人開始運用專案管理課堂上學到的技術來工作，帶來更高的透明度，更成熟的專業度，欣慰之餘，我也針對其中一件事「透明度」提出一點小提醒。

理想情況下，組織應該要追求專案的透明度——除非有特殊理由。

譬如說，Rex 老師在課堂上就提醒過：「利害關係人矩陣」不必然需要對外公開透明。試想：如果某一位利害關係人看到自己被歸在 “High Interest but Low Power” 象限，會作何感想？

Rita Mulcahy 在 PMP Exam Prep 書中也如此提醒：

Source: PMP Exam Prep by Rita Mulcahy

另一個例子，是專案組合管理 (project portfolio management)。

我們會根據某些質化或量化角度替專案組合做評估與分級。如果整個組織已經有公認成熟的量化評估方法（尤其是有 PMO 編制的組織），那就是走公開透明的路線；否則，可能會用簡單的質化方式，像是艾森豪矩陣之類的二軸工具予以初步分級。

此時，請小心拿捏：這種二軸評估矩陣是否真的需要公開透明。試想：如果某一位利害關係人看到自己的專案被歸在 “Not Important” 或是 “Not Urgent” 的象限，會作何感想？

小總結：有些專案管理／專案組合管理資訊，可能只能在專案團隊內部揭露。不是為了隱瞞，而是為了妥善管理利害關係人。

專案 Kick-off meeting 的前置作業

Mon, 11 Jul 2022 15:00:00 +0800

（改寫自公司內部 memo）

（Target audience: 上過【專案管理第一次就上手】的同仁）

很高興看到二月及四月上過【專案管理第一次就上手】的同仁們，開始在工作上運用課堂所學，尤其是「專案管理問題清單」開始被廣泛運用在大大小小專案的 kick-off meeting 上面，這是非常好的現象。

這份 memo，我針對 kick-off meeting 的定位及前置作業多做一些補充，算是這陣子貼身觀察的小小心得。

定位

關於 Kick-off meeting 的定位，Rex 老師在課堂上有提過：

Source: 【專案管理第一次就上手】by Rex Feng

接下來的問題就是：要怎麼做，才能夠「獲得大家支持」？畢竟，光是在會議現場「公告天下專案即將啟動」，並不必然會順水推舟達到「獲得大家支持」的結果。

我認為，關鍵就在於「事前的利害關係人管理」。

請注意，這句話有兩個重點：「利害關係人管理」以及「事前」，更進一步說，這涉及到 WHEN (事前) 與 DO WHAT (管理) 兩個議題。

WHEN

既然提到「kick-off meeting 必須在『事前』先做一些事」，那麼，kick-off meeting 的時機點，會是在專案管理生命週期（亦即「五大流程群組」：initiating、planning、executing、monitoring and controlling、closing）的什麼時機進行，才算是最恰當的？

以 The PMBOK Guide 6/e 而言，kick-off meeting 是擺在「Planning 結束」 ←→ 「Execution 開始」這個中間地帶：

Source: The PMBOK Guide, 6/e

DO WHAT

既然 kick-off meeting 是落在「Planning 結束」 ←→ 「Execution 開始」這個時間點，那麼，以下這幾個活動，應該都已經進行到某個完成度了：

Scope
- Collect Requirements
- Define Scope
- Create WBS
Stakeholder
- Plan Stakeholder Engagement
Communication
- Plan Communications Management

總而言之，理論上，「利害關係人管理」應該早在 kick-off meeting 之前就已經做到某個程度了。

那麼，kick-off meeting 本身都在做什麼？

Kick-off meeting 之前居然要做這麼多事情，那麼，kick-off meeting 本身還要做什麼？

Rita Mulcahy 在 PMP Exam Prep 書中說得好：

Source: PMP Exam Prep by Rita Mulcahy

事前準備若做得好，kick-off meeting 多半的時間，是在 “review” 會議前就規劃出來的 project plan（縱然這可能只是一份仍待 rolling wave planning 的版本），做些最後的對齊與釐清，然後，拍板定案。

No Surprise

理論上，kick-off meeting 現場，應該不會有太多的 “surprise!” 發生，更多的是一種儀式，一種畫押。

如果當場會有過多的 “surprise!"，那就代表事前準備仍有疏漏。

所以君婷老師在〈老闆心，海底針：我該如何錨定老闆的目標？〉這篇文章就提醒過：

在某些有規模的專案當中，「定出專案的目標」本身就是一個專案前的專案，而且是個非常重要的專案，請用看待一個「正式專案」，態度嚴謹看待之，而你必須先取得這個專案的結果（目標）。

如果真的要 fast tracking 抄捷徑，那就得承擔對應的風險。

願大家在專案管理路上繼續精進，讓我們的工作進展得更順利，朝向 Rex 老師所講的「諸葛亮」境界邁進。

職涯躍升書系導讀會，Part 1：喚醒個人及團隊的成長意識

Fri, 17 Jun 2022 20:00:00 +0800

2022 年一月起，我開始每個月一次，每次兩小時的【職涯躍升書系導讀會】，讓公司同仁自由報名，希望藉由這種草根性的軟性活動，另闢一條 bottom-up 的改革路徑。畢竟，深遠持久的影響，不能少掉「喚醒基層意識」這環節。

前六個月的選書如下：

個人層面，喚醒個人成長意識
- ① 經理人之道
- ② 三年後，你的工作還在嗎？
- ③ 不懂這些，別想加薪
團隊層面，喚醒團隊成長意識
- ④ 獨角獸專案
- ⑤ Amazon 的人為什麼這麼厲害？
- ⑥ 克服團隊領導的五大障礙

以下列出這六場導讀會的介紹文案。

經理人之道

活動名稱：《經理人之道》導讀會

時間：

導讀人：William Yeh

目標聽眾：技術領域的初階主管、地下主管、工頭、組頭，以及有志於在一兩年內成為上述身分的人。

活動進行方式：

活動前：請先自行讀完《經理人之道》至少第 1～6 章。
活動中：導讀、討論、Q&A。

參考資料：

我寫的推薦序：軟體研發者的隨身職涯教練

三年後，你的工作還在嗎？

Dear all,

2014 年初，我以 architect 身分加入Ｇ公司。當時我對於 individual contributor (IC) 路線能走到什麼地步，仍然充滿疑惑，身邊也沒有 mentor 可以解惑。

幸運的是，我在 2014 年 8 月就入手《三年後，你的工作還在嗎？》這本剛出爐的新書。這本書的觀念，徹底重塑了我的認知，成為我私房的職涯祕笈。甚至當我數年後成為主管，我還自掏腰包送給屬下一人一本，以重塑整個部門的意識（有圖為證）：

值此歲初重新檢視與訂定個人年度計畫的時機，我大力推薦用這本書伴你度過農曆新年。

不懂這些，別想加薪

Dear all,

為了離開舒適圈，看看外面的世界，我去外商圈打滾了一陣子，儘管我的英語聽說能力並不算好。

在外商，異國異地 con-call 開會，讀不到共時性的空氣，已經是一種低情境的溝通了，使用英語，更是嚴重限縮語言表達力的頻寬。低情境、低頻寬，是我面對的第一個困境。

我更發現，為了突破低情境低頻寬的禁錮，不只簡報風格，不只溝通風格，甚至連更基本的職場思維也得轉變。我得盡快尋得具體的方法，從頭練習職場基本功——我需要學會在低情境、低頻寬處境下更簡潔、更高效的風格，這風格還得具有某種跨文化、跨語言的通用性。

後來，我拿出早已躺在書架上好幾年的這本書，重新蹲馬步：

《不懂這些，別想加薪》

不要被狀似聳動的書名騙了。這本內容扎實的書，不僅是表格，不僅是話術，更是職場思考的基本功。

照著這本書刻意練習幾個月，某些核心要點甚至還刻意默寫默背起來。沒有 mentor/coach 在側，自承進步緩慢，卻已經開始敏銳看到許多身邊的反例：

口語陳述冗長，聽不到重點
簡報層次錯綜，看不到結構
簡報資料蕪雜，看不到牛肉

當我照著書中第一堂課「一分鐘口頭報告」的兩份表格自我操練，也照著第六堂課及第十一堂課介紹的兩種不同的簡報情境重塑自己的簡報思路之後，這類反例在我眼中就顯得粒粒分明。

看得到問題，察覺到不足，喚起意識，才容易催生改善的行動。

如果你也想重頭練習我所謂的職場基本功，我邀請你，照著以下步驟進行：

開始閱讀《不懂這些，別想加薪》這本書。
拿出隨身筆記本，開始敏銳觀察你身邊發生的這些具體事件，並記錄下來。在下次導讀會時，秀出你所記錄的這些事件：
- 口語陳述冗長，聽不到重點
- 簡報層次錯綜，看不到結構
- 簡報資料蕪雜，看不到牛肉
記錄之餘，請進一步思考：如果換成《不懂這些，別想加薪》這本書教的方法，應該怎麼調整？

另外，這本書第七堂課介紹「DISC 個性分類」，我也在 Scrum 團隊提過幾次。我建議大家可以先做一下附件的小測驗，我們在導讀會現場會聊聊這個東西。

獨角獸專案

Dear all,

近十年，軟體研發界有兩大類重要思潮。在技術面，有大數據、機器學習、immutable infrastructure、微服務、容器、函式編程、資料流水線等；在流程面，則有敏捷開發、DevOps、自助服務、混亂工程、精實 UX 等。這些思潮，有些是新發明，有些則是文藝復興，甚至是跨界學習而來。

因此，當我 2021 年底答應要來這裡時，雖然早有心理準備，但實際進來看到這邊的軟體技術及行事流程，與外界所謂「業界標準配備」差距甚大，仍然嚇了一跳。

當然啦，這也是我來這裡第一年的重要目標之一：「Raise the bar for 各職能工作者，至少要對齊業界水平」。

業界水平是什麼模樣？大體上，就像《獨角獸專案》這本小說所描繪的那樣。

在這小說中，你可以看到在「無極限零件公司」這樣年營業額 40 億美元的製造商暨零售商中，行銷企劃部門、軟體研發部門、服務維運部門彼此爭功諉過的寫實場景。你會看到故事主角梅克辛如何在穀倉泥淖中獨自展開她的「英雄之旅」，與地下反抗軍合作，導入先進的軟體研發思潮。正當一切似乎漸入佳境時，居然還有一條懸疑支線在背後悄悄醞釀⋯⋯高潮迭起，頗有潛力改編成劇情片。

如果你是愛看熱鬧的小說族，你會喜歡它的。

當然啦，內行看門道。這本奇書，並不止於小說，而是真正可以照表操課的。

在參加導讀會之前，我建議大家依照「速讀」及「精讀」兩階段依序進行：

速讀階段：速讀完《獨角獸專案》至少一遍，先享受高潮起伏的劇情，並熟悉人物與關係。
精讀階段：挑出書中所有與「系統與組織的五大理念」有關的段落，越多越好。

我自己的做法是：每讀到一個有關的地方，就用書籤標註（善用不同顏色的標籤更好）。如下圖：

以上，請務必在導讀會之前確實完成。導讀會時，我們會以此為基礎，玩一場我在 DevOpsDays Taipei 2021 帶的工作坊。我們將以「系統思考」角度，帶你分析書中倡議的「五大理念」，你將會得到有助於形塑適合 IT 滋長企業文化的施力線索。

Amazon 的人為什麼這麼厲害？

Dear all,

我自認有一點點文青的基因。像詹先生寫《創意人》及《城市人》，企劃的《謀殺專門店》，創辦的【明日報】，都是我小時候愛讀的東西。

因此，當 2021 年 10 月初Ｓ君 & Ｃ君與我接洽，我是充滿驚喜的。當時我心想，有機會在曾經引領台灣網路圈不斷創新的Ｐ集團底下服務，應該是非常光榮的事。

是的，在我學生時期，Ｐ的確是台灣網路圈的創新火車頭。

不過，當我進來之後，我很驚訝地發現，Ｐ與我學生時期的印象已經大大不同了。就如我在上一次《獨角獸專案》導讀會的文案所說：

當我 2021 年底答應要來這裡時，雖然早有心理準備，但實際進來看到這邊的軟體技術及行事流程，與外界所謂「業界標準配備」的差距甚大，仍然嚇了一跳。

當然啦，這也是我來這裡第一年的重要目標之一：「Raise the bar for 各職能工作者，至少要對齊業界水平」。

業界水平是什麼模樣？大體上，就像《獨角獸專案》這本小說所描繪的那樣。

《獨角獸專案》描繪的是「軟體技術及行事流程」的業界水平，至於「專業主義及企業文化」的業界水平，我打算透過《Amazon 的人為什麼這麼厲害？》這本書來與大家一同探討。

《Amazon 的人為什麼這麼厲害？》這本書所描繪的，其實不只是 Amazon 一家公司的狀況，其實不只是電商龍頭的狀況，更是許多一流外商的共同水平。

我期待大家能好好吸收這本書所勾勒的「專業主義及企業文化」，我也會如此要求大家，追上業界水平，成為專業的工作團隊。

克服團隊領導的五大障礙

Dear all,

四月五月導讀會的選書當中，《獨角獸專案》描繪的是「軟體技術及行事流程」的業界水平，《Amazon 的人為什麼這麼厲害？》描繪的是「專業主義及企業文化」的業界水平。接下來六月份的導讀會，我打算藉由《克服團隊領導的五大障礙》這本書，談談「績優團隊」的業界水平。

記得自己第一次認真思考「績優團隊」這件事，且把這件事視為己任，是在 2015 年閱讀《鳳凰專案》這本書的時候（記得嗎？這是《獨角獸專案》的前作）。我也注意到故事中 CEO 史蒂夫在第 18 章中運用了《克服團隊領導的五大障礙》所介紹的「個人歷史演練 (personal history exercise)」來重塑團隊，擊節讚嘆於峰迴路轉的劇情之餘，不免也心生疑竇：這一招真的有那麼神嗎？

因此，我入手了《克服團隊領導的五大障礙》這本書，也根據這本書介紹的方法，用在團隊集體塑造上，用在新人 onboarding 上，也用在個人 1:1 上，可說是我的私房法寶。

這本書的部份重點，可參考以下幾篇文章：

如果你對這幾篇文章頗有共鳴，想進一步學習具體做法，或是也想再一次從商業小說角度看看「績優團隊」的樣貌，那麼，極力推薦你讀一讀《克服團隊領導的五大障礙》這本書，並且嘗試運用書中介紹的方法。

這次導讀會，請在參加之前，先自行做一下 pp.226～227 的【團隊評估】。

還有，這次導讀會，會有一點噁心。在此先預告一下。

【職涯躍升書系導讀會】系列

❶ Part 1: 喚醒個人及團隊的成長意識 (計 6 冊)

❷ Part 2: 高效團隊的工作方法 (計 2 冊)

❸ Part 3: 職場心理：觀點、期待、渴望 (計 3 冊)

圖表，要有重點訊息

Thu, 09 Jun 2022 20:00:00 +0800

月前看到君婷老師提的這則重大發現：「當你沒辦法 convince 對方的時候，那就想辦法 confuse 他。」

對於「塞一大堆無關緊要，但看起來好像很認真整理過的資料」這件事，我是感同身受的——尤其是職場的會議簡報。

職場的會議簡報，下焉者，塞一大堆原始數據；中焉者，把數據整理為樸素的統計圖表；上焉者，會針對圖表的洞見予以錘鍊。¹ 上焉者的境界，可能需要一段時間訓練與即時回饋，恐非短期可奏效；但我發現，只要掌握一個逆向工作法的小訣竅，就能找到改善中焉者表現的線索。

金字塔原理的 “so what?” 觀點

記得第一次看到這個訣竅，是從 Barbara Minto《金字塔原理》書中學來的：

先決定你想要利用圖表回答的問題，將答案當作標題，然後選擇最適合的圖表格式來呈現該論點。

務必確定圖表的標題直接表達它的內容。標題可以是一個完整的句子，或是包含動詞的一句片語，這麼做讓你可以核對圖表帶給觀眾的視覺印象是否符合你希望表達的內容。

同樣出自麥肯錫人、同樣在談金字塔原理的另一本書《邏輯思考的技術》，第四章舉了一個具體例子：

Source: 《邏輯思考的技術》

這份圖表，只有把數據整理為樸素的時序表格及初級分類，但對讀者來說，如果未經解說，其實很難一眼看出作者為什麼要秀出這份表格：

即使觀察相同的東西，由於觀察者有興趣或關心的事情不同，很可能會得出不同的 “so what?” 內容。

不要以為「只要看到圖，應該就一目瞭然了」，因為那樣會變成把 “so what?” 全權交由接收者解釋。不可以認為「看了就會懂」而放任不管，明確表示出「總之，從這裡我們可以看出什麼」，是非常重要的。

這份圖表，缺少明確的 “so what?” 線索，充其量只是落於「中焉者」層次。

因此，《麥肯錫新人培訓 7 堂課》的第七課，就明確提出以下這種「一張圖表、一個訊息」範本供新人依循 ²，內容包括「一個經過徹底調查，將所有資料結晶化後的訊息，以及一張簡單表示相關情報的圖表」：

Source: 《麥肯錫新人培訓 7 堂課》

事先逆向思考這張圖表想傳達的 “so what?” 關鍵訊息是什麼，然後明確揭露在大標題或小標題上。我發現，只要掌握這個小訣竅，就有助於引導自己接下來該朝什麼方向去加工錘鍊，好讓圖表能夠支持這段 “so what?” 關鍵訊息。

簡報大師的觀點

以上都是麥肯錫人的觀點。那麼，簡報大師，尤其是視覺簡報大師、敘事簡報大師的觀點呢？就請 Nancy Duarte 及 Brent Dykes 兩位大師現身說法吧。

Nancy Duarte 在《矽谷簡報女王用數據說出好故事》第六章，將圖表簡報頁面的標題再細分成「圖表標題」與「研究心得」兩部份，並主張：

圖表標題要合乎事實，保持中性。
研究心得則是敘述，從圖表中你得到的見解，支持你如何看待數據呈現的問題或機會。

Source: 《矽谷簡報女王用數據說出好故事》

Brent Dykes 在《資料故事時代》第八章，主張要善用「解釋性」的標題：

我們常在圖表上寫描述性的標題，而不是解釋性的標題，因此浪費了那個寶貴的空間。

你用資料講述故事時，必須把握機會，利用標題來強調每個圖像的重點。

Source: 《資料故事時代》

看起來，兩位簡報大師的觀點，都與金字塔原理的 “so what?” 觀點相吻合。

資料中立性的觀點？

有些人可能認為，資料，就該是客觀中性的存在，應該讓樸素的統計圖表直出，讓數字自己跳出來說話，不該滲雜人為的誘導。

真的是這樣嗎？

資料固然不能造假，統計圖表也不能刻意施以歪曲事實的加工，但這不意味著我們就要棄守主觀詮釋的權力——這不是客觀理性，而是怠惰。

尤其是職場的會議簡報。

對於資料中立性議題，《２軸思考》說得好：

工作上有大成就的人，其資料一定會加上自己的意見，或說偏見。製作資料時，一定要避免完全交由對方判斷而絲毫不滲入自己的意見。

相反地，當自己是資訊接受者，就必須冷靜判斷，避免被這樣的「偏見」迷惑。

Source: 《２軸思考》

這也不禁讓我聯想到洪震宇在《精準寫作》提出的「魚骨寫作法」觀點。雖然不是針對資料圖表，但中心思想一樣適用：

我從學員的魚骨寫作練習發現，大家並不習慣這種逆向思考的寫作方法。學員說，要想清楚再寫，是一大挑戰，因為沒有勇氣第一句就破題，總喜歡鋪陳迂迴。

問題在於過去的寫作慣性：❶ 喜歡把重點、主題藏在段落中，似乎怕人一眼看穿。❷ 想法不聚焦，邊寫邊想、邊想邊寫；寫完後，沒有仔細消化想法，到底要呈現什麼主題？沒想法，就端不出魚頭句。

或許，端得出想法，有勇氣破題，不僅是寫作，同樣也是職場會議簡報該學的功課吧。

我講的不是 TED 或 keynote speech 那種簡報。忙碌的職場人士，並不需要時時刻刻追求加工到資訊圖表 (infographic) 等級，因此，我並不把「上焉者」標準設定到這個層次。 ↩︎
當我還是職場新鮮人時，好像沒有人教過我要這麼做⋯⋯唉。 ↩︎

很簡單的東西，也要單元測試嗎？

Tue, 24 May 2022 12:00:00 +0800

（改寫自公司內部 memo）

Hi all engineers,

上完一整天單元測試課程之後，有同事問我：「有沒有標準來決定要不要寫單元測試？」

剛讀完劉潤《底層邏輯》的我，對於這類疑似「注射器」的問句格外敏感。雖然我可以瀟灑引述 Working Effectively with Legacy Code 的說法「我毫無疑問地將『遺留程式碼』定義為『沒有編寫測試的程式碼』」：

沒有編寫測試的程式碼是糟糕的程式碼——不管我們多麼細心地編寫它們，不管它們有多漂亮、物件導向或封裝良好。有了測試，我們就能夠迅速、可驗證地修改程式碼的行為。沒有測試，我們就不知道修改後的程式碼，實際上是變得更好還是更糟。

但當下我還是決定先展開一場對話。

我：「我一時想不出來有沒有合適的標準，但我有一個簡單的 gut feeling 來判斷：如果我沒有把握證明這段程式碼會表現出該有的行為，那麼我就應該考慮替它加一段測試，用測試來表現出這段程式碼的確忠實表現出該有的行為，讓測試來說話。」

同事：「即使是很簡單的程式碼，也需要加單元測試嗎？這會不會太麻煩了？」

我心中頓時浮現一個聲音：“如果你有 TDD (test-driven design) 的觀念或紀律，就不會有此一問了。再簡單的程式碼，都會測試先行——何況，簡單的程式碼，對應的單元測試會很難嗎？如果很難很繁雜，那麼，或許這程式碼本身並沒有當初想像中那麼簡單。”

但當下我還是決定繼續對話，先不要說教⋯⋯

我：「能不能舉一個『簡單的程式碼』的例子？」

同事：「就像某一個 function，它會先檢查輸入的日期格式，如果格式不是 yyyy/mm/dd 就會失敗；如果格式對了，就會繼續往下做正事⋯⋯」

我：「且慢，你所說的『如果格式不對，就會失敗』這句話，所謂的『失敗』是指什麼？」

同事：「啊⋯⋯就是失敗呀！」

我：「讓我們用程式語言的角度來講。你所謂的『失敗』，是指 return false 呢，還是 throw exception？」

同事：「嗯，以這個例子來說，是 throw exception。」

我：「好的，那麼，你怎麼證明，在遇到錯誤的日期格式時，你的程式碼真的會 throw exception？」

同事靜默中⋯⋯

我：「在談論寫不寫單元測試時，我想稍微區分一下問題，究竟是 ❶ 不會寫，或者是 ❷ 懶得寫？」

我：「就以這一個例子來說，你知道該怎麼單元測試嗎？」

同事靜默中⋯⋯

我：「目前的主流單元測試框架，都有 Assert.ThrowsException 或 Assert.ThrowsExceptionAsync 之類的設施去處理 exception，所以『❶ 不會寫』就不成立了。只剩下一個問題：『❷ 懶得寫』。」

我：「你會在這段 function 一開頭的 doc comment 陳述說：『如果日期格式錯誤，會 throw XXX exception』嗎？」

同事：「會。」

（他大概不敢當面說不會，因為我兩個月前才寫過一篇內部 memo 講 “doc comment” 這件事。）

我：「針對 throw exception 這個行為，既然你都已經花時間寫程式了，也都已經花時間寫 doc comment 了，為什麼不順手寫一小段單元測試來證明你的程式碼與 doc comment 是對齊的，讓測試來說話？」

同事靜默中⋯⋯

我：「而且，你寫的程式，不只是給現在的你自己看，不只是給 code reviewers 看，也會給幾個月後、甚至一兩年後接手維護的其他人看。萬一有一天，別人沒注意到『日期格式』這件事就改寫這段程式碼，你的程式又沒有單元測試的保護，你會不會擔心對方把你的程式改壞了？」

同事靜默中⋯⋯

我：「所以在單元測試課堂的開場致詞中，我強調：『單元測試是程式設計師的職業道德』，就是這個意思。」

最後，請容我引述《修改軟件的藝術 (Beyond Legacy Code)》裡面的金句：

在編寫程式碼之後才編寫測試，往往會發現程式碼難以測試，需要大量的清理來讓其可以測試，這可能會成為一個大工程。最好是一開始就編寫出可測試的程式碼，而編寫可測試程式碼的最好方式是先編寫測試。

沒法進行測試，則說明我有些設計問題需要重新進行思考。

應該假設測試集是對整個用戶故事的完整定義。如果沒有用測試來描述一個行為，那麼這個行為很可能是錯的。任何沒有在測試集中體現的行為，都被視為不存在。

測試集不僅驗證行為，而且描述行為。用測試描述行為，從而建立活的文檔。

（PS. 以上情節，是根據實際對話加油添醋改編而成，請勿對號入座。）

推動改變的評估流程

Mon, 16 May 2022 20:00:00 +0800

在發出內部 memo 〈請珍惜你們學到的通關密語〉之後，收到這樣的來信：

上周假日也花了點時間，將您從去年 11 月起寫給大家的每一封信都讀了一遍，雖然還不是全部內容都完全吸收和理解，但仍然覺得受益匪淺，真的非常感謝您願意無私的分享您過去許多很棒的經驗和想法。

我很喜歡您用「通關密語」來形容這些語彙，突然覺得他們不再是死板板的方法論，而像是賦予了它們魔力，雖然不至於天真到認為知道這些詞彙和正確的應用，就能馬上變成具有超能力的 superman，但至少能讓我在規劃專案時更自信和從容。

溢美之詞就摘錄到此。以下是正題：

同時，我雖然也很認同這些詞彙確實是「通關密語」，畢竟清楚和正確的定義可以有效減少許多溝通時的落差和模糊地帶，更快的凝聚共識，但前提是和具有同為專業的人溝通，我想這也是您迫切希望大家能盡快建立起這些基本常識的原因吧~

但經驗豐富如您，一定也有許多，甚至是多數時候，都是在和沒有這些基本常識的人溝通吧！過去我就有許多這樣的經驗，不管面對公司主管或是面對客戶時，要求我產出一個四不像等情況。

通常這種時候我的作法會是，不再堅持使用這些專業詞彙，而是解釋我產出的每個圖表的目的、用途和邏輯，但不幸的是還是有很多時候是無法被理解的，通常結局就是我需要照著對方的邏輯和方法，做出一個我自己無法認同的東西，但因為這才是利害關係人們可以接受的作法，所以為了可以溝通和讓專案順利進行，我還是會做。

所以很想問問 William 您是否有類似的經驗呢？那您是怎麼面對和解決的呢?

這是大哉問。

大體上，我會根據幾個角度迅速評估一下這整件事。

❶ 值不值得推動改變？

我常用 Impact Effort Matrix ¹ 這種簡易的兩軸思考工具，迅速定位這項改變是否值得。橫坐標是「可付諸實現的速度」，縱座標是「效益、影響」。

Impact Effort Matrix

從圖上來看，若想推動的改變恰巧落在「1 號」位置，那就太幸運了，投資報酬率最高。萬一沒那麼幸運，落在「7 號」位置呢？

引述《麥肯錫＆波士頓解決問題方法和創造價值技巧》的精闢見解：

確實，以「1 號」著手是正確的。

那麼，「7 號」就被永久棄之不顧了嗎？並不是那樣的，「7 號」的建構化還做得不夠，還是一個大塊。所以，要花費時間把它再進一步細化，重新做成「1 號」那樣的小塊。這樣問題就容易解答了。

把這個擱置的「7 號」建構化為「1 號」，就是諮詢顧問展現本領的地方了。

如果 Benefit/Impact 夠大，才值得進一步往下評估予以細化的 Effort。

就以推動敏捷為例。「在導入敏捷的初期階段，首要焦點應放在 Team 、Product Owner 及 Organization 三者。」² 可是，萬一組織現況無法在這三方面大刀闊斧改變呢？或者表面上似乎做了調整，但其實骨子裡的結構並沒有調整多少，又該如何是好？

此刻，就需要暫時退後一步，設法把這個「7 號」的大塊任務細化到「1 號」這種層次——這也就是〈敏捷啟航的專業基礎：共同語彙〉一文的立論。

❷ 用 Fogg Behavior Model 評估 Effort

我常用 Fogg Behavior Model: B = MAP 評估可能的 Effort。

▶︎ Motivation：當事人是否有改變的動機？

簡單一點的情況，我會用「洞」與「痛」、笨問題法則（為什麼非得如此如此⋯⋯）來判斷。 ³

複雜一點的情況，我會用 TOC 抵制變革層次來判斷。 ⁴

▶︎ Ability：當事人是否有改變的能力？

▶︎ Prompt：當事人是否遇到推動改變的臨門一腳？

我常用「三不四人」來判斷：不舒服、不甘於、不能停、人背叛、人出現、人離開、人不理。 ⁵

B = MAP 具體的運用方法很多。對於當事人越了解，越能發掘洞見，找出有創意的方法。譬如說：

Motivation 可以訴諸權力關係，可以訴諸外部壓力，可以訴諸同儕壓力。
Ability 可以訴諸教育訓練，可以訴諸教練手法，可以訴諸新陳代謝。
Prompt 通常要訴諸善用局勢或創造局勢，或者⋯⋯機緣巧合的運氣。

就以推動敏捷為例。想推動敏捷，要改變的事情太多了，我會視情況，分階段推動具體的敏捷實踐措施。

譬如說，剛嘗試 Scrum 的團隊，常會對我沒有主動帶領 Planning Poker 活動感到不解。我的觀點是，Planning Poker 要發揮效果，不至於淪為玩一玩而已，得先經過一番練習；練習要到位，卻可能會佔用過多時間。

我的做法是，在初期，我寧可先對「工作透明化」這件事著墨。畢竟，「工作透明化」是 Benefit/Impact 非常大的，Motivation 是很強烈的，而 Planning Poker 則未必。所以，在裁適敏捷方法時，我會優先處理工作透明化，並多方製造 Prompt 的局勢；至於 Planning Poker 則看情況。

❸ 在這件事情上，我有多少的主導權？

主導權越高，就越不需要費神在 Effort 上。

French and Raven (1965) 將權力來源分為六種：強制權 (coercive power)、酬賞權 (reward power)、參照權 (referent power)、法職權 (legitimate power)、專家權 (expert power)、資訊權 (informational power)。平時善於經營權力基礎的深度及廣度，才容易推動改變。

以上就是我快速評估推動改變的可能性及施力點的大致流程。

系列文章

❶ 改變的框架

❷ 改變／改革：流程與衡量指標

❸ 推動改變的評估流程

Impact Effort Matrix 又名 Benefit Effort Matrix、PICK Matrix，詳見這段影片。 ↩︎
出自〈敏捷啟航的專業基礎：共同語彙〉一文。 ↩︎
「洞」與「痛」、笨問題法則，出自裘凱宇《過好人生學》。 ↩︎
TOC 抵制變革層次，詳見〈改變的框架〉一文。 ↩︎
「三不四人」出自憲哥《人生準備 40% 就衝了！：超乎常人的目標執行力》。 ↩︎

「改變」系列

Mon, 16 May 2022 00:00:00 +0000

改變的框架

改變／改革：流程與衡量指標

推動改變的評估流程

向頂尖管顧公司學習的書

Sun, 08 May 2022 15:00:00 +0800

好友進了台灣前百大公司，最近有感而發：

請問與麥肯錫有關的書籍，你會推薦哪些？

在這間公司辛苦摸索幾個月，我才意識到，大家在使用的術語都來自麥肯錫。譬如：MECE、Story Line、論述 (Issue)⋯⋯等等。

突然被洽詢這問題，其實有點心虛，畢竟我沒待過麥肯錫這類頂尖的管理顧問公司，不太有資格回答。不過，既然自己去年曾經系統閱讀過相關書籍（見〈2021 個人回顧〉一文），半年以來也一直運用書本裡的方法來推動改革，對於這些方法算是小有心得，因此，野人獻曝一下也無妨。

「問題分析與解決」書單

朋友問的是「與麥肯錫有關的書籍」，如果範圍稍微擴大一點，連「與 BCG 有關的書籍」也納入，那麼，值得一讀的多產作者就有勝間和代、高杉尚孝、大嶋祥譽、內田和成、安宅和人⋯⋯等人。

為了聚焦，我只挑選對「非以顧問為業」的初階至中階職場人士都能受益的書籍。

註：以下書籍，有些可能要去圖書館找。

入門篇：職場基本功

文章開頭提到的 MECE、Story Line、論述 (Issue)⋯⋯等等，這幾本書都有提到，我甚至認為這幾本書所觸及的內容應該成為職場的通識教育。

大嶋祥譽：《麥肯錫精英最重視的 39 個工作習慣》
大嶋祥譽：《麥肯錫新人培訓 7 堂課》
高杉尚孝：《麥肯錫寫作技術與邏輯思考》
安宅和人：《議題思考》

進階篇：思考框架

市面上談思考框架的書很多，百科類的也不少，與其貪多嚼不爛，不如先確實吸收麥肯錫專家們萃取出來的精華。

大嶋祥譽：《麥肯錫新人邏輯思考 5 堂課》
大嶋祥譽：《麥肯錫思考模型活用法》
勝間和代：《新・知識生產術》
高杉尚孝：《麥肯錫問題分析與解決技巧》

進階篇：金字塔原理

以上書籍消化完畢後，若行有餘力意猶未盡，不妨啃一啃這幾本深度探討「金字塔原理」的書。不過，在此得先提醒你一個可能的副作用：日後當你遇到不符合「金字塔原理」的商業文書或簡報，極可能感到很不耐煩——「金字塔原理」一上身，可能就回不去了。

Barbara Minto：《金字塔原理》(原理篇 + Workbook)
照屋華子、岡田惠子：《邏輯思考的技術》

進階篇：顧問法寶

即使不是身處管理顧問業，但他們的宏觀視角是很值得學習的。

請珍惜你們學到的通關密語

Fri, 29 Apr 2022 17:00:00 +0800

（改寫自公司內部 memo）

Dear all 夥伴，

過去三個月，我根據自己的職場經驗，以及我對大家的專業要求，安排許多課程及講座。從一系列 1:1 訪談中得知，不只是主管們動了起來，連小夥伴也開始試著實踐。我很欣慰。

譬如說，送你們這群中階主管及資深工作者去接受專案管理培訓之後，我終於可以在大大小小會議上公然用專案管理語彙進行詢問與討論了，不必拐彎抹角替這些對我來說已經是「系統一」的管理切入點逐一解釋或比喻。

The bar has been raised，這才像專業場域。

有些人對我說，上了這些課程，他們才知道原來這些共同語彙是專業工作所必備的。只是也不免好奇：對於這些語彙，真的有必要那麼咬文嚼字嗎？

譬如說，專案管理課堂上，老師一再強調表述形式：WBS 要以「名詞、交付物」表述，里程碑要以「時刻、完成」表述，任務要以「動詞」表述。SBE 課堂上，老師也強調以「Given-When-Then 句型」表述的需求。同仁們發現，不只是課堂演練時老師會要求這些細節，課程結束後，在工作上我也會繼續要求，故有此一問。

我的觀點是，請把它們當成是專業領域的「通關密語」看待。理由有三。

請試著培養英語文法意識

企業講師 Lisa Lai 曾說：目前通行的管理理論及方法，多半來自美國。

確實有道理。信手拈來幾個例子：科學管理之父泰勒 (Taylor)，美國人；現代管理學之父彼得．杜拉克，在美國成名；六標準差方法，源自美國；平衡計分卡，源自美國；OKR 之父 John Doerr，美國人；OKR 思想源自 Andrew Grove，成年即定居美國；專案管理學會 PMI，總部在美國；Scrum 之父 Ken Schwaber 及 Jeff Sutherland，美國人。

主流的管理理論及方法，幾乎很難沒有美國的蹤跡。語言是思想的重要載具，英語又可算是專業領域的世界語，因此，他們所發展出來的管理工具或思考工具，帶有濃厚的英語文法色彩也就不足為奇。 ¹

與中文相比，英語是個文法意識較嚴謹的語言，詞類時態語態形式分明。因此，在運用英語世界發展出來的工具時，請試著將頭腦切換至同一頻道，運用起來比較順暢，也更顯得內行——你是個與國際思維接軌的專業工作者。

請展現內行氣

勝間和代在《新．知識生產術》曾說過自己剛到麥肯錫工作時發生的慘痛經歷：

對麥肯錫人來說，沒有遵循金字塔結構和 MECE 的文章，就等同於「外行人在閒聊」。於是，我的提案在格式階段就已經不被接受，更不用說是內容了。

「外行人在閒聊」

同理，未以「名詞、交付物」表述的 WBS、未以「時刻、完成」表述的里程碑、未以「動詞」表述的任務，看在受過專業訓練的人眼中，就等同於「外行人在閒聊」。

請大家展現「內行氣」。

守破離

學習新的事物，面對新的規範，不習慣是正常的，尤其又涉及用字遣詞。

日本劍道素有「守、破、離」三個學習階段，金庸小說《神鵰俠侶》也提到劍魔獨孤求敗的武學造詣可分為幾個階段：

「凌厲剛猛，無堅不摧，弱冠前以之與河朔羣雄爭鋒。」
「重劍無鋒，大巧不工。四十歲前恃之橫行天下。」
「四十歲後，不滯於物，草木竹石均可為劍。自此精修，漸進於無劍勝有劍之境。」

如果你還處於「守」這個階段，請堅持下去，把這個階段的要求操練純熟，變成自己的「系統一」。時機成熟了，再談「破」或是「離」。切忌好高騖遠自作聰明揠苗助長。

對我來說，這些共同語彙，可說是專業領域的「通關密語」，使用得當，能夠展現「內行氣」。

請珍惜你們學到的通關密語，並反覆在工作上下意識練習與實踐。

如果你們還想知道更多專業的通關密語，我三月份導讀會的選書：功夫老師的《不懂這些，別想加薪》是個不錯的起點。

【咬文嚼字的必要性】系列

❶ 咬文嚼字的必要性（一）：用句型輔助思考

❷ 咬文嚼字的必要性（二）：階段性的預期成果設定

❸ 請珍惜你們學到的通關密語

歐美系的思考框架或準則，很喜歡用「句型」式的步驟來引導思考，且多半都很注重文法的合式。我四年前的舊文〈咬文嚼字的必要性（一）：用句型輔助思考〉就列了許多例子。 ↩︎

經理人視角的敏捷通識課

Sat, 16 Apr 2022 18:00:00 +0800

[課程推薦文] 高效產出：突破資源限制的敏捷管理術

在商業世界，「敏捷」又變成流行語了。許多人風聞敏捷兩大流派 Scrum 及 Kanban 勾勒出來的美麗新世界，聽起來也頭頭是道，便以為敏捷轉型是輕而易舉、隨插即用、立竿見影的事。

不過，真實世界不必然會像宣傳的那麼單純。等到真正開始嘗試時，遇到已知或未知的障礙，才開始懷疑人生，心生退轉。「敏捷轉型」這條路，怎麼走起來並沒有那麼敏捷呀？

其實，「敏捷」這道處方未必有錯，錯的可能是病患未先接受過合適的衛教。

坊間的敏捷衛教多半是由顧問、教練、證照供應商所提供，內容專業度是有的，但多半只呈現出乙方觀點，缺少甲方的第一人稱視角，尤其是切身之痛的視角。

乙方觀點是：「你應該如何如何如何，不應該如何如何如何 (Thou shall… Thou shall not…)。」
甲方視角是：「你說得倒輕鬆。你又不是我，你不了解我的兩難與無奈。」

不對等的視角，衛教效果有限，難怪甲方容易心生退轉。

為了平衡，除了敏捷宣傳品或培訓教材之外，我們還需要另一種敏捷通識課，以第一人稱的經理人角度現身說法，告訴我們踏上敏捷轉型之旅之前，必須要先做好哪些心理建設。

Yves 身為跨國企業經營者，帶領公司敏捷轉型，成為台灣、甚至東南亞的敏捷標竿企業。由他親自開講的這門敏捷通識課【高效產出：突破資源限制的敏捷管理術】，格外具有說服力。畢竟這些內容，都是企業經營者親自神農嚐百草之後淬煉出來的精華，都是實證有效的作法。

這門敏捷通識課，鎖定三個必須具備的認知：

敏捷核心觀念與流程。Yves 從 Scrum 及 Kanban 擷取最精華的觀念及流程，用傳統經理人也領會得了的方式講解。這 50 分鐘的內容，既可作為敏捷的先導知識，亦可作為經理人日後的提醒：勿因阻礙而忘卻敏捷導入的初衷。
敏捷之旅的關卡。Yves 從實務中挑選敏捷之旅的五大關卡：主管權力、角色分工、團隊決策、僵化思維、與市場脫節，以 40 分鐘逐一提供對應的處方，有些處方甚至不是一般敏捷教材會談到的。
自管理的軟性修練。任何轉型都需要考慮人性層面，轉型到對於「人性」格外細膩的敏捷世界更是如此，我們甚至可以說，絕大多數的敏捷轉型失敗，追根究柢就是對於「人性」議題的無意識或無能力。Yves 以公司經營者的切身經驗，提煉出「IMPACT 影響力」六字訣：I Message、Mindfulness、Positive Language、Active Listening、Curiosity Question、Target Alignment。我誠懇建議，有心推動敏捷轉型的經理人，應該認真聆聽這 50 分鐘的內容，並有耐心將它推廣並內化到整個組織裡，由經理人帶頭改變，才容易風行草偃。

身為敏捷推手，我過去曾從 Yves 身上學習許多。我敢保證，這門線上課，絕對是值得常常拿出來溫習的敏捷通識課。

如果你也想吸收 Yves 以企業經理人視角親自開講的敏捷通識課【高效產出：突破資源限制的敏捷管理術】，現在到 2022-04-30 之前，你可以用以下優惠碼，享有更優惠的價格（早鳥優惠，再折價 300 元）。

課程：【高效產出：突破資源限制的敏捷管理術】
課程網址：https://www.cwlearning.com.tw/course-set/109
優惠碼：william300
優惠期限：2022-04-30

敏捷啟航的專業基礎：共同語彙

Sat, 05 Mar 2022 14:00:00 +0800

LeSS 的 “Scrum Master focus over time” 一文主張，在導入敏捷的初期階段，首要焦點應放在 Team 、Product Owner 及 Organization 三者。

Scrum Master focus over time (from LeSS)

如果借用麥肯錫 7S 模型來分析這些初期的施力重點，不難發現，Organization 的施力點大致可直接對應到 7S 的結構 (Structure) ¹ ，至於 Team 及 Product Owner 的施力點，則是對應到 7S 的風格 (Style)、技能 (Skills)，甚至是共同價值觀 (Shared Values)。

前者屬於硬性要素，較易理解，也較易實施；後者屬於軟性要素，較抽象，也不易立竿見影——這是敏捷啟航時需要面對的模糊題。

面對軟性要素，除了像【敏捷原理與團隊塑造】工作坊這種典型的起手式，我發現，要促成根本改變，還得致力於「建立共同語彙」。我還更進一步發現，這些共同語彙，不只是敏捷轉型需要，就算不談敏捷轉型，也一樣需要——這應該是各職能工作者都該有的專業基礎。

其中，我最看重且亟需建立的共同語彙有三：

5W1H
WBS & MECE
Working backwards collaboratively

5W1H

很多人視 5W1H 為過氣的老調。有趣的是，日本人對於經典的 5W1H 似乎情有獨鍾，出了幾本專書：《5W1H 超強思考術：你的所有問題，都可以靠 5W1H 解決！》、《5W1H 經典思考法：容易獲得成果的人都在用》。

5W1H 不只是表面上「人事時地物」這麼單純的事項羅列，以事實為基礎的行事態度才是它更深層的意涵。如果套用麥肯錫常用的「天空、下雨、雨傘」比喻，如果連「天空」這個事實層次都無法精準陳述，後續「下雨」的推論詮釋或是「雨傘」的行動決策，都是刻舟求劍。

對敏捷的影響：若行事態度不以事實為基礎，等於是推翻了 Scrum 經驗主義三支柱當中的「檢視性 (inspection)」，就別奢望能夠正確發揮 Scrum 的功效。

WBS & MECE

工作分解 ² ，是專業工作者的基本功。磨練工作分解的技術，不管是 WBS 形式還是 MECE 意識，都能促成更專業的工作品質。

對敏捷的影響：儘管敏捷並不講究在一開頭就進行鉅細彌遺的工作分解，但這並不代表敏捷就不需要工作分解技能了。此技能若不精熟，Sprint Planning 或 Sprint Refinement 等活動很快就會卡關。

Working backwards collaboratively

Working backwards 一詞，近年來因 Amazon 而聲名大噪，但這觀念其實相當古老。至少當我們還在學生時期，都懂得所謂的「逆推法」解題祕訣：面對數學證明題，有時候可以嘗試從待證明的結果往回推導個幾步；面對閱讀測驗，較有效率的做法，往往是先快速掃描後面的提問及選項，而不是傻傻地先閱讀冗長的文本。

迷宮，未必非得從入口出發；從出口往回倒著走，可能更容易破關。

Working backwards 是學生的法寶，只可惜到了職場，只有一流高效人士才懂得重拾這個絕招。像在專案管理領域中，WBS 就是最典型的 working backwards 應用：從「最終交付物」出發的分解結構 (a deliverable-oriented hierarchical decomposition)。

一流高效人士不只是懂得 working backwards，更懂得 working backwards collaboratively。專案管理名著 Work Breakdown Structures: The Foundation for Project Management Excellence 就說，WBS 不是 PM 一個人悶著頭生出來的，而是靠整個團隊的力量集結完成：

Who owns the WBS, who should be involved in developing it, who keeps it up to date? The answer to each of these is the project manager and the project team. […] who is responsible for the upkeep of the WBS? This is the responsibility of the entire project team.

不靠整個團隊的力量，很難做到 WBS 所講究的 “100% rule”。

對敏捷的影響：不具備 working backwards collaboratively 的心態及技藝，就只是表面功夫的敏捷。就以敏捷圈常見的 user story 及 SBE 手法為例：

User story：經典句型 “who + what + why” 及 acceptance criteria 就是 working backwards，3C 要素當中的 “conversation” 就是 working collaboratively。
SBE：經典句型 “given-when-then" 就是 working backwards，3 amigos 活動就是 working collaboratively。

交叉訓練

5W1H、WBS & MECE、working backwards collaboratively 這些共同語彙，不只是敏捷轉型需要，就算不談敏捷轉型，也一樣需要——這應該是各職能工作者都該有的專業基礎。

檯面上沒有單一課程能深度涵蓋這三種語彙。我只好打組合牌，透過幾種課程的交叉訓練，從不同角度冶煉出這三種語彙的交集，再以我的【職涯躍升書系導讀會】做為佐料來提味：

	Git	專案管理入門	SBE	TDD	遠距工作講座
5W1H	✓	✓
WBS & MECE		✓
Working backwards		✓	✓	✓
Working collaboratively	✓	✓	✓		✓

教育訓練效果不彰，很多時候是因為：❶ 主管自己都沒上過，❷ 沒有人致力於把它變成組織內的共同語彙，❸ 沒有人有 coaching 的意識與行動。如此這般，就淪為徒具形式，船過水無痕。

透過交叉訓練，應用場景自然而然擴大起來，再搭配正確的 coaching 意識與行動，將更有機會成為真正實質意義上的「共同語彙」。

整土

這些共同語彙一旦真正建立起來，許多 Scrum 元素就顯得理所當然。

Scrum 跑不順，不見得是 Scrum 的錯。畢竟 Scrum 是個篇幅 20 頁的擴大機，原本的天籟會增益，反之——噪音亦然。

Scrum 懷璧其罪很久了。

在敏捷啟航之前，花點時間處理這些軟性要素，在組織中種下這些共同語彙，把硬土、淺土、雜土整理成好土，整理成易於滋養敏捷的環境吧。

Scrum master 培訓系列

❶ 如何訓練一個新的 Scrum master？

❷ 敏捷之途無他，刻意練習而已矣！

❸ Scrum 認證模擬測驗的兩項啟發

❹ 敏捷啟航的專業基礎：共同語彙

即使 Kanban 方法是傳説中一開始對既有組織結構衝擊最小，且明文宣稱 “Start with what you do now“ 及 “Initially, respect current processes, roles, responsibilities, and job titles”，但根據 Kanban from the Inside 一書的說法，Kanban 最輕量的導入手法 “The Sustainability Agenda” 當中，就包含 ① Visualize, ④ Make Policies Explicit, ⑤ Implement Feedback Loops 這三項 Transparency 實踐手法——說實話，這未必是小小的衝擊！如果借用麥肯錫 7S 模型來分析這些初期的施力重點，可說是從 7S 的體制 (Systems) 這項硬性要素及風格 (Style) 這項軟性要素切入。 ↩︎
請參考〈工作分解講座・閱讀材料〉一文。 ↩︎

Scrum master 培訓系列

Sat, 05 Mar 2022 00:00:00 +0000

如何訓練一個新的 Scrum master？

敏捷之途無他，刻意練習而已矣！

Scrum 認證模擬測驗的兩項啟發

敏捷啟航的專業基礎：共同語彙

2021 個人回顧

Tue, 28 Dec 2021 22:00:00 +0800

年初，從外商被挖腳到台商；年末，又再被挖腳到另一間台商。

我常笑著說：今年，好像都在消費我在 2019～2020 年間外商經驗的戰備存糧。

到了年終，又開始要做個總回顧，再對來年許願。去除一些不便揭露的事情，以下是簡單的回顧。

補血課程

這一年，由於 COVID-19 因素，參加的實體課程，就只有公司舉辦的這兩場內訓，而且都是國外課程的中文化版本，很值得推薦：

這一年，我上的多半是線上課程。我漸漸不追求 100% 完課，反而視為書本之外的另一種素材，只要其中某些片段能夠引為己用，就算值得。畢竟，我們都不見得需要 100% 讀完一整本書，為什麼我們需要把一門線上課 100% 上完？

就以我今年重點修練科目「金字塔原理」為例，除了書本之外，在 Bryan 的《知識型商品的文案寫作課》線上課程也聽到了 26 分鐘的相關內容，在張敏敏的《敏捷溝通力》線上課程也有 14 分鐘，里茲螞蟻《三步驟邁向進階英文口說》更是到處都是這種論述結構。有機會從更多角度去看這主題，滿有趣的。

我不追求 100% 完課。話雖如此，但當七月初收到 Udemy 這樣的通知，還是小小虛榮了一下。

Udemy 超過 8 小時

演講及授課

今年，由於 COVID-19 因素，再加上自覺已經過了能夠恣意跑趴出沒社群活動的人生階段，婉拒許多邀約，只接了一場公開工作坊：

從系統思考角度讀《獨角獸專案》

反之，如果是在公司的上班時間、用公司的場地舉辦活動，安排起來較有餘裕，也就順勢辦了好幾場：

在Ｋ公司內部 Agile Guild 舉辦一場【Scrum WHAT & WHY 討論：以 Scrum 認證模擬測驗為素材】小活動
在Ｋ集團內部讀書會舉辦一場【《經理人之道》導讀會】
在Ｐ集團內部舉辦兩場【Agile Workshop / 敏捷原理與團隊塑造】工作坊

Agile Workshop @ PChome

這次 Agile Workshop 算是初步成功將 OKR、OGSM、JTBD 部份精華融合到 impact mapping 當中了。也算了卻一樁塵封三年的心願。

尤其當我看到某團隊在上完課之後，自組織弄出這樣的 Scrum 空間，內心感動難以言喻。

某團隊的 Sprint 0 環境

問題解決的系統閱讀之旅

我在〈如何訓練一個新的 Scrum master？〉一文曾提到：

視團隊狀況及他的信心指數，我會開始逐步請他主持某些 Scrum 會議。

至於 retrospective 則可能是最具挑戰性的。這階段，能否搭配更即時更精準的事後回饋，甚至事前就進行沙盤推演，是成敗關鍵。

在我自己的 Agile Workshop 中，第二日原本就有一個名為「retrospective 進階篇」的單元。不過，隨著經驗累積，深感有重新設計的必要。因此，我默默展開一場「問題分析與解決」的系統閱讀之旅。

老書新書讀完一輪，思維相互碰撞，漸漸忘記原本的動機「訓練 Scrum master」，轉而鑽研到更深層的課題去了。此中有真意，欲辨已忘言。

「問題分析與解決」書單

這堆書籍當中，我對於其中兩類格外有感。

① 當了一陣子幕僚，總算比較看得懂溫老的書《顧問成功的祕密》。引述一段君婷老師的精闢評論：

溫老的書狀似戲謔，但這陣子周遊列國的經歷告訴我，這是真的：

顧問第一法則：不管客戶怎麼跟你說，一定有問題。
顧問第二法則：無論問題乍看之下如何，問題一定出在人身上。
顧問第四法則：如果別人沒有雇用你，千萬不要去解決他們的問題。
費雪基本原則：你現在適應得愈好，你的適應性就變得愈差。「顧問是比較不能適應目前的一種人，這使得他們的適應性比較強。」

② 像《金字塔原理》這種經典還是該用力啃一啃。畢竟，金字塔原理的牛肉，可不只有 MECE 及 why so/so what 而已，許多洞見都被稀釋書籍草草帶過。

認真啃了這類書籍，刻意練習須臾，驚覺勝間和代在《新．知識生產術》預告過的副作用真的也上身了。

「外行人在閒聊」

周遊列國，其致一也

這幾年在職場上周遊列國的經歷，讓我對王羲之《蘭亭集序》這句話格外有感：「雖世殊事異，所以興懷，其致一也。」

不同的是，國家、產業、公司、產品線、團隊、制度、文化、技能。

相同的是，「不管客戶怎麼跟你說，一定有問題」及「無論問題乍看之下如何，問題一定出在人身上」這兩大顧問法則，不斷上演。

相同的是，系統思考呈現出來的系統基模，也不斷現蹤。

很寫實的是，我在兩屆 DevOpsDays Taipei 帶的兩場系統思考工作坊，推演出來的 CLD，無心插柳，在日後周遊列國的旅程中都親眼目睹：

我在 2018 年根據《The DevOps Handbook 中文版》第七章設計的系統思考工作坊，描繪出來的飲鴆止渴、成長上限、捨本逐末動態結構，簡直就是某公司某團隊的寫照。
我在今年根據《獨角獸專案》設計的系統思考工作坊，描繪出來的捨本逐末動態結構，簡直就是某公司的寫照。

系統思考這門直探本質的技藝，很值得好好掌握。

也很慶幸看到這些年周遊列國的經歷及探索沒有白費，若干本質逐漸結晶固化下來。

吉卜林：「僅知英國的人，如何能知道英國呢？」

教練的必要

周遊列國也讓我看到：敏捷不起來，很多時候是因為輕忽技術實踐，甚至漠視。

就像《灌籃高手》安西教練的犀利質問：

「有人教導基本動作嗎？」

「每個人都各打各的，完全不團結。」

「球隊的教練到底在搞什麼？」

「基本動作」

我也漸漸體會到：其實，中高階主管也極需要 coaching。

我甚至懷疑：他們當年真的上過他們現在要初階主管接受過的培訓嗎？

沒有人做，就由我來起個頭吧。誰叫我現在的職稱有一個 “agile coach” 字眼呢？

技術面的培訓，已經逐步規劃與執行。

至於非技術面的培訓，一部份打算以導讀會的形式進行。目前的戰備存糧計有：

給自己一個 2022 的小挑戰，也算是刻意練習「金字塔原理」12 回合 (是的，我以金字塔原理來進行每一場導讀會)。

2022 許願

2022 年，希望自己能做到：

每個月辦一場 2hr 導讀會。
繼續更深度的本質修練。
繼續增進商務英語聽說能力。
開放冒險選項。

就醬。

Scrum 認證模擬測驗的兩項啟發

Sun, 11 Jul 2021 16:00:00 +0800

公司內 agile guild 定期聚會輪到我來主持了。這次我打算帶一場「Scrum WHAT & WHY 討論：以 Scrum 認證模擬測驗為素材」的小活動。

理論上來說，「Scrum WHAT & WHY」的終極答案應該是來自 The Scrum Guide，不過，這份輕薄短小的文件就像成文法典法條，不易引發實務聯想。反之，Scrum 認證模擬測驗可說是非常好的 Scrum 靈魂拷問材料，尤其是對略有實務經驗的人來說，內容可說是拳拳到肉，足以激盪小組討論的火花。若只以功利角度看待，就太可惜了。

有圖為證：

2021-07-21 活動迴響

Scrum.org 系統的證照是永久有效的。儘管自己早在 2018 年就有 PSM 1 證照，卻也想趁此機會再檢驗一下自己對於 Scrum 的認識。因此，上網找了一份免費的、有針對 The Scrum Guide 2020 版做過更新的「PSM 1 模擬測驗」，40 道題目，限時 30 分鐘，份量為正式測驗的一半。

結果還頗令人欣慰。和三年前相比，這次讀題變快，思考更少，分數也提高了（儘管這並非官方提供的模擬題） —— 或許也跟去年自己整理過一系列 Essence of Scrum 文章有關吧。

PSM 1 模擬測驗

答錯的題目中，有兩題滿有意思的，值得特別探討。

警告：以下有雷。如果你也打算去嘗試這份「PSM 1 模擬測驗」，請先去考一考，考完了再回來讀本文。

Sprint Goal

這一題是關於 Goal 的：

請先思考幾秒鐘：你認為答案會是什麼？

讓我們看看 The Scrum Guide 怎麼說。2017 版是如此描述 Sprint Goal 的：

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog.

2020 版則是如此描述：

The Sprint Goal is the single objective for the Sprint.

從 “an objective” 字眼替換成 “the single objective”，可看出背後想要強調的意涵。

因此，面對這題，在作答時，原本我還想把 Goal 標準放寬，結果就是⋯⋯

PSM 1 模擬測驗：Goal

PSM 可是非常強調原汁原味的，在核心理念上毫不妥協。

Scrum master as a management role

這一題是關於 management 的：

請先思考幾秒鐘：你認為答案會是什麼？

讓我們看看 The Scrum Guide 怎麼說。2017 版對於 Scrum Team 及 Scrum Master 的描述是：

Scrum Teams are self-organizing and cross-functional.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide.

2020 版則是如此描述：

(Scrum Teams) are also self-managing, meaning they internally decide who does what, when, and how.

Scrum Masters are true leaders who serve the Scrum Team and the larger organization. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. The Scrum Master is accountable for the Scrum Team’s effectiveness.

從 “self-organizing” 字眼替換成 “self-managing”，從 “servant-leader” 字眼替換成 “true leaders”，從 “responsible” 字眼替換成 “accountable”，可看出背後想要強調的意涵。

看了以上論述，你認為這題的答案會是什麼？

在作答時，原本我還想比照一般 agile 陣營或多或少有點輕視管理陣營的傾向或潛規則，選個貌似政治正確的答案，結果就是⋯⋯

PSM 1 模擬測驗：management

PSM 可是非常強調 Scrum Master 崇高價值的，在核心理念上毫不妥協。

關於這議題，我認為 LeSS 的 Role of Manager 論述得相當精闢，尤其是以下這張圖，清楚標示出 Scrum master 的 “manager” 幅度，值得一讀：

Role of Manager (LeSS perspective)

值得精讀的文獻

The Scrum Guide 2020 版真的很值得精讀，細細體會它如何將敏捷的「本質」闡述得更精準。

建議你：做完「PSM 1 模擬測驗」後，請確實檢討一次：針對每一題，盡量從 The Scrum Guide 找出佐證或反證的根據。如此一來，你會更貼近 Scrum 的靈魂。

更建議 Scrum master：請試著在你的團隊中舉辦幾次這類的討論活動。若引導得當，你們會在饒富趣味的觀點辯論中，逐漸凝聚團隊運作的共識。

Scrum master 培訓系列

❶ 如何訓練一個新的 Scrum master？

❷ 敏捷之途無他，刻意練習而已矣！

❸ Scrum 認證模擬測驗的兩項啟發

❹ 敏捷啟航的專業基礎：共同語彙

企業能否吸引專業人士？看這 14 點。

Tue, 06 Jul 2021 20:00:00 +0800

時代不斷進步，競爭日益激烈，專業工作者的門檻也愈來愈高。我們對 individual contributor 專業能力的期待是高的，相對的，這群人的自我意識自然也不低。

企業挑人才，人才也挑企業。

問題來了：企業能否吸引專業人士？

我從兩本書，摘錄出個人比較心儀的優勢導向、人本導向觀點。

巴金漢如是說

Marcus Buckingham 常發表領導力與人力發展的獨到見解，是我相當佩服的人。像他在 2017 年領袖高峰會演講 Reinventing Performance Management 提出的架構，就是我團隊領導的圭臬，以前我還將它製成卡片，用於 one on one 的引導或教練活動。

他 2019 年的書《關於工作的 9 大謊言》滿有意思的，可說是對他過往相關論述的總整理。不管你對他熟不熟悉，請先瀏覽作者提出的「九大謊言」清單，思考一下你該如何反駁？

謊言＃1　人們在意他們為哪家公司工作
謊言＃2　最佳計畫致勝
謊言＃3　第一流的公司把目標層層下達
謊言＃4　最優秀的人才是通才
謊言＃5　人們需要反饋
謊言＃6　人們能夠可靠評量他人
謊言＃7　人們具有潛力
謊言＃8　工作與生活平衡最重要
謊言＃9　領導力是一種東西

「謊言」？乍看之下頗為聳動。若進一步研讀作者提出的大規模實證資料，就能理解「真相」論述的理由：

編號	謊言	真相
＃1	人們在意他們為哪家公司工作	人們或許在意自己在哪家公司工作，一旦入職之後，他們關心的是屬於哪支團隊。
＃2	最佳計畫致勝	最佳情報致勝：即時協調你的團隊，重度倚賴每個團隊成員有根據的詳細情報。
＃3	第一流的公司把目標層層下達	第一流的公司不是把目標層層下達，而是把意義層層下達。
＃4	最優秀的人才是通才	第一個事實：職能是無法評量的。第二個事實：對任何職業或活動的高效能表現所做的研究顯示，卓越其實是個人獨特性 (idiosyncrasy) 使然。
＃5	人們需要反饋	人們需要的不是反饋，而是「關注」，而且是關注他們做得最好的事情。
＃6	人們能夠可靠評量他人	雖然人們無法可靠評量他人，但能夠可靠評量自己的體驗。
＃7	人們具有潛力	「人們有潛力」這個概念並不正確，或者，更確切地說，沒有助益；真相是：人們有動能。
＃8	工作與生活平衡最重要	最重要的，不是追求工作與生活的平衡，最重要的是找到工作中的喜愛、你的熱情所在。
＃9	領導力是一種東西	領導力不是一種東西，因為它無法被可靠評量；追隨是一種東西，因為它能夠被可靠評量。一個人是否為領導者，唯一的決定因子是有沒有人追隨。

從這份「謊言 vs 真相」清單，可看出 Marcus Buckingham 的論述是優勢導向、人本導向。

杜拉克如是說

談到優勢導向、人本導向，不由得想起《彼得・杜拉克的管理聖經》(The Practice of Management) 早在 1954 年就對於 individual contributor 的特殊需求，提出獨到的觀點：

From: The Practice of Management, Peter Drucker (1954)

大師如是說：

一、專業性職務的目標，必須是專業上的目標。儘可能為專業人員提供經理人的願景，讓他們了解專業工作對於企業整體的影響，因此他們可以自己想清楚怎麼做才能為公司帶來最大的貢獻。

二、優秀的專業人員往往不是傑出的管理人才。原因不見得在於專業人員寧可獨自工作，而是他們通常很厭煩行政作業。優秀的專業人員往往對行政管理人員缺乏敬意，他欽佩的是在專業領域中表現比他優秀的人。

企業需要的是為個別貢獻者提供一條與管理職位平行的升遷管道。這些新升遷機會的聲望、重要性和地位應該和傳統管理職位沒有兩樣。

三、我們必須肯定專業人員對公司的貢獻絕對不遜於經理人的貢獻。

四、公司應該對專業人員提出許多要求，絕對不接受、也不寬容拙劣和平庸的表現。但是，究竟專業人員如何完成工作，則必須交由他自行負責，也自行決定。專業人員的上司應該有能力協助、教導、指引屬下，他和專業人員的關係應該好像大學的資深教授與年輕教授之間的關係，而不是從屬關係。企業需要給予稀有而寶貴的專業人才 —— 能啟發同事的教師，充分的肯定、地位和獎勵。

五、專業人才需要在企業內外都獲得專業上的肯定。

從這 9 + 5 點，大概可以粗略勾勒出專業人士心之所向的關鍵因素。

服務事故處理的系統思考

Mon, 05 Apr 2021 20:00:00 +0800

集團內 Agile CoP 定期聚會，最近都在團練「行動學習 (action learning)」。

行動學習十分殊勝。多元探詢角度居然能夠同時並存，對我來說，在參加之前委實難以想像。

我參加了兩次，上次我選擇的提問切入點 ¹ 是「問題重塑」，這次刻意換成「系統思考」來練練。

某團員提出一則個案讓大家探討：

P0 事件令人疲於奔命，大家也認同軟體服務系統 Op-friendly 很重要。問題是：應該由誰去推動？

一看這敘述，內心小劇場就開始了：我超想換回上次的「問題重塑」切入點呀！不過，轉念一想，「系統思考」也是能夠重塑問題的⋯⋯

於是，藉由團員夥伴們從各個角度提問，我漸漸系統思考出一些端倪（並偷偷夾帶一些問題重塑）。接下來，就要帶著這份初期假設去小步行動了。

具體細節不便在此公開揭露，我就改用有些局部類似的場景：《獨角獸專案》第 11 章的故事情節當例子吧。

規則

《獨角獸專案》主角梅克辛很納悶：為什麼她一直陷在工單的無窮迴圈？

是我們一手造成的。我們制定了一系列規定，強調 QA 從開發部門分離出來的必要性，你懂的，以便保護業務不受那些瘋狂、無所顧忌的開發人員波及。每一年，我們都用任何出了差錯的事作為名堂，制定更多的規則來『提升開發人員的問責性』，然而只讓效率更加緩慢。

常聽人們說 IT 是整個組織的神經樞紐。但出於某種原因，企業卻容忍他們的中樞神經逐漸退化，好比多發性硬化症擾亂了大腦內部與在身體間流動的資訊流一樣。

若改用系統思考 CLD 圖來表達，這是企圖利用「制定更多規則」來達到平衡迴路：

CLD Part 1：制定規則的平衡迴路

規定，初衷是好的；可是，過度的規定，會反噬系統研發。

就像《獨角獸專案》第 8 章所描述的情景：

第三理念的對立面是堅持程序合規性和 TWWADI 的人，你們懂吧，『The Way We’ve Always Done It.（這是我們一貫的做法）』。無數的規則、條例、流程、程序、批准和階段門檻，隨時都有新的規則出現，為了防止最近的災難再度發生。

嚴格的專案計畫、不靈活的採購流程、強勢的架構審查委員會、不頻繁的發布時程、冗長的審核流程、嚴格的職責分離⋯⋯你們對程序合規性一定深有體會。

每一項都增加了我們所做的每一件事的協調成本，也推高了延遲成本。再加上決策所在和工作執行地之間的距離不斷擴大，我們交付的成果品質每下愈況。正如戴明大師 (W. Edwards Demming) 的觀察，『一個壞系統將次次擊潰所有好人。』

用系統思考 CLD 圖來表達，這是「制定更多規則」所產生的惡化增強迴路：

CLD Part 2：制定規則的惡化增強迴路

欲證實是否真有如上圖所預測的惡化增強迴路，可沿著增強迴路觀察關鍵變數的增長趨勢：

Restrictions on Dev
Dev’s willingness to cooperate and contribute

捨本逐末系統基模

上圖，像極了捨本逐末 (shifting the burden) 系統基模的「症狀解」及「副作用」部分：

捨本逐末 (shifting the burden) 系統基模 (摘自 Wikipedia)

既然如此，我們就來補上「根本解」，把整幅拼圖完成：

CLD Part 3：以整體價值流思考的平衡迴路

這塊拼圖，也正是 DevOps 運動講究的整體價值流思考。

適合的特質

剩下的問題是：這塊拼圖，該由誰來拼？

無疑的，在《獨角獸專案》故事中，適合推動這些改變的人，就是紅衫軍。

讓我們試著不要只鎖定在特定的單一英雄人物身上，而是試著重塑問題，改問：紅衫軍有什麼特質？

《獨角獸專案》第 5 章，如此形容紅衫軍：

對鳳凰專案的大多數人來說，營運部只代表在另一頭接收任務工單的人。他們是所有人的抱怨對象。但是，庫爾特和這群烏合之眾顯然有截然不同的工作之道，他們用非正式的方法繞過正常的組織溝通管道。

梅克辛非常興奮。她對這個團隊一直致力完成的事以及自己被選來幫忙這件事，發自內心感到驚艷。我終於找到屬於我的部落了，她心想。這就是經營人脈的意義所在——你可以集結一群充滿動力的人來解決一個大問題，儘管這個組合人選和官方組織架構圖一點關係也沒有。

第 5 章，如此形容梅克辛：

梅克辛，你為了破解鳳凰專案軟體版本的努力成果讓我們很驚艷。我們對你所展現的技術和社交技巧深感敬畏，你成功地找出了幾乎所有的環境要素，這件事需要驚人毅力、專注，還有永不妥協的態度！

第 12 章，如此形容香儂：

梅克辛欣賞香儂盡量把握任何機會讓人們站在同一陣線。

第 17 章，如此形容比爾與梅克辛：

許多企業認識了三層面理論，還是無法好好地投資新一代創新事務。換句話說，他們在核心業務投資不足，因為他們被脈絡業務綁架了。脈絡業務管理不善是一流企業的罩門。被脈絡業務耽誤的公司沒有辦法專心推動核心業務。

的確有一條改造公司的策略，但它需要近乎苛刻的專注與堅持。

最適合管理脈絡業務就是比爾和梅克辛這樣的人。這絕非易事。你需要一個真正了解公司業務的人，能夠不屈不撓地在全公司上下推動標準化，把組織的最佳利益視為第一位，清楚科技的運用時機與分寸。

但願以上這些摘錄的段落，足以給任何有志推動改變的有志之士一些啟發。

行動學習三要素 L = P + Q + R，當中的 L 為 learning，P 為 programmed knowledge，Q 為 questioning，R 為 reflection。 ↩︎

被 Yves 啟發的敏捷轉型之旅

Wed, 31 Mar 2021 08:00:00 +0800

（2021-06-16 補記）在 Yves 臉書看到《敏捷管理生存指南：不是快，而是適者生存》這本書終於要上市的消息，非常振奮。僅以此文，紀念當年 Yves 部落格文章給我的種種啟示。

《敏捷管理生存指南：不是快，而是適者生存》

起頭

2016 年七月，剛升上 Gogolook 的部門主管，也不容我再迴避一個埋藏已久的內心交戰：公司再這樣下去是不行的，朝敏捷的方式轉型才有出路。可是「轉型」二字談何容易，「敏捷轉型」更涉及深層的心智模式，匹夫之勇是行不通的，非長期抗戰不為功。

我需要一份地圖，告訴我敏捷轉型的航道上可能有哪些冰山或暗礁。就算還不知道該如何排除剷平，至少知道該如何趨避。

幸運的是，此刻 Yves 剛出爐的〈找出組織無法變敏捷的阻礙 – 團隊共創法實做〉部落格文章，恰如一場及時雨。文章不僅整理出敏捷轉型常見的 12 項阻礙，更進一步將它們分成三大類型，並開出三帖藥方：

人員或組織的慣性 → 解決慣性的方法就是一直動，平衡日常營運與變革，控制前進的腳步，從走路、小碎步、健走慢慢加速到需要的節奏。
主事者的重視程度 → 權力越集中的組織越有可能大幅改變組織架構與資源投注，否則就得組織扁平化，採用自組織模式。
人員沒有能力或知識 → 給資源學習，給空間運用。

綜合考慮之後，我選擇在自己有直接職位權影響力的團隊內，打破慣性，亦步亦趨植入 Scrum 相關知識與實踐。這個小團隊的成功，便成為日後在公司內進一步擴大敏捷施行範圍的指標性個案。

我很感激 Yves 這篇文章的啟示。

遊戲

敏捷實施一小陣子，很快就會觸碰到一個迴避不了的衝突點：自組織、自管理要到什麼程度，才不是淪為玩假的敏捷？

隔壁團隊嘗試跑了 Kanban 一陣子，遇到這類問題，找我討論。

我知道這問題應該被解決，但該如何解決？當時的我並沒有頭緒，更何況這是隔壁的團隊，是我沒有直接職位權影響力的團隊。

我又向 Yves 的部落格取經。幸運的是，Yves 稍早在〈自己來做到死！ – 玩授權撲克來學主管如何授權〉這篇文章裡就點出一個關鍵，也介紹一個有趣的工具：

當主管在考慮工作的授權時，不應該問自己「要不要授權？」，而要問自己「要如何授權？」

因為跟自組織一樣，授權不是 0 跟 1 二選一，而是程度多寡的差異。授權撲克（Delegation Poker）就是幫助我們思考「要如何授權？」的一個好工具。

這麼有趣的工具，令人躍躍欲試。於是，我開始密謀在公司月會時，帶這個團隊公開玩一場「授權撲克」遊戲，既解決他們的問題，也試圖在寓教於樂氣氛中對全公司傳達「某些不一樣的事正在發生」的訊號。

我大致上是根據 Yves 文章介紹的玩法，微調成更像 planning poker 的方式，讓團隊公開探討幾項活動的授權等級：

Refine PBI
Select SBI
Estimate SBI
Freeze spec
Unfreeze spec
Allow fast lane during sprint
Manage tech debt

（也感謝 Yves 慷慨贈我幾盒鈦坦科技設計的授權撲克。）

這場公開活動，不僅達到預計的效果，也讓我更敢公開進行一些非傳統的引導活動。

空間

2017 上半年，公司人數成長到空間不敷使用，打算再租下另一層辦公室。

國內外敏捷先驅的經驗告訴我們，合適的實體空間，能夠催化敏捷的成效。因此，這是千載難逢的大好機會，可以從頭開始把空間塑造成可滋養敏捷成長的模樣。

事情就是這麼湊巧。這一年來，每當我遇到相關的疑惑、需要相關的參考對象，Yves 就是會這麼湊巧的與我的敏捷探索之路產生交集。

此刻，Yves 所在的鈦坦科技也正在搬遷他們的台北辦公室，葉千綸設計師更在 3 月 30 日晚間公開分享新辦公室的設計理念。於是，我們去取經，並設法將一些有趣的元素帶回來。

後來，與業界交流敏捷轉型甘苦談，才赫然發現，封閉的實體空間，對台灣軟體研發圈子的傷害有多大。我們真的很幸運，能在推動敏捷轉型的初期，就有可師法的對象，讓實體空間不致成為敏捷的阻力。

人的問題已經夠麻煩了，如果連空間都是麻煩製造者，怎麼能苛責敏捷轉型不順利？

引導

知識性的 Scrum 課程很多，但軟技能卻很少直接在 Scrum 課程中傳授。

這麼說或許並不公平，畢竟 Scrum 只是具體而微的框架，不是包山包海的滿漢全席，骨肉還是需要由其他地方填補。

什麼才是 Scrum 需要搭配的軟技能？

Yves 的〈敏捷 X 引導 – 讓 Scrum 團隊自組織的具體方法〉部落格文章點出一個關鍵：

Scrum 架構裡有那麼多的溝通在發生，沒有人可以真正控制事情的進行，主管需要學習其他的領導方式。

於是，我開始從這篇文章中按圖索驥，尋找與溝通、領導、引導相關的軟技能：

焦點討論法 (Focused Conversation, ORID)
團隊共創法 (Consensus Workshop)
開放空間會議 (Open Space Technology)

這些引導技能，水很深，我沒能全盤掌握，但已經夠讓我在公司內推動不少敏捷變革措施。

一路以來，從 Yves 的文章受益匪淺。現在，欣見 Yves 將多年心得整理成有系統的專書《敏捷管理生存指南：不是快，而是適者生存》，相信更能幫助尚在摸索的芸芸眾生。

《敏捷管理生存指南：不是快，而是適者生存》

　　　　　　—— 敏捷魔藥師　葉秉哲 (William Yeh)　2021-03-31

從系統思考角度讀《獨角獸專案》

Sun, 28 Mar 2021 16:00:00 +0800

活動名稱：從系統思考角度讀《獨角獸專案》

時間：2021-11-24 (三) / 13:30–15:00 (因疫情影響延期舉辦)

會議：DevOpsDays Taipei 2021 的 603 會議室

課程簡介

《獨角獸專案》是本寫實刻劃軟體研發者日常甘苦的商業小說，但內行看門道，這本奇書，並不止於小說，而是真正可以照表操課的，以敏捷的 IT 能力驅動並翻轉整間公司的競爭力。

我在本書推薦序也曾如此建議：『請以「系統與組織的五大理念」觀點細讀，從頭分析故事的人事時地物及因果關係。經此一番系統思考，比起許多愛談高大上理念的敏捷、DevOps、數位轉型書籍，你將會有更深刻具體的領悟。』

問題是：如何系統思考？如何照表操課？

這場 90 分鐘的迷你工作坊，將以「系統思考」角度，帶你分析書中倡議的「五大理念」，你將會得到有助於形塑適合 IT 滋長企業文化的施力線索。

目標聽眾

已有《獨角獸專案》一書，想從中擷取可行洞見的人。

程度分級 ★☆☆ (通識)：介紹新知給尚未具備或僅具備少許該領域知識的人，也包含非技術議題。

聽眾收穫

認識高效能研發團隊的核心特質，以及促成這些特質的關鍵施力點。

注意事項

學員需知

上課前，請先完成「課前作業」（後詳）。
上課時，請攜帶「課前作業」及《獨角獸專案》一書。建議攜帶繁體中文版，以備隨時照頁數檢索。

課前作業

根據學員不同的狀況，我將課前作業分成兩部分：

必備作業：所有人都務必在課前確實完成。
選配作業：行有餘力，請在課前盡量做。做得越多，課堂上就越輕鬆。

必備作業

請依照「速讀」及「精讀」兩階段依序進行：

➊ 速讀階段：速讀完《獨角獸專案》至少一遍，先享受高潮起伏的劇情，並熟悉人物與關係。

➋ 精讀階段：挑出書中所有與「系統與組織的五大理念」有關的段落，越多越好。

我自己的做法是：每讀到一個有關的地方，就用書籤標註。如下圖：

用書籤標註五大理念的例子

一點小建議：請善用不同顏色的標籤，或是可寫字的標籤，以便檢索。

以上請務必在課前確實完成。

選配作業

若行有餘力，請針對前面挑出的「五大理念」段落，分析其中的因果關係。

就以《獨角獸專案》第七章為例，埃瑞克在對紅衫軍成員侃侃而談第一理念「簡潔性和區域性 (locality and simplicity)」時，有個段落提到「程式碼區域性與組織區域性」：

因果關係例子：《獨角獸專案》第七章

讓我們先以「因果關係」角度直接翻譯這段文字吧。初期，你可能會解讀出三組因果關係：

因果關係 Part 1：直接翻譯

這三組因果關係貌似彼此獨立。若再仔細檢視，你可能會發現彼此之間並不是毫無關聯，而是可以辨識出一些共同結構或模式：

因果關係 Part 2：找出共同模式

最後，再進一步以「系統思考」常見的「增強迴路」角度來檢視，我們可以合理腦補上「正確歸因」與「錯誤歸因」兩項元素，統整出一份較完整的因果關係圖：

因果關係 Part 3：增強迴路

因果關係圖一旦推導到這種地步，施力線索也就昭然若揭。

這就是「系統思考」的威力。

這份「選配」作業，請盡可能在課前多做一些。課前做得越多，課堂上你就會越輕鬆。

做不出來的，也別擔心，課堂上會以分組方式進行，有隊友會與你一齊破關。

《獨角獸專案》系列文章

❶ 值得你看門道的好書——《獨角獸專案》推薦序

❷ 從系統思考角度讀《獨角獸專案》

系統思考工作坊 - 系列文章

❶ 【系統思考的四堂課】緣起

❷ 第一場公開班課後回覆：思維的重量訓練

❸ 從系統思考角度讀《獨角獸專案》

➍ 從系統思考角度談 DevOps 三步工作法

「系統思考工作坊」系列

Sun, 28 Mar 2021 00:00:00 +0000

【系統思考的四堂課】緣起

第一場公開班課後回覆：思維的重量訓練

從系統思考角度讀《獨角獸專案》

如何訓練一個新的 Scrum master？

Wed, 17 Mar 2021 20:00:00 +0800

今天在公司內 agile guild 定期聚會中，討論到一個有趣的議題：

「如何訓練一個新的 Scrum master？」

邊寫便利貼，邊回想自己過往經驗，也試圖歸納統整一些層次。

寫完，講完，驚覺：這跟憲哥在《教出好幫手》提出的 OJT 步驟、福哥在《教學的技術》提出的演練法，結構極為相似。¹

我的方法是分成三大階段。

➊ 教學

這位待培養的 Scrum master 置身的團隊，可能已經有跑一些 Scrum 了，也可能根本就是 Scrum 沙漠。不管是哪一種情況，在第一階段的重點是：先求對 Scrum 有個概括不偏斜的理解（但尚不須深度理解每一個細節），搭建正確穩固的鷹架。

最省事的，就是直接送去上課。當然啦，要慎選老師，不能選只顧著考證照的。

其次，就是靠自己，根據實際需要，針對特定議題，設計相關的體驗式迷你工作坊。

這階段，類似憲哥福哥講的「我說給你聽」。

➋ 觀察員筆記

鷹架搭好了，我就會請他準備「觀察員筆記」。

在團隊中，儘管他檯面上的身分還是 product owner 或 developer，但要開始適度切出一個「觀察員」的分靈體，觀察我是怎麼扮演 Scrum master 的角色。

觀察，即時筆記，並在定期 1 on 1 場合提出來釋疑或討論。我甚至還會鼓勵並協助他們去觀察其他團隊，接觸不同的運作風格，比較，辯證，並逐漸勾勒想像出他們屬意的風格。

這階段，類似憲哥福哥講的「我做給你看」。

➌ 登場

視團隊狀況及他的信心指數，我會開始逐步請他主持某些 Scrum 會議。

Daily Scrum 及 sprint review 通常是可以最早開始嘗試的，至於 retrospective 則可能是最具挑戰性的。這階段，能否搭配更即時更精準的事後回饋，甚至事前就進行沙盤推演，是成敗關鍵。

這階段，類似憲哥福哥講的「讓你做做看」。

Creditability

為什麼要如此大費周章？Scrum 三支柱不是有一條 “adaptation” 嗎？Scrum 不是講究 “courage” 核心價值嗎？為什麼不放膽讓他從經驗中學習？

可能是我對於「Scrum master 的 creditability」很注重吧，非常小心維護 Scrum master 見習生在團隊中的 creditability。畢竟，歪樓的 Scrum 太多太多了，Scrum 被外行人誤解已經是家常便飯。對於 Scrum master 這個常被外行人誤解的角色，我的期許是：經營好第一印象，不要曝於坐實錯誤第一印象的風險——那會導致改革的倒退。

更嚴重的是：如果置身的是一個對 Scrum 懷有戒心的組織，這極可能嚴重摧毀 Scrum master 見習生好不容易萌芽的浩然之氣。就像孟子所說：「我善養吾浩然之氣⋯⋯其為氣也，至大至剛，以直養而無害，則塞於天地之間。其為氣也，配義與道；無是，餒也。」

我寧可大費周章，以直養而無害。慢一點，比較快。

一些個人經驗的整理，供大家參考。也願各位新的 Scrum master 都能找出自己的風格。

Scrum master 培訓系列

❶ 如何訓練一個新的 Scrum master？

❷ 敏捷之途無他，刻意練習而已矣！

❸ Scrum 認證模擬測驗的兩項啟發

❹ 敏捷啟航的專業基礎：共同語彙

憲哥福哥的 PESOS 作法是：P 學習前準備 → E 解釋：我說給你聽 → S 示範：我做給你看 → O 演練：讓你做做看 → S 成效追蹤。 ↩︎

軟體研發者的隨身職涯教練——《經理人之道》推薦序

Sun, 21 Feb 2021 16:00:00 +0800

研究所時期，身為實驗室的師兄，我必須帶領學弟妹完成各種公民營機構的合作計畫案。那是我第一次接觸到「領導技術團隊」這件事——這件學校不會教的事。

後來，在新創圈打滾，陸續經歷了小工頭、技術負責人、部門主管等身分轉變，甚至也有機會從事跨部門、跨團隊的 Scrum master 及變革推動者。資歷增加，守備範圍不斷擴大，一路走來，跌跌撞撞在所難免。遇到挫折時，不免自問：這真的是我想走的路嗎？我不能只當單純的個別貢獻者 (individual contributor) 就好了嗎？

沒有 mentor 在身邊，得向書籍求教。

書架上不乏經理人職涯發展的忠告。針對經理人與個別貢獻者兩種職涯路線的分野，《彼得・杜拉克的管理聖經》(The Practice of Management) 如是說：

專業人員和經理人一樣，同時肩負「工作」和「團隊運作」的責任。差別：經理人必須為成果負責，因此他必須為別人的工作負責。個別專業貢獻者無論採取單獨工作方式，或是團隊的一分子，也為成果負責，但只為自己的工作成果負責。唯有當其他人了解他的工作成果，並且能運用他的工作成果時，他的工作才能發揮功效。

但是，優秀的專業人員往往不是傑出的管理人才。原因不見得在於專業人員寧可獨自工作，而是他們通常很厭煩行政作業。優秀的專業人員往往對行政管理人員缺乏敬意，他欽佩的是在專業領域中表現比他優秀的人。

企業需要的是為個別貢獻者提供一條與管理職位平行的升遷管道。這些新升遷機會的聲望、重要性和地位應該和傳統管理職位沒有兩樣。專業人員的上司應該有能力協助、教導、指引屬下，他和專業人員的關係應該好像大學的資深教授與年輕教授之間的關係，而不是從屬關係。

至於經理人路線，針對一般領域的經理人，《經理人的一天：明茲伯格談管理》(Managing) 如此提醒：

只會溝通的管理者，從來不會完成任何事情；只會行動的管理者，最後是一人包辦所有事物；只在乎掌控的管理者，可能下面只剩一些唯命是從的馬屁精。

有效的管理者不會在各個角色之間保持完美的平衡，他們雖然無法忽視某些角色，但可以偏向其中幾個角色。管理工作的關鍵在於，把管理的所有面向融入這種動態平衡中。

進一步，針對技術領域的經理人，《領導者，該想什麼？》(Becoming a Technical Leader) 提出犀利的拷問：

我能一面當領導者，一面繼續提升我的技術能力嗎？一個毫無技術背景的人，有可能在技術界成為領導者嗎？一旦成為領導者，我必須犧牲多少技術專業能力？我能得到多少回報？

諸位大師所言極是。不過，資質駑鈍如我，難以直接將如此泛化的建議轉換到軟體技術領域。畢竟在我們這個領域裡，技術深度與廣度皆日新月異，技術選型更迭頻繁，更講究組織扁平以迅速應變，因此，過去那些針對一般領域、甚至一般技術領域的職涯分化發展通則，未必能夠不假思索直接套用到軟體技術領域。

我更期待看到具體建議，而且是專門針對我們這個軟體技術領域而提出的具體建議：

軟體研發者，在不同的職涯階段，對於溝通、行動、掌控三個面向，各該保持哪一種動態平衡狀態？
軟體研發者，在不同的職涯階段，對於軟體技術能力，該追求或維持到什麼程度？又該如何做到？
軟體研發者，面對「經理人」與「個別貢獻者」兩條路線，是否只能二選一？是否都是單行道？

這類疑惑，沒有 mentor 在身邊，實在難以解決。

因此，當我看到 Camille Fournier 寫的《經理人之道：技術領袖航向成長與改變的參考指南》(The Manager’s Path) 這本書，以她從軟體工程師開始，一路做到 CTO，甚至避險基金公司常務董事的豐富經驗，直言不諱道出具體觀點，不禁擊節讚嘆。

這不是一本廣泛適用所有人的管理學書籍，而是一本專門寫給工程經理的工具書。工程管理是一門技術學科，而不是僅僅一套帶人心法。

《經理人之道：技術領袖航向成長與改變的參考指南》

譬如說，對於尚處於非正式的技術負責人 (team lead) 階段，她建議要專注在：透徹瞭解架構、注重團隊精神、領導技術決策、溝通。到了更正式的工程經理 (engineering manager) 階段，她建議，除了必須增進人員管理技能，萬萬不可忘記繼續維持技術敏銳度：

從我的經驗來看，絕大多數工程部門管理的挑戰都在「工程」與「管理」的交集處。人事管理不容易，我不會低估處理人際關係的挑戰，而這些與人打交道的能力在各行業都吃得開。

然而，工程部門管理的挑戰並不僅止於人員管理的面向。我們管理的是一群技術人員，且我們之中大多數人來自技術專家的職位。我決不會建議非技術專業背景人員管理工程部門！在技術上長年累積的專業有助於獲得團隊的信任，並幫助你領導團隊做出高效決策。當你努力成為一名成功的工程主管，不要低估技術能力的價值。

點出「維持技術敏銳」的重要性之後，她也建議初階技術主管可以這麼做：

當然，你要學會平衡的藝術。當你轉換跑道到管理職時，維持技術敏銳可能是一項艱鉅挑戰。然而，在管理團隊的這個階段，假如你不再維持對程式碼的敏銳度，你將面臨在職涯發展中過早和技術脫節的風險。雖然你日後打算走管理職，但這也不代表你應該放棄技術責任。事實上，我在關於 Engineering Lead 的職位描述中特別提過，我希望這個職位的經理還要負責交付小功能並修復 bug。

可悲的是，某些公司實際上並沒有開出「有一點時間開發程式碼的經理」的職缺。我的建議是繼續維持對技術的敏銳度，直到你真的認為自己夠懂程式碼和系統設計等領域，再決定你是否想轉換到管理職。一旦和程式碼說了再見，重新回到程式碼的懷抱將格外困難。更有甚者，假如你過早與技術脫節，你可能因為技術專業積累的不足，而無法朝更高的管理階層邁進，最終只能止步於中階主管職。

對於逐漸昇到類似工程總監位子的人，她也提出具體建議以盡可能維持技術敏銳度：

幸運的是，對我們來說，還有幾個不需要碰大量程式碼的辦法幫助我們保持手感。對於二級審核人員來說，程式碼審查就是個好方法。假如你更親力親為地建立系統，請繼續關注這些系統，因為你會比大多數人更能牢記技術細節，可以透過程式碼審查和提問來幫助為這個系統工作的工程師。

最後，即使你不大算寫太多 code，我也強烈建議你每週至少有一個完整的半天時間，不要安排任何會議或其他工作，專注在一些富有創造性的追求，比如撰寫關於技術的部落格文章、準備科技大會的演講內容，或者參與一個開源專案。

針對軟體技術領域，「經理人」與「個別貢獻者」兩條路線的取捨，她的觀點是：

一定要記得你有權利更換職涯跑道。人們通常會在某個時候嘗試管理職，然後發現他們不喜歡當主管，兜兜轉轉回歸技術職位。走上管理職，你不是不能回頭，但記得睜大眼睛去嘗試。每個職位角色都有各自的優缺點，自己親自去感受最適合你的那一種。

她也建議如何引導下屬對「經理人」與「個別貢獻者」兩條路線進行探索：

在人們夠格被升職到資深工程師或更高的職等之前，鼓勵他們累積管理或指導經驗。對於大多數公司來說，管理職和技術職的分岔點應該是人們開始展現領導力的階段，無論這個領導力是管理人員還是設計軟體。即便人們負責設計軟體，也會面對人與人之間的互動與需求；出類拔萃的資深個人貢獻者也知道如何管理專案和指導團隊中佔比更多的菜鳥／初階工程師。你可以考慮將指導經驗作為資深個人貢獻者的升職條件。

以上是我從書中信手捻來的幾則精闢見解，書中還有更多精彩內容待你發掘。

我認為，身為軟體研發從業人員，只要你不是自雇者，只要你想在軟體研發組織內，統合團隊力量做一番大事，都值得細讀此書，把此書當作軟體研發者的隨身職涯教練：覆盤總結自身經驗，解決當下問題，凝聚團隊，培訓優秀下屬，並替未來道路預做準備。

這將是能陪伴你很久的一本書。

　　　　　　—— 敏捷魔藥師　葉秉哲 (William Yeh)　2021-02-21

2020 個人回顧

Sat, 26 Dec 2020 20:00:00 +0800

年初，再多跨出舒適圈一步，換到另外一間外商。

如果說 2018 是收攝靜觀的一年，2019 是驚滔駭浪的一年，那麼，2020 算是兩者兼具。

到了年終，又開始要做個總回顧，再對來年許願。去除一些不便揭露的事情，以下是簡單的回顧。

翠峰湖 (2020-08-13)

補血課程

這一年，由於 COVID-19 因素，參加的實體課程，就只有這一場，而且還是首發場：

512 / 目標管理與團隊績效 – 統整 OKR 與 KPI 的有效實務

我曾於 2018 年 Q4 在執掌部門內試行導入 OKR。對於這個我只起了個頭，但遺憾因為換公司而沒能一路帶著它發展下去的大膽嘗試，一直持續關注，希望能有機會吸收專家的實際導入經驗。

彼得・杜拉克在 The Practice of Management 揭示：「企業管理，也就是目標管理。」

君婷老師的這堂 OKR + KPI 首發課程，雖然表面上是在談目標管理，但卻讓我一直聯想到：這簡直就是迷你版的企業管理課！

512 / 目標管理與團隊績效 – 統整 OKR 與 KPI 的有效實務

這次課堂上，一方面得以更專注觀摩老師是如何處理某些理論與在地實務的兩難議題，更能不時抽出神來，俯視反思某些平日已經隱隱約約觸及到，但並未徹底認真系統化對待的選擇。

譬如說，individual contributor 與 manager 的分野。經過這堂課的洗禮，我認為，目標管理能力，大概就是兩路線最大的試金石吧。

課堂上也再次讓我反思另一個觀點：企業的本質，就是傳話遊戲。

OKR 有許多精巧的設計，但若不明本質，很容易被無視。

只套上 OKR 形式外殼而忘了時時心繫著本質，是刻舟求劍緣木求魚。本質，很重要。

出自《轉職必勝班》

上完這門超值的課，萌生重讀目標管理之父彼得・杜拉克開山之作 The Practice of Management ¹ 的念頭，以求打通任督二脈。1954 年的書，就看到許多 OKR 核心元素，理念闡述也比現今許多 OKR 書籍更深刻。有人文底蘊，相對與現今管顧業流行的食譜式風格。

在企業中，經理人並不會自動自發追求共同目標。相反的，企業在本質上包含了三種誤導經理人的重要因素。

The Practice of Management

1954 年的書，半世紀之後，居然仍能精準地針砭職場。果然是從本質出發的管理學開山之作。

學苟之本，書架上那四、五本曾經捧讀再三的 OKR 專書，瞬間皆為註腳。

演講及授課

今年，由於 COVID-19 因素，再加上自覺已經過了能夠恣意跑趴出沒社群活動的人生階段，婉拒許多邀約，只接了一場公開演講，以及一場公部門的 3 小時延長版：

gRPC：更高效的微服務介面
- 30 分鐘版 @ 台灣雲端大會 2020
- 3 小時版

淡出這類活動，另一個更重要的原因是：以下這些思考與探索，佔據我更多心力。

敏捷本質的再思

去年，我曾針對敏捷基本功進行一些反思。

今年年初來到的這間外商，極度重視文字溝通，也有些常態性在家遠距工作的同仁，再加上 COVID-19 攪局，種種因素加總在一起，我素來習以為常不疑有他的敏捷作法，遭遇未曾預料的崩解危機。

譬如說，我常常反思：原本就很奉行 Agile Manifesto 四大總綱的團隊，會比較容易適應遠距工作模式呢，還是相反？

就以 “Individuals and interactions over processes and tools” 這種推崇高頻寬溝通、甚至連空氣都讀得出來的敏捷第一總綱而言，一旦碰到「遠距工作模式」，豈不是被迫降級到 over 的右邊？就以 “Working software over comprehensive documentation” 及 “Customer collaboration over contract negotiation” 第二、第三總綱而言，一旦碰到「文檔驅動」，豈不是被迫降級到 over 的右邊？

（倒退的反模式？）

凡此總總，算是浸潤 agile 多年的我，不得不開始反思的文化衝擊。

我必須再次解構敏捷，剝離表象，更抓緊本質。

漸漸地，我提煉出某些更核心的元素，整理成 ‘Essence of Scrum’ 系列（未完，待續）：

後來，The Scrum Guide 在 2020 年 11 月的改版中，有許多地方滿符合我萃取與補充強調的地方，所見略同，深感欣慰。

核心本質釐清了，還得設想配套。

敏捷本質的配套

Scrum 是很細緻的輕量級框架。輕量，但細緻。

就像精煉過的套路定石，精煉到外行人嫌它粗糙。常常要實際運用了，卡住了，與其他方法碰撞了，才恍然大悟：原來 Scrum 之所以要這樣設計，是這個原因呀；之所以行不通玩不下去，原來是自己這邊功力有待提升呀。

Scrum 是一面照妖鏡，顯影出自身不足。

什麼樣的功力需要提升呢？

專業領域的技術功力自不在話下，畢竟此乃專業品質之根基；至於與專業領域技術無直接相關的層面，則是常被忽略的重點。

我發現，電腦玩物站長 Esor 寫的《時間管理的 30 道難題》，正是一枚火石，可與 Scrum 碰撞出火花。

時間管理的書很多，但難得看到像這一本深刻觸及本質的好書。

譬如說，本書第四章探討任務分解、短時間專注等時間管理手段。可是，看到暢談「短時間專注」原理的這一頁，不禁聯想到：Scrum 講究的 sprint cadence 不也是如此嗎？如果像 waterfall 信徒那樣誤把 Scrum 當成只知不斷爆肝短衝，不適合長期抗戰，那也太小覷 Scrum 了，更是不理解「短時間專注的節奏跟頻率」的真義。

《時間管理的 30 道難題》 p.150

第二章，簡直就是在講敏捷法的本質。

雖沒明講，但內行人一看就知道帶有 impact mapping 及 sprint planning 的共通精神。儘管這本書針對的是「個人」的時間管理，請試想：如果每個個人都具備如此思維，一旦放大至「團隊」的規模，豈不是水到渠成？

時間管理要思考的，不是如何把更多看似重要的目標排入待辦清單。時間管理要思考的，是如何「把事情完成得很重要」。

《時間管理的 30 道難題》第二章

《時間管理的 30 道難題》真是一本奇書。不僅可與 Scrum 碰撞出火花，也看到許多可與【過好人生學】² 相呼應之處：創造結果的能力、路徑依賴⋯⋯。

私心認為，想導入敏捷的團隊，甚至想導入遠距敏捷的團隊，都該先接受像這本書這種層面的培訓，提升這類與專業領域技術無直接相關的基本功。如此配套，精煉過的 Scrum 套路定石，方可為我們所用，方可從容應付更多樣化的現實限制，避免受迫性或非受迫性失誤。

從運動看教練的本質

今年淡出跑趴社群活動，更能陪伴小孩。

享親子之樂之餘，陪小孩走一遭，自己也會持續變強。

圍棋如此，桌球亦然。如今，很能體會《棋靈王》佐為的心境：

佐為：「變強的人，是我。」

出自《棋靈王》

這半年，涉獵許多桌球領域的教學資源，乃至更一般性的運動教練心法 ³，居然體會出一些運動之外的共通道理。

譬如說，《心志教練》反對浮誇取向，堅持貫徹簡單的根基：

簡單並不代表容易，而且通常越簡單越能達到目標。

很不幸地，目前許多狂人都在傳遞無意義的資訊，更糟的是，都用漂亮的糖衣來包裹。千萬不要成為這些騙子眼中的肥羊呀。

《心志教練》

譬如說，我很欣賞的馬凱旋教練，極強調基本功。他主張不要太早追逐炫目的花招，反而應該進行帶有要求的基本練習——枯燥，卻是後發先至。像以下幾段教學影片，不時可看到他苦口婆心，甚至帶點嚴厲的斥責：

其中，〈正手击球总是找不到点，应该怎么办？〉這段教學影片太精彩了，充滿一堆智慧語錄。不管你懂不懂桌球，請跟著我從 4:36 開始聽訓吧！

5:30 / 自個兒練⋯⋯我教六歲的孩子，三分鐘就會。
6:13 / 為什麼要看著球引拍呢？從一般角度上說，咱們一般的球，沒有來不及的，只有你錯誤的動作結構，你才來不及。
6:46 / 從開始的慢速開始，你得把那個節奏找著。你慢的球都沒節奏，你怎麼打呀？
7:37 / 不是說這有什麼複雜，是你的方法不對。成年人打球有個最大的問題：急性子嘛，第三分鐘會打了吧，第四分鐘就想發力。
8:07 / 我不是說讓大家伙兒跟著我們業餘體育學校六歲孩子一樣那麼練，但是你們要明白他們為什麼要那麼練。儘管孩子還小，但是它包含著最樸實的道理：①動作要穩定，②節奏要穩，③必須有回合。你沒回合，那動作的穩定性從哪兒來呢？ […] 那一定是從定點來的，一定是從單一速度來的，肯定是這樣。所以說，成年人學打球，你們別圖快。
9:32 / 會打球的人，好看，動作協調，觀念是什麼呢？①放鬆，②動作成比例。
10:26 / 你記著：兵乓球，好的技術，一定是簡單的。好動作是舒服的。

這些桌球訓練語錄，像極了技術領域的 kata 與 dojo，觸及許多 coaching 本質，甚至在運動、技術以外的領域也可見到。

原理，原則，果然具有跨領域的共通性。令人聯想劉大任在《強悍而美麗》如此形容山普拉斯 (Pete Sampras)：

看山普拉斯打球，你似乎可以看到這麼一種信息：在這個世界上，你就愛一種東西，你就在你愛的這個東西裡把自己練到完美，練到無懈可擊。

你因此尋得滿足，此外的一切其實無足輕重。就這樣，你變得堅強，足以抵抗不時傾巢而來的寂寞；你變得勇敢，你學會拒絕周遭的喧嘩與熱鬧；你學會簡單而嚴肅，你形成一種風格，唯你獨有。

是的，簡單而嚴肅。訓練的本質，教練的本質，就是如此。

我似乎也該回到自己的原點，當年那個啟迪我步上征途的原點。

出自《琴之森》

亂曰


不沾水的理智線
　　空想多想。
　泅水吧，撲通
求生意志領你向何方
憑誰問

　　認知邊界不斷衝撞
　　我舞影凌亂
　獨酌，敬
這一年
像極了愛情

2021 許願

2021 年，希望自己能做到：

繼續在信仰裡聆聽與順服。
繼續更深度的本質修練。
繼續增進商務英語聽說能力。
開放冒險選項。

就醬。

彼得・杜拉克 The Practice of Management 這本經典著作，2020 年有新的繁體中譯本：《彼得‧杜拉克的管理聖經》。 ↩︎
我在〈2019 個人回顧〉曾大力推薦裘凱宇老師【過好人生學】這門線上課程。 ↩︎
這半年來在桌球方面的探索，詳見〈直拍橫打兩個月心得小記〉及〈教練與選手之間〉兩篇文章。 ↩︎

教練與選手之間

Tue, 03 Nov 2020 22:30:00 +0800

近來敏捷同溫層流行學習「教練」技能。

至於我，由於這兩個月以來開始自學桌球的「直拍橫打」技術，關注的重點，自然是「教練」觀念的源頭——運動領域了。

在尋找相關資訊的過程中，王楠、張怡寧、劉國梁、馬琳⋯⋯當年耳熟能詳的名字不時出現在電腦螢幕前。如今，拜網路之賜，我們有機會從相關訪談中，一窺這些名將當年在役時期，與教練之間、與隊友之間的心路歷程。

王楠

王楠職業生涯共獲得 24 個世界冠軍。在這段專訪中，談到她與曾傳強教練的師徒情誼，尤其是曾教練幾番語重心長的「汗水跟淚水的一段歷史」評語：

另一段專訪，則道盡運動員異於常人的心理掙扎：

張怡寧

外號「大魔王」的張怡寧，職業生涯共獲得 19 個世界冠軍。她在專訪中多次提到李隼教練對她的影響：

劉國梁

劉國梁，是第一個成功以直拍橫打技術在世界舞台取得佳績的桌球選手，職業生涯共獲得 11 個世界冠軍。他在專訪中提到自己從頂尖運動員轉換成教練身份時，成功與失敗的內心轉折：

有這些經歷，才成就了日後強大的總教練「劉胖」：

馬琳

終於輪到我的私淑對象馬琳了。在這段專訪中，馬琳與吳敬平教練之間的信任關係，令人動容：

於是，我們才有機會一再看到神乎其技的馬琳：

福原愛

福原愛，從三歲九個月起，在媽媽兼教練的帶領下，開始了又哭又笑的桌球旅程：

在這段專訪中，也特別提起與湯媛媛教練亦師亦友的關係，以及與偶像王楠搭檔雙打的點滴：

心志教練

隨著這些桌球選手的專訪，回味許多精彩賽事，更對於源自運動領域的「教練」一詞，有更嚴肅的體會。

心理素質的洞察與操練，是頂尖教練最突出的能力。

心志教練，最重要的就是被信任。

—— Brett Bartholomew《心志教練》

我們人生中，有多少機會能遇到如此這般的「教練」？

直拍橫打兩個月心得小記

Sun, 25 Oct 2020 10:00:00 +0800

緣起

哥哥正式學桌球一年半載了，妹妹暑假時也開始正式上課。身為爸爸，為了避免太早被孩子們追上，除了找空檔與這群有上課的對打，也偷偷思索進步之道。

有一次，忘了帶自己的日直球拍去，又遇到有人邀約對打，便借教練的橫拍一用。突然發現，儘管我是直拍握法，但這橫拍打起來卻十分順手。

這擊球感實在難以忘懷。思之數日，突發奇想：既然想換球拍，索性嘗試看看中直、直拍橫打？

於是，中年，改變一下揮拍習慣。從日直換成⋯⋯

用了三十多年的日直，現在才發現，更適合自己的，居然是圓拍短柄的中直。

從日直換成中直

如切如磋，如琢如磨

直拍，比橫拍難。

握法難，就連球拍也難養。

玩直拍，總讓人想到《小王子》這段經典對話：

小王子說：「什麼叫『馴養』？」

「這是件被遺忘的事。」狐狸說：「馴養就是『建立關係⋯⋯』」

「建立關係？」

狐狸說：「不錯。對我來說，你只不過是個小孩，跟其他成千成萬的小孩沒有分別，我不需要你，你也一樣不需要我。我對於你也只不過是一隻狐狸，跟成千成萬其他的狐狸一模一樣。但是，假如你馴養我，我們就彼此互相需要。你對於我將是世界上唯一的，我對於你也將是世界上唯一的⋯⋯」

「一個人只要認識他馴養的東西就好。」狐狸說：「很多人不再有時間去認識東西。但是因為商人並不賣朋友，所以很多人沒有朋友。假如你想得到一位朋友，那麼就馴養我吧！」

「我該怎麼做？」小王子問。

狐狸回答說：「你該很有耐心。你先坐得離我遠一點，像這樣，坐在草地上。我就拿眼角看你，你不要說話。語言是誤會的泉源。但是，每天你可以坐近我一點⋯⋯」

直拍，像極了這種「馴養」關係。得很有耐心，每次打完後，用砂紙小磨一點點⋯⋯漸漸地，馴養，合手。

為了反手位的豎拍角度，拍柄反面也得額外處理：

照著幾則 YouTube 教學調整拍柄，總算可以稍微在實戰中順手使出幾次有效的直拍橫打。

回不去了

桌球真的是對於手感極度敏感的運動。才短短兩個月，已經不太適應以前的日直手感了。

用了三十多年的日直，現在才發現，更適合自己的，居然是圓拍短柄的中直。

有所變，有所不變。

不變的是，依然鍾愛大芯軟彈的手感。

直拍橫打入門教學影片

在台灣，直拍橫打的教練不常見。

所幸有 YouTube。

基本概念

反手位的處理，是直拍橫打與傳統日直的主要不同：

戰術觀念也要跟著改變：

唐瑤說明直拍橫打技術的發展現況：

握拍法

直拍是很個人化的。因此，直拍橫打的握拍法，也和傳統直拍一樣，存在不同的說法。

我不是專業人士，只能博採眾議，多方嘗試，再逐漸調整出適合自己的方式。

以下就列出幾個我參考過的。

首先，談到直拍橫打，自然不能略過這項技術霸主——王皓的現身說法：

乒乓网的《全民学乒乓直拍篇》，算是我看到最細膩的握拍解說。其中，第 1.1 集說明直拍打磨的重點：

第 1.3 集解說「正手利」與「反手利」握拍方式的利弊：

乒乓网「濕父」郭云鹏的這兩段影片解說也很細膩。第一段：

第二段，解說最基本的拍型控制：

唐瑤的這兩段解說也很仔細。第一段：

第二段：

可再參考看看吴迪的解說：

也可參考鄒陽的解說：

基礎功夫，先練推擋撞擊

可先看唐瑤的解說：

郭焱有一系列很棒的教學影片，值得仔細觀摩。第一段影片，主張「先練擊打，再練摩擦」的順序：

第二段，提醒直拍橫打初學者，要先學會穩定控制手指及手腕：

可再參考看看吴迪的解說：

也可參考廖教練的解說：

也可參考鄒陽的解說：

最後，看看馬凱旋兩段糾正問題的影片。第一段：

第二段：

進階功夫，加強力量與摩擦

郭焱解說加強摩擦的方式與判斷擊球點：

馮元瀚解釋銜接動作的姿勢與重心要點：

「濕父」解說調節拍面與距離，以加強力量的技術：

「濕父」糾正引拍與發力的問題：

馬凱旋糾正出檯球的引拍與發力問題：

光是這些影片，就足以讓初學者認真揣摩好一陣子。

桌球反彈板

沒有教練指導，又沒有對練者，光看影片，學得了直拍橫打嗎？

此時，不妨善用「濕父」代言的反彈板。

在辦公室裡放一塊反彈板，有事沒事就練上幾分鐘，當作公餘的伸展放鬆。對這反彈板，得有主動發力的意識，才能夠來來回回好幾趟。如此發力，約十分鐘，就開始出汗了。

對我來說，正手位不難，當作暖身。暖身後，就開始磨練直拍橫打的反手位。每次不求多，但求不間斷。一兩個禮拜下來，漸漸掌握到拍面調節與擊球力道，也漸漸能夠簡單地一來一回好幾趟，頗有成就感。

桌球反彈板

以上就是這兩個月以來自練直拍橫打的心得。

桌球是少數幾個對場地要求不高，從四歲到九十歲都可以樂在其中的運動。從細膩到粗獷的多變風格，更是迷人。時值中年，還有機會能夠重拾學齡期練球的樂趣，也算難得。僅以此文做個小紀錄。

值得你看門道的好書——《獨角獸專案》推薦序

Sat, 03 Oct 2020 10:00:00 +0800

2011 年 8 月，瀏覽器之父 Marc Andreessen 曾在華爾街日報評論道：「軟體正在蠶食整個世界」(software is eating the world)。

接下來這十年，果然如他所預言，世界徹底被軟體顛覆。各行業，如果不對軟體研發的重要思潮保持關注，就無法善用科技力量站在競爭力的最前線。

這些思潮，不只是純軟體界在乎，就連《獨角獸專案》這本小說的場景設定：汽車零件製造商暨零售商，影響一樣深遠。畢竟「軟體正在蠶食整個世界」。

某方面來說，《獨角獸專案》這本書，可謂 2010～2020 這個波瀾壯闊時代軟體研發界的具體縮影。

獨角獸專案 (The Unicorn Project)

如果你是愛看熱鬧的小說族，你會喜歡它的。

如果你是非技術人，「軟體正在蠶食整個世界」，於公於私，免不了必須與組織內外的技術人打交道。因此，這本書請不要走馬看花。請設身處地多讀幾次，增長同理心，瞭解這群愛說外星語的「外星人」的日常，有助於你和諧推動工作任務。尤其是新產品上線前的兵荒馬亂局面，請不吝對這群外星人多給些關愛的行動。

如果你是第一線的軟體研發者，這本寫實刻劃日常甘苦的書，能點燃或重燃你的熱情，像故事主角梅克辛及反抗軍一樣，用技術改變世界，至少改變公司。

當然啦，內行看門道。這本奇書，並不止於小說，而是真正可以照表操課的。

如果你是技術經理人，在對劇情發展擊節讚歎之餘，不妨換位思考：換作是我，會如何決定優先順序？會如何設定領先指標？會如何協調目標衝突的相關部門？會如何兼顧近憂與遠慮？如何形塑適合 IT 滋長的企業文化？如何處理外部利害關係人的財務表現壓力？

在前一部姊妹作《鳳凰專案》中，神祕人物埃瑞克教導了三步工作法、四大類工作，引導無極限零件公司的維運團隊走出裁撤危機，成為 IT 敏捷力的堅強後盾。如今，在這本《獨角獸專案》裡，埃瑞克以另一個神祕的碼頭酒吧酒保身分亮相，教導了企業經營的三層面、四大區域顧客群、系統與組織的五大理念，引導無極限零件公司的研發團隊站在企業視角，以敏捷的 IT 能力驅動並翻轉整間公司的競爭力。

一言以蔽之，本書鎖定在敏捷性，尤其是企業敏捷性。

這麼精彩的書，只讀一遍是不夠的。

我鼓勵讀者們，第一遍看熱鬧，第二遍看門道。第一遍速讀，先享受高潮起伏的劇情，並熟悉人物與關係。第二遍重讀時，請以「核心業務與脈絡業務」及「系統與組織的五大理念」兩種觀點細讀，從頭分析故事的人事時地物及因果關係。經此一番系統思考，比起許多愛談高大上理念的敏捷、DevOps、數位轉型書籍，你將會有更深刻具體的領悟。

橫看成嶺側成峰，願你能從中獲益。

　　　　　　—— 敏捷魔藥師　葉秉哲 (William Yeh)　2020-10-03

《獨角獸專案》系列文章

❶ 值得你看門道的好書——《獨角獸專案》推薦序

❷ 從系統思考角度讀《獨角獸專案》

推薦序：讓 GitLab 成為數位轉型的重要推手

Mon, 28 Sep 2020 14:00:00 +0800

「如今的 GitLab 已經不是單純的 Git service，而是具備完整 workflow 的 DevOps platform。」

2019 年，我因爲工作需要，得開始研究 GitLab 某些功能。巧合的是，當時我也正擔任「第 11 屆 iT 邦幫忙鐵人賽」評審，就在陳正瑋【和艦長一起 30 天玩轉 GitLab】參賽文章中，學到我所需要知道的一切。

後來，陳正瑋的這系列文章不負眾望，榮獲 DevOps 組冠軍。

頒獎典禮上，我鼓勵陳正瑋將這系列文章整理修潤，成為華文世界第一本 GitLab 專書。畢竟，我實在想不到有誰能夠比鐵人賽冠軍、GitLab 官方認證的 “GitLab Hero” 更適合做這件事的人。

和艦長一起 30 天玩轉 GitLab

陳正瑋，在業界暱稱為「艦長」。早在 2015 年，那個台灣對於 DevOps 還懞懞懂懂的年代，正瑋與一群熱血份子就率先成立 DevOps Taiwan 社群，舉辦 Meetup 及數屆 DevOpsDays Taipei 大會，對於推廣 DevOps 觀念及技術，有難以磨滅的貢獻。因此，他也一直被起鬨「支持正瑋無限期連任 DevOps Taiwan 社群組織者」。

有技術，有熱情，由他來詮釋 DevOps，我們是充滿信心的。

在這本《和艦長一起 30 天玩轉 GitLab》書中，你並不會看到他一股腦推銷 GitLab 功能，而是不斷為文提醒讀者反思：

我們真的需要這功能嗎？
我們真的準備好要進入這麼一個深不見底、看不到盡頭的技術坑嗎？
天有不測風雲，萬一 CI/CD 自動化系統出了問題，我們真的有手動處理的備案嗎？
我們真的有在做「持續整合」嗎？還是只是部分的「工作自動化」？

畢竟，如同正瑋一再提醒的：「DevOps 涉及文化、實踐方法及工具，企業組織必須從這三個層面多管齊下，才有機會成功實踐 DevOps。」這本書是起點，不是終點，希望大家除了學會 GitLab 這麼優異的 DevOps platform 之外，更能深刻探討 DevOps 背後的文化及實踐方法，讓 GitLab 成為數位轉型的重要推手。

　 —— 敏捷魔藥師　葉秉哲 (William Yeh)

從系統思考角度讀《目標》：第一～三章

Sun, 13 Sep 2020 22:00:00 +0800

緣起

高德拉特系列著作是我的管理啟蒙書，《目標》更是每隔一陣子就會重讀的經典。

這次，我打算以系統思考 (systems thinking) 角度重讀。尤其是以我在【系統思考的四堂課】提出的「SLR·CPI 法」來逐步分析。

土井英司在《一流的人讀書，都在哪裡畫線？》點出箇中訣竅：

世上的一切都有「原因」與「結果」，線要畫在原因上，而非結果上。只要掌握這個基礎，就能在書中畫出很好的線。

用土井英司這種方法重啃經典，燒腦，進度慢，但在腦中結晶的速度卻快多了。

我也發現，小說體裁絲毫不減《目標》這本書值得劃線的區域，反而能提供更多脈絡。

就先從第一～三章開始吧。

Current Reality Tree (CRT)

《目標》第一～三章主要在描述故事主角羅哥 (Alex Rogo) 所負責的工廠、以及所隸屬的事業部，目前正遭遇的困境。

根據敘事及對話，再略加推演，可繪出初步的 CRT。為了方便查考，括號中列出對應的《目標》中譯本頁碼。

《目標》§1--§3 Current Reality Tree

Causal Loop Diagram (CLD)

進一步萃取本質，可發現，此處至少出現了兩個系統基模。

第一個是「飲鴆止渴」(fixes that fail)，症狀解反而會回頭加劇問題：

《目標》§1--§3 Causal Loop Diagram (Part 1)

第二個是「捨本逐末」(shifting the burden)，症狀解反而會侵蝕實施根本解的能力：

《目標》§1--§3 Causal Loop Diagram (Part 2)

合併起來，這就是《目標》第一～三章所述困境的本質：

《目標》§1--§3 Causal Loop Diagram (All)

POOGI 聚焦五步驟

故事中羅哥的上司：事業部副總裁皮區 (Bill Peach)，雖然一出場就幫了個倒忙，但不以人廢言，有段教訓羅哥的話值得深思：「你已經有足夠的人手了！看在老天的分上，看看你們的效率！你還有很多改進的空間。先證明給我看你可以有效運用現有人力，否則就別哭訴人手不夠！」

這還滿符合 POOGI 的起手式：

Identify 確認瓶頸／限制／制約因素：「有效運用現有人力」的能力。
Exploit 決定如何充分運用瓶頸／限制／制約因素：「先證明給我看你可以有效運用現有人力」。

其實，在第二章的喃喃自語中，主角羅哥已經開始隱隱觸及本質議題了，只是還沒站在適當的視角。所幸，神秘人物鐘納 (Jonah) 即將在《目標》第四章登場，藉由不斷質疑最根本的商業思維，引導羅哥去大膽質疑系統思考點出的本質議題。

從系統思考角度讀《目標》 - 系列

REFERENCES

　🅐 Current reality tree (CRT) and POOGI are from the field of TOC’s thinking processes

　🅑 Causal loop diagram (CLD) is from the field of system dynamics

ARTICLES

　❶ 第一～三章

　❷ 第四章 (TODO)

　❸ TODO

Essence of Scrum

Thu, 20 Aug 2020 00:00:00 +0000

Essence of Scrum: Daily Scrum

Essence of Scrum: Sprint Planning

Essence of Scrum: Sprint Review

Agile Success Recipes: Example Agendas for Efficient Scrum Ceremonies

Essence of Scrum: Sprint Review

Thu, 20 Aug 2020 08:00:00 +0800

This article discusses the essence of Sprint Review .

In a nutshell

Sprint Review is a time-boxed¹ event in which the Scrum Team and invited stakeholders inspect what has been Done with respect to the Sprint Goal , gain insight into values, and adapt business strategy if necessary.

Output

Essential:

An adapted Product Backlog
An adapted business strategy and roadmap²

Better:

Celebration³

Input

Essential:

Sprint Goal
Increment ⁴
Sprint Backlog

Better:

Feedback from real-world customers and markets⁵

Tools and Techniques

Essential:

Self-managing instead of being conducted solely by Scrum Master , Product Owner , or dedicated persons⁶
Encouraging a focus on the Sprint Goal rather than individual Sprint Backlog Items .
Encouraging a focus on the learning rather than just checking off Sprint Backlog Items .⁷

Better:

Diverge-converge meeting pattern⁸

'Essence of Scrum' Series

❺ Agile Success Recipes: Example Agendas for Efficient Scrum Ceremonies

❹ Sprint Review

2020-11-24 Memo

The series of articles have been updated according to the 2020 revision of The Scrum Guide (published on Nov 2020).

The Sprint Review is intended to be an opportunity for learning, not a formal product launch presentation. The Scrum Guide 2017 says that “This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration. […] The Scrum Master teaches everyone involved to keep it within the time-box.” A Scrum Book even emphasizes that ‘The event should be time-boxed to a maximum of three hours. The focus is on assessing the product. The Development Team should not spend more than about 30 minutes specifically preparing for this event. Too often a team will prop up the product with temporary supporting structures to make it work well for the Sprint Review, or will spend time trying to “impress” the stakeholders with a sophisticated presentation. There is very little opportunity to be convincing here: the product stands on its own. The team demonstrates the product in an environment approximating that of an end user, without any special “demo support,” and without any props that could make the product appear better than it is. A good rule of thumb is: No PowerPoint® (unless your product is PowerPoint).’ ↩︎
The Scrum Guide 2020 says that in the Sprint Review , “During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. […] The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.” A Scrum Book says that “It is good for the Product Owner to adopt a vulnerable posture and to hear whether the team endorses and trusts the decisions and directions by which he or she is directing the team, particularly with respect to the product direction and dealing with technical debt and product quality. This helps reinforce the Community of Trust.” ↩︎
A Scrum Book suggests that “A Sprint Review is an opportunity for the team to reflect on their accomplishments during the past Sprint, which contributes to growth in Product Pride. A Sprint Review can be a form of celebration if the team reaches a particularly noteworthy goal, or just for the sake of celebrating now and then. A company in Finland would occasionally have a Sprint Review in a sauna, with good food and drink, going late into the evening. The event covered the perfunctory agenda items but the real focus was for the team to celebrate its work together. (Thanks to Jukka Järvelä for this story!).” ↩︎
The Scrum Guide uses the term “Increment ” to refer to “the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.” To be more precise, A Scrum Book uses the term “Regular Product Increment ”, and LeSS uses the term “Potentially Shippable Product Increment ” (often abbreviated as “PSPI”). ↩︎
Agile for Everybody says that ‘One of the many ways that organizational leaders often accidentally undermine Agile principles is to continue asking only company-centric questions, such as “Are we on time and on budget?” and “Has your manager approved this?” as opposed to customer-centric questions, such as “How do our customers feel about this change to the product?” One immediate and powerful sign that you’re on the right track is that leaders are asking customer-centric questions or, even better, referring directly to customer quotes and insights.’ ↩︎
The Scrum Guide 2020 says that “The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.” ↩︎
LeSS advocates the “Inspect-Adapt and not Inspect-Accept” concept: “The most common mistake in a Sprint Review is to focus on the Product Owner accepting items from the teams. This is a misunderstanding of the purpose of the Sprint Review and moves it away from empirical process control towards finding blame. The Sprint Review is an opportunity for everyone to collaborate about the product.” ↩︎
LeSS advocates a bazaar-style Sprint Review: “The Sprint Review is best conducted using a diverge-converge meeting pattern. During the diverge periods, use a bazaar. This is analogous to a science fair: A large room has multiple areas, each staffed by team representatives, where the items developed by a team are shown and discussed. Stakeholders visit areas of interest. During the converge periods, stakeholders summarize their opinions from the bazaar. A subset of items may be inspected on a common computer projector during this time, also.” ↩︎

Essence of Scrum: Sprint Planning

Sun, 09 Aug 2020 13:00:00 +0800

This article discusses the essence of Sprint Planning .

In a nutshell

Sprint Planning is a time-boxed¹ event in which the Scrum Team defines the Sprint Goal and makes a feasible plan for the goal, to the best knowledge, information and belief of the team.

Output

Essential:

Sprint Goal
A feasible plan for achieving the Sprint Goal
Sprint Backlog Items with the property of INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable)²

Better:

A coherent Sprint Goal ³ and expectation for the outcome to be seen at Sprint Review

Input

Essential:

Strategy breakdown (e.g., product roadmap, OKR, OGSM, impact mapping, user story mapping).
A Product Backlog that has been refined during Product Backlog Refinement and adapted during previous Sprint Review
Action items created during previous Sprint Retrospective ⁴
Influences⁵

Better:

The top Product Backlog Items meet the Definition of Ready criteria⁶ defined and evolved by the Scrum Team .

Tools and Techniques

Essential:

Short-term strategic planning statements in brief
Judgment to balance a variety of needs and goals⁷, especially “whole product focus”⁸ and technical excellence⁹
Logical approach to ordering items
Logical approach to breaking down items
Estimation in proper granularity¹⁰
Encouraging a focus on the team rather than individuals.

Better:

Two parts planning¹¹
SPIDR (Spike, Paths, Interfaces, Data, and Rules)¹² (should be used in Product Backlog Refinement as well)
Techniques for enabling specification¹³ (should be used in Product Backlog Refinement as well)
Visualized information radiators (e.g., Scrum board, Kanban board).
Self-managing instead of being conducted solely by Scrum Master .
Encouraging participative decision-making in proposal and ordering of Sprint Backlog Items

Example

以談判角度看 Sprint Planning (Sprint Planning: A Negotiation Perspective)

'Essence of Scrum' Series

❸ Sprint Planning

❺ Agile Success Recipes: Example Agendas for Efficient Scrum Ceremonies

2020-11-24 Memo

The series of articles have been updated according to the 2020 revision of The Scrum Guide (published on Nov 2020).

The Scrum Guide says that “Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. […] The Scrum Master teaches the Scrum Team to keep it within the time-box.” A Scrum Book suggests that “It is important that Sprint Planning allow time for enough design to create a well-understood Sprint Backlog. But the planning should be time-boxed. A rule of thumb is that the event should take no more than four hours for a two-week Sprint and proportionally less for shorter Sprints. If it takes longer, it takes longer—but seek kaizen opportunities to reduce the amount of time to plan and to correspondingly increase the time spent on building product.” Teddy Chen advocates in his article sticking to the timebox to avoid the “big up-front design” symptom. ↩︎
Agile Alliance says that “The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story.” Read Bob Hartman’s article “New to agile? INVEST in good user stories” for more info. ↩︎
Scrum works better when it is considered an enabling engine toward a coherent goal rather than just a collection of work packages by chance. The Scrum Guide 2020 version says that “the Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.” A Scrum Book says that “The Scrum Team can use the Sprint Goal to frame the selection of PBIs for the Sprint but in some sense the Sprint Goal is more important even than the sum of the individual PBIs.” Roman Pichler says in his article “A Template for formulating great sprint goals” that “your sprint goal should differ from your user stories. The goal explains the why it is a good idea to carry out the sprint an implement the stories. The user stories enable you to reach the goal. It’s a common mistake to confuse the two.” ↩︎
The Scrum Guide 2017 puts more emphasis on the follow-up actions for Sprint Retrospective : “To ensure continuous improvement, it (the Sprint Backlog) includes at least one high priority way in which the team works, identified in the previous Retrospective meeting” (p.16). In 2020 version it is expressed in a more relaxed tone: “The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.” Emerson Mills suggested in his CSM class putting these identified technical improvements into Sprint Planning Part 2 (source: “我在第二次 Certified ScrumMaster 課程學到的事（1）”. ↩︎
The Scrum Guide 2017 says that “Each Sprint may be considered a project with no more than a one-month horizon” (p.9). In this regard, a sprint cannot be immune from influences discussed in the PMBOK Guide, such as enterprise environmental factors and organizational process assets. ↩︎
Definition of Ready ↩︎
Peter Drucker emphasized in his book The Practice of Management (pp. 62-63, 87) that “To manage a business is to balance a variety of needs and goals. This requires judgment. The search for the one objective is essentially a search for a magic formula that will make judgment unnecessary. But the attempt to replace judgment by formula is always irrational; all that can be done is to make judgment possible by narrowing its range and the available alternatives, giving it clear focus, a sound foundation in facts and reliable measurements of the effects and validity of actions and decisions. And this, by the very nature of business enterprise, requires multiple objectives. […] Yet, there is no formula for doing the job. Each business requires its own balance—and it may require a different balance at different times.” ↩︎
The definition of “product” by the Scrum Team has also defined what is in scope and what is by default out of scope for the team. For example, what parts of Ops should be handled by the Scrum Team ? LeSS advocates a broader product definition and a “whole product focus” point of view: “Whenever there is a choice to optimize a team output or the whole product, we always chose the whole product. […] In many large product development groups, getting everyone to focus on the whole product instead of their individual parts/tasks/specialization is one of the hardest parts of scaling Scrum. Always keep a whole product focus, keep reminding everyone there is no value in separate parts or half-working parts.” ↩︎
“Principles behind the Agile Manifesto” emphasizes that “Continuous attention to technical excellence and good design enhances agility.” LeSS identifies several areas of technical excellence. ↩︎
Mike Cohn discusses different levels of estimation activities in his article “Why Agile Teams Should Estimate at Two Different Levels.” ↩︎
It is common to divide the Sprint Planning into 2 parts. Here is a good quote from LeSS: "Sprint Planning One focuses on selection of ready items from those offered by the Product Owner, wrapping up lingering questions, and definition of the Sprint Goal. Sprint Planning Two focuses on creating a plan of work to get to ‘done’ for each item. The items and plan of action or tasks comprise the Sprint Backlog." ↩︎
Mike Cohn proposed the SPIDR approach (spike, paths, interfaces, data, and rules) for breaking down user stories. Watch the “Stop Wasting Time Splitting Stories” video for more details. ↩︎
Enabling specification ↩︎

Blackbox Exporter 小記

Fri, 07 Aug 2020 08:00:00 +0800

在用 Prometheus + Grafana 監控自家服務的同時，我們也會想用同一套系統去監控第三方服務。

本文介紹一個好用的 Prometheus 官方工具：Blackbox exporter，可以省下手刻 curl 腳本的工夫。我也順便介紹一些踩過的雷。

健康狀況的揭露方式

第三方服務的健康狀況，有不同的自我揭露方式：

API：像 Google Cloud 有提供 json endpoint。
Feed：像 AWS 有提供 RSS feed，Google Cloud 有 RSS feed，Stripe 有 Twitter @stripestatus 及 RSS feed。
網頁：像 AWS 有提供 Service Health Dashboard 網頁，Google Cloud 有 Status Dashboard 網頁，Stripe 有 System Status 網頁。
統包服務：像 Pingdom、Downdetector 可以一站通吃想監控的第三方服務群。
不完全揭露。

針對這些林林總總的揭露方式，Blackbox exporter 提供幾種 prober：http_probe、 tcp_probe、dns_probe、icmp_probe，即使面對「不完全揭露」自身健康狀況的第三方服務，還是可以在某些程度上間接採集他們的健康狀況，只要你留意這個「採集」的舉動沒有副作用。

Blackbox exporter 分工架構

在 Prometheus 微服務架構中，是讓各種 exporter 先去 probe 各自責任區內的 metrics，再讓 Prometheus 透過 HTTP 去 scrape 這些 exporter 採集到的 metrics。

基於這個分工體系，Blackbox exporter 負責去 probe 第三方服務的健康狀況，再提供一個 /probe 介面讓 Prometheus 去蒐集匯總 metrics。

Blackbox exporter 分工架構

所以，一開始，我們會先試著寫好 blackbox.yml 設定檔，先測試 Blackbox exporter 能正常運作，之後才去串接 Prometheus。

Blackbox exporter 初體驗

官方提供的陽春版 blackbox.yml 設定檔展示了一些常見的 blackbox exporter 模組 (module)，很適合初次上手之用：

# https://github.com/prometheus/blackbox_exporter/blob/master/blackbox.yml
modules:
  http_2xx:
    prober: http
  http_post_2xx:
    prober: http
    http:
      method: POST
  #...

其中，最常用的應該是 http_2xx 模組了。如果你只需要用到這模組，可以不必準備 blackbox.yml 設定檔。

我們可以先下載並啟動 Blackbox exporter:

$ ./blackbox_exporter

預設情況下，Blackbox exporter 會透過 port 9115 提供探測服務。

現在，讓我們透過 Blackbox exporter 內建的 http_2xx 模組，探測 github.com 的健康狀況：

$ curl 'localhost:9115/probe?target=github.com&module=http_2xx'

或是乾脆省略掉預設的 http_2xx 模組名稱：

$ curl 'localhost:9115/probe?target=github.com'

透過 Blackbox exporter 探測 github.com 的輸出結果

# HELP probe_dns_lookup_time_seconds Returns the time taken for probe dns lookup in seconds
# TYPE probe_dns_lookup_time_seconds gauge
probe_dns_lookup_time_seconds 0.057117535
# HELP probe_duration_seconds Returns how long the probe took to complete in seconds
# TYPE probe_duration_seconds gauge
probe_duration_seconds 1.833592006
# HELP probe_failed_due_to_regex Indicates if probe failed due to regex
# TYPE probe_failed_due_to_regex gauge
probe_failed_due_to_regex 0
# HELP probe_http_content_length Length of http content response
# TYPE probe_http_content_length gauge
probe_http_content_length -1
# HELP probe_http_duration_seconds Duration of http request by phase, summed over all redirects
# TYPE probe_http_duration_seconds gauge
probe_http_duration_seconds{phase="connect"} 0.425883281
probe_http_duration_seconds{phase="processing"} 0.433015322
probe_http_duration_seconds{phase="resolve"} 0.086735632
probe_http_duration_seconds{phase="tls"} 0.443000784
probe_http_duration_seconds{phase="transfer"} 0.663546262
# HELP probe_http_redirects The number of redirects
# TYPE probe_http_redirects gauge
probe_http_redirects 1
# HELP probe_http_ssl Indicates if SSL was used for the final redirect
# TYPE probe_http_ssl gauge
probe_http_ssl 1
# HELP probe_http_status_code Response HTTP status code
# TYPE probe_http_status_code gauge
probe_http_status_code 200
# HELP probe_http_uncompressed_body_length Length of uncompressed response body
# TYPE probe_http_uncompressed_body_length gauge
probe_http_uncompressed_body_length 137503
# HELP probe_http_version Returns the version of HTTP of the probe response
# TYPE probe_http_version gauge
probe_http_version 1.1
# HELP probe_ip_addr_hash Specifies the hash of IP address. It's useful to detect if the IP address changes.
# TYPE probe_ip_addr_hash gauge
probe_ip_addr_hash 2.436894991e+09
# HELP probe_ip_protocol Specifies whether probe ip protocol is IP4 or IP6
# TYPE probe_ip_protocol gauge
probe_ip_protocol 4
# HELP probe_ssl_earliest_cert_expiry Returns earliest SSL cert expiry in unixtime
# TYPE probe_ssl_earliest_cert_expiry gauge
probe_ssl_earliest_cert_expiry 1.652184e+09
# HELP probe_ssl_last_chain_expiry_timestamp_seconds Returns last SSL chain expiry in timestamp seconds
# TYPE probe_ssl_last_chain_expiry_timestamp_seconds gauge
probe_ssl_last_chain_expiry_timestamp_seconds 1.652184e+09
# HELP probe_success Displays whether or not the probe was a success
# TYPE probe_success gauge
probe_success 1
# HELP probe_tls_version_info Contains the TLS version used
# TYPE probe_tls_version_info gauge
probe_tls_version_info{version="TLS 1.3"} 1
~ % curl 'localhost:9115/probe?target=github.com&module=http_2xx'
# HELP probe_dns_lookup_time_seconds Returns the time taken for probe dns lookup in seconds
# TYPE probe_dns_lookup_time_seconds gauge
probe_dns_lookup_time_seconds 0.025288617
# HELP probe_duration_seconds Returns how long the probe took to complete in seconds
# TYPE probe_duration_seconds gauge
probe_duration_seconds 1.776282033
# HELP probe_failed_due_to_regex Indicates if probe failed due to regex
# TYPE probe_failed_due_to_regex gauge
probe_failed_due_to_regex 0
# HELP probe_http_content_length Length of http content response
# TYPE probe_http_content_length gauge
probe_http_content_length -1
# HELP probe_http_duration_seconds Duration of http request by phase, summed over all redirects
# TYPE probe_http_duration_seconds gauge
probe_http_duration_seconds{phase="connect"} 0.414948208
probe_http_duration_seconds{phase="processing"} 0.42066351300000004
probe_http_duration_seconds{phase="resolve"} 0.038381098
probe_http_duration_seconds{phase="tls"} 0.465243547
probe_http_duration_seconds{phase="transfer"} 0.65392713
# HELP probe_http_redirects The number of redirects
# TYPE probe_http_redirects gauge
probe_http_redirects 1
# HELP probe_http_ssl Indicates if SSL was used for the final redirect
# TYPE probe_http_ssl gauge
probe_http_ssl 1
# HELP probe_http_status_code Response HTTP status code
# TYPE probe_http_status_code gauge
probe_http_status_code 200
# HELP probe_http_uncompressed_body_length Length of uncompressed response body
# TYPE probe_http_uncompressed_body_length gauge
probe_http_uncompressed_body_length 137509
# HELP probe_http_version Returns the version of HTTP of the probe response
# TYPE probe_http_version gauge
probe_http_version 1.1
# HELP probe_ip_addr_hash Specifies the hash of IP address. It's useful to detect if the IP address changes.
# TYPE probe_ip_addr_hash gauge
probe_ip_addr_hash 1.664977422e+09
# HELP probe_ip_protocol Specifies whether probe ip protocol is IP4 or IP6
# TYPE probe_ip_protocol gauge
probe_ip_protocol 4
# HELP probe_ssl_earliest_cert_expiry Returns earliest SSL cert expiry in unixtime
# TYPE probe_ssl_earliest_cert_expiry gauge
probe_ssl_earliest_cert_expiry 1.652184e+09
# HELP probe_ssl_last_chain_expiry_timestamp_seconds Returns last SSL chain expiry in timestamp seconds
# TYPE probe_ssl_last_chain_expiry_timestamp_seconds gauge
probe_ssl_last_chain_expiry_timestamp_seconds 1.652184e+09
# HELP probe_success Displays whether or not the probe was a success
# TYPE probe_success gauge
probe_success 1
# HELP probe_tls_version_info Contains the TLS version used
# TYPE probe_tls_version_info gauge
probe_tls_version_info{version="TLS 1.3"} 1

大部分情況下，我們只需要看其中的 probe_success 這項 gauge 指標：

# HELP probe_success Displays whether or not the probe was a success
# TYPE probe_success gauge
probe_success 1

請用 Blackbox exporter 去戳戳看其他網站吧。

IPv6/IPv4 問題

如果用 Blackbox exporter 去探測 google.com，會得到很奇怪的結果：

$ curl 'localhost:9115/probe?target=google.com'

[略]
# HELP probe_ip_protocol Specifies whether probe ip protocol is IP4 or IP6
# TYPE probe_ip_protocol gauge
probe_ip_protocol 6
# HELP probe_success Displays whether or not the probe was a success
# TYPE probe_success gauge
probe_success 0

打開 debug 模式查查看：

$ curl 'localhost:9115/probe?target=google.com&debug=true'

Logs for the probe:
ts=2020-08-07T07:42:43.560461Z caller=main.go:304 module=http_2xx target=google.com level=info msg="Beginning probe" probe=http timeout_seconds=119.5
ts=2020-08-07T07:42:43.561257Z caller=http.go:323 module=http_2xx target=google.com level=info msg="Resolving target address" ip_protocol=ip6
ts=2020-08-07T07:42:43.573101Z caller=http.go:323 module=http_2xx target=google.com level=info msg="Resolved target address" ip=2404:6800:4008:801::200e
ts=2020-08-07T07:42:43.57317Z caller=client.go:252 module=http_2xx target=google.com level=info msg="Making HTTP request" url=http://[2404:6800:4008:801::200e] host=google.com
ts=2020-08-07T07:42:43.573276Z caller=main.go:119 module=http_2xx target=google.com level=error msg="Error for HTTP request" err="Get \"http://[2404:6800:4008:801::200e]\": dial tcp [2404:6800:4008:801::200e]:80: connect: no route to host"
[略]

從上面的 log 可看到，Blackbox exporter 試圖透過 IPv6 連線到 google.com，導致錯誤。

Prometheus 核心成員 Brian Brazil 在 “Checking for HTTP 200s with the Blackbox Exporter” 文章說明這問題的原因及解法：

You may see a surprising failure if you don’t have a working IPv6 setup, as the Blackbox exporter will prefer an IPv6 address if one is returned by DNS.

You can adjust this behaviour by adding preferred_ip_protocol: "ip4" to the module’s configuration.

所以，我會在 blackbox.yml 設定檔當中，增加另一個模組，取一個好記的名字：

modules:
  # module: expect http_2xx, with ip4
  http_2xx_with_ip4:
    prober: http
    timeout: 5s
    http:
      preferred_ip_protocol: "ip4"

  #...

然後，重啟 Blackbox exporter，記得要餵給它新的設定檔：

$ ./blackbox_exporter --config.file=./blackbox.yml

這次，讓我們改用新增的模組去探測 google.com：

$ curl 'localhost:9115/probe?target=google.com&module=http_2xx_with_ip4'

這次，總算可以看到正常的 probe_success 了：

# HELP probe_ip_protocol Specifies whether probe ip protocol is IP4 or IP6
# TYPE probe_ip_protocol gauge
probe_ip_protocol 4
# HELP probe_success Displays whether or not the probe was a success
# TYPE probe_success gauge
probe_success 1

Auth

某些第三方服務的 HTTP 端點需要夾帶 auth 相關欄位。

像 Stripe API 文件就說：

Authentication to the API is performed via HTTP Basic Auth. Provide your API key as the basic auth username value. You do not need to provide a password.

If you need to authenticate via bearer auth (e.g., for a cross-origin request), use -H "Authorization: Bearer sk_test_4eC39HqLyjWDarjtT1zdp7dc" instead of -u sk_test_4eC39HqLyjWDarjtT1zdp7dc.

那麼，這段 auth 資訊該放到 prometheus.yml 還是 blackbox.yml 設定檔？畢竟與 basic_auth 相關的設定內容，在 Prometheus 設定文件及 Blackbox exporter 設定文件都出現過。

動手實驗看看吧！

實驗程式放在 https://github.com/William-Yeh/blackbox-exporter-demo

實驗所需環境：

Docker 19.03.12 以上。
Docker Compose 1.26.2 以上。

我設計了兩個 Prometheus job，分別對應到兩種不同的 basic_auth 擺放位置：

Prometheus Job	prometheus.yml	blackbox.yml
stripe-healthcheck		✓ basic_auth
stripe-healthcheck-wrong-config	✓ basic_auth

一切準備就緒，來試試看哪一種寫法才是對的吧。

請用 Docker Compose 執行：

$ docker-compose up

請用瀏覽器打開 http://localhost:9090/ 進入 Prometheus 儀表板：

用 Prometheus 觀看 Blackbox exporter 採集到的內容

事實證明，stripe-healthcheck-wrong-config 這一組的寫法是錯誤的，要學 stripe-healthcheck 這一組將 basic_auth 擺到 blackbox.yml 裡面才對。

這是我踩過的雷。

參考資料

Blackbox exporter 並不難，麻煩的是要找到好範例~~來偷抄~~。

關於 Blackbox exporter 的部份：

設定檔說明：Blackbox exporter configuration
較完整的設定檔範例

關於 Prometheus 的部份：

Understanding and using the multi-target exporter pattern
整體 Configuration 說明

Essence of Scrum: Daily Scrum

Sun, 02 Aug 2020 16:00:00 +0800

This article discusses the essence of Daily Scrum .

In a nutshell

Daily Scrum is a time-boxed daily event in which the Developers gather together to quickly inspect current performance and to identify necessary actions in order to increase the confidence in achieving the Sprint Goal .

Output

Essential:

Updated confidence in the Sprint Goal supported by evidence.
Updated plans, if necessary, for achieving the Sprint Goal .

Input

Essential:

Up-to-date Sprint performance status supported by evidence.

Tools and Techniques

Essential:

Time-box facilitation techniques.¹
Goal-oriented inquiry.² I suggest iterating based on Sprint Backlog Items instead of persons:
1. To brief what the Developers have moved toward the Sprint Goal since the last Daily Scrum .
2. To brief what the Developers plan to do toward the Sprint Goal today.
3. To identify potential risks that affect the ability to achieve the Sprint Goal .
Encouraging a focus on the team rather than individuals.

Better:

Visualized information radiators (e.g., Scrum board, Kanban board).
Self-managing instead of being conducted solely by Scrum Master .

'Essence of Scrum' Series

❷ Daily Scrum

❺ Agile Success Recipes: Example Agendas for Efficient Scrum Ceremonies

2020-11-24 Memo

The series of articles have been updated according to the 2020 revision of The Scrum Guide (published on Nov 2020).

The Daily Scrum is typically time-boxed to avoid diving into implementation details. The Scrum Guide even defines it as “a 15-minute time-boxed event.” A Scrum Book: The Spirit of the Game also suggests that “this meeting is for replanning and decision-making, not for problem-solving. Strictly time-box the meeting to keep focus on the daily plan and to avoid robbing time from development.” ↩︎
Traditionally Daily Scrum is for each person to take turns to speak up the “three questions”. For example, The Scrum Guide 2013 version said that “During the meeting, the Development Team members explain: […]” This may imply micro-management, however. In 2017 version it was rephrased in a less prescriptive style as “Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used: […].” In 2020 version it was even simplified further as “The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.” ↩︎

Essence of Scrum: Product Backlog Refinement

Wed, 29 Jul 2020 22:00:00 +0800

Preface of the series

The series of “Essence of Scrum” articles tries to identify the essence of Scrum elements (e.g., events and artifacts) so that:

the core can be understood without much effort.
the feeling overwhelmed can be reduced.
the gradual adoption is more possible.

My selection and elaboration of “essence” is very subjective. Follow the advice at your own risk.

Main references for the whole series:

The Scrum Guide by Ken Schwaber and Jeff Sutherland
A Scrum Book: The Spirit of the Game by Jeff Sutherland, James O. Coplien, et al.
Manifesto for Agile Software Development and Principles behind the Agile Manifesto
~~A Guide to the Scrum Body of Knowledge (SBOK® Guide)~~
LeSS Framework

The first article discusses the Product Backlog Refinement (PBR).

In a nutshell

Product backlog refinement (PBR) is a Scrum event in which the Scrum Team properly orders and breaks down Product Backlog so that the Developers feel confident enough about the top Product Backlog Items to take them into a Sprint .

Output

Essential:

A Product Backlog that is both ordered¹ and granularity gradient²:
- Is ordered according to product roadmap and expectations of stakeholders.
- Is granularity gradient according to confidence of the Scrum Team .

Better:

A Product Backlog that has the property of ODDE (ordered, dynamic, detailed appropriate, and estimated)³.
The top Product Backlog Items meet the Definition of Ready criteria⁴ defined and evolved by the Scrum Team .

Input

Essential:

Strategy breakdown (e.g., product roadmap, OKR, OGSM, impact mapping, user story mapping).
A Product Backlog that is roughly ordered according to product roadmap and expectations of stakeholders.

Tools and Techniques

Essential:

Short-term strategic planning statements in brief
Logical approach to ordering items
Logical approach to breaking down items
Estimation in proper granularity⁵

Better:

SPIDR (Spike, Paths, Interfaces, Data, and Rules)⁶
Techniques for enabling specification⁷
Encouraging participative decision-making in proposal and ordering of Product Backlog Items

Example

以 impact mapping 進行參與式決策 (Impact Mapping as Participatory Decision Making)

'Essence of Scrum' Series

❶ Product Backlog Refinement

❺ Agile Success Recipes: Example Agendas for Efficient Scrum Ceremonies

2020-11-24 Memo

The series of articles have been updated according to the 2020 revision of The Scrum Guide (published on Nov 2020).

“Priority” is the term used in the Scrum Guide 2010: “Product Backlog is sorted in order of priority” (p.6). But the term was changed to “order” in 2011: “Product Backlog management includes: […] Ordering the items in the Product Backlog to best achieve goals and missions” (p.5). See the article “Ordered Not Prioritized” for more details. ↩︎
The Scrum Guide 2017 says: “Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail” (p.15). See “Granularity Gradient” for more details. ↩︎
Daniel Teng proposed the ODDE properties (ordered, dynamic, detailed appropriate, and estimated) for product backlog. See the article “ODDE 的 Product Backlog” (in Chinese) for more details. ↩︎
Definition of Ready ↩︎
Mike Cohn discusses different levels of estimation activities in his article “Why Agile Teams Should Estimate at Two Different Levels.” ↩︎
Mike Cohn proposed the SPIDR approach (spike, paths, interfaces, data, and rules) for breaking down user stories. Watch the “Stop Wasting Time Splitting Stories” video for more details. ↩︎
Enabling specification ↩︎

Go Best Practices

Fri, 10 Jul 2020 08:00:00 +0800

今年一月，換到一家以 Go 為主力語言的公司。

習慣了 Java 紀律，一碰到 Go 的自由奔放，不禁想尋求一些 best practices 與 patterns。

以前我曾蒐集過一份 Go Best Practices 清單。浸潤 Go 半年後，再回頭看這些內容，當初不甚明瞭之處，竟然也懂了許多。便想重新整理一次，並加上個人的短評。

語言基礎

▷ Effective Go

自從 1991 年 Effective C++ 橫空出世，以後任何書敢冠上 “Effective” 之名，幾乎都是重量級的保證。

“Effective Go” 這份文件，雖然篇幅還沒充實到足以成為一本書，但內容名副其實，原汁原味道出 Go 的核心風格，是非常好的入門補充讀物。

Package 命名與組織

▷ Style guideline for Go packages

這篇短文可以幫助你學會「正統」的 Go package 風格。

中小規模的程式結構

知名輕量級框架 Go kit 作者 Peter Bourgon 分享過許多實務經驗，其中這兩篇文章很值得一讀：

▷ Go best practices, six years in

▷ Go for Industrial Programming

或許是因為我們公司自建的 Go 微服務框架 Orion ¹，骨幹結構非常接近 Go kit，所以我對這兩篇文章非常有感。

專案佈局

其他程式語言的經驗愈多，愈容易把 ~~~不良習慣~~~ 不搭配的習慣帶進 Go 來，尤其是專案佈局風格。

在 Go 裡，通常最簡單的專案佈局方式是：你選用哪一個主框架，就遵照著它建議的佈局。

不過，如果用的是像 Gin 這種超輕量的迷你框架，或者根本沒有套用任何框架，那麼，以下這一篇文章、一份範例，是很好的起點：

▷ Standard Package Layout

▷ Standard Go Project Layout

即使你信仰 DDD (domain driven design) 或 clean architecture 路線，也盡量不要不假思索將其他語言的實踐風格直接照搬過來——你會寫出很醜陋的 Go 程式。

Design Patterns

▷ awesome-patterns

熟悉 design patterns 的人，可從這裡得到用 Go 實作的靈感。

關於 Orion，詳見〈在旋轉拍賣 Carousell 一年看到的後端架構、挑戰與生活〉一文。 ↩︎

Travis CI 虛擬機的地雷

Thu, 09 Jul 2020 23:00:00 +0800

我算是 Travis CI 的老用戶了。

以前 Travis CI 很慢，對 Docker 不友善，又很難 debug，讓我一度將重心轉移到後起之秀 CircleCI。後來 Travis CI 向 CircleCI 看齊，讓我們能夠 ssh 進去虛擬機 debug，兩者的差距已經逐漸縮小。所以，我自己的重要專案，總是盡量同時掛上 Travis CI 及 CircleCI，讓 CI pipeline 的核心在某種程度上也能盡量 reproducible 不被 lock in。

Travis CI 也提供許多常見的程式語言及伺服器軟體，以方便做 CI 測試。我個人的習慣是，盡量不去使用這些功能，而是直接用 Docker 或 Docker Compose 來組裝，以降低對於 Travis CI 的依賴（尤其我還要兼顧 CircleCI）。

不過，如果是與人合作的專案，就得顧及其他人的習慣。我在使用 Travis CI 提供的伺服器軟體 Postgres、Cassandra、RabbitMQ 時，遇到一些雷，特地記錄下來，供有類似困擾的人參考。

虛擬機版本

在 .travis.yml 檔案裡面可以指定 CI 虛擬機的 Ubuntu 版本¹。若不特別指定，以現在（2020 年七月）來說，預設版本會是 Ubuntu 16.04 LTS，代號為 Xenial。

我遇到一些專案，.travis.yml 指定的是代號為 Trusty 的 Ubuntu 14.04 LTS。由於 Trusty 的官方保固期限已於 2019-04 到期²，理論上來說，至少應該要升級到 2021-04 才到期的 Xenial 版，才比較安全。

事情並沒想像中那麼簡單。

我以兩個 repo 來示範：

使用 Trusty 虛擬機的專案：test-travisci-trusty
使用 Xenial 虛擬機的專案：test-travisci-xenial

譬如說，在原本使用 Trusty 的專案中跑得好好的 .travis.yml 檔，如果不假思索直接照搬到使用 Xenial 的專案，一下子就卡住了：

Travis CI Xenial 噴出錯誤

非常詭異。反覆實驗，總算找出需要修改的三個地方。

Postgres

使用 Trusty 虛擬機時，照著 Travis CI 官方指南及問題排除文件，我們可以順利安裝不同版本的 Postgres：

官方指南：Setting up Databases and Services - Using a different PostgreSQL Version
Authentication 問題：Issue #9624

換成 Xenial 虛擬機時，不知為何，Postgres 的 port 居然靜悄悄地換成了 5432，而且沒有文件直接明講。

解決之道很簡單，直接修改相對應的變數：

Postgres 修改之處

你也可以直接點選這裡剪貼相關的設定內容。

Cassandra

使用 Trusty 虛擬機時，照著 Travis CI 官方指南，我們可以順利安裝不同版本的 Cassandra：

官方指南：Setting up Databases and Services - Cassandra

換成 Xenial 虛擬機時，不知為何，Cassandra 不再是 Travis CI 直接提供的資料庫了，而且沒有文件直接明講。

解決之道是自力救濟，自己下載，自己安裝³：

Cassandra 修改之處

你也可以直接點選這裡剪貼相關的設定內容。

RabbitMQ

使用 Trusty 虛擬機時，照著 Travis CI 官方指南及 Stack Overflow 問答庫，我們可以順利安裝 RabbitMQ 以及常用的 rabbitmqadmin 設定工具：

官方指南：Setting up Databases and Services - RabbitMQ
Stack Overflow 問答：Declaring rabbitmq exchanges in travis build setup

換成 Xenial 虛擬機時，這次官方文件總算有特別提醒對應的修改⁴。可惜 Travis CI 只做了一半，忘了啟動常見的 RabbitMQ Management Plugin。

解決之道是自力救濟，自己開啟：

Cassandra 修改之處

你也可以直接點選這裡剪貼相關的設定內容。

結語

代號為 Xenial 的 Ubuntu 16.04，官方保固期將於 2021-04 到期，若升級到代號為 Bionic，官方保固期到 2023-04 的 Ubuntu 18.04，免不了又要經歷一輪類似的修改。

據我目前初步測試，Travis CI 的 Bionic 虛擬機會遇到更多雷（難怪 Travis CI 目前仍然預設為 Xenial）。如果沒有其他考量，我還是強烈建議，直接用 Docker 或 Docker Compose 去設定 CI 所需動用的程式語言及伺服器軟體，以降低對於 Travis CI 的依賴，甚至預留轉換至 CircleCI 或 GitHub Actions 的彈性。

Travis CI 支援許多虛擬機，完整列表請見 “Build Environment Overview” 一文。 ↩︎
在 Ubuntu version history 文件中，詳列了 Ubuntu 各版本代號及官方保固期限。 ↩︎
我參考 aiocassandra 專案的設定，將 Cassandra 安裝在 Travis CI 的 Xenial 虛擬機上：https://github.com/aio-libs/aiocassandra/blob/master/.travis.yml ↩︎
可能也是在官方論壇收到 “RabbitMQ on Xenial” 這則提問，Travis CI 才會把這一段解法放進官方文件吧。 ↩︎

Jira Board Hacks

Sat, 06 Jun 2020 08:00:00 +0800

實體看板

在導入 Scrum 時，我偏好實體看板。

實體看板容易 zoom in/out，利於適時切換俯瞰與細節視角，不需過度的數字管理。

實體看板的空間共時性，容易塑造團隊的一體感。

實體看板彈性大，能以最小成本，讓團隊在敏捷路上不斷嘗試與調整。

實體看板

不過，在重視數字管理的組織，或是有 remote 成員存在的組織，恐怕不得不面對數位化電子看板的存在。輕量級的如 Trello，重量級的如 Jira，不管並存抑或取代，都得學著與之共舞。

說實在的，為了迎合管理視角，電子看板犧牲許多實體敏捷性。萬一真的不能不採用，我們還是得學著發揮它的優點，並設法降低它的負面影響。

以下我會介紹幾個小技巧，讓我過去一個禮拜在透過 Jira 引導 daily stand-up 時，找回部份實體看板的手感。

Jira 的泳道縮放

Daily stand-up 一開始，我習慣先站在更全局的角度鳥瞰：將卡片全都收縮起來，只留下泳道 (swimlane)。畢竟，與 sprint goal 最直接對應的，是 swimlane，而非個別卡片。

我會先用 Jira 熱鍵 z 隱藏側邊欄，用 Jira 熱鍵 - 收縮泳道：

Jira 看板，泳道視角

接下來，再逐一展開個別泳道來進行探討：

Jira 看板，泳道局部展開

Jira 的全局卡片視角

為了迎合管理視角，Jira 的每一張卡片，塞了非常多資訊：

Jira card

這其實並不算是問題——如果單獨只看一張、兩張卡片的話。

聽出我的弦外之音了嗎？

問題在於：若將所有卡片全都陳列在看板上，會發現，卡片佔用的總面積，與實際展現出來有意義的資訊總量，不符合比例原則。

個別卡片已經太佔空間了，更糟糕的是，能夠擺放卡片的看板區域，也被別人偷偷霸佔。

以我的 13.3 英吋螢幕為例。寶貴的螢幕可視區域中，最上面是一堆置頂區域：先是一排選單，再來是好幾排大標題，接下來才輪到一排看板的進度欄。經過這一輪置頂空間爭奪戰，1/5 空間被吃掉了，剩下來的看板空間，能夠在同一頁完整秀出來的卡片，最多只有 12 張；想看更多，只得往下捲動：

手術前的 Jira 看板，空間利用率甚低。

需要一直捲動的看板，如何給人全局觀？

簡言之，Jira 缺少許多軟體常見的 “Zen mode” 或 “Presentation mode”。我希望，當卡片太多時（我知道這是 bad smell 啦⋯⋯），能夠一鍵隱藏不必要的置頂區域，隱藏不必要的卡片欄位，譬如說，只秀出卡片標題。

用暴力猴之類的東西就辦得到。我寫了一隻簡單的 userscript：Atlassian JIRA - Cleaner Rapid Board，透過它，只要一鍵（預設為 Ctrl-H），就能切換成較清爽的全局視角：

手術後的 Jira 看板，空間利用率提高了。

如此一來，寶貴的螢幕可視區域，只放絕對必要的資訊，就能多擺幾張卡片（是的，是的，我知道這是 bad smell 啦⋯⋯）。

不過，Jira 本身已經夠笨重了，甚至連 Jira 本身的熱鍵都會不時失效；若再搭配像暴力猴這類 script 式外掛，可能會不夠穩定。如果你想要穩定一點的方案，或者不想透過熱鍵切換，只想一勞永逸眼不見為淨，不妨考慮改用 Stylish 之類的東西，自動套用：

/* For horizontal headers */
 .css-e2mdyo, #ghx-header {
    display: none !important;
}

/* For card fields */
 section.ghx-extra-fields, div.ghx-row.ghx-highlighted-field {
    display: none !important;
}

Jira 的聚焦卡片視角

在 daily stand-up 進行時，常常需要讓大家知道「我們現在正在討論某一張卡片」。

在 Jira 裡，我們可以對某一張卡片原地拖曳一下下，就會有類似的視覺聚焦效果：

原地拖曳卡片

不過，視覺效果還有很大的改善空間，而且⋯⋯需要一直維持拖曳狀態，手指頭會累。

你可以改用素有「簡報神器」之稱的 Logitech SPOTLIGHT 的聚光燈特效。視覺效果一流，但缺點一樣是手指頭需要一直按著簡報器按鈕，聚光燈會晃動，大拇指會疲累。你也可以試著用我以前在〈簡報者的小工具〉一文介紹過的 Mouseposé 軟體，手指頭就不必一直按著不放，聚光燈也會穩穩的固定不動：

透過 Mouseposé 聚焦特定卡片

總結

電子看板犧牲許多實體敏捷性。

本文介紹幾則 Jira 電子看板的小技巧，有些是 Jira 本身就有提供的，有些則是透過其他軟體輔助：

善用 Jira 熱鍵 z 及 - 縮放泳道。你也可以從 ? 當中嘗試看看有沒有更多適合自己風格的熱鍵。
善用暴力猴或 Stylish 整頓出全局卡片視角。你可以從我寫的 Atlassian JIRA - Cleaner Rapid Board 當出發點，修改成適合自己的版本。
善用 Mouseposé 聚焦單一卡片。

希望透過這些工具，加上適度的引導技巧，能夠更接近實體看板的手感。

gRPC 測試工具

Tue, 14 Apr 2020 22:00:00 +0800

RESTful API 時代，我們有許多簡單好用的測試工具：有酷炫的 Postman，有命令列控愛用的 HTTPie，當然也有硬漢必備的萬用瑞士刀 curl。

那麼，gRPC 呢？

這篇文章介紹兩個好用的小工具：gRPCurl 及 ghz，一個是輸入輸出介面測試工具，另一個是壓測工具，也順便介紹一些簡化測試的技巧。

待測程式

待測程式放在 https://github.com/William-Yeh/grpcurl-and-ghz-demo

檔案簡介：

.
├── README.md
├── build.sh                 ← 編譯命令
├── go.mod
├── go.sum
├── out                      ← 編譯後的可執行檔
│   ├── server
│   └── server-new
├── routeguide               ← gRPC 介面定義；原封不動取自 "gRPC-Go" 專案
│   ├── route_guide.pb.go
│   └── route_guide.proto
├── server                   ← server 程式；原封不動取自 "gRPC-Go" 專案
│   └── server.go
├── server-new               ← 由我修改過的新版 server 程式
│   └── server-new.go
├── testdata.dat             ← 給 gRPCurl 的測試資料
└── testdata.json            ← 給 ghz 的測試資料

為了方便起見，我挑選 “gRPC-Go” 專案裡面的 “the route guide server and client” 範例做為待測程式。

這隻 server 程式透過 gRPC 提供 RouteGuide 服務，我們這次只會測試其中的 RecordRoute 呼叫。以下是從 gRPC 介面定義檔 route_guide.proto 摘錄我們會用到的部份：

package routeguide;
service RouteGuide {
  //...

  // A client-to-server streaming RPC.
  //
  // Accepts a stream of Points on a route being traversed, returning a
  // RouteSummary when traversal is completed.
  rpc RecordRoute(stream Point) returns (RouteSummary) {}
}

message Point {
  int32 latitude = 1;
  int32 longitude = 2;
}

message RouteSummary {
  int32 point_count = 1;
  int32 feature_count = 2;
  int32 distance = 3;
  int32 elapsed_time = 4;
}

//...

我也針對 server 程式小改三個地方，弄出另一個 server-new 程式：

$ diff  server/server.go  server-new/server-new.go
42a43
> 	"google.golang.org/grpc/reflection"
55c56
< 	port       = flag.Int("port", 10000, "The server port")
---
> 	port       = flag.Int("port", 20000, "The server port")
243a245,248
>
> 	// Register reflection service on gRPC server.
> 	reflection.Register(grpcServer)
>

簡單來說，新舊兩版的差別是：

舊版 server 的 gRPC port = 10000，新版 server-new 則是 20000。
新版 server-new 支援 server reflection 功能。稍後會再說明這是什麼。

實驗環境

實驗所需環境：

Go 1.14 以上。
gRPCurl 1.5.0 以上。
ghz 0.51.0 以上。

先來編譯程式：

$ ./build.sh

成功後，會在 out 目錄拿到兩份執行檔：

out/server：原封不動來自 “gRPC-Go” 專案的 server 程式。
out/server-new：由我小小修改過的新程式。

進行實驗時，建議將你的終端機配置成這樣：

終端機建議配置

然後，請分別啟動 out/server 及 out/server-new 程式：

# 舊程式，跑在 10000 port
$ out/server

# 新程式，跑在 20000 port
$ out/server-new

一切就緒，準備要來測試它們了。

實驗一：搭配 proto 檔

先針對舊版的 server 來實驗。

gRPCurl

gRPCurl，顧名思義，是在向硬漢必備的萬用瑞士刀 curl 致敬。不妨將它視為 gRPC 版的 curl。

gRPCurl 使用上最主要的差別是，因應 gRPC 的特性，必須餵給它 proto 檔案，才會知道該如何封裝訊息格式。

譬如說，我們可將 proto 檔案的路徑寫在 -import-path 中、將 proto 檔案名稱寫在 -proto 中、將參數寫在 -d 中，再呼叫 server 的遠端程序：

$ grpcurl -plaintext  \
    -d '{"latitude":-460000000,"longitude":-1160000000} {"latitude":720000000,"longitude":-540000000}' \
    -import-path ./routeguide        \
    -proto       route_guide.proto   \
    127.0.0.1:10000                  \
    routeguide.RouteGuide.RecordRoute

{
  "pointCount": 2,
  "distance": 13975745
}

我們也可將事先備妥的資料檔餵給 gRPCurl。像是含有 100 筆資料的 testdata.dat：

$ grpcurl -plaintext -d '@'            \
    -import-path ./routeguide          \
    -proto       route_guide.proto     \
    127.0.0.1:10000                    \
    routeguide.RouteGuide.RecordRoute  \
  < testdata.dat

{
  "pointCount": 100,
  "distance": 1003784333
}

ghz

ghz 壓測工具，是這麼自我介紹的：

Simple gRPC benchmarking and load testing tool inspired by hey and grpcurl.

所以，從命令列參數及統計結果上，都可看出它們的影響。

譬如說，我們可將 proto 檔案的路徑寫在 --import-path 中、將 proto 檔案名稱寫在 --proto 中、將參數寫在 --data 中，再呼叫 server 的遠端程序：

$ ghz --insecure  -z 20s  \
      --data '[{"latitude":-460000000,"longitude":-1160000000},{"latitude":720000000,"longitude":-540000000}]' \
      --import-paths ./routeguide         \
      --proto        route_guide.proto    \
      --call routeguide.RouteGuide.RecordRoute  \
      127.0.0.1:10000

壓測 20 秒，結果如下：

Summary:
  Count:        548082
  Total:        20.00 s
  Slowest:      50.36 ms
  Fastest:      0.12 ms
  Average:      1.74 ms
  Requests/sec: 27403.72

Response time histogram:
  0.123 [1]     |
  5.147 [543463]        |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  10.170 [4297] |
  15.194 [271]  |
  20.217 [8]    |
  25.241 [3]    |
  30.264 [1]    |
  35.288 [0]    |
  40.311 [0]    |
  45.335 [0]    |
  50.358 [1]    |

Latency distribution:
  10 % in 0.90 ms
  25 % in 1.21 ms
  50 % in 1.58 ms
  75 % in 2.04 ms
  90 % in 2.66 ms
  95 % in 3.24 ms
  99 % in 4.93 ms

Status code distribution:
  [Canceled]      33 responses
  [Unavailable]   4 responses
  [OK]            548045 responses

Error distribution:
  [33]   rpc error: code = Canceled desc = grpc: the client connection is closing
  [4]    rpc error: code = Unavailable desc = transport is closing

同樣的，我們也可將事先備妥的資料檔餵給 ghz。像是含有 100 筆資料的 testdata.json：

$ ghz --insecure --data=@  -z 20s  \
      --import-paths ./routeguide         \
      --proto        route_guide.proto    \
      --call routeguide.RouteGuide.RecordRoute  \
      127.0.0.1:10000  \
  < testdata.json

壓測 20 秒，結果如下：

Summary:
  Count:        788680
  Total:        20.00 s
  Slowest:      28.02 ms
  Fastest:      0.13 ms
  Average:      1.23 ms
  Requests/sec: 39432.62

Response time histogram:
  0.126 [1]     |
  2.915 [772021]        |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  5.705 [15003] |∎
  8.495 [1000]  |
  11.285 [458]  |
  14.074 [95]   |
  16.864 [10]   |
  19.654 [12]   |
  22.444 [3]    |
  25.233 [5]    |
  28.023 [40]   |

Latency distribution:
  10 % in 0.65 ms
  25 % in 0.86 ms
  50 % in 1.11 ms
  75 % in 1.42 ms
  90 % in 1.88 ms
  95 % in 2.30 ms
  99 % in 3.57 ms

Status code distribution:
  [OK]         788648 responses
  [Canceled]   32 responses

Error distribution:
  [32]   rpc error: code = Canceled desc = grpc: the client connection is closing

實驗二：不需搭配 proto 檔

使用前，每次都要先備妥待測程式的 proto 檔，其實也滿麻煩的。萬一複雜的 proto 檔案又去 import 其他 proto 檔 ¹，可能就得條列一堆 -import-path 或 --import-path 命令列參數給 gRPCurl 及 ghz。

有沒有省力一點的方法？

有的，就是透過 server reflection 功能。

Server reflection

我以這次的範例程式 server-new 為例，說明如何加上 server reflection 功能。

首先，請加上 google.golang.org/grpc/reflection 套件：

import "google.golang.org/grpc/reflection"

接著，在 grpcServer.Serve 之前，呼叫 reflection.Register：

grpcServer := grpc.NewServer(opts...)
//...

// Register reflection service on gRPC server.
reflection.Register(grpcServer)

grpcServer.Serve(lis)

只需要這兩個步驟，你的 gRPC 程式本身就具有 server reflection 功能，對方不再需要 proto 檔案就能直接進行遠端呼叫。

針對新版的 server-new 來實驗看看吧。

gRPCurl

我們可用 list 指令查詢 server-new 提供哪些服務：

$ grpcurl -plaintext  127.0.0.1:20000  list

grpc.reflection.v1alpha.ServerReflection
routeguide.RouteGuide

可用 describe 指令查詢 server-new 提供服務的介面：

$ grpcurl -plaintext  127.0.0.1:20000  describe

grpc.reflection.v1alpha.ServerReflection is a service:
service ServerReflection {
  rpc ServerReflectionInfo ( stream .grpc.reflection.v1alpha.ServerReflectionRequest ) returns ( stream .grpc.reflection.v1alpha.ServerReflectionResponse );
}
routeguide.RouteGuide is a service:
service RouteGuide {
  rpc GetFeature ( .routeguide.Point ) returns ( .routeguide.Feature );
  rpc ListFeatures ( .routeguide.Rectangle ) returns ( stream .routeguide.Feature );
  rpc RecordRoute ( stream .routeguide.Point ) returns ( .routeguide.RouteSummary );
  rpc RouteChat ( stream .routeguide.RouteNote ) returns ( stream .routeguide.RouteNote );
}

可用 describe 指令進一步查詢某參數的具體格式：

$ grpcurl -plaintext  127.0.0.1:20000  describe .routeguide.Point

routeguide.Point is a message:
message Point {
  int32 latitude = 1;
  int32 longitude = 2;
}

可看出，gRPCurl 不需要 proto 檔案，就能直接向 server-new 查詢遠端呼叫所需知道的介面細節。

最後，讓我們將含有 100 筆資料的 testdata.dat 餵給 gRPCurl 來測測看：

$ grpcurl -plaintext -d '@' \
    127.0.0.1:20000         \
    routeguide.RouteGuide.RecordRoute  \
  < testdata.dat

{
  "pointCount": 100,
  "distance": 1003784333
}

有了 server reflection 功能，是不是方便多了？如果你有權修改原始程式，這是值得好好考慮的，可讓測試工作輕鬆一點。

當然啦，你可以考慮在 production 環境關掉這功能；但在測試環境中，這真的很方便。

ghz

儘管 server reflection 通常不會在 production 環境啟用，不過我還是很好奇：server reflection 對執行效率的影響有多少？尤其是涉及 marshalling。

用 ghz 試試看吧！

$ ghz --insecure --data=@  -z 20s  \
      --call routeguide.RouteGuide.RecordRoute  \
      127.0.0.1:20000  \
  < testdata.json

壓測 20 秒，結果如下：

Summary:
  Count:        826524
  Total:        20.00 s
  Slowest:      19.79 ms
  Fastest:      0.12 ms
  Average:      1.17 ms
  Requests/sec: 41317.73

Response time histogram:
  0.118 [1]     |
  2.085 [776730]        |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  4.052 [45892] |∎∎
  6.019 [3018]  |
  7.986 [550]   |
  9.953 [112]   |
  11.920 [74]   |
  13.887 [51]   |
  15.854 [37]   |
  17.821 [17]   |
  19.788 [1]    |

Latency distribution:
  10 % in 0.62 ms
  25 % in 0.82 ms
  50 % in 1.06 ms
  75 % in 1.36 ms
  90 % in 1.80 ms
  95 % in 2.20 ms
  99 % in 3.38 ms

Status code distribution:
  [OK]            826483 responses
  [Canceled]      40 responses
  [Unavailable]   1 responses

Error distribution:
  [40]   rpc error: code = Canceled desc = grpc: the client connection is closing
  [1]    rpc error: code = Unavailable desc = transport is closing

雖然這還不算非常嚴謹的實驗，但可看出，沒有 server reflection 功能的 server 版本，與有此功能的 server-new 版本，執行效率沒有顯著差異。

因此，server reflection 功能，值得嘗試。

總結

本篇文章，介紹兩個好用的 gRPC 測試小工具：輸入輸出介面測試工具 gRPCurl，以及壓測工具 ghz。最後並推薦 server reflection 功能來簡化 gRPC 測試工作。

ghz 也有 web 介面，目前是 beta 狀態。有興趣的，請去 ghz 官網看看。

Proto 檔案也可以 import 其他 proto 檔。詳見 https://developers.google.com/protocol-buffers/docs/proto3#importing-definitions ↩︎

gRPC Load Balancing in Kubernetes

Mon, 30 Mar 2020 22:30:00 +0800

Kubernetes 有個很方便的地方：只要修改 deployment 的 spec.replicas 數字，就能橫向擴展 pod，以應付更大的流量負載需求。

這一招，對於 stateless 的 HTTP 服務很管用，也是 Kubernetes 入門教學愛用的例子。但是，對於 gRPC 呢？

gRPC 是以 HTTP/2 作為傳輸協定，而 HTTP/2 的特點是持久連線：

One connection per origin

all HTTP/2 connections are persistent, and only one connection per origin is required, which offers numerous performance benefits. – Introduction to HTTP/2

既然 gRPC 會盡可能維持既有連線，不會傻傻地一直斷線與重連，那麼，當 Kubernetes 橫向擴展 pod 了，gRPC 流量是否也能順便平均分散到新長出來的 pod 身上，還是死咬著原本的連線不放？

做個簡單的實驗吧。

實驗環境

實驗程式放在 https://github.com/William-Yeh/grpc-lb

實驗所需環境：

Go 1.14 以上。
Kubernetes 1.14 以上。
Skaffold 1.6.0 以上。
Linkerd 2.7.0 以上。

實驗進行之前，請先編譯所需的執行檔及容器映像檔：

# Generate native binaries in `out` directory: 
./build.sh

# Generate Docker images:
skaffold build

會產生以下程式：

執行檔 out/server & 映像檔 addr-server：接收 HTTP 及 gRPC 連線，傳回自己的 IP 位址。
執行檔 client-http & 映像檔 addr-client-http：透過 HTTP 查詢 server 位址。
執行檔 client-grpc & 映像檔 addr-client-grpc：透過 gRPC 查詢 server 位址。

實驗一：純 Kubernetes 模式

首先實驗看看，若 server 程式跑在 Kubernetes 裡，除了 HTTP 流量會自動負載均衡之外，是否 gRPC 流量也享有同等待遇。

實驗一：純 K8s 模式的佈局

為了方便一眼看出整體狀況，請將終端機面板配置如下：

實驗一：終端機建議配置

請依照以下步驟進行實驗：

建立 grpc-lb namespace：
```
kubectl create ns grpc-lb
```
在 grpc-lb 裡執行 server，此時 spec.replicas 為 1：
```
skaffold dev  -n grpc-lb
```
執行 client-http，透過 HTTP 連線到 server：
```
out/client-http  http://127.0.0.1:30080/addr
```
執行 client-grpc，透過 gRPC 連線到 server：
```
out/client-grpc  localhost:30051
```

因為現在 server pod 只有一個，所以 client-http 及 client-grpc 都只會連線到同一個 IP 位址（即此例的 10.1.0.8）。

現在，讓我們把 server pod 的 spec.replicas 數字擴展成 5：

kubectl scale -n grpc-lb \
  --replicas=5  deployment/addr-server

如下圖所示，當 server pod 數目從 1 變成 5，Kubernetes 的確開始將 HTTP 流量平均分配到 5 個 pods 身上（即此例的 10.1.0.8 ～ 10.1.0.12）。可是 gRPC 流量卻仍然綁在舊的那一個 pod 身上（即此例的 10.1.0.8）。

實驗一：gRPC 流量並未平均分配

可見，Kubernetes 並沒有對 gRPC 進行負載均衡。

為什麼？

L4 vs L7 負載均衡

根據 “gRPC Load Balancing inside Kubernetes” 一文所述，Kubernetes 原生的負載均衡機制，是建立在 L4：

When you create a Service in Kubernetes, it creates a layer 4 proxy and load balance connections to your pods using iptables, the service endpoint is one IP and a port hiding your real pods.

因此，對於不具備真正持久連線的 HTTP 來說，Kubernetes 原生的 L4 負載均衡機制足以應付 ¹；但是，對於真正具有持久連線的 gRPC，L4 就行不通了。

文中列出三種解決方法：

Client 端的負載均衡：叫 client 維持一個 gRPC connection pool，主動與每一個 gRPC server pods 都維持連線。缺點是：必須修改 client 程式碼，也暴露 server pods 的一些內部細節。
Kubernetes edge 端的負載均衡：透過 ingress 之類的機制。
Kubernetes service mesh：透過 sidecar 之類的機制。

為了簡單起見，我參考 Kubernetes 官網文章 “gRPC Load Balancing on Kubernetes without Tears” 的做法，用 Linkerd 2 這個 service mesh 方案來實驗。 ²

實驗二：Service mesh 模式

根據 Linkerd 官網 FAQ 所述：

Linkerd 1.x is built on the “Twitter stack”: Finagle, Netty, Scala, and the JVM.

Linkerd 2.x is built in Rust and Go. It is significantly faster and lighter weight than 1.x, but currently only supports Kubernetes.

Linkerd 2 比前一版有長足的進步，又是 SMI 陣營的一員，頗值得一試。

Linkerd 前置作業

安裝 Linkerd 2 到現行的 Kubernetes cluster：

# Install
linkerd install | kubectl apply -f -

# Check
linkerd check

先刪掉舊的 grpc-lb namespace:
```
kubectl delete ns grpc-lb
```
建立新的 grpc-lb namespace，並注入 Linkerd：
```
kubectl apply -f ns.yml
```
檢查一下 grpc-lb namespace 的 data plane 是否正常：
```
linkerd -n grpc-lb check --proxy
```

我們把 grpc-lb namespace 圈成一塊 service mesh 疆域。如果一切順利，在 grpc-lb namespace 裡面的東西，會自動被 Linkerd 接管——包括 gRPC 負載均衡。

Replicas = 1

首先實驗看看，若我們將 addr-client-grpc 與 server 都放在 service mesh 疆域內，兩者間的 gRPC 流量是否會自動負載均衡。我也保留一份舊的 client-grpc 故意「不」讓它跑在 Kubernetes 裡面，作為對照組。

實驗二：K8s service mesh 模式的佈局

為了方便一眼看出整體狀況，請將終端機面板配置如下：

實驗二：終端機建議配置

請依照以下步驟進行實驗：

移掉 skaffold.yaml 這一行的註解符號：

deploy:
  kubectl:
    manifests:
      - server.yml
      #- client-grpc.yml  ← 請讓這一行生效！

在 grpc-lb namespace 裡執行 addr-client-grpc 及 server，此時 server 的 spec.replicas 為 1：
```
skaffold dev  -n grpc-lb
```
等前一個步驟跑到穩定狀態之後，在 Kubernetes 外面也執行一份舊的 client-grpc 作為對照組：
```
out/client-grpc  localhost:30051
```

此時，因為 server pod 只有一個，所以，位於 service mesh 疆域內的 addr-client-grpc 及疆域外的 client-grpc 都只會連線到同一個 IP 位址（即此例的 10.1.0.71）。

Replicas = 5

一切就緒，讓我們把 server pod 的 spec.replicas 數字擴展成 5：

kubectl scale -n grpc-lb \
  --replicas=5  deployment/addr-server

如下圖所示，當 server pod 數目從 1 變成 5，Kubernetes 的確開始將 service mesh 疆域內 addr-client-grpc 產生的 gRPC 流量平均分配到 5 個 pods 身上（即此例的 10.1.0.71 ～ 10.1.0.75）。可是「不」位於 service mesh 疆域的 client-grpc 產生的 gRPC 流量，就仍然綁在舊的那一個 pod 身上（即此例的 10.1.0.71）。

實驗二：gRPC 流量分配狀況

Linkerd 儀表板

讓我們看看酷炫一點的東西吧！請用以下命令打開 Linkerd 儀表板：

linkerd dashboard &

請切換到 grpc-lb namespace，觀察三個角色之間的網路互連架構，並檢視一些效率指標。如下圖所示，Linkerd 2.7.0 對於 gRPC load balancing 的表現很不錯，即使打開 mesh sidecar，P99 latency 也仍然壓在 10ms 左右的水準：

實驗二：Topology

從下圖也可以看到 5 個 server pods 都有輪流服務到 addr-client-grpc。其中，最後一個 pod 比較可憐，湊巧服務到獨佔連線的外部 client-grpc：

實驗二：gRPC 負載均衡的數據

簡單的實驗，示範在 Kubernetes 裡，可以透過 service mesh 替 gRPC 加上負載均衡機制。

嚴格來說，HTTP/1.1 的 keep alive 機制，或多或少會影響到 Kubernetes 的負載均衡效果。不過正如維基百科所說，許多 Web server 本來就會針對 HTTP 設定較短的 timeout 以避免副作用。若真的要在 Web 上進行持久連線，一般都會建議改走 WebSocket 路線。 ↩︎
有在玩 Istio 的朋友，可以參考〈Istio 基礎 — gRPC 負載均衡〉一文的做法。不過，比較起來，Istio 設定上會比 Linkerd 複雜。 ↩︎

Idempotency Key：原理與實測

Tue, 10 Mar 2020 23:00:00 +0800

最近幾年，在微服務打滾的人，不時會遇到神祕的 “idempotency key” 字眼。本文爬梳 idempotency key 的技術背景，探討運作流程，並分析資料庫的實作選項。

Idempotency 冪等性

在 API 服務中，常常需要留意 idempotency（冪等性）。

名詞：idempotency，形容詞：idempotent。

“Idempotency” 這字眼源自數學。維基百科是這麼解釋 “idempotent function” 的：

idempotent elements are the functions f: E → E […] such that for all x in E, f(f(x)) = f(x)

如果套用到電腦界 ¹，idempotency 性質可以詮釋成：

f：可以是 function 或是 API endpoint。
x：可以是 argument 或是 API header & payload。
如果 f 是 idempotent，就代表：對 f(x) 執行 1 次產生的效果，與執行 N 次產生的效果，完全一樣。

譬如說，如果有一個管理商品庫存的服務：

type Item struct {/*...*/}

type ItemInventory interface {
	func GetQuantity(item Item) int       // 查詢庫存量   
	func SetQuantity(item Item, num int)  // 設定庫存量
	func DecreaseQuantity(item Item)      // 庫存量減一
}

那麼，像以下這些動作，呼叫 1 次的效果，與呼叫 N 次的效果一樣，即可稱為是 idempotent：

var num int

// 查詢庫存量
num = inventory.GetQuantity(item)
num = inventory.GetQuantity(item)
num = inventory.GetQuantity(item)
//...

// 設定庫存量
num = 100
inventory.SetQuantity(item, num)
inventory.SetQuantity(item, num)
inventory.SetQuantity(item, num)

反之，像以下這些動作，呼叫 1 次的效果，與呼叫 N 次的效果會不一樣，即可稱為是 non-idempotent：

/*...*/                              // 起初庫存量為 100
inventory.DecreaseQuantity(item)     // 庫存量會變成 99
inventory.DecreaseQuantity(item)     // 庫存量會變成 98
inventory.DecreaseQuantity(item)     // 庫存量會變成 97

Non-idempotent 操作有必要存在嗎？

在 functional programming 思潮下，immutability 及 idempotency 似乎才是政治正確之舉。

Non-idempotent 的操作，真的有必要存在嗎？

譬如說，即使沒有 non-idempotent 的 DecreaseQuantity，我們仍可透過 idempotent 的 SetQuantity 來達到一樣的效果：

num = inventory.GetQuantity(item)       // 起初庫存量為 100

numTarget := num - 1
inventory.SetQuantity(item, numTarget)  // 庫存量會變成 99

numTarget--
inventory.SetQuantity(item, numTarget)  // 庫存量會變成 98

numTarget--
inventory.SetQuantity(item, numTarget)  // 庫存量會變成 97

如此一來，是否真的沒有必要再留下 non-idempotent 的 DecreaseQuantity？至少有兩件事需要思考：

語意層面的改變。原本 DecreaseQuantity 的簽名，並沒有「庫存量」這一欄，也就是說，client 並不需要知道「目前庫存量」，即可進行「庫存量減一」。如果改寫成 SetQuantity 版本，簽名不同，多了「庫存量」欄位，換句話說，原本不必知道的「庫存量」內容，現在就必須透露出來了——這改變了原本「庫存量減一」的操作語意。
同步問題。同一時間，萬一有別人也在透過這個新方法改動「庫存量」，就會發生 race condition。

因此，某些時候，non-idempotency 可能無法完全迴避。

HTTP 的 idempotency 規範

HTTP 對於 idempotency 有一些規範。像 HTTP/1.1 的規格書 §9.1.2 就指出：

Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.

RFC 5789 也提到：

PATCH is neither safe nor idempotent as defined by RFC2616, Section 9.1.

所以，綜合來說，在 HTTP 的標準規範當中，只有 POST 及 PATCH 不是 idempotent。

對這些 HTTP 細節感興趣的，請參考 ihower 的〈HTTP Verbs：談 POST, PUT 和 PATCH 的應用〉一文。

Web API 的 idempotency 問題

前面的 Go 程式碼講的是 in process 場景。環境單純，沒有太多失敗、重試的未知狀況，不會有太大的 idempotency 問題。如果換成 out of process 場景，環境不再單純，網路環境不可靠，另一頭的通訊對象也不見得是穩定的，失敗、重試的未知狀況勢必增加，idempotency 就變成不得不去正視的議題。

譬如說，如果把管理商品庫存服務實作成 RESTful API：

Go + Gin 實作的 RESTful API 例子

import (
	"github.com/gin-gonic/gin"
	"strconv"
)

func main() {
	//...
	router := gin.Default()

	// 查詢庫存量
	router.GET("/inventory/quantity/:item_id", func(c *gin.Context) {
		//...
		num ：= inventory.GetQuantity(item)
		//...
	})

	// 設定庫存量
	router.PUT("/inventory/quantity/:item_id", func(c *gin.Context) {
		//...
		num, _ := strconv.Atoi(c.PostForm("num"))
		inventory.SetQuantity(item, num)
		//...
	})

	// 庫存量減一
	router.POST("/inventory/quantity/:item_id/dec", func(c *gin.Context) {
		//...
		inventory.DecreaseQuantity(item)
		///
	})

	router.Run()
}

對於原本就是 idempotent 的 GetQuantity 和 SetQuantity 操作來說，換成 RESTful 版本並沒什麼問題。像以下這個例子中，Client 在 🅐 步驟向 Server 呼叫 query quantity 操作時，只要該資料沒被別人改動到，這個 🅐 步驟不管重試多少次，得到的結果都會是一樣的。

Idempotent API operations

但是，對於原本就是 non-idempotent 的 DecreaseQuantity 操作來說，一遇到失敗、重試的未知狀況就麻煩了。像以下這個例子中，Client 在 🅑 步驟向 Server 呼叫 decrease quantity 操作時，Server 及 DB 都完成了各自的任務，可惜當 Server 在回傳結果給 Client 時，因為網路不穩定而漏失訊息。

Client 不會知道 🅑 背後涉及的各個環節究竟完成了多少，只會以為 🅑 步驟沒有生效，便主動以 🅑’ 步驟重試一次。Server 並不知道這個 🅑’ 只是個美麗的誤會，只能忠實地再執行一次 DecreaseQuantity 操作。於是，DecreaseQuantity 這個 non-idempotent 操作，就被錯誤地重複使用，造成錯誤的結果。

Non-idempotent API operations

這也是為什麼我們在一些沒有仔細處理 idempotency 的交易網站上，會看到這類警語：

交易進行中，請勿按下【重新載入此頁】按鈕，以避免重複扣款。

也就是說，他們認為，倘若因為電腦或網路不穩定而頻頻手動重試，從而導致的任何不良後果，都是使用者不聽勸告的錯。

向 TCP 取經

在不穩定的分散式系統中，對於 non-idempotent 的操作，該如何避免重試所引發的問題？

不妨師法 TCP 吧，畢竟它算是在不可靠的 IP 傳輸環境中進行可靠傳輸的老祖宗了。

每一個 TCP segment 的 header 都帶有一個序列號 (seq)，透過它，TCP 通訊的雙方，得以在不可靠的環境中，處理連線建立、流量控制、連線關閉等議題。² 就以 TCP 的 3-way handshake 機制為例，雙方藉由 seq 來溝通是否成功地傳送與接收訊息：

TCP 3-way handshake

我們來分析 🅒 🅓 🅔 這幾種訊息丟失的狀況。

如果 🅒 訊息在中途就丟失了：

那麼，Server 自然不會送出 🅓。
既然 Client 遲遲沒收到 🅓，也就會繼續重試 🅒 (seq=x)。

如果 🅒 訊息成功送給 Server 了，但 🅓 訊息卻在中途就丟失了：

既然 Client 遲遲沒收到 🅓，就會繼續重試 🅒 (seq=x)。
Server 在收到 🅒 時，會根據 seq=x 得知這是重複的訊息。

如果 🅔 訊息在中途就丟失了：

既然 Server 遲遲沒收到 🅔，就會繼續重試 🅓 (seq=y)。
Client 在收到 🅓 時，會根據 seq=y 得知這是重複的訊息。

根據以上分析，我們可從 TCP 偷學一個祕訣：只要在 request 附上一個識別碼，就能讓通訊雙方偵測出失敗重試的情況，以採取對應的措施。

這就是 TCP 在 layer 4 進行的可靠傳輸措施。

識別碼，由誰來產生？

這一招，不僅在 layer 4 行之有年，在 layer 7 也一樣管用。

接下來的問題是：識別碼，由誰來產生？由 request 的接收方，還是發起方？

識別碼可以由 request 接收方：server 產生。像 Restful Web Services Cookbook §10.8 & §10.9 就建議，針對 non-idempotent 的操作，server 可先產生 nonce 當作識別碼，將它當成參數添加到服務的 URI 上面，再請 client 透過這個加過料的 URI 來操作 server 的服務。

也有人把識別碼的生成責任交給 request 發起方：client 來做。像 Stripe 官方提供的 StripeClient 程式庫，針對 POST 及 DELETE 類型的操作，會先在 client 這邊產生 uuid v4 當作識別碼，將它添加到 HTTP header 中（此例為 Idempotency-Key），再傳給 server：

# It is only safe to retry network failures on post and delete
# requests if we add an Idempotency-Key header
if %i[post delete].include?(method) && Stripe.max_network_retries > 0
    headers["Idempotency-Key"] ||= SecureRandom.uuid
end

簡單的概念，近年來較新的服務，尤其是與金流或電子商務有關的，似乎也很流行這種 “idempotency key” 手法：

Adyen: API idempotency
Airbnb: Avoiding Double Payments in a Distributed Payments System
Square: Working with APIs: Idempotency
Stitch Fix: Patterns of Service-oriented Architecture: Idempotency Key
Stripe：API Reference: Idempotent Requests

概念很簡單，卻有個來歷不明的酷炫名詞 “idempotency key”。根據 Stripe 工程師 Brandur Leach 在 “Implementing Stripe-like Idempotency Keys in Postgres” 一文所說，這名詞是 Stripe 發明的：

An idempotency key is a unique value that’s generated by a client and sent to an API along with a request. The server stores the key to use for bookkeeping the status of that request on its end. If a request should fail partway through, the client retries with the same idempotency key value, and the server uses it to look up the request’s state and continue from where it left off. The name “idempotency key” comes from Stripe’s API.

在沒有進一步翻案證據之前，暫時姑且接受「這是 Stripe 發明的」的說法吧。

Idempotency key 的生成

理論上，任何機制，只要在合理範圍內具有唯一性，就能用來產生 idempotency key。

但實務上，在實作 idempotency key 時，可能還需要考慮幾個議題：

由資料庫自動產生，還是由程式邏輯層產生？
純亂數，還是單調遞增？

資料庫能夠自動替我們產生單調遞增序號。只要將 idempotency key 宣告成 MySQL 的 auto_increment 或 PostgreSQL 的 serial 之類的資料型態，再搭配像 MySQL 的 last_insert_id() 或 PostgreSQL 的 insert returning 之類的查詢語法，即可一次搞定 idempotency key 生成與儲存。

乍看之下很方便，不過，如果資料庫有分庫分表，就需要再額外處理，才能確保序號的唯一性。另一個或許更嚴重的缺點是，從架構潔癖的角度來看，違反了 clean architecture 的分層原則與相依原則：

資料庫是個細節，我們將這些東西放在外頭，在那邊它們不會有什麼危害。

資料庫不是資料模型。資料庫是一塊軟體，是提供對於資料存取的工具。它是一個低層級的細節——是一種機制。一名好的架構師，不會允許底層機制污染系統的架構。

同樣有架構潔癖的 DDD，也不喜歡過於仰賴資料庫機制，像 Implementing Domain-Driven Design 的 §5.2 就直接建議大家將序號產生機制放在 Repository 層。³

如果要改由程式邏輯層產生 idempotency key，可能會直接套用 uuid，甚至訴諸 Snowflake、Sonyflake、Leaf 這類分散式 ID 服務。不依賴資料庫，彈性大，也符合架構潔癖。

不依賴資料庫，符合了架構潔癖，是否會因此犧牲了資料庫的效能？接下來我們就來探討這議題。

Idempotency key 的儲存

透過程式邏輯產生的 id，可粗分為三大類：

純亂數：像 uuid v4
局部單調遞增：像 uuid v1
全域單調遞增：像 Snowflake、Sonyflake、Leaf

這些 idempotency key 該如何儲存，才可與資料庫內建的單調遞增序號一較高下？

理論上來說，在目前資料庫系統主流的 B+ tree 索引結構下，單調遞增的數值，會比純亂數來得有效率。因此，若不計資料欄位大小差異，三者的存取效率，理論上應該會是 Snowflake > uuid v1 > uuid v4。

不過，我對於 PostgreSQL 提供的 uuid 資料型態格外感興趣：

PostgreSQL provides storage and comparison functions for UUIDs, but the core database does not include any function for generating UUIDs, because no single algorithm is well suited for every application.

從 PostgreSQL 原始碼 uuid.h 及 uuid.c 來看，骨子裡是用 16 bytes 字元陣列來實作：

/* uuid size in bytes */
#define UUID_LEN 16

typedef struct pg_uuid_t
{
	unsigned char data[UUID_LEN];
} pg_uuid_t;


/* internal uuid compare function */
static int
uuid_internal_cmp(const pg_uuid_t *arg1, const pg_uuid_t *arg2)
{
	return memcmp(arg1->data, arg2->data, UUID_LEN);
}

/* hash index support */
Datum
uuid_hash(PG_FUNCTION_ARGS)
{
	pg_uuid_t  *key = PG_GETARG_UUID_P(0);

	return hash_any(key->data, UUID_LEN);
}

對於 uuid 的存取性能，PostgreSQL 似乎是有備而來胸有成竹。

因此，我針對 PostgreSQL 的 uuid 資料型態，分別實驗「亂數」與「遞增數值」存取效率，順便也拿 bigint 做對照組，看看這些排列組合，哪一種比較適合 idempotency key 用途：

Idempotency Key 類型	演算法	資料大小 (bytes)	PostgreSQL 資料型態
亂數	uuid v4	16	uuid
遞增數值	uuid v1	16	uuid
遞增數值	Snowflake	8	bigint

針對這些排列組合，我進行三組實驗：

寫入 N 筆資料：InsertUuidV1、InsertUuidV4、InsertSnowflake
隨機存取 10% 資料，無 DB cache：SelectUuidV1/clean、InsertUuidV4/clean、InsertSnowflake/clean
隨機存取 10% 資料，有 DB cache：SelectUuidV1/cache、InsertUuidV4/cache、InsertSnowflake/cache

實驗程式放在 https://github.com/William-Yeh/idempotency-key-test

我的實驗環境：

MacBook Pro
CPU: 2.8 GHz 四核心Intel Core i7
Go: 1.14
PostgreSQL: 12.2

首先牛刀小試一下，實驗 10 萬筆資料：

Test with N=100k

乍看之下，三種 idempotency key 資料類型，彼此性能差異並不大。數量級分別是：

寫入 N 筆資料：每秒能處理約 5*10³ 筆操作。
隨機存取 10% 資料，無 DB cache：每秒能處理約 5*10⁴ 筆操作。
隨機存取 10% 資料，有 DB cache：每秒能處理約 8*10⁴ 筆操作。

放大十倍試試看，實驗 100 萬筆資料：

Test with N=1m

最後，實驗 300 萬筆資料，順便看看三種 idempotency key 資料類型佔用的索引空間：

Test with N=3m

執行速度差異不大。至於索引結構，則是 uuid v1 顯著偏高，而 uuid v4 與 snowflake 無太大差異。

綜合以上實驗，PostgreSQL 的 uuid 效能十分優異，足堪大任。我建議：如果你的 idempotency key 想要是亂數，可以直接把 uuid v4 存在 uuid 欄位中；如果你的 idempotency key 想要是單調遞增數值，不妨考慮把 snowflake 存在 bigint 欄位中。

如果你用的是其他資料庫系統，此處的建議不見得適用，請自行實驗。

致謝

實驗設計過程中，從 Carousell 同事得到許多建議，特此致謝。

We’re hiring!

嚴格來說，電腦領域講的 “idempotency”，已經與數學領域講的 “idempotency” 不盡相同了，可說是一種假借。詳情請見維基百科的說明： https://en.wikipedia.org/wiki/Idempotence#Computer_science_meaning ↩︎
對於 TCP 序列號機制感興趣的，可參考鄭中勝寫的三篇介紹文章：〈TCP 序列號 (Sequence Number, SEQ)〉、〈TCP 三向交握 (Three-way Handshake)〉、〈TCP 流量控制 (Flow Control)〉。 ↩︎
在 DDD 中，id 生成機制很適合放在 Repository 層。如果你沒有 Implementing Domain-Driven Design 這本書，也可以參考劉鳳軒寫的〈DDD 戰術設計：Entity 概念與實作〉一文。 ↩︎

求職，別忘了突出你的亮點

Wed, 08 Jan 2020 22:30:00 +0800

在網路上看到 Joe 喟然嘆曰：「今天重要功課：仔細看過明天 20 位履歷課同學的履歷以及繳交的功課。說起來這堂課好像是我們最耗能的一堂課，完全是做功德的一堂課。」

我，身為履歷表價值鏈另一端的面試官，也很能瞭解這番滋味。¹

近年來，履歷教戰守則廣傳，有專書，甚至還有專門課程。理論上，「不懂得 ~~包裝美化履歷~~ 正確呈現履歷」的低級錯誤應該會越來越少見——其實不然。驚訝的是，即使是獵頭轉來的履歷也常無法倖免，真不知該怎麼說了。

遇到比較多的反例，是沒有亮點。

年資，不必然是亮點

先破除一個迷思：年資，不必然是忠誠，不必然是專注，不必然是匠人精神。一言以蔽之，不必然是亮點。

猶記 2016 年擔任軟體工程師面試官時，看著其中某一份履歷，我寫下如此感觸：

收到一份履歷，他在某接案公司待了 N 年。

很可惜。在我眼中，這只值兩年呀。

對接案公司無不敬之意。但是，字裡行間，實在看不出反駁我對他「只有兩年的工作經驗，只不過重複了 N 年」認知錯誤的理由。

其實，多年以來，每一段面試高峰期都會出現同樣的觀察與感觸——看不出求職者的亮點，尤其是與職務相關的亮點，遑論職涯層次的亮點。

書面的履歷表也就罷了。更麻煩的是，怕誤判，約來面試，試著口頭引導一下，都不見得引導得出來。

面試官當下的任務，是替用人單位選才，而不是當應徵者的職涯諮詢者。

請自己先正確表述你的亮點，而不是徒留年資流水帳。

成長性

不同企業、不同職種，側重的亮點或許不盡相同。

在我所處的軟體研發領域，「成長性」是非常重要的。除非某職缺有立即上戰場的急迫性，否則，我會側重在求職者的成長性，包括硬技能成長性及軟技能成長性；有時候，成長性甚至會重於即戰力。

什麼樣的成長性才稱得上是亮點？

且讓我套用裘凱宇老師在【過好人生學】課程所講的「站位／靶位」概念來分析：

固定站位：在單一領域，發展到學徒、創造、達人的哪一個階段？
固定靶位：在單一領域，持續創造了什麼成果？
固定站位，不固定靶位：多元發展
不固定站位，固定靶位：跨界創意
不固定站位，不固定靶位：多元發展＋跨界創意

站位／靶位的固定與否，是個人的主觀選擇（或被動的被選擇）；不過，不管是屬於哪一種排列組合，請試著客觀回顧履歷一遍，能否據以勾勒出某些清晰的移動路徑？

成長性，從這路徑就看得出來了。

你，是一直在打怪升級成長 ²，是在死守四行倉庫，還是在宇宙漂流？

敏銳於遊戲規則

履歷，畢竟是對既有產品（「個人」）既成事實的推銷；說句老實話，不免有為時已晚的風險。更可靠的，應該是在走到這田地之前，就下意識讓自己在站位／靶位兩方面都逐漸成長。

成長，不是臨時抱佛腳一蹴可幾，更不是刻舟求劍緣木求魚。

成長，需要敏銳於職場的遊戲規則。

其一：

其實，每一個位子都有可能發光發熱，重點仍在於是否有自覺進行「換位思考」及「系統思考」。

有自覺，你的一年工作經驗，就有別人 N 年的價值；反之，你的 N 年工作經驗，就只有一年的價值。

— Quote: 2016-08-20 Tweet

其二：

不是在大公司就一定學得深，不是在新創就一定學得廣。

重點仍在於自己。在於「自己有沒有系統思考及換位思考的自覺及行動」。

在於專業態度。

「專業技能」固然重要，但是，能夠讓自己從流水帳的制式履歷表欄位中脫穎而出的，終究是「專業態度」。很準。只要針對每一份履歷表，個別客製化追問一兩次，幾乎就能分辨出哪些人有下意識追求「專業態度」的成長。

— Quote: 〈專業態度的養成〉

其三：

許多事情，跟你身在大公司還是小公司是低度相關的。心智框架，是要靠自己主動觀察、取經、思考的。

— Quote: 2016-08-15 Tweet

成長，是下意識的選擇，是用持續的意志去磨銳遊戲規則的基本功：換位思考、系統思考、專業態度、心智框架。

求人找亮點？

大環境長期低薪，促使許多人尋求更多元的選項。就連「副業」這個老詞彙，居然也孳生「斜槓」這個聽起來更新潮、也更容易炒作的詞彙。職涯、生涯的重定位，一時之間蔚為風潮。

是真需求也好，是炒作起來的需求也好，有需求，就有供給。於是乎，坊間有了《做自己的生命設計師》這樣的書，有了所謂【設計你的人生】工作坊，甚至像 S 姐在〈默默的，你認知的這些工作都已轉型〉所說，開始有了 “career coach” 這樣的新興職業。³

打著 “career coach” 名號的，在這一兩年，真的如雨後春筍（尤其是在 FB & LinkedIn）。

多試試，無妨；但，請慎選建議。畢竟，自稱 “coach” 者，並不總是 coach。

正派的推薦

其實我真的很鼓勵求職者，在丟出履歷、赴約面試之前，先讀讀一些正派的相關書籍，或尋求正派的諮詢者。畢竟，不是每位面試官都想在緊湊的當下順便兼任求職諮詢。

面試官很累的，別奢想他們都是卞和。請自己打磨出你的亮點。

四處征戰的應徵者也是很累的，我知道。所以，請不要奢想你是當下就能七步成詩感動天地的曹植，請事先就打磨出你的亮點。

之所以會強調「正派」二字，是因為⋯⋯在某些書上看到一些耍小聰明的招數。說實在的，那些小聰明，請不要秀出來～～

書籍

推薦這幾本正派的書。不管是身為面試者還是被面試者，我都從中獲得許多啟發：

對外商或國際化環境感興趣的，除了《2030 轉職地圖》之外，可再參考以下這本：

《外商、大企業求職秘笈》

至於暗黑一點的，就不公開列了。

實體課程

［Disclaimer］以下列的課程，我都沒上過，也沒拿工商服務費，我的信心，純粹根據他們過往發表極有洞見的內容而來。請自行判斷察驗。

大人學：A103 / 履歷優化與個人品牌重塑
獵頭的日常 (Lynn)：完備你的履歷轉職力、提升你的面試潛勝率、專屬你的優勢說明書

至於暗黑一點的，就不公開列了。

詳見〈技術面試的小觀點〉一文。 ↩︎
詳見〈打怪升級路線圖〉一文。 ↩︎
獵頭 S 姐甚至說：「有點沮喪，因為 LinkedIn 都找得到以下這些位置，但在 104 卻用手指頭算得出來，但為什麼大家還是要瘋狂依賴 104？」 ↩︎

2019 個人回顧

Thu, 26 Dec 2019 23:00:00 +0800

年初，告別服務五年的單位，走出舒適圈，歸零，重啟。

如果說 2018 是收攝靜觀的一年，那麼，2019 可謂驚滔駭浪了。做對了一些事，也犯下許多蠢事。

到了年終，又開始要做個總回顧，再對來年許願。去除一些不便揭露的事情，以下是簡單的回顧。

鷹村對幕之內畫的那條線，我要踏過去了。

補血課程

這一年，由於時間問題，參加的補血課程大幅減少。只能精選再精選。

實體課程中，收穫最大的，就屬這場暌違多年經典課程的復刻版：

201a / 專案管理個案實戰 - 利害關係人與需求管理

若要用一句話來描述它，我會說，這是一門回歸本質的課。畢竟，專案的起點，就是目標與限制；而左右目標與限制的最大因素，就是利害關係人與需求管理。擒賊不擒王，後續的種種規劃執行手法只是徒然在失焦的漩渦中打轉。

個案攻防一如往常的燒腦，彷彿把過去幾年幾門課的核心都橫向統整了一輪：101、A101、302、510⋯⋯覆盤檢討，照見許多這陣子刻意練習，但還沒到位之處。

充電，重新得到力量。

201a / 利害關係人與需求管理

除了實體課程，我也嘗試了一些線上課程。不過，截至目前為止，真正 100% 完課，且不時還會回頭複習的，就只有裘凱宇老師的這門課：

【過好人生學】除了熱情，你更需要知道的事

裘凱宇老師主辦的實體講座我參加過幾次了，也有幾本他的書，對他開的線上課程，我是充滿信心的。試聽 30 分鐘，很快就決定參加。

難得有這一系列我不忍心 1.25 倍速快轉的中文音頻。在通勤的捷運車廂，裘老師溫暖療癒的嗓音，猶如及時雨，撫慰了我徬徨的心。

隨著課程進行，我開始正視自己三個老毛病：熱情症候群、堅持妄想症、理想偏執狂，更老老實實照著課程練習，重新扎根四個關鍵能力：

創造結果的能力：聚焦、優化、反饋
建立生態圈的能力：學徒、創造、達人
做決定的能力：期望值、預想最差結果、正確歸因、時間軸思考
創造意義的能力：解決問題、迎向挑戰、投入行動

將近 4 小時的線上音頻課程，猶如一場觀念重塑之旅，對職場生涯本質再一次深思與探索，對我幫助極大。

脫敏

2019 年，到了一間素有敏捷標竿之名的外商。

首當其衝的難關，不是敏捷文化，是商務英語。

聽與說，向來是我的罩門。尤其是遠距 con-call，通訊品質變數叢生，少了現場白板輔助，純以赤裸裸的聽力應付南腔北調，令人不寒而慄。

張瀞仁 (Jill) 在《安靜是種超能力》提到：內向者的能量較易耗盡，需要妥善管理能量。我則是有另一番新體悟：與外國人隔空對話，也是很耗能量的～～～

能量，要如何保護？

我從 Jill 書中看到 “desensitization” 這個看起來很管用的點子：

脫敏是不斷地讓自己暴露在恐懼的事物前，讓大腦中的杏仁核逐漸降低敏感度（譬如讓有懼高症的人常常爬高梯），當然，過程中必須仔細控制恐懼程度。或許光用想的就很可怕，但只要跨出第一步，其他就會漸漸好轉。

我得盡快尋找具體的方法，脫敏自己對於 con-call in English 的恐懼；而且，要先聚焦，精準地脫敏對於技術領域商務英語的 con-call 恐懼。

首先，鎖定這四本核心教材：

尤其是 Clare 介紹的綜效式商英學習法及自學商英教材，乍看之下很蠢，就是傻傻的跟述 (shadow)、朗誦 (recite)、聽寫 (dictate)。

這方法，十幾年前張嘉倩的書有講，郭岱宗的書有講，現在 Clare 的書還是這麼講。而且這方法也非常吻合裘凱宇老師【過好人生學】課程所講的「建立學習反饋機制」要點：小時段、小行為、小實驗、小挑戰。

似拙，實巧。

這麼多人都這麼講了。十年前，我當耳邊風；我再不照著做，再過十年，還是會怨嘆一直原地踏步。傻得願意相信，就對了。

於是，我就這樣老老實實地進行英聽特訓。光是第一周，就感受到在「脫敏」方面有一點效果，大受鼓舞。

要持續下去。

回歸基本功

在外商，異國異地 con-call 開會，已經是一種低情境的溝通了 ¹，使用英語，更是嚴重限縮表達力的頻寬。低情境、低頻寬，顛覆我多年的認知。

簡報尤然。我過去慣常的簡報模式，高度仰賴口語埋哏與鋪陳，快慢交錯的視覺節奏更是拿手好戲。可惜的是，以現在自己的英語口語程度，其實很難支撐得起駕馭得了這種簡報風格。

記得自己簡報風格的轉變關鍵，第一是高橋流，第二是 Prezi，第三是 Keynote。現在，好像遇到第四個轉捩點了。投影片好像應該要更瘦身、更樸素才是⋯⋯

我更發現，為了突破低情境低頻寬的禁錮，不只簡報風格，不只溝通風格，甚至連更基本的職場思維也要轉變。套句裘凱宇老師【過好人生學】課程所講的，我需要踏實走一次「學徒」階段。我得盡快尋得具體的方法，從頭練習職場基本功——我需要學習在低情境、低頻寬處境下更簡潔、更高效的風格，還得具有某種跨文化的通用性。

最後，我鎖定這兩本，重新蹲馬步：

功夫老師：《不懂這些，別想加薪》²
《埃森哲顧問教你６堂回報的話術》

蹲馬步的書：職場基本功

不要被狀似聳動的書名騙了。這兩本書作者都有管顧背景，內容扎實，且相呼應之處甚多。讀到後來，發現，這不僅是話術，更是職場思考的基本功。

譬如說，《不懂這些，別想加薪》介紹的「一分鐘口頭報告」要點，就跟《埃森哲顧問教你６堂回報的話術》介紹的「自我主導說明」形式非常相似。既然英雄所見略同，原理沒問題，就老老實實照著功夫老師交代的方式來做：

接下來便是要勤於練習並運用。你可以將「一分鐘工作進度口頭報告表」和「一分鐘問題現況口頭報告表」兩個表格列印出來隨身攜帶，未來要向主管報告前，依表格中的方式和提醒進行思考，在一分鐘內精準又明快的做好口頭報告。

有時我也會切換成英文來練習：特地從商英教父 Quentin Brand 幾本書尋找對應的罐頭 set phrases，偷學一些得體的應對方法。

如此刻意練習幾個月。沒有 mentor/coach 在側，自承進步緩慢，卻已經開始敏銳看到許多反例的問題。值此，不禁想起《神雕俠侶》中甫遭斷臂之禍，卻別有一番奇遇的楊過：

如此練劍數日，楊過提著重劍時手上已不如先前沉重，擊刺揮掠，漸感得心應手。同時越來越覺以前所學劍術變化太繁，花巧太多，想到獨孤求敗在青石上所留「重劍無鋒，大巧不工」八字，其中境界，遠勝世上諸般最巧妙的劍招。他一面和神雕搏擊，一面凝思劍招的去勢回路，但覺越是平平無奇的劍招，對方越難抗禦。比如挺劍直刺，只要勁力強猛，威力遠比玉女劍法等變幻奇妙的劍招更大。

當晚他竟不安睡，在水中悟得了許多順刺、逆擊、橫削、倒劈的劍理，到這時方始大悟，以此使劍，真是無堅不摧，劍上何必有鋒？

是的，「重劍無鋒，大巧不工」。

本質練習

楊過有神雕幫忙練劍，我沒有。只好私底下設計一些練劍方法與儀式。

譬如說，《埃森哲顧問教你６堂回報的話術》提出兩則思考要點：具體化 (crystallize) 及概述 (summarize)。拿我熟悉的議題小試須臾，驚覺：我以為我知道，但其實我不知道。

該向幾年前的自己看齊，重拾學徒之心，對這些我以為我知道的東西從頭演繹一番。

因此，我在筆記軟體開設【本質練習】專區，不敢說每天，但至少常常拿來重整精煉自己所知的事物。譬如說，以下是我對某些 agile/devops/arch 議題的私房詮釋（這只是截至目前的版本）：

Agile 本質簡述：一種以高速、高頻率 PDCA 循環的角度，處理複雜問題的態度及方法。
Cloud native 本質簡述：An architectural style designed around elasticity and anti-fragility in a massive dynamic environment.
Container 本質簡述：一種將異質性應用程式 & 相依執行環境予以統一封裝的高效率單位與機制 (An efficient packaging unit and mechanism for heterogeneous apps and dependent environment)。
DevOps 本質簡述：Engineering practices & culture to glue dev & ops to evolve a high performing team.
Kubernetes 本質簡述：大規模微服務容器自動化調度的產業標準平臺 (An industry standard platform for orchestrating containerized microservices at scale)。
Microservices 本質簡述：「單一職責介面」與「去中心化」的架構設計風格 (An architecture style based on SRP interface and decentralization)。
Scrum 本質簡述：一種經驗主義式的敏捷實踐流程，擅長高強度操練經驗曲線 (An agile process based on empiricism to train experience curve in a high-intensity style)。

我也常常用心智圖來鋪陳這些具體化的本質概述。近來更體會到，以前一直把心智圖用錯了——心智圖，不是拿來讀的，是拿來畫的。

如此練劍數月，體會到難以言喻的好處。這種本質修練，應該會一直持續下去吧。

敏捷基本功

手持玄鐵重劍，為之四顧，躊躇滿志，忍不住對所見所聞臧否巷議。

譬如說，看到一些敏捷心靈雞湯文章說要換位思考、要 QBQ，就忍不住提出修正觀點：

QBQ 和同理心，誤用，或是無限上綱使用，很容易被歸為資方的洗腦工具。

越來越覺得，欠缺 QBQ，不全然是當事人自己不正面思考、不當責的問題，常常也是結構面造成的。譬如：刺蝟原則。

沒有刺蝟原則，就很難要求 ownership，也就更難要求 QBQ 或同理心。所以，一路溯源，就跟管理界的老生常談搭上線了。

現在，我逐漸傾向：怪罪敏捷之前，先反思：是不是連核心的管理與領導思路都歪掉了呢？或許，那才是基本功呀。

譬如說，看到君婷老師〈為什麼團隊總是對目標無感？〉一文提到：「你的團隊有多麼目標導向，取決於你有多強大的讓團隊精準理解並聚焦目標能力，這需要練習，更需要準備。」就忍不住附和：

這，真的是談 KPI 或更潮的 OKR 之前，就該先磨練的基本功。

基本功沒到位，空談許多炫酷潮詞，是枉然的。

譬如說，看到君婷老師〈到底是誰殺了敏捷？〉一文提到：「相信組織在導入敏捷前，一定花了許多時間與精力說服老闆、克服文化、組織重建、團隊成熟度的問題，但開始正式 run 敏捷之後，卻忘了最重要的利害關係人，其心中最要緊的價值。」又忍不住附和：

熊熊想到去年發表的那張敏捷導入 CLD ³…

起手式，很重要。看懂局與勢，很重要。

多多回到基本原理，勤練基本功吧。

什麼是敏捷的起手式？

像前面擷取的三段短評，其實說穿了，就是老掉牙的 5W1H 當中的 Why + What + Who，就是本篇年度回顧文章一開頭提到的目標與利害關係人兩大要素，敏捷圈甚至早已發展出慣用的 impact mapping 引導手法呢（所以，我的招牌課程【敏捷原理與團隊塑造】第一天下午就是以 impact mapping 進行個案研討）。你，在敏捷鳴槍起跑前，有整個團隊跑過一輪 impact mapping 來對焦嗎？

起手式，很重要。

像這樣在研討會、在社群聚會、在網路採集田野故事，匪夷所思的「敏捷怪現狀」屢見不鮮，卻也多半都能夠以根本原理來解釋。

根本原理，不會因為是老掉牙的老調而不再重要。⁴

（速成班不會講的事）

敏捷失敗，有人怪罪沒有全部跑過規定的 4(+1) 會議，有人怪罪 top down 導入，有人怪罪 bottom up 導入，有人怪罪插單太多，有人怪罪沒有專職 Scrum master，有人怪罪顧問只會嘴砲，有人怪罪文化劣根性或國情不合⋯⋯

真可謂「幸福的敏捷都是相似的，不幸的敏捷則各有各的不幸」呀！

儘管 Scrum 不見得才是最好最適的，但是，田野觀察到業界對於 Scrum 誤解之深，就覺得 Scrum 被玩爛被汙名化，良有已也。

形式與本質都歪得很嚴重。更慘的是，在「守」的階段，賴以捍衛形式與本質的 Scrum master，依然是稀缺資源。

我置身一間素有敏捷標竿之名的外商，得以就近觀察某個新人過半的新產品團隊。我發現，即使有極為優秀的 Scrum master 近乎全程坐鎮，都還需要好幾個 sprints 才看到內化的持續改善跡象，委實難以想像沒有正知見坐鎮的 Scrum，會歪樓到什麼地步。

（守、破、離）

很慶幸自己走過了那些迷惘掙扎期。

試著回到單純的根本原理吧。網路上、文獻上到處都可以找到一些正派的根本原理：Agile Manifesto、Scrum 3 pillars、Scrum 5 values、Modern Agile、systems thinking… 請從任何一組根本原理來審視你們的工作，誠實地。

撇開會議、流程、看板、便利貼、組織、角色等外在形式，回到根本原理，會發現，很多原理是相通的。很多基本原理或基本功，若不扎實，再多新潮的技法，也只是浮沙築高塔。

請撇開外在形式，先拿【過好人生學】課程所講的兩種「優化」思維來重新審視你敏捷之旅的本質吧——洞與痛、笨問題法則：

洞：你的敏捷之旅，是為了獲得什麼利益？
痛：你的敏捷之旅，是為了解除什麼痛苦？
笨問題法則：為什麼一定得如此？如果不這麼做，會怎麼樣？

「有不得機得勢處，其病必於腰腿求之。」

技術基本功

在敏捷成熟度低的地方，挑戰的是變革管理能力。反之，則是基本功的扎實程度。⁵

Scrum Master focus over time (from LeSS)

2019 年，於公於私，我個人的技術主場都是 Kubernetes。追逐 K8s 最新進展，降低 K8s 導入門檻，實驗 K8s 詭譎之處，寫了幾篇文章，帶了幾場 K8s 工作坊 ⁶，給了幾場演講⋯⋯可說一整年都在與 K8s 為伍。

熱鬧的外在，內在卻開始感到某種空虛與不安。

K8s，固然是在 DevOps 與 cloud native 相關領域集其大成的霸主，站在巨人肩膀上，乍看之下可增加一甲子功力。不過，讓我們誠實一點吧：你的功力，真的因此而徒增一甲子了嗎？

譬如說，K8s 發明人之一 Brendan Burns 寫了一本有趣的小書《分散式系統設計：可擴展、可靠服務的樣式和範例》，大量運用 K8s 示範現代分散式系統中重要的泛用模式，是非常精要的 K8s 應用指南。那麼，試問：K8s 用了好一陣子的你，能夠像 Brendan Burns 這樣在 cloud native 領域將 K8s 揮灑自如嗎？

如果不能，那麼，問題出在哪裡呢？

外行與內行的差別 (from 琴之森 Vol 16)

雖然我們常說：不要重複造輪子，但這並不代表，我們連造輪子的能力都不去操練。

與其一直沈迷於熱鬧的 DevOps toolchains，不如回頭重新蹲馬步，回歸扎實的技術本質。

「重劍無鋒，大巧不工。」

蹲馬步的書：軟體架構

似乎不只我有這種想法。我在這次 iT 邦幫忙鐵人賽評審感言中寫下：

這一屆鐵人賽，我提出一則令人欣喜的整體觀察：更多人開始回歸基本功。像〈從 0 至 1 盡可能的建立一個好的系統〉、〈在分散的世界中保持一致〉、〈Think in Domain-Driven Design〉這三篇得獎作品，都是值得好好學習的架構設計教材，連我都從中獲益甚多。

我期待大家在研讀這些精彩作品時，也請試著和他們一樣回歸基本功。每讀懂一個小議題，請自己試著重現作者的思路，自行推導，自行寫程式印證，把基本功重新磨練一次。

這樣子，才不辜負這些作者嘔心瀝血隔空授藝與傳功呀！

洋洋灑灑一堆蹲馬步的書，份量沉重，將是我 2020 的功課。套句裘凱宇老師【過好人生學】課程所講的，重新扎根在這領域「建立生態圈的能力」。

信仰基本功

再來是私領域了。

2019 下半年，經歷了許多實質意義與象徵意義的生老病死，彷彿度過了好幾年。

不過，卻也豐豐富富經歷到我所信的神是真的。

藉著重新修練禱告的功課，帶領我走出曠野。一幕幕猶如連續劇的異象，橫跨數月，令人讚嘆與敬畏。

蹲馬步的書：禱告

在禱告中，一句句經文，猶如活水，湧流不已：

以別神代替耶和華的，他們的愁苦必加增。(詩 16:4)
我們的大祭司並不是不能同情我們的軟弱。(希 4:15)
你們看天空的飛鳥：牠們不撒種，不收割，也不收進倉裡，你們的天父尚且養活牠們；難道你們不比牠們更寶貴嗎？所以不要憂慮，說：「我們該吃甚麼？喝甚麼？穿甚麼？」這些都是教外人所尋求的，你們的天父原知道你們需要這一切。你們要先求他的國和他的義，這一切都必加給你們。所以不要為明天憂慮，因為明天自有明天的憂慮，一天的難處一天當就夠了。 (馬 6:26, 31-34)

這種屬靈經驗，得親身經歷；一旦親身經歷，就再也回不去了。

「不論你信主的時間有多久，都應感受到被更新、改變、鼓舞和激勵。」

傾聽神的聲音，順服，活出旨意中的命定——這是人生信仰的基本功。

在這 Xmas 賜平安意念之日，也該為明年做某些決定了。

最困難的抉擇

2020 許願

2020 年，希望自己能做到：

繼續在信仰裡聆聽與順服。
繼續更深度的本質修練。
繼續增進商務英語聽說能力。
走出蟄伏期。
開放冒險選項。

就醬。

艾琳．梅爾 (Erin Meyer) 說：「在低語境文化中，良好的溝通是精準、簡單、明確和清楚的，以表面意義來了解訊息，也認同應該為了釐清而重說一次，以書面陳述訊息的情況也一樣。在高語境文化中，溝通是複雜、微妙和多層次的，訊息通常是隱含而不直接明說，較少以書面形式提出，大多是開放供人解讀，至於怎麼解讀，要看對言外之意的領悟而定。」她在《文化地圖》書中，針對八個面向的文化量表，有更詳盡的分析：高情境 vs 低情境、直接否定回應 vs 間接否定回應、原理優先 vs 應用優先、平權式 vs 階級、共識 vs 由上而下、任務導向 vs 關係導向、對峙 vs 避免對峙、線性時間 vs 彈性時間。 ↩︎
今年我也交互參考重讀了好幾次劉恭甫（功夫老師）兩本後續的書：《左思右想：36 堂有效解決工作難題的創新思考》及《Ｘ計畫：打造人生黃金交叉線的轉機與關鍵》，獲益良多。 ↩︎
詳見我於 Agile Summit 2018 發表的演講：〈從限制理論角度談敏捷導入階段〉 ↩︎
很多人視 5W1H 為過氣的老調。有趣的是，日本人對於經典的 5W1H 似乎情有獨鍾，出了幾本專書：《5W1H 超強思考術：你的所有問題，都可以靠 5W1H 解決！》、《5W1H 經典思考法：容易獲得成果的人都在用》。 ↩︎
引述 LeSS 的 “Scrum Master focus over time” 觀點：“LeSS adoptions often involve large codebases with lots of archaic and messy legacy code; applying modern practices on them is challenging. The focus on development practices stays high as it will only become harder and harder to improve the teams even further.” ↩︎
2019 年，我帶了幾場【給 RD 的 Kubernetes 初體驗】工作坊，有 GKE 版本，也有 EKS 版本。 ↩︎

技術面試的小觀點

Wed, 04 Dec 2019 22:00:00 +0800

年底，人才流動的旺季。

這陣子，經手一堆履歷，更面試超過十場，深深覺得，若多一點人懂得面試的遊戲規則，甚至更廣義的職場遊戲規則，將是賓主盡歡的美事。

Bryan 說得好：「求職過程投入越多，越能理解這個遊戲規則，也對自己的目標更清晰！」

我們或許都沒有前衛到像 Netflix《給力》那樣「鼓勵員工經常去面試別家公司的工作」，但說實話，多一些面試與被面試的經歷，的確能夠更掌握遊戲規則，也會衝擊到自己原先的浪漫幻想，降低美麗的錯誤，將自己導向更務實的定位。

面試與被面試都經歷過不少的我，想針對這陣子的所見所聞，分享一些個人的觀點。

刷題

以前我對刷題之舉是很不屑一顧的。總覺得這不是每位軟體工程師都需要去嘗試的。

不過，就如同程天縱在〈自己爬上巨人的肩膀：踏入職場的艱辛旅程〉一文對美國軟體研發界的觀察：

在十年前的 2009 年，只要會寫軟體，甚至不需要經驗，學校一畢業就可以很容易的找到工作。

但近十年來，大量中國和印度的留學生來到了美國，專攻互聯網、軟體開發、算法、人工智慧、大數據分析、雲計算等等領域，使得就業競爭越發激烈。尤其川普總統上任以後，緊縮了綠卡和移民的名額，導致美國留學申請的門檻更加提高了。

因此，過去簡單的、走形式的面試問題和技術測試，難度就越來越高了；尤其網路和社群的普及，考過的題目立刻被分享在網上。因此，各個徵才企業就不斷的更新題庫、甚至提高難度。於是，LeetCode 網站上的題目，幾乎都是要去面試的軟體工程師必「做」、必「背」的。

典型的滾雪球軍備競賽，正增強迴路。

甚至像這篇文章所說，不只是近期內打算求職的人會去刷題：

如今在矽谷的每一天，這個「刷題例行工作」，更是許多不論資深或資淺的工程師，在上班時間外的「必做功課」之一。

每天利用時間刷題，連續這樣刷上幾個月到一兩年，在矽谷是司空見慣的：最近我有兩個同事離職去了 Uber，他們在此之前分別刷了一年和整整兩年的考古題目；另一位同事刷了半年的題，進了 Amazon。

這就是美國軟體研發重鎮的遊戲規則。

台灣，雖然還沒有發展出如此激烈的競爭態勢，但相對低薪太久了，優秀人才思遷外流，精明外商也在台設置研發據點就地搶人，導致刷題風氣也開始在某些小圈子裡盛行。像這次 iT 邦幫忙鐵人賽就有兩位以 LeetCode 為主題的得獎者，其中一位甚至還在別處開設線上課程教人 LeetCode 解題呢。

當然啦，刷題網站不只可拿來操練演算法，據我所知，同溫層當中也有些人拿這類刷題素材做為 TDD kata。最有名的例子就是 91 了。

因此，我開始修正對於刷題網站的觀點。我會視情況，用兩種解題心態來看待它們：

Kata 心態。借用刷題素材，熟悉新的程式語言及標準程式庫，或是磨練 TDD 之類的技法。此時的重點在於「型」的固化與內化，不在於演算法的錙銖必較，因此，要有「可能暫時過不了刷題評分系統」的心理準備。
演算法複雜度優化心態。我建議，盡量自我要求，不要驟然追求速解，該用類似 How to Solve It 或 Introduction to Algorithms: A Creative Approach 之類的逐步推演思路，有系統地闡述，才能鍛鍊出通用的解題思路，不至於淪為「背解法」。

（似乎該拿來練一下了⋯⋯）

Kata 心態

Kata 心態，不只是拿來面對刷題素材，更應該拿來用在更廣泛的地方。

尤其是軟體架構。

雖然我們常說：不要重複造輪子，但這並不代表，我們連造輪子的能力都不去操練。

譬如說，當你學到分散式系統、微服務架構時，會不會試著甩開別人包得好好的現成框架，改而像 Andrew 那樣自我練習，從頭開始構築方案？ ¹

有興趣的話，趁這次機會，用簡化過的 POC 環境來練習看看吧！POC 的好處是你可以專注在問題本身，盡可能地排除其他環境或是框架帶來的干擾，讓你專心地思考問題本身該怎麼解決。也只有 POC，你才能有機會觀察到實際測試的統計數據與評分，讓你比較與改善的過程可以更加科學。 — 〈後端工程師必備: 排程任務的處理機制練習〉

譬如說，當你學到最近當紅的 DDD 及 clean architecture，會不會試著甩開別人包得好好的現成框架，改而像這次 iT 邦幫忙鐵人賽的優選作品〈Think in Domain-Driven Design〉那樣，試著從頭開始構築方案？

造輪子的能力，是否曾經刻苦磨練過，在面談時很難隱藏。

身體學會的，誰也帶不走。

行為面談

行為面談法 (behavioral interview) 是許多招募專家推薦的面談策略，搭配 STAR (situation, task, action, result) 問題設計，可以挖掘到很深的層次。²

行為面談，對於「被面談者」來說，挑戰性自不在話下；但是，對於「面試官」來說，也不是很輕鬆的差事。事前的設計要花時間，甚至得客製化；就連面談當下的引導、追溯與記錄，甚至事後的歸納整理與評斷，都非常費神。

這一直困擾著我。

所幸，後來受到《Amazon 的人為什麼這麼厲害？》的啟發，對行為面談法多了些把握。

《Amazon 的人為什麼這麼厲害？》作者佐藤將之是日本亞馬遜創始成員，服務了 15 年。他的現身說法，應該頗具代表性。

本書試著以 Amazon 角度，回答一個關鍵問題：

到了面試的時候，面試官會注意應徵者的哪些特質呢？

用一句話來說，就是對象是否具備「我們的領導力準則」(our leadership principles; OLP) 特質。

很多企業的 vision/mission/values 是寫給華爾街看的。漂亮的話人人會說，怎麼知道是不是玩真的？

Amazon 的做法很有趣：在面試當中察驗。

Amazon 14 OLP

《Amazon 的人為什麼這麼厲害？》解釋 OLP 在面試時扮演吃重的角色：

OLP 也會實際在面試時採用。對亞馬遜來說，徵才面試的目的，是深入探究面試者在過去的工作過程中如何發現 OLP。換句話說，亞馬遜不會只看技能或成績，還會看面試者是否能加速亞馬遜的成長，而重要的判斷基準就是這套領導力準則。

第一關面試會由招募經理進行，人事部也會視情況面試。⋯⋯

負責第二關的面試官，都會事先從招聘經理那裡收到以下請託：「一對一面試時，希望特別針對這個重點提問。」這個重點也是 OLP 中的其中一項。面試官在詳閱履歷表後，便會依照事前收到的要求，思考要發問的問題，與應徵者一對一面試。

具體的 OLP 提問方式，其實就跟行為面談法的精神相同：

亞馬遜的招聘面試非常注重邏輯，應該有不少應徵者在面試過程中覺得「被追問到底」。這是因為在面試過程中，面試官必須具體的詢問「基於什麼樣的想法，做了什麼事，如何成功的⋯⋯」，並將其記錄下來。

不問「這是⋯⋯？」或「是否⋯⋯？」等封閉式問句，而是用 5W1H 來提問。

經常有應徵者在履歷表上過度誇耀自己的實績，這時若能深入發掘：「如何思考，並具體採取了什麼行動？」就能不被對方的職稱所動搖，看出應徵者的實力。

我從這本書學到，要把行為面談法連繫到企業的核心價值觀。

更重要的是，要自己融會出一套，與核心價值聯繫起來的 STAR 架構，不管是面試還是被面試。

譬如說，針對技術領域，我自己發展出一套容易操作的探索察驗程序，並聯想《復仇者聯盟》與四顆無限寶石的情節，以便記憶：

Stones

這需要操練。

以 DevOps 領域為例

口說無憑，就以最近在 DevOps 社群看到的話題為例吧。

在「請問各位在面試 DevOps Engineer 都會問什麼問題」討論串當中，Rick Hwang 提出一則很好的示範：「你過去的經驗，通常用哪一種部署策略？考慮哪些因素？為什麼？怎麼實踐？」不難看出，這已經算是很接近 STAR 精神的行為面談。

我也來稍微示範一下，如何將行為面談法連繫到企業的核心價值觀。

如果我們想聯繫上 OLP 核心價值，該怎麼問呢？

顧客至上：「你過去的經驗，通常用哪一種部署策略？是給哪些人用的？他們對此有什麼看法？你有嘗試過推動其他更好的部署策略嗎？他們對此又有什麼看法？過程中遇到哪些困難？你是如何克服的？」
創新與簡化：「新的部署策略，哪些地方比以前方便，哪些地方反而比以前複雜？當他們抱怨時，你是如何進一步克服這問題的？」
刨根問底：「如果要進行混合雲與多雲的部署，你會怎麼做？」視情況，這議題可以挖得很深很深⋯⋯

如果我們想聯繫上 DevOps 核心價值，該怎麼運用《復仇者聯盟》四顆無限寶石的口訣來提問呢？

Reality：「你過去的經驗，通常用哪一種部署策略？」視現場互動情況，再以 5W1H 角度去蒐集具體事實：what? why? why not? for who? with who? when? how? …
Space：「以你所知，還有哪些部署策略是業界流行的？你為什麼不採用它們？以你所知，在部署策略上，未來的趨勢是？你對它們的評論是？」
Time：「假設有一個像 xxx 這樣的個案，你會如何導入剛剛提到的 yyy 部署策略？」
Mind：「這種導入過程，需要哪些人配合？你會如何說服他們配合？」

運用之妙，存乎一心。這需要操練。

馬拉松

程天縱在〈自己爬上巨人的肩膀：踏入職場的艱辛旅程〉一文提到：

在美國最夢幻的僱主就是「FLAG」四家企業：Facebook 、LinkedIn、Amazon、Google。這四家企業招聘軟體工程師都非常慎重，進入門檻也都非常的高。

這些公司的面試，都要經過四、五輪的電話面試、線上技術測試、視訊面試和測驗，最糟糕的是，時間拖得非常長，前後有長到兩、三個月的。

《Amazon 的人為什麼這麼厲害？》也自嘲：

人力仲介業界常說亞馬遜的招聘面試會「搞死仲介」，因為他們向亞馬遜推薦的人才都很難被錄用，所以常會抱怨：「已經不知道該推薦誰才好了」。只不過，我們的想法是「寧缺勿濫」，內部有招聘優秀人才的基本思維及穩健機制。

第一關面試會由招聘經理進行。⋯⋯

第二關面試可以說很有亞馬遜的風格。首先是人數，最多會從公司內部召集五名面試官，皆為其他部門的管理者階層。這群面試官之中，肯定會包含一位稱為「抬桿者」(bar raiser) ³ 的人物。第二關面試也是一對一，每次約 40~45 分鐘，最多要進行五場。

我並不盲目鼓吹這種過五關斬六將的風格。不過，如果你遇到這樣的機會，請把握，如果這是值得的。

請保持向著標竿直跑的勇氣與耐心吧。

對於軟體架構 kata 感興趣的，請拿 Andrew 的【架構面試題】系列文章來挑戰看看吧！ ↩︎
對於行為面談法 (behavioral interview) 感興趣的，可讀讀知名獵頭 Lynn 所寫的〈【面試的藝術】行為面試，現正進行中〉一文。 ↩︎
「抬桿者」(bar raiser) 是 Amazon 很獨特的用人思維。請參考〈亞馬遜如何挑選人才？〉一文。 ↩︎

Volume Resizing Mechanism in Kubernetes

Wed, 31 Jul 2019 13:00:00 +0800

Non-stop storage scaling (vertical or horizontal scaling) is essential in a data-intensive system, database servers in particular.

Is it possible in Kubernetes?

In Kubernetes v1.11 the persistent volume expansion feature is being promoted to beta and enabled by default.¹ There is also a nontrivial real-world use case for this: Strimzi Kafka operator. Strimzi merely builds on top of existing Kubernetes storage class mechanism to grow the storage of Kafka cluster.² Therefore, the volume resizing feature is not exclusively available for Strimzi and Kafka. You can put this feature into your own application as long as you learn the mechanism.

To get a concrete knowledge of the volume resizing, I’ve conducted a simple experiment on GCP and GKE. The experiment tries to answer the following questions:

Does volume resizing really work in Kubernetes?
Is the resizing process non-stop?
Are data still persistent after resizing?

All experiment materials are available in the vol-resize repo, for your convenience.

About the sample app

A sample app voltest.sh will be used for the whole experiment.³ It displays the size of available disk spaces in the specified mount point (as the 1st argument), and also records the data continuously in the specified output file (as the 2nd argument; default to "data").

Let’s see how it works. Assume that we are in the /home directory, with available disk space about 4.5 GB:

% pwd
/home
%
% df -h
Filesystem      Size  Used Avail Use% Mounted on
overlay          41G   32G  8.2G  80% /
tmpfs            64M     0   64M   0% /dev
tmpfs           848M     0  848M   0% /sys/fs/cgroup
/dev/sda1        41G   32G  8.2G  80% /root
/dev/sdb1       4.8G   38M  4.5G   1% /home
overlayfs       1.0M  160K  864K  16% /etc/ssh/keys
shm              64M     0   64M   0% /dev/shm
overlayfs       1.0M  160K  864K  16% /etc/ssh/ssh_host_dsa_key
tmpfs           848M  736K  847M   1% /run/metrics
tmpfs           848M     0  848M   0% /run/google/devshell

At first run, it shows the space of current directory and records them continuously in the data file within the same directory:

% docker run -it  -v $(pwd):/mnt  williamyeh/voltest  /mnt
---> Checking /mnt/data
1 : 4.5G
2 : 4.5G
3 : 4.5G
4 : 4.5G
5 : 4.5G
6 : 4.5G
7 : 4.5G
8 : 4.5G
9 : 4.5G
10 : 4.5G
11 : 4.5G
12 : 4.5G
^C
%

Interrupt the execution at 12 on purpose, and run again. You’ll see that it picks up the last serial number 12 and continues counting:

% docker run -it  -v $(pwd):/mnt  williamyeh/voltest  /mnt
---> Checking /mnt/data
13 : 4.5G
14 : 4.5G
15 : 4.5G
16 : 4.5G
17 : 4.5G
18 : 4.5G
19 : 4.5G
20 : 4.5G
21 : 4.5G
22 : 4.5G
23 : 4.5G
^C
%

Now the data file should have 23 lines of records:

% cat data
1 : 4.5G
2 : 4.5G
3 : 4.5G
4 : 4.5G
5 : 4.5G
6 : 4.5G
7 : 4.5G
8 : 4.5G
9 : 4.5G
10 : 4.5G
11 : 4.5G
12 : 4.5G
13 : 4.5G
14 : 4.5G
15 : 4.5G
16 : 4.5G
17 : 4.5G
18 : 4.5G
19 : 4.5G
20 : 4.5G
21 : 4.5G
22 : 4.5G
23 : 4.5G
%

In the following experiment we’ll use the app and the data file to answer the 3 questions:

Does volume resizing really work in Kubernetes? Just inspect the disk spaces it displays.
Is the resizing process non-stop? Just inspect the screen output.
Are data still persistent after resizing? Just inspect the content of data file.

Ready?

Experiment part 1: initial size

The experiment is conducted on GCP and GKE. However, it should apply to other cloud Kubernetes platforms as well, with minor modification.

➊ Clone the experiment repo to your workspace or Cloud Shell:

% git clone https://github.com/William-Yeh/vol-resize.git

➋ Prepare a Kubernetes cluster in GKE.

➌ Create a 20GB persistent disk named voltest. For example, the following command will create such a persistent disk in the us-central1-a zone:

% gcloud compute disks create         \
    --size=20GB --zone=us-central1-a  \
    voltest

Check if the underlying persistent disk is created:

➍ We need a storage class with allowVolumeExpansion enabled. The manifest file expansion-ss.yml is provided as follows:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: expansion
parameters:
  type: pd-standard
provisioner: kubernetes.io/gce-pd
allowVolumeExpansion: true
reclaimPolicy: Delete

Create a storage class expansion for this:

% kubectl apply -f expansion-ss.yml

➎ We need a PV manifest file voltest-pv.yml to associate it with the existing persistent disk just created before:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: voltest
spec:
  storageClassName: "expansion"
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 20Gi
  gcePersistentDisk:
    pdName: voltest
    fsType: ext4

Create the persistent volume voltest now:

% kubectl apply -f voltest-pv.yml
persistentvolume/voltest created
% kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
voltest   20Gi       RWO            Retain           Available           expansion               8s

Note that the voltest PV is in “Available” status.

➏ We need a PVC manifest file voltest-pvc.yml to claim the PV:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: voltest
spec:
  volumeName: voltest
  storageClassName: "expansion"
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

Claim the persistent volume now:

% kubectl apply -f voltest-pvc.yml
persistentvolumeclaim/voltest created

% kubectl get pvc
NAME      STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
voltest   Bound    voltest   20Gi       RWO            expansion      11s

% kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM             STORAGECLASS   REASON   AGE
voltest   20Gi       RWO            Retain           Bound    default/voltest   expansion               13m

Note that the voltest PV/PVC pair is in “Bound” status.

➐ We need a manifest file voltest-app.yml for our sample app to access the PV/PVC:

apiVersion: apps/v1
kind: Deployment
...
spec:
  replicas: 1
  ...
  template:   # pod definition
    ...
    spec:
      containers:
        - name: voltest
          image: williamyeh/voltest
          volumeMounts:
            - mountPath: "/mnt"
              name: voltest

      volumes:
        - name: voltest
          persistentVolumeClaim:
            claimName: voltest

Invoke the sample app now:

% kubectl apply -f voltest-app.yml

Open another terminal pane to watch the logs continuously:

% kubectl logs -f deployment/voltest
---> Checking /mnt/data
1 : 20G
2 : 20G
3 : 20G
4 : 20G
5 : 20G
6 : 20G
7 : 20G
8 : 20G
9 : 20G
10 : 20G
11 : 20G
12 : 20G
...

Quite familiar output. Everything works fine.

Keep the logs running. We’ll see it again and again.

Experiment part 2: resizing

Now we’re about to resize the volume.

➊ Edit the voltest PVC:

% kubectl edit pvc/voltest

➋ Change the value of spec.resources.requests.storage from 20Gi to 100Gi. Save, and exit.

➌ Check if the logs are still being generated, and the content of the logs.

➍ Check the size of underlying persistent disk. It should be expanded to 100 GB now.

➎ Check if the PV/PVC are both expanded:

% kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM             STORAGECLASS   REASON   AGE
voltest   100Gi      RWO            Retain           Bound    default/voltest   expansion               45m

% kubectl get pvc
NAME      STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
voltest   Bound    voltest   20Gi       RWO            expansion      32m

PV is expanded to 100 GB, but PVC not yet. In other words, block storage volume is expanded, but file system is not yet. The reason is described in the “Resizing Persistent Volumes using Kubernetes” article:

“Once underlying volume has been expanded by the storage provider, then the PersistentVolume object will reflect the updated size and the PVC will have the FileSystemResizePending condition.”
“File system expansion must be triggered by terminating the pod using the volume […] then pod that uses the PVC can be restarted to finish file system resizing on the node.”

For now the question “2. Is the resizing process non-stop?” should be obviously answered. Let’s move on to handle the FileSystemResizePending condition by restarting the related pods.

Experiment part 3: restart the pod

➊ Kill the pod, and let deployment restart a new pod for us (replicas=1):

% kubectl get pods
NAME                      READY   STATUS    RESTARTS   AGE
voltest-d88ff8c49-66wk2   1/1     Running   0          23m

% kubectl delete pod voltest-d88ff8c49-66wk2

➋ Watch the logs! Our sample app will see the file system expansion progress on the fly:

13465 : 20G
13466 : 20G
13467 : 20G
13468 : 24G
13469 : 30G
13470 : 30G
13471 : 30G
13472 : 30G
13473 : 30G
13474 : 42G
13475 : 77G
13476 : 99G
13477 : 99G
13478 : 99G
13479 : 99G
13480 : 99G
13481 : 99G
13482 : 99G

➌ Check if the PV/PVC are both expanded:

% kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM             STORAGECLASS   REASON   AGE
voltest   100Gi      RWO            Retain           Bound    default/voltest   expansion               57m

% kubectl get pvc
NAME      STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
voltest   Bound    voltest   100Gi      RWO            expansion      44m

For now the remaining questions “1. Does volume resizing really work in Kubernetes?” and “3. Are data still persistent after resizing?” should be obviously answered.

Conclusion

As can be seen in this experiment, all you have to do to grow the PV/PVC are:

Preparation

Use Kubernetes ≥ 1.11.
Set allowVolumeExpansion: true for your storage class, and choose an appropriate underlying provisioner (storage provider).
Use the storage class in your PV and PVC.

Expansion

Increase the PVC spec.resources.requests.storage value.
Restart the related pods.

Kubernetes 1.11 also introduces an alpha feature called online file system expansion. You can track its progress in the Kubernetes CSI Developer Documentation “Volume Expansion”.

You may use the volume resizing feature since Kubernetes 1.11. Read the article published by kubernetes.io in more detail: “Resizing Persistent Volumes using Kubernetes”. ↩︎
To know more about how Strimzi implements the volume resizing for Kafka, read these articles: “Persistent storage improvements” and “Resizing persistent volumes with Strimzi”. ↩︎
The Docker image for this voltest.sh app is available in williamyeh/voltest for your convenience. ↩︎

CKAD (Certified Kubernetes Application Developer) 相關資料

Thu, 11 Jul 2019 17:00:00 +0800

Linux Foundation 旗下的 CNCF (Cloud Native Computing Foundation) 提供兩個與 Kubernetes 相關的個人技術檢定：偏維運的 CKA (Certified Kubernetes Administrator)，以及偏研發的 CKAD (Certified Kubernetes Application Developer)。

其中，CKAD 與我關注的範圍、與我設計的工作坊最接近，便想進一步瞭解它的細節。

CKAD logo

根據官方資料，CKAD 的 curriculum 只有列出檢定考試的主題與比例，並沒有列出具體的應考讀物。目前看到最接近「欽定本」地位的 CKAD 檢定準備教材，就屬 Linux Foundation 製作的 LDF259 線上課程了——全長 35 小時，$299 美金。

不過，是否還有其他選擇？

實惠的線上課程

我在 Udemy 找到一份新台幣 $390 的線上課程 Kubernetes Certified Application Developer (CKAD) with Tests。花十幾分鐘試過它的預覽單元，發現它的內容很扎實，實作練習也很活潑，應該滿適合從實作中學習的人，從過程中發現不足之處，再去找相關資料補強。

即使我對 Kubernetes 已經有一定的掌握程度，也有設計實作教材的能力，但我還是喜歡以它作為配套。

這會是我的 CKAD 首推材料。我建議，即使不購買這份教材，也請花十幾分鐘把它的預覽單元全都走過一遍。

牛刀小試

根據 CKAD 線上考試規定，應考時，不能使用紙張或數位筆記軟體 ¹。因此，這場檢定，很大幅度在考核肌肉記憶，以及 kubernetes.io/docs/ 官方文件查找能力。

既然遊戲規則訂成這樣，我們就該先體驗一下這有多麼殘酷。呵。

我建議，如果你曾經有過一點點 Kubernetes 經驗，此刻，請先去 dgkanatsios/CKAD-exercises 挑戰看看你的肌肉記憶。儘管這不是官方釋出的模擬試題，但牛刀小試一番，接受洗禮，或是打擊，總是好的。

官方文件

經過以上的洗禮，知道自己不足之處，就可以開始啟動特訓之旅。

根據 CKAD 線上考試規定，應考時，你不能向 Google 求助；你能用瀏覽器查找的文件，只有 Kubernetes 官方文件 ²。

因此，請盡快熟悉以下幾個限定的參考資料來源：

也請從現在開始自我要求，不論在其他任何地方看到的資料，都請務必回到以上官方欽定的參考資料所在地，逐一找出可與之對應的關鍵字、章節、語法規格、範例。

這是 CKAD 應考時，你唯一的浮木舟。即使你並未志在 CKAD，這仍然是很好的習慣。

前人經驗

有了以上的心理建設，接下來，就可以用健康心態欣賞一下前人的經驗：

CKAD Exam on Jul 9, 2018.
My Feedback about CKA and CKAD on Jun 4, 2018.
Tips to pass Certified Kubernetes Application Developer (CKAD) exam on Dec 15, 2018.

感謝你花了幾分鐘，讀完由一位沒參加過 CKAD 的人所整理的這篇文章。

CKA/CKAD Candidate Handbook v1.20 提到：“The following resources are forbidden during the exam: Use of devices other than the exam desktop; Notes; Documentation; Notepads (other than what’s provided within the exam browser tab); Course manuals […]” ↩︎
CKA/CKAD Candidate Handbook v1.20 提到：“You are permitted to use your Chrome or Chromium browser to open one additional tab in order to access assets at https://kubernetes.io/docs/ and its subdomain, https://github.com/kubernetes/ and its subdomains, or https://kubernetes.io/blog/. No other tabs may be opened and no other sites may be navigated to. The allowed sites above may contain links that point to external sites. It is the responsibility of the candidate not to click on any links that cause them to navigate to a domain that is not allowed.” ↩︎

Docker File Permissions on Windows

Mon, 24 Jun 2019 12:00:00 +0800

Currently Linux containers are still more popular than Windows containers. And Windows users often need to use Linux containers even from their Windows computers.

Recently I’ve found something very strange about Linux-style file permissions when the Docker images are built from Windows hosts.¹ Therefore, I’ve conducted a suite of test cases to investigate whether file permissions are preserved with Docker & Skaffold toolchains. All experiment materials are available in the container-chmod repo.

% git clone https://github.com/William-Yeh/container-chmod.git

Experiment setting

The experiments are composed of a few files with typical Unix-style file permissions:

.
├── skaffold.yaml
└── src
    ├── Dockerfile
    ├── file-644.txt
    └── script-755.sh

-rw-r--r-- 1 william  70 Jun 24 17:01 Dockerfile
-rw-r--r-- 1 william  57 Jun 24 15:17 file-644.txt
-rwxr-xr-x 1 william  84 Jun 24 15:19 script-755.sh

We will use two ways to build the Linux-container images:

To build image with docker build command (Docker Engine 18.09.2).
To build image with skaffold build command (Skaffold v0.32.0).

And we’ll conduct the experiments in the following environment settings:

Host	Built w/ Docker CLI	Built w/ Skaffold (WSL version)	Built w/ Skaffold (host version)
macOS	➊	N/A	➋
WSL + Docker Desktop for Windows	③	➍	N/A
Windows	⑤	N/A	⑹

Will all experiments display the correct file permissions?

macOS: ➊ ➋

Let’s begin with macOS, which acts as the control group.

Perfect! All Unix-style file permissions are set correctly.

total 20                                                                        
drwxr-xr-x    1 root     root          4096 Jun 24 22:30 .                      
drwxr-xr-x    1 root     root          4096 Jun 24 22:30 ..                     
-rw-r--r--    1 root     root            70 Jun 24 22:18 Dockerfile             
-rw-r--r--    1 root     root            57 Jun 24 22:18 file-644.txt           
-rwxr-xr-x    1 root     root            84 Jun 24 22:18 script-755.sh

WSL: ③ ➍

On Windows, my preference is to use WSL to connect to Docker Desktop for Windows.² Will this combination work well with Unix-style file permissions?

Below are experiments conducted on WSL:

As shown in this demo, the ➍ skaffold experiment works quite well on WSL. The ③ docker-cli experiment works, though not the best-possible Unix-style file permissions:³

SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories.

Pure Windows: ⑤ ⑹

What if a Windows user sticks with pure-Windows toolchains, i.e., use traditional Command Prompt (cmd) to connect to Docker Desktop for Windows?

The ⑤ docker-cli experiment shows the same result as in previous ③ '-rwxr-xr-x' permission:

C:\> docker run -it test-docker                                           
File permission (script-755.sh) should be: 755  rwxr-xr-x              
total 20                                                               
drwxr-xr-x    1 root     root          4096 Jun 25 03:45 .             
drwxr-xr-x    1 root     root          4096 Jun 25 03:45 ..            
-rwxr-xr-x    1 root     root            70 Jun 25 03:44 Dockerfile    
-rwxr-xr-x    1 root     root            57 Jun 24 08:03 file-644.txt  
-rwxr-xr-x    1 root     root            84 Jun 24 08:03 script-755.sh

However, the ⑹ skaffold experiment shows the worst result:

C:\> skaffold-windows-amd64.exe build
Generating tags...
 - test-skaffold -> test-skaffold:dbe377c
Tags generated in 228.0023ms
Starting build...
Found [docker-for-desktop] context, using local docker daemon.
Building [test-skaffold]...
Sending build context to Docker daemon  4.096kB
Step 1/4 : FROM alpine:3.9.4
...


C:\> docker run -it 25997136449a
docker: Error response from daemon: OCI runtime create failed: container_linux.go:344:
starting container process caused "exec: \"/app/script-755.sh\": permission denied": unknown.


C:\> docker run -it 25997136449a  ls -al
total 20
drwxr-xr-x    1 root     root          4096 Jun 25 03:51 .
drwxr-xr-x    1 root     root          4096 Jun 25 03:53 ..
-rw-rw-rw-    1 root     root            70 Jun 25 03:44 Dockerfile
-rw-rw-rw-    1 root     root            57 Jun 24 08:03 file-644.txt
-rw-rw-rw-    1 root     root            84 Jun 24 08:03 script-755.sh

As shown in the demo, Skaffold blindly sets all the file permissions as '-rw-rw-rw-', eliminating the 'x' permission required for the script-755.sh script file.

Conclusion

Different Unix-style file permissions will be generated in the Docker images when building Linux containers with different combination of host operating systems, docker cli, and Skaffold toolchains:

Host	Built w/ Docker CLI	Built w/ Skaffold (WSL version)	Built w/ Skaffold (host version)
macOS	➊	N/A	➋
WSL + Docker Desktop for Windows	③	➍	N/A
Windows	⑤	N/A	⑹

Results:

Best results: ➊ ➋ ➍
Acceptable results: ③ ⑤
Unacceptable results: ⑹

My suggestions for building Linux images are:

If your applications require adequate file permissions (especially the 'x') and you cannot completely control the build toolchains to use, be sure to modify your Dockerfile accordingly.
If you can control the whole toolchains to use (e.g., in the CI/CD pipeline), stick with the Linux ones.

There is also an issue about this in Skaffold: Issue #1470: Permission denied through skaffold ↩︎
See my article “在 Windows 上復刻 Mac 使用習慣”. ↩︎
See thaJeztah’s comment on GitHub about this. ↩︎

Auto-Reload from ConfigMap

Mon, 17 Jun 2019 17:00:00 +0800

My previous article “Inotify in Containers” has demonstrated that when ConfigMap is mounted as directories, any changes in the ConfigMap will propagate to related pods, and can be detected with inotify-like APIs.

A follow-up question might be: what should a well-behaved application react to this trigger accordingly? What if it’s a ill-designed application?

To clarify this I’ve conducted a series of experiments for 3 possible configmap-reloading strategies:

Built-in auto-reloading apps
External signals
Pod rollout

In this article I’m going to explain the experiments and preliminary findings. All experiment materials are available in the configmap-auto-reload repo.

Built-in auto-reloading apps

Some applications (e.g., Traefik) are smart enough to gracefully reload themselves whenever they detect any configuration changes without downtime. Will this work with Kubernetes ConfigMap?

See the traefik-example demo:

Perfect! Traefik auto-reloads itself as long as you correctly mount the traefik-config ConfigMap as /etc/traefik/ directory for the pod. Here’s the related code snippet:

[file]
watch = true
directory = "/etc/traefik/"

External signals

Some applications can reload configurations; but not auto-reload. Instead, they reload their configurations when they are told to do so. For example, when Nginx receives a HUP signal (nginx -s reload) ¹, and when Apache HTTP Server receives a HUP signal (apache -k restart) or USR1 signal (apache -k graceful) ², they will reload new configurations without downtime.

Who should be the HUP signal sender in Kubernetes?

Before Docker and Kubernetes rule the world, there were plenty of such tools, e.g., inotify-tools and Chokidar cli. People used them to watch for changes in specified directories and to invoke dedicated actions accordingly (including sending signals, of course).

Combo trick: Inotifywait + Nginx

Will this combo trick work with Kubernetes ConfigMap?

See the inotifywait-example demo:

Good! Inotifywait detects the changes and sends HUP signals to Nginx as long as you correctly mount the nginx-config ConfigMap as /etc/nginx/ directory for the pod. Here’s the related code snippet:

if [[ "$(inotifywatch -e modify,create,delete,move -t 15 /etc/nginx/ 2>&1)" =~ filename ]]; then
    echo "Try to verify updated nginx config..."
    nginx -t
    if [ $? -ne 0 ]; then
        echo "ERROR: New configuration is invalid!!"
    else
        echo "Reloading nginx with new config..."
        nginx -s reload
    fi
fi;

DISCLAIMER: it’s just for demo; not a robust implementation. For more examples, see ³⁴⁵.

CAUTION: it is against the best practice of “one process per container” policy.⁶ If you really want to use this combo trick, try to model it as “multiple containers within a single pod.”

Pod rollout

Some applications do not have any configuration reloading mechanism. What should we do? Maybe the only reasonable way is to rollout their running instances, and just spawn new ones with the new configurations.

Reloader is a generic solution for Kubernetes. With the help of it, pods can be restarted whenever related ConfigMap has changed.

See the reloader-example:

Perfect! Nginx pods get rolling updated by Reloader as long as you annotate the Nginx deployment with configmap.reloader.stakater.com/reload. Here’s the related code snippet:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  annotations:
    configmap.reloader.stakater.com/reload: "nginx-config"
  ...

Conclusion

If your application is smart enough to gracefully reload itself whenever it detects any configuration changes, it continues working well with ConfigMap in Kubernetes.

If not so smart, an easier approach is to use automatic tools (e.g., Reloader) to rolling update related pods.

I will not recommend the watch+signal approach (e.g., inotify-tools). It is prone to error and zombie processes.

Series of Articles

❶ Inotify in Containers

❷ Containers and Environment Variables

➌ Auto-Reload from ConfigMap

Nginx official document: Controlling nginx ↩︎
Apache official document: Stopping and Restarting Apache HTTP Server ↩︎
An implementation worth studying: https://github.com/rosskukulinski/nginx-kubernetes-reload ↩︎
Q&A in Stack Overflow: Nginx Reload Configuration Best Practice ↩︎
https://github.com/telephone/nginx-watch ↩︎
Best practices for building containers. ↩︎

Containers and Environment Variables

Mon, 17 Jun 2019 14:00:00 +0800

My previous article “Inotify in Containers” has demonstrated that when ConfigMap is mounted as directories, any changes in the ConfigMap will propagate to related pods.

A follow-up question might be: what if the ConfigMap is mounted as environment variables?

Some said that the answer is NO in Kubernetes¹; even in the old Docker world². Therefore, I’d like to begin with a simple experiment to try to answer the question: After a container starts, will it see any changes of environment variables?

The experiment material is available at https://github.com/William-Yeh/container-and-env , and here’s a simple demo:

It is obvious in the demo that the changes of environment variables will not affect already-running processes inside the containers — let alone pods in the Kubernetes world.

To simply put, if you want ConfigMap to propagate its changes to related pods, mount the ConfigMap as directories, not environment variables.

Series of Articles

❶ Inotify in Containers

❷ Containers and Environment Variables

➌ Auto-Reload from ConfigMap

An analysis of ConfigMap hot-reload can be found in the article by Jimmy Song: “ConfigMap 的热更新”. ↩︎
A good Q&A in Stack Overflow: Reload configuration when env variable has changed. ↩︎

Inotify in Containers

Mon, 10 Jun 2019 18:00:00 +0800

It is usually necessary to watch for any changes in file systems, both in development and in production modes. For example, in the development mode Webpack can watch files and recompile whenever they change; in the production mode Consul Template can watch runtime configs and invoke specific applications whenever they change.

These are well-known scenarios in traditional pre-container world. How about the container world? Do they behave the same in the new container world?

I’ve occasionally found that something behave differently in the container world. To clarify this I’ve conducted a series of experiments. In this article I’m going to explain the experiments and preliminary findings. All experiment materials are available in the fswatch repo.

Experiment setting

I’ve divided the experiments into 4 groups.

Group A (experiment 1 to 3) is the traditional native mode: run native apps in their native host operating systems, respectively. This is considered as the control group.
Group B (experiment 4 to 6) is the Linux container mode: run the same containerized Linux app in 3 different host operating systems.
Group C (experiment 7) is the Windows container mode: run the containerized Windows app in the Windows operating system.
Group D (experiment 8) is the Kubernetes mode: run the containerized Linux app in Kubernetes.

Host OS	App run asnative app	App run asLinux Container	App run asWindows Container	‖	App run inK8s (Linux Container)
Linux	1	4	N/A	‖	8
Mac	2	5	N/A
Windows	3	6 (LCOW)	7 (WCOW)

Group A: native mode

Let’s start with the native mode as the control group. We’ll see how it works in the traditional world of Linux, Mac, and Windows.

To make life easier, I’m using the fsnotify library to unify a variety of underlying operating system APIs (e.g., inotify in Linux, kqueue in macOS, and ReadDirectoryChangesW in Windows). Statically-linked binaries for the 3 platforms are generated with the Go compiler 1.12.5:

2,943,200 (bytes) fswatch-linux-x86_64
2,861,360 (bytes) fswatch-mac
2,914,304 (bytes) fswatch-x86_64.exe

These experiments are easy to try by yourself. Take experiment 1 “run native Linux app in Linux host OS” for example:

In this group, changes in the file system can be tracked successfully by their native API mechanisms, respectively.

Group B and C: container mode

Containers make things a little bit complicated.

TL;DR: The LCOW version doesn’t work well.

When there’s a mismatch between host OS and container, inotify may not work well.

Take experiment 6 (LCOW) “run containerized Linux app in Windows host OS” for example. The document for Docker Desktop for Windows has a warning for us:

Inotify on shared drives does not work

Currently, inotify does not work on Docker Desktop for Windows. This becomes evident, for example, when an application needs to read/write to a container across a mounted drive. Instead of relying on filesystem inotify, we recommend using polling features for your framework or programming language.

For Windows users, inotify works well in the WCOW mode (experiment 7).

On the other hand, Mac users are luckier. Docker Desktop for Mac doesn’t have much trouble here (experiment 5) thanks to excellent implementation of osxfs. See “File system sharing (osxfs)” and “Performance tuning for volume mounts (shared filesystems)” articles for more information.

File system events

Most inotify events are supported in bind mounts, and likely dnotify and fanotify (though they have not been tested) are also supported. This means that file system events from macOS are sent into containers and trigger any listening processes there.

Group D: K8s mode

How about Kubernetes? Does inotify work well with the ConfigMap?

Below is the demo for experiment 8:

As you can see in this demo, any changes in the ConfigMap will propagate to related pods in a couple of seconds, and inotify will detect this event as well. ¹

Caution about symbolic links

In such situation, however, you should use inotify to watch for directories instead of merely for files. It is because Kubernetes may use symbolic links to point to versioned ConfigMap volumes, and inotify doesn’t work well with such symbolic links. ²

Let’s retry the demo, but this time we’ll focus on the directory layout from the pod’s point of view.

The demo from 0:38 to 1:55 shows the directory layout from the pod’s point of view:

/mnt/site # ls -al
total 12
drwxrwxrwx    3 root  root   4096 Jun 12 06:19 .
drwxr-xr-x    1 root  root   4096 Jun 12 06:19 ..
drwxr-xr-x    2 root  root   4096 Jun 12 06:19 ..2019_06_12_06_19_15.187277003
lrwxrwxrwx    1 root  root     31 Jun 12 06:19 ..data -> ..2019_06_12_06_19_15.187277003
lrwxrwxrwx    1 root  root     15 Jun 12 06:19 main.css -> ..data/main.css

Simply put, things go well if you’re inside the pod and watch for /mnt/site directory, but may not go well if you try to watch for a specific file /mnt/site/main.css since it is internally a symbolic link managed by Kubernetes.

Conclusion

The inotify mechanism works in the container and Kubernetes world, except for the LCOW case.

If such a feature is needed in the LCOW setting, maybe you have to seek another workaround workflow; e.g., put inotify mechanism outside the container, and propagate the event explicitly into the containers if any. This is exactly what Skaffold is doing.

Also note that inotify works better when ConfigMap is mounted as directories, rather than as merely files.

Series of Articles

❶ Inotify in Containers

❷ Containers and Environment Variables

➌ Auto-Reload from ConfigMap

Another analysis of ConfigMap hot-reload can be found in the article by Jimmy Song: “ConfigMap 的热更新”. ↩︎
Use INotify to watch a file with multiple symlinks ↩︎

Kubernetes 的入門認知與導入策略

Fri, 17 May 2019 12:00:00 +0800

前天我在 2019 台灣雲端大會帶了兩個場次，一個是現場實作場次，一個是經驗分享演講：

Lab / 給 RD 的 Kubernetes 初體驗 (90 minutes)
Speech / 當 .NET 遇到 Kubernetes (30 minutes)

兩個場次，一言以蔽之，都圍繞在 Kubernetes 的入門認知與導入策略上。

以「問題解決」角度看 Kubernetes 導入

〈當 .NET 遇到 Kubernetes〉這場演講，是以「問題解決」的角度，探討導入 Kubernetes 的困難與策略，尤其是針對 .NET 族群。

整場演講的脈絡如下：

① 為什麼要導入 Kubernetes？

我們的現況是什麼？
外面的世界已經是什麼樣子？
不正視差距，會有什麼影響？

② 為什麼還不導入 Kubernetes？

我嘗試用法格行為模型 (B=MAP) 來歸類問題原因：

Motivation / 我們真的認識 Kubernetes 真實的利益是什麼嗎？
Ability / 正確認識技術核心、外在因素、內在因素，才能正確評估我們的技術能力是否已經提升到足以擁抱 Kubernetes 的地步。
Prompt / 是否有臨門一腳的驅動力？

③ 有什麼建議的導入選項？

我發現 Prajakta Joshi 的演講 “Strategies for Bringing Kubernetes, Istio, Traffic Director, and Envoy to Brownfield with Walmart, Google, Tetrate” ¹ 已經給了很好的建議。因此，我引述她的論點，建議大家可以採用兩種路徑：(a) Container first and mesh next，(b) Mesh first and container next。

我這場演講有開放錄影。等上線了，我會再補上連結。

RD 也需要略懂 Kubernetes

Kubernetes 是目前雲端環境的顯學。可是，傳統的程式，並不是原封不動搬上去，就能夠自動享受 Kubernetes 所宣稱的種種好處。新的環境，不僅需要新的 Ops 思維，也需要新的 Dev 思維。

我設計〈給 RD 的 Kubernetes 初體驗〉工作坊，嘗試以一個半小時的時間，從軟體研發者的角度，探討軟體的設計該做哪些最起碼的改變，並從實作中體驗 Kubernetes 引進的新觀念及新效益。

我希望能夠讓學員從實例中體驗，傳統 web 應用程式在搬上 Kubernetes 時，可能會經歷哪些架構面的調整，才能享受新架構的效益。

我試圖不只是 demo，也不只是讓大家能無腦照著做，還試圖進行一些觀念講解。短短一個半小時，野心太大，只好割捨原本已經準備好的 API Gateway 例子 ²，集中在以下課題：

容器化
微服務
組態管理
多重環境管理：本機端與雲端（以 GKE 為例）

範例程式也以疊代演進的形式，逐步添加 Kubernetes 功能，呼應〈當 .NET 遇到 Kubernetes〉演講所提出的 “Container first and mesh next” 導入策略。

Container:

1.0: Extracted from Microsoft Docs.
2.0: Dockerize the app with simple Dockerfile and docker-compose.yml.
3.0: Separate frontend and backend into 2 distinct containers.

Kubernetes:

4.0: Support Kubernetes (locally).
4.1: Use Kubernetes dashboard.
5.0: Support ConfigMap and naming convention.

Cloud（感謝上官林傑大力支援 Google Cloud 的 redeem coupon）：

6.0: Support Kubernetes on the cloud (GKE for example).
7.0: Support canary release.

可惜，一個半小時的時間還是太短了，最後面 30 分鐘其實是在趕進度，跳過了一些原本應該仔細講解的環節（譬如：ConfigMap、label & selector、ephemeral vs static external IP 的區分⋯⋯）。我再考慮另外找個社群的場子，辦一次較完整的 workshop 吧。完整的，應該會需要 2.5～3 小時。

2019-06-16 補充

一個月後，應 GCPUG Taipei 之邀，我辦了一場 3+1 小時的 Workshop，投影片及實作範例都有更新。

希望這一場演講，一場實作工作坊，對大家有助益。

我在〈Next ’19 的 Istio 場次重點摘要〉一文中，有介紹 Prajakta Joshi 在 Google Cloud Next ’19 另一場精彩的演講。 ↩︎
關於 Kubernetes 的 API gateway，請參考〈Nginx Ingress 與 Ambassador 簡易性能比較〉一文。 ↩︎

Next '19 的 Istio 場次重點摘要

Fri, 19 Apr 2019 23:00:00 +0800

四月 9–11 日去舊金山參加 Google Cloud 的 Next ’19 大會，收穫頗大。

這場大會，同一時段就有近 30 場專題演講同時進行，議程滿滿，勢必得做取捨。基於工作需要及個人興趣，我主要選擇與容器相關的場次：service mesh、Windows containers、混合雲、資安實務。

我發現，光是這些場次，就得花很大力氣去消化、實驗與應用。

我們這些所謂的「台港團」會在 GCPUG Taipei 舉辦一場分享會。因為自己不克參加，便以這篇文章，針對我鎖定的核心議題：Istio，做一番重點摘要，以饗讀者。

以下內容，不完全按照 Next ’19 的議程時間順序，而是依照我主觀的排列。

看完後，對於 Istio 應該就有不錯的全面認知了。

漸進式導入 Istio

很有意思的演講，很適合作為 Istio 入門。

【演講】Incrementally Adopting Istio 【重點摘要】

3:20 - 微服務面臨的挑戰。
6:18 - Istio 的 control plane 三大元件，就是設計來一一對應這些問題的。
10:38 - Istio 的 telemetry 機制。
11:42 - Istio 的 traffic 管理機制。
15:10 - Istio 的 security 機制。
16:27 - 在 GKE 安裝 Istio 的方法及使用建議。
19:11 - 接下來就是一系列的漸進式示範。

Istio 的 Traffic：宏觀角度

在 Istio + Envoy 體系中，是透過 control plane 的 Pilot 元件及 xDS 協定，去管理 data plane 的 Envoy 網路流量。

以此為基礎，Google Cloud 推出 Traffic Director 服務，用統一的 control plane、透過同樣的 xDSv2 API，去管理 GCP 能觸及的 GKE、GCE，甚至自建的 Kubernetes cluster；也藉此處理 GCP 之專屬特性。

某種意義上，可以把 Traffic Director 視為將 Istio 的 Pilot 元件託管給 Google Cloud。

這場演講，儘管旨在廣告宣傳 Google 自家的 Traffic Director 服務，但講員之一 Prajakta Joshi 非常厲害，對於一般性的 service mesh 觀念也介紹得非常生動。

這一場值得全程觀看。我僅摘錄部分重點。

【演講】Traffic Director and Envoy-Based L7 ILB for Production-Grade Service Mesh and Istio 【重點摘要】

1:21 - 很中肯的觀點：將 service mesh 視為 “SDN for services”。
4:45 - Istio 簡介。
5:48 - 介紹 Istio 的 Pilot 流量管理議題。
6:40 - 正式介紹 Traffic Director。
14:45 - Live demo: global load balancing。
23:45 - 介紹 service mesh 流量控制的特色：“change traffic flow without changing code”，以及 traffic splitting、traffic steering、fault injection、mirroring (shadowing)、load balancing、circuit breaking、outlier detection 等高檔特性。
29:39 - Live demo: traffic splitting。
35:37 - 預告 Traffic Director 的產品路線圖。
42:56 - 某客戶的 monolith 階段性轉型經驗。

講員 Prajakta Joshi 另一場演講 “Strategies for Bringing Kubernetes, Istio, Traffic Director, and Envoy to Brownfield with Walmart, Google, Tetrate” 也很棒，可惜並未釋出投影片及錄影。精彩內容，就留在我的手機相簿裡面啦。

Istio 的 Traffic：實踐角度

我聽了 Megan O’Keefe 兩場硬底子的演講。

第一場演講，以大量實例現場展示 Istio 的 traffic rules。

【演講】Istio in Production: Day 2 Traffic Routing 【重點摘要】

2:18 - Istio 與 Envoy 簡介。
9:13 - Live demo: rollout。
13:45 - Live demo: content-based routing。
16:48 - Live demo: circuit breaking。
20:46 - Live demo: chaos testing。
24:48 - Live demo: ingress and egress。
36:26 - Istio 1.1 現況。
37:18 - Istio 導入建議：“start slow and incrementally”。
38:36 - Istio 還能夠做什麼？

第二場演講，就更硬碰硬的處理 Istio 每天都可能遇到的幾個實踐問題，以及如何查找問題、解決問題的過程。三段 live demo，涵蓋 Istio control plane 的三大元件：Pilot、Mixer、Citadel，非常扎實。

【演講】Debugging Istio: How to Fix a Broken Service Mesh 【重點摘要】

0:35 - Service mesh 是要解決甚麼問題？Istio 的 control plane 就是設計來一一對應這些問題的。
2:54 - 可是，Istio 又會連帶引入哪些複雜度？
4:46 - Live demo: traffic management.
20:47 - Live demo: telemetry.
27:58 - Live demo: security.
44:23 - 除錯工具推薦清單。

這兩場 Megan O’Keefe 的演講，雖然硬底子，卻十分具體，可操作性高，值得全程觀看。

從 SRE 角度看 Istio

這一場，只能說，非常非常非常精彩。

對於讀過 Google 的 SRE 一書的人來說，看到 SLO、error budget 之類的觀念，居然可以在 Istio 上面如此實現，真是大開眼界。

【演講】Understanding SLOs and Error Budgets With Istio 【重點摘要】

1:40 - SLI/SLO/SLA 基本觀念。
7:41 - “uptime” 的新觀點。
9:04 - 將 error budget 視為 “amount of SLOs you can spend”。
13:49 - Live demo!
28:02 - 客戶證言：Schlumberger 公司。

把 VM 也帶進 Service Mesh

Service mesh 並不是容器的專利；古老的 VM 其實也可以納入治理體系。

透過 Istio 的 mesh expansion 機制，VM 只要安裝 node agent 及 Envoy proxy，即可登記為 Kubernetes/Istio cluster 的 service entry 資源，進行 service discovery 等互動。

【演講】Istio Service Mesh for VM Native 【重點摘要】

8:00 - 介紹 Istio 的 mesh expansion 機制。
11:04 - 具體步驟。
13:23 - Live demo!

Windows Containers

自從 3 月底 Kubernetes 1.14 宣布正式支援 Windows 之後¹，我就很期待到 Next ’19 現場眼見為憑。

這一場值得全程觀看。我僅摘錄部分重點。

【演講】Windows Containers in Google Kubernetes Engine 【重點摘要】

7:50 - “I have a dream…”
12:15 - Windows host OS and base image requirements
17:23 - Which to containerize?
22:14 - Kubernetes 1.14 stable supports Windows containers and Windows Server 2019
25:44 - Limitations for Windows containers (for now)
28:16 - GKE “is working on supporting Windows containers” (preview now)
30:40 - Live demo!
37:00 - Early Access Program (EAP)

API 視角

不管你想在容器化、微服務、service mesh 路線走到多遠，「API 管理」一直都是需要持續關注的一環。

針對這議題，Next ’19 是以 Apigee 為主軸²，分別介紹 Apigee 如何與 service mesh 和 serverless 技術搭配運用。

【演講】APIs, Microservices, and the Service Mesh 【重點摘要】

3:21 - 介紹 mTLS。
7:06 - 用 Istio 在 control plane 層次確保 mTLS 之類的 policy。
12:47 - 介紹 service mesh 時代的 API 管理架構。
33:09 - 什麼時候才需要 service mesh？

【演講】API Management for Serverless and Multi-Cloud 【重點摘要】

13:35 - 示範 Cloud Run 與 Apigee。
24:15 - 示範 Cloud Functions 與 Apigee。

這麼多乾貨，值得花點力氣好好消化。

投影片

2019-07-02 補充

兩個月後，應 GCPUG Taipei 之邀，我還是在 Meetup #48 給了一場分享。投影片在此：

Kubernetes 1.14: Production-level support for Windows Nodes, Kubectl Updates, Persistent Local Volumes GA ↩︎
Apigee 於 2016 年被 Google 併購。詳見〈Google 以 6.25 億美元收購 Apigee，強化 API 管理服務〉一文。 ↩︎

在 WSL 裡使用 Ansible + Vagrant

Thu, 18 Apr 2019 23:00:00 +0800

既然要開始在 Windows 上沿用 Mac 及 Unix 的命令列工具習慣¹，免不了要處理 Ansible 及 Vagrant。

雖然這兩個軟體都有對應的 Windows 版本，但據我以前的經驗，卡卡的，有許多小地雷；畢竟這些發跡自泛 Unix 家族的軟體，不是那麼容易無縫移植到對命令列不友善的 Windows 家族。

如今 Windows 已經有 WSL (Windows Subsystem for Linux) 機制，是否可以更無痛享用 Ansible 及 Vagrant 呢？

可以的。

大體而言，我們會兵分二路：

在 Windows 上，會安裝 VirtualBox。
在 WSL 上，會安裝 Vagrant 及 Ansible。

虛擬機選項一：VirtualBox

用慣 Mac 或 Linux 的人，可能會想沿用 VirtualBox 虛擬機軟體。畢竟 VirtualBox 是同屬開源生態系的一員，和其他開源軟體的相容性最高。

你可以直接去官方網站下載安裝檔（VirtualBox 本體，以及 VirtualBox Extension Pack），或是直接透過 Chocolatey 套件管理工具來安裝：

C:\> choco install virtualbox

安裝完後，還有一關要克服。

一般來說，在同一個 host OS 上，同一時間，只能有一個底層虛擬機制存在（除非有像「巢狀虛擬化」之類的黑魔法……吧？）。因此，VirtualBox 無法與 Windows 官方欽定的 Hyper-V 機制同時並存，一山不容二虎²。

如果決定要使用 VirtualBox，請用管理者權限執行以下命令，暫時關閉 Hyper-V 功能³：

C:> dism.exe /Online /Disable-Feature:Microsoft-Hyper-V

C:> bcdedit /set hypervisorlaunchtype off

這麼做的缺點是：由於 Docker Desktop for Windows 會用到 Hyper-V 機制，所以，關閉了 Hyper-V，等於是關閉了 Docker Desktop 的使用權。如果稍後還想使用 Docker Desktop，就得手動恢復 Hyper-V 功能：

C:> dism.exe /Online /Enable-Feature:Microsoft-Hyper-V-All

C:> bcdedit /set hypervisorlaunchtype auto

你可能需要在 Hyper-V 與 VirtualBox 模式之間來回切換，也需要重新開機。

虛擬機選項二：Hyper-V

在 Windows 上面玩 VirtualBox 這麼麻煩，換成 Hyper-V 會不會比較省事？

很可惜，我在 “Hyper-V Administrators” 這一關觸礁了。嘗試一些可能的解法⁴，都無效。

真的有需要時，再回來研究吧。

Vagrant

直接比照 Linux 安裝 Vagrant 的方法。

請在 WSL 底下，直接去官方網站下載安裝檔，或是用 Apt 之類的套件管理系統來安裝。

安裝完畢，請根據官方網站的建議設定環境變數。尤其是 VAGRANT_WSL_ENABLE_WINDOWS_ACCESS 這一項：

export VAGRANT_WSL_ENABLE_WINDOWS_ACCESS="1"

Ansible

直接比照 Linux 安裝 Ansible 的方法。

請在 WSL 底下，照著官方網站的安裝步驟來執行。譬如說，在 Debian/Ubuntu 系列下，可以用 Apt 套件管理系統來安裝。

Ansible + Vagrant

現在，試試看把 Ansible 和 Vagrant 結合起來！

先準備好 Vagrantfile 檔案：

Vagrant.configure(2) do |config|
  config.vm.box = "bento/ubuntu-18.04"

  config.vm.network "forwarded_port", guest: 80, host: 8080

  config.vm.provision "ansible" do |ansible|
     ansible.compatibility_mode = "2.0"
     #ansible.verbose = "vvv"
     ansible.playbook = "playbook.yml"
     ansible.become = true
  end

end

還有 Ansible 的 playbook.yml 檔案：

- hosts: all
  become: true
  tasks:
    - name: install nginx
      apt: name=nginx state=present update_cache=yes

試著啟動看看：

% vagrant up

如果一切順利，你可以在 http://localhost:8080/ 看到 Nginx 歡迎畫面。

在 Docker + Kubernetes 時代，用到 Ansible 的機會愈來愈少了，Vagrant 更是如此；不過，保有這種工具，在處理還來不及跟上腳步的舊系統仍然很管用。因此，花一點功夫湊出堪用的組合，希望能有順手的 WSL 環境。

這段故事，詳見〈在 Windows 上復刻 Mac 使用習慣〉一文。 ↩︎
技術上來說，Hyper-V 是屬於 type-1 hypervisor，VirtualBox 是屬於 type-2 hypervisor。詳見維基百科 “Hypervisor” 條目。 ↩︎
在 Windows 上關閉 Hyper-V 機制，請參考以下文章：“(Solved) VT-x is Not Available (verr_vmx_no_vmx) in Windows 10 – but Available for Oracle VirtualBox”、〈Win10 10月更新 VirtualBox VT-x is not available (VERR_VMX_NO_VMX). 解决〉、“[Solved] VT-x is not available (VERR_VMX_NO_VMX)”。 ↩︎
當 Vagrant 在使用 Hyper-V 時，會出現 “Hyper-V Administrators” 權限問題。我嘗試以下幾篇文章，可惜仍未解決：“Vagrant issue #378”、“Allowing non-Administrators to control Hyper-V–Updated”、“Getting Homestead to play nice with Hyper-V”。 ↩︎

WSLtty + tmux 組合技

Wed, 17 Apr 2019 22:00:00 +0800

在 Windows 10 上面使用 WSL 已經一個月了¹。小狀況也就罷了，但 Cmder 不夠穩定的顯示邏輯卻最讓我頭痛，在視窗尺寸變化時，無法正確處理字元位置。更令人費解的是，即使是其他狀似更華麗（也更耗資源）的替代方案，也仍然有這些問題²。

既然酷炫的終端機競品問題多多，乾脆回歸極簡的 WSLtty³，並混搭 tmux⁴ 來彌補。可惜，畢竟是組合技，無法完全複製 Mac 的 iTerm2 使用經驗。

此事古難全。

WSLtty 剪貼簿

在 X Window 或 Mac 的終端機，只要按下滑鼠右鍵就能夠 paste 文字。如果在 WSLtty 上也想這麼玩，請在 %APPDATA%\wsltty\config 設定檔加上這一行：

RightClickAction=paste

Tmux 與 zsh

啟動 tmux 時，似乎並不會根據 /etc/passwd 的資訊來喚起自訂的 shell，而是一律喚起 bash。

解決方法是，在 ~/.tmux.conf 加上這一行：

set-option -g default-shell /bin/zsh

Tmux 的 pane

用慣 iTerm2 的我，對 tmux 的 pane 功能不太習慣。

譬如說，在 tmux 新增 pane 或 window 時，不會自動帶入目前的目錄 $PWD，而是一律帶入 $HOME，很不方便。Tmux 預設的組合鍵 <prefix> % 及 <prefix> " 難記又難按，也很令人頭痛。

因此，我綜合多人的做法⁵，解決目錄問題，換成好記好按的組合鍵，更可用方向鍵來切換 pane：

# Create new window (tab) with current path
unbind c
bind -n M-t new-window -c '#{pane_current_path}'  # mimic for iTerm2 habit

# Split panes with current path
# @see https://unix.stackexchange.com/a/247449
unbind '"'
unbind '%'
bind -n M-d split-window -h -c '#{pane_current_path}'  # Split panes horizontal
bind -n M-D split-window -v -c '#{pane_current_path}'  # Split panes vertically

# Switch panes using Alt-arrow without prefix
bind -n M-Left  select-pane -L
bind -n M-Right select-pane -R
bind -n M-Up    select-pane -U
bind -n M-Down  select-pane -D

Tmux Plugin Manager

Tmux 設定太多了，就有人寫了外掛管理系統 Tmux Plugin Manager。雖然目前我還用不到，但還是先安裝，以備不時之需。

首先，下載 TPM：

% git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm

將以下幾行加到 .tmux.conf 最後面：

# List of plugins
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-sensible'

# Initialize TMUX plugin manager
# (keep this line at the very bottom of tmux.conf)
run -b '~/.tmux/plugins/tpm/tpm'

Tmux 還有很多高段的功能，以後有需要再研究吧。

如此這般拼湊起來，雖然還不能完全複刻 Mac 的 iTerm2 使用經驗，但也已經算是可以接受了。當然啦，私心還是希望 Cmder 或 Hyper 能夠好好解決顯示問題，就不必動用 tmux 了。

這段故事，詳見〈在 Windows 上復刻 Mac 使用習慣〉一文。 ↩︎
關於其他更華麗，卻也更耗資源的 Windows 終端機方案，可參考這幾篇介紹文章：〈在 Windows 上面用 WSL 优雅开发〉、“ConEmu vs Hyper vs Terminus vs MobaXTerm Terminator vs Ubuntu WSL”。 ↩︎
關於 WSLtty，可參考保哥的〈介紹好用工具：WSLtty (Mintty as a terminal for WSL)〉一文。 ↩︎
關於 tmux，可參考這幾篇介紹文章：〈tmux ，不只是 terminal multiplexer〉、〈tmux 快速入門筆記〉、〈終端機 session 管理神器 — tmux〉。 ↩︎
Shubham 提供的做法，可讓新開的 pane 及 window 保持在目前所在的目錄。Ham Vocke 的文章也介紹幾種有趣的 tmux 設定。 ↩︎

給 RD 的 Kubernetes 初體驗

Tue, 02 Apr 2019 16:00:00 +0800

活動名稱：給 RD 的 Kubernetes 初體驗

時間：2019-05-15 (三) / 11:00–12:30

會議：台灣雲端大會 (Cloud Edge Summit 2019)

課程簡介

Kubernetes 是目前雲端環境的顯學。可是，傳統的程式，並不是原封不動搬上去，就能夠自動享受 Kubernetes 所宣稱的種種好處。

新的環境，不僅需要新的 Ops 思維，也需要新的 Dev 思維。我們將以一個半小時的時間，從軟體研發者的角度，探討軟體的設計該做哪些最起碼的改變，從實作中體驗 Kubernetes 引進的新觀念及新效益。

課程目標

從實例中體驗，傳統 web 應用程式在搬上 Kubernetes 時，可能會經歷哪些架構面的調整，才能享受新架構的效益：

容器化
微服務
組態管理
API gateway
多重環境管理：本機端與雲端（以 GKE 為例）

課程架構

主題	內容簡介	類型	時間(分)
1. 基本觀念	快速介紹 Kubernetes 基本觀念	簡報介紹	10
2. 本機端實作	移植 web 軟體至本機端 Kubernetes	實機操作	50
3. 雲端實作	將 Kubernetes 成果送上雲端	實機操作	20
4. 總結	Kubernetes 微服務要點總結	簡報介紹	10

注意事項

學員能力要求

須具備簡單的 Web 前後端觀念。
須具備 Docker、Docker Compose、git 基本操作能力。

學員需知

請先在自備筆電中安裝 Docker Desktop，並開啟其中的 Kubernetes 功能。
本課程有一部分實作活動會使用 Google Kubernetes Engine (GKE) 及 Container Registry (GCR) 服務。為了讓現場體驗活動順暢，請學員事先申請好 Google Cloud Platform 帳號，並自主練習約 45 分鐘的 “A Tour of Qwiklabs and the Google Cloud Platform” 免費活動，確保你在來到活動現場之前，就已熟悉 Google Cloud Shell 的操作環境。
本實機操作課程由【Google Developers 贊助】。如果你是第一次用 GCP account 或還在 Free Trial 期間內，請繼續用 Free Trial 來操作；如果你已經是正式的 account，活動現場將提供你足夠額度的 coupon 來使用。

Nginx Ingress 與 Ambassador 簡易性能比較

Fri, 29 Mar 2019 23:00:00 +0800

API gateway 是微服務環境，甚至 service mesh 的要角 ¹。

在 Kubernetes 上面，API gateway 選項眾多。有像 HAProxy 及 Nginx 這些石器時代老傢伙跨足過來，也有打從一開始就走 cloud native 路線的後起之秀。

該如何選擇？

根據 Steven Acreman 寫的 Ingress 評比文章的看法：

The safest choice is ingress-nginx. This is the one that most people use and it’s extremely reliable. Before you begin I’d recommend you read this blog to get ahead of some of the problems you may encounter.

My vote for the coolest ingress definitely goes to Ambassador. If you’re just running standard http based micro services and fancy living on the bleeding edge then you should definitely get Istio, Ambassador and Jaeger setup as a proof of concept.

進一步研讀 Ambassador 相關資料 ²，發現他們鎖定的 service mesh 路線很合我的胃口，站在 Envoy 巨人肩膀上更是聰明。不過，理論歸理論，我想親自試試看現在的 Ambassador 是否堪當大任？

初步，我只先拿 ingress-nginx 這個所謂的 “the safest choice” 作簡單的性能比較。將來有機會再進行更徹底的 chaos monkey 測試。

實驗環境

為了簡化實驗步驟，我直接採用 Google Cloud Platform 的 GKE。

Kubernetes 版本：1.11.7-gke.12
Node：2 台 n1-standard-1

我選用的標靶軟體是 hello-app，分別用以下兩種 API gateway 來對外提供服務介面：

Nginx ingress 版本：0.23.0
Ambassador 版本：0.52.0

最後，我利用 boom 進行簡單的壓力測試。

Nginx ingress

為了簡單起見，我直接套用以下這份 Qwiklabs 的全部步驟：

GSP181 - NGINX Ingress Controller on Google Kubernetes Engine

照著做完後，Nginx ingress 會在 GKE 開放一個公開的 http 服務存取點。

我們可以先用 kubectl get services 查看 API gateway 的 public IP 位址。假設是 35.222.12.84 的話，這個服務路徑則是 http://35.222.12.84/hello/。

Ambassador

首先，仿造前面的 Qwiklabs 步驟，在 GKE 上建立起相同規模的 k8s cluster。也執行一份 hello-app service。

為了安裝 Ambassador，我們需要開啟 GKE 權限：

% kubectl create clusterrolebinding my-cluster-admin-binding  \
    --clusterrole=cluster-admin  \
    --user=$(gcloud info --format="value(config.account)")

接下來，就是正常的 Ambassador 安裝步驟：

% kubectl create -f http://bit.ly/2UmsPuE

此刻，我們終於可以透過 Ambassador，替 hello-app 設定 API gateway 規則：

% kubectl create -f https://bit.ly/2YyZzjO

照著做完後，Ambassador 會在 GKE 開放一個公開的 http 服務存取點。

我們可以先用 kubectl get services 查看 API gateway 的 public IP 位址。假設是 35.224.99.169 的話，這個服務路徑則是 http://35.224.99.169/hello2/。

簡單的壓測

為了簡單起見，我在 GCP 的 Cloud Shell 進行壓測。我會對 Nginx ingress 及 Ambassador 兩種情況，各送出一萬個 API 存取要求。

針對 Nginx ingress 的情況進行測試：

% docker run --rm  williamyeh/boom  \
    -n 10000 -c 100  http://35.222.12.84/hello/

Summary:
  Total:        16.2312 secs
  Slowest:      0.3252 secs
  Fastest:      0.1568 secs
  Average:      0.1616 secs
  Requests/sec: 616.0963
  Total data:   660000 bytes
  Size/request: 66 bytes

Status code distribution:
  [200] 10000 responses

Response time histogram:
  0.157 [1]     |
  0.174 [9803]  |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  0.190 [96]    |
  0.207 [0]     |
  0.224 [0]     |
  0.241 [0]     |
  0.258 [0]     |
  0.275 [0]     |
  0.292 [0]     |
  0.308 [0]     |
  0.325 [100]   |

Latency distribution:
  10% in 0.1576 secs
  25% in 0.1583 secs
  50% in 0.1593 secs
  75% in 0.1608 secs
  90% in 0.1632 secs
  95% in 0.1661 secs
  99% in 0.3152 secs

針對 Ambassador 的情況進行測試：

% docker run --rm  williamyeh/boom  \
    -n 10000 -c 100  http://35.224.99.169/hello2/

Summary:
  Total:        16.8132 secs
  Slowest:      0.3857 secs
  Fastest:      0.1571 secs
  Average:      0.1662 secs
  Requests/sec: 594.7715
  Total data:   660000 bytes
  Size/request: 66 bytes

Status code distribution:
  [200] 10000 responses

Response time histogram:
  0.157 [1]     |
  0.180 [9595]  |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  0.203 [304]   |∎
  0.226 [0]     |
  0.249 [0]     |
  0.271 [0]     |
  0.294 [0]     |
  0.317 [0]     |
  0.340 [0]     |
  0.363 [8]     |
  0.386 [92]    |

Latency distribution:
  10% in 0.1596 secs
  25% in 0.1607 secs
  50% in 0.1623 secs
  75% in 0.1656 secs
  90% in 0.1717 secs
  95% in 0.1786 secs
  99% in 0.3596 secs

儘管不夠嚴謹，但仍可以約略看出 Ambassador 的性能已經逼近 Nginx ingress。以才兩歲半的 Envoy ³、才滿兩歲的 Ambassador ⁴ 來說，已經很不容易了。

這是一個值得開始嘗試的好物。

對於 API gateway 來龍去脈感興趣的，可參考 Ricky 的文章〈Overview API Gateway〉、Andrew 的文章〈架構師觀點 - 轉移到微服務架構的經驗分享 (Part 3)〉。 ↩︎
對於 Ambassador 早期發展歷程感興趣的，可參考他們寫的這兩篇文章：“Building Ambassador, an Open Source API Gateway on Kubernetes and Envoy” 及 “Kubernetes Ingress 101: NodePort, Load Balancers, and Ingress Controllers”。 ↩︎
Envoy 1.0.0 版發布日期為 2016 年 9 月。 ↩︎
Ambassador 0.1.3 版發布日期為 2017 年 3 月。 ↩︎

在 Windows 上復刻 Mac 使用習慣

Thu, 14 Mar 2019 08:00:00 +0800

改用 Mac 已經六年了。現在要再回頭碰 Windows，還真有點不習慣。

這年頭，許多軟體其實都有 Mac 及 Windows 版了：Chrome、Firefox、Slack、Evernote、Dropbox、VSCode……最大的差別，應該是終端機命令列工具。

上古時代，需要靠 Cygwin 或 MinGW 方案，才能勉強湊出一點點 Unix 的命令列感覺，但地雷超級多，難以作為嚴肅用途。後來，到了 2015 年，從保哥那邊知道有 Cmder 這個好物 ¹，微軟又於 2016 年推出 WSL (Windows Subsystem for Linux) 機制，Windows 這邊似乎出現曙光，對 Unix 命令列愛好者展現出久違的吸引力。

為了在 Windows 10 上面復刻我的 Mac 的體驗：iTerm2 + Zsh + Oh My ZSH，我試了幾天，把步驟整理如下。

WSL

請根據保哥的文章〈介紹好用工具：WSL (Windows Subsystem for Linux)〉進行以下步驟：

安裝 WSL。
安裝一個 Linux distribution。
第一次執行 WSL，並設定 Linux 的帳號密碼。

Zsh + Oh My ZSH

在 WSL 中安裝 zsh 及 oh-my-zsh：

% sudo apt-get install zsh

% sudo sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

將 zsh 設為內定 shell：

% chsh -s $(which zsh)

如果你的 zsh theme 含有許多特殊的符號字元，請順便安裝 Powerline 系列字型。

Cmder

Cmder 有「完整版」及「迷你版」兩種安裝方式。有了 WSL 之後，msysgit 可以退場，因此，我們只需安裝 Cmder 迷你版。

用 Chocolatey 套件管理工具安裝比較簡單：

C:\> choco install cmdermini

細節請見 https://chocolatey.org/packages/cmdermini 。

整合 Cmder 與 WSL

為了讓 Cmder 以 WSL + Zsh 模式啟動，我們需要新增一個 Cmder 的 “Startup / Tasks”。

譬如說，我們可新增一個名叫 {WSL::zsh} 的 task，將 command 寫成：

set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -C~ -cur_console:p:t:"zsh" -t zsh -l

新增 Cmder 啟動設定

存檔完畢，以後只要以 {WSL::zsh} 模式啟動，Cmder 就會自動套用 WSL + zsh 組態。

進一步的設定細節，請參考 https://conemu.github.io/en/BashOnWindows.html 一文。

設定 Cmder 熱鍵

為了復刻出類似 Mac + iTerm2 的使用習慣，我會花一些時間調整 Cmder 熱鍵設定。請參考保哥的文章〈介紹好用工具：Cmder (具有 Linux 溫度的 Windows 命令提示字元工具)〉進行熱鍵設定。

在 Windows 與 WSL 之間進行複製貼上的剪貼簿操作時，常會遇到換行問題。此時我也會順便將 Ctrl-V 組合鍵的 “Paste mode #2” 設定成 “Multi lines” ²：

調整 Cmder 剪貼簿的換行處理方式

檔案系統

我習慣將 Windows 的 D: 作為文件儲存專用區。

預設情況下，WSL 會將 D: 掛載在 /mnt/d，檔案系統則是 DrvFs：

% mount -l
rootfs on / type lxfs (rw,noatime)
none on /dev type tmpfs (rw,noatime,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,gid=5,mode=620)
none on /run type tmpfs (rw,nosuid,noexec,noatime,mode=755)
none on /run/lock type tmpfs (rw,nosuid,nodev,noexec,noatime)
none on /run/shm type tmpfs (rw,nosuid,nodev,noatime)
none on /run/user type tmpfs (rw,nosuid,nodev,noexec,noatime,mode=755) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noatime)
D: on /mnt/d type drvfs (rw,noatime,uid=1000,gid=1000,case=off)
C: on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,case=off)

不過，因為某些複雜的原因 ³，我們必須重新設定 /mnt/d 的 mount 參數，才能讓 Linux 的檔案讀寫權限正常運作。

我們先卸載 /mnt/d，再用夾帶 metadata 的方式重新掛載它：

% sudo umount /mnt/d

% sudo mount -t drvfs D: /mnt/d -o metadata,uid=1000,gid=1000,umask=22,fmask=111

先查看是否成功:

% mount -l
rootfs on / type lxfs (rw,noatime)
none on /dev type tmpfs (rw,noatime,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,gid=5,mode=620)
none on /run type tmpfs (rw,nosuid,noexec,noatime,mode=755)
none on /run/lock type tmpfs (rw,nosuid,nodev,noexec,noatime)
none on /run/shm type tmpfs (rw,nosuid,nodev,noatime)
none on /run/user type tmpfs (rw,nosuid,nodev,noexec,noatime,mode=755) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noatime)
D: on /mnt/d type drvfs (rw,relatime,uid=1000,gid=1000,umask=22,fmask=111,metadata,case=off)
C: on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,case=off)

如果成功了，請記得將這設定寫進 /etc/fstab 裡面，下次 WSL 啟動時就會自動生效：

D: /mnt/d drvfs rw,relatime,uid=1000,gid=1000,metadata,umask=22,fmask=111 0 0

Docker 與 Kubernetes

雖然保哥的文章推薦在 WSL 裡的 Linux 再安裝一份 Docker engine ⁴，但我比較傾向不要。我比較傾向共用既有資源，讓 WSL 直接連接到 Docker Desktop for Windows 身上。畢竟，在同一台電腦上，要維護兩套 Docker engine，太累了。

我參考上官林傑的文章〈在 Windows Subsystem for Linux (WSL) 下使用 Windows 上的 Docker Engine〉，做好必要的設定，但省略文中提到的 alias 步驟（稍後會說明為什麼）。簡單來說，請先進行這三步驟：

打開 Docker Desktop for Windows 的 “Expose daemon on tcp://localhost:2375 without TLS.” 選項。
在 WSL 裡設定 DOCKER_HOST 環境變數： export DOCKER_HOST="tcp://localhost:2375"
在 WSL 裡 sudo visudo 以下環境變數： Defaults env_keep += "DOCKER_HOST"

上述文章建議透過 alias docker=docker.exe 的方式來使用 Docker Desktop for Windows 的 docker client。不過，這些 alias 未必都能在 script 中展開 ⁵ ——有鬆綁的方法，但我不喜歡破例。我比較傾向在 WSL 裡用簡單的 wrapper script 來處理。

首先是 /usr/local/bin/docker 檔案：

#!/bin/bash

# allow WSL to have access to Docker Desktop for Windows
exec  "/mnt/c/Program Files/Docker/Docker/resources/bin/docker.exe"  "$@"

其次是 /usr/local/bin/docker-compose 檔案：

#!/bin/bash

# allow WSL to have access to Docker Desktop for Windows
exec  "/mnt/c/Program Files/Docker/Docker/resources/bin/docker-compose.exe"  "$@"

別忘記打開它們的 'x' 權限：

% sudo chmod a+x  /usr/local/bin/docker  /usr/local/bin/docker-compose

也別忘了，要將 Windows 上面的 Kubernetes 設定連接過來：

% ln -s /mnt/c/Users/xxx/.kube/config ~/.kube/config

好了，現在已經復刻一部分 Mac 的使用習慣了。是該要好好享受一下這種混血環境了。

2019-04-17 後續發展

使用了一個月，不太能夠忍受 Cmder 不夠穩定的顯示邏輯：在視窗尺寸變化時，無法正確處理字元位置。因此，我改用〈WSLtty + tmux 組合技〉。

2023-02-06 後續發展

四年來 WSL 與容器世界都起了一些變化，本文有些內容已經不敷使用。請改用〈WSL2 + Podman + K3s 組合技〉。

保哥於 2015 年九月舉辦過【打造一個具有 Linux 溫度的 Windows 命令提示字元工具】線上講座，也寫了〈介紹好用工具：Cmder〉一文。 ↩︎
Cmder 的剪貼簿設定細節，請見 https://conemu.github.io/en/SettingsPaste.html 。 ↩︎
關於 WSL DrvFs 的 metadata 權限設定細節，請參考這三篇文章：“Chmod/Chown WSL Improvements”、“Going Overboard with WSL metadata”、〈WSL 配置指北：打造 Windows 最强命令行〉。 ↩︎
保哥的文章〈我的 Windows Subsystem for Linux (WSL) 終極開發人員配置 - 2018 版〉。 ↩︎
Bash 的行為是：“Aliases are not expanded when the shell is not interactive, unless…”，請參考 “Why doesn’t my Bash script recognize aliases?” 這類文章。 ↩︎

Kubernetes Best Practices 資料

Mon, 25 Feb 2019 12:00:00 +0800

Kubernetes 演化速度令人驚訝。彈性之大，令人聯想到當年 Perl 圈子奉為圭臬的 TIMTOWTDI 口號。

選擇過多也會帶來問題。發展到某個階段，也該適時沈澱收斂出較佳的實務建議準則。

因此，我稍微搜尋一下相關資料，作為參考。

（這應該會是一份需要常常更新的文件）

整體建議

Kubernetes Best Practices by Daz Wilkin
Kubernetes Application Operator Basics by Michael Hausenblas

資源設定建議

Configuration Best Practices by Kubernetes
9 Best Practices and Examples for Working with Kubernetes Labels by Hasham Haider
Recommended Labels by Kubernetes
Kubernetes Namespaces: use cases and insights by Mike Altarace & Daz Wilkin

套件管理建議

The Chart Best Practices Guide by Helm

資安建議

Kubernetes Security Best-Practices by Peter Benjamin
9 Kubernetes Security Best Practices Everyone Must Follow by CNCF
101 More Security Best Practices for Kubernetes by Adrian Goins

技術領導者微培訓

Sat, 19 Jan 2019 10:00:00 +0800

最近，我們研發組織有幅度不算小的變動，某些技術人會被要求承擔更多的技術領導責任。

不過，正如溫伯格大師在《領導者，該想什麼？》所說，技術人常會面臨天人交戰：

儘管學校教育告訴我說，每一個好公民都應該負起領導責任，但痛苦經歷讓我害怕擔任任何領導者的角色。我學會盡可能推卻成為領導者的機會。面對領導的問題，我常假裝它是不存在的。為保證我永遠不會涉及到需要運用領導技能的場合，我選擇電腦軟體作為我的職業。

事情發展非我所願。每當我在所負責的技術性工作上有出色表現時，同事就知道要對我更加尊敬，似乎把我當成他們的領導者。沒有人勉強我當領導者，是我自己陷入這樣一個矛盾的情境。

為了讓過渡階段更順暢，雖然我在這裡只剩下很短的時間能夠幫忙了，但還是想略盡棉薄之力。

以下是我的【技術領導者微培訓】企劃案。

培訓目標

引述《領導者，該想什麼？》第一章的列表，只要你對以下課題感到疑惑，這本書、這門課，對你應該都會有些幫助：

領導者真的那麼愚蠢嗎？有時他們的確給人那種印象嗎？
我能成為領導者，但不要像一般領導者那樣嗎？
我能一面當領導者，一面繼續提升我的技術能力嗎？
一個毫無技術背景的人，有可能在技術界成為領導者嗎？
一旦成為領導者，我必須犧牲多少技術專業能力？
我能得到多少回報？
如果我是領導者，我需要擺出上司架式，對屬下頤指氣使嗎？
我能藉由讀書習得領導技能嗎？
我還可以從何處學習成為領導者呢？
為何人們視我為領導者，而我卻不認為自己是領導者呢？
為何我自認為很能幹，人們卻不把我當成領導者呢？
倘若我不想承擔領導責任，又如何？
到底什麼是領導？

這本書、這門課，沒辦法讓你一夕之間脫胎換骨，但能給你經過證實可行的方向。能獲得多少，端看你認真投入的程度、誠實面對自己的態度、敏銳觀察及切實反思的職場人紀律。

如果他們的態度不夠嚴謹，那麼我建議他們做的任何事情，都是在浪費我的時間。 (p. 122)

Becoming a Technical Leader

進度

請依照指定進度，先自行想辦法閱讀指定讀物《領導者，該想什麼？》，並填寫學習單。

第一週／領導概說

閱讀進度：第一章～第五章。

學習單：

準備一張清單，列舉說明哪些情境因為你的出現，使得他人的生產力因而「提升」。請準備另一張清單，列舉說明哪些情境因為你的出現，使得他人的生產力因而「下降」。你能找出這兩類情境的差異之處，並能分辨出它們的特色嗎？列出這張清單，能讓你更認識自己，及更認識讓你獲得授權的環境嗎？ (pp. 41–42)
根據前一個問題所準備的兩張清單內容來看，你是所屬團體的資產還是負債？ (p. 42)
你帶一組人做事，用什麼方法促使成員從不同角度檢討目前執行情形？獨自一人做事時，你又用什麼方法自我檢討？有任何途徑可幫助你改善目前自我檢討的方法嗎？ (p. 68)
下一次帶一組人執行任務，列出你在行使領導技能時所做的所有事情。若未能列出至少十件事，請你再做一遍該任務，一直做到為了完成一個任務，至少要做十件有助於領導的事。列出此份清單後，試著將它們依瞭解問題、控制點子的流通、維持品質分門別類。分類後，能看得出你的領導風格傾向於其中一類嗎？你做的哪些事無法歸類到這三類？ (p. 68)
你多久沒有登上一個新的高原期了？你還在享受目前位於高原期的好日子嗎？為順利攀登下一個高原期，你做了哪些準備？ (p. 82)
你上一次針對職業生涯做重大改變，到現在有多久的時間了？在整個過程中，令你印象最深刻的事情或感受是什麼？ (p. 97)
最近一次你熟識的人做了重大職業改變，你的反應為何？你有沒有藉此機會想到自身處境？ (p. 97)

第二週／創新

閱讀進度：第六章～第九章。

學習單：

至少閱讀一本你所景仰人物的自傳。在日記裡寫下該自傳中最讓你感到驚訝的事，以及最讓你感動的情節。 (p. 129)
你想出很多點子，後來怎麼樣了？大多數都實現了嗎？有多少點子因為創新程度不夠而胎死腹中？有多少點子因為環境不支援而被迫消失？領導不當或領導能力不足，是你犯該錯誤的主因嗎？何種訓練有助於提升你在上述案例行使領導技能的品質？ (改編合併自 p. 140 & p. 141)
你是否讓成功的事實變成繼續前進的絆腳石？如果你超越了目前的成就，哪些東西會跟著改變？你會怎麼做？ (p. 156)
你記得職業生涯中最淒慘的一段經歷嗎？你難以承受的是什麼？你如何從人生的最低潮走出來？你學到了什麼功課？再遇到人生低潮時，你會用不同方式處理嗎？ (p. 156)
和他人打交道時，他們瞭解你的動機嗎？你希望他們瞭解你的動機嗎？你如何確認他們是否瞭解你的動機？ (p. 156)
畫出你的事業線。可能的話，找一位或多位朋友分享你的經歷，和他們討論你的人生起伏。記得將事業線延伸到未來。設想它是一部電影或一部小說，你會取什麼樣的名字？你希望由何人擔任這部電影的主角？ (p. 156)

第三週／動機

閱讀進度：第十章～第十五章。

學習單：

試著回想你最近做過的一些蠢事。別人發現你做了那些蠢事，你作何反應？在追求攀登職涯高峰的過程中，你的自我防禦心理越來越重或越來越輕？對於你採取的自我防禦作為，你如何處置它們？ (p. 174)
你曾否將事務置於人之上，現在你後悔了？你曾否將人置於事務之上，現在你後悔了？ (p. 187)
玩遊戲的時候，你對得分較有興趣，還是對遊戲本身較有興趣？玩團隊遊戲的時候，你對團隊的得分較在意？還是對自己的得分較在意？這兩種心態，如何影響你貢獻力量於團隊，對於團隊成績有何影響？如果是團隊工作呢？ (p. 225)
你是否曾在某團隊中毫無貢獻？當你察覺到這一點時，你的感受是什麼？ (p. 239)
回憶最近一次你進行力量交易遭逢失敗的事例。你從這次交易中學到什麼？你能否以現在的新觀點從那件事再學習？ (p. 239)
哪些在你內心運作的事，你努力不顯現於外？你知道其中運作的情形嗎？如果你將這些精力用在別處，結果將如何？ (p. 239)

第四週／組織

閱讀進度：第十六章～第十九章。

學習單：

在目前的工作環境裡，你擁有幾種不同的力量？你如何將這些力量轉換為更有效用的型態？你如何運用轉換得來的力量？ (p. 252)
如果你在團隊中擔任決策者，你如何判知自己表現良好？你是否紀錄決策內容，並在事後檢視？你是否詢問團隊成員，這項決策對他們有何影響？如果你沒問，原因是什麼？ (p. 264)
你是否因組織缺乏效率受獎勵？或給予缺乏效率的組織獎勵？你能否創造一個相反的工作環境？ (p. 273)
列一張清單，寫出你可以觀察並實驗組織運作的各個機會。再列一張清單，寫出你可以觀察並實驗，但你未加以利用的各個機會。你能否從第二張清單中挑出一個項目，找出未利用的原因，然後清除？ (p. 284)
回想一下你是否有下述經驗：全力以赴的時候，卻被認為沒有盡力。當時你有何感受？你是否為自己辯護？結果如何？ (p. 285)
回想某次，你認為某人沒有做出貢獻的情況。你是否能解讀為，在那種情況下，他已經盡力而為？當時那個人試圖解決什麼問題？下次再發生類似狀況時，你能否找出原因？ (p. 285)

第五週／轉變

閱讀進度：第二十章～第二十四章。

學習單：

上次新主管上任時，你首先注意到他哪一點？你花多少時間才信任這位新主管？他的哪一項動作獲得你的信任？哪一項動作減少你的信任？你積極和新主管配合，還是奮力和新主管作對？為什麼？ (p. 299)
如果你預先知道你將接受某項考驗，你的情緒反應如何？如果你突然發現自己將接受考驗，你的情緒反應又是如何？兩者有何不同？是否有可以相互借鏡之處？ (p. 311)
你的工作環境是否有持續發生的衝突？你能否想出三種改變組織的方式，以避免這些衝突？或是三種改變人際關係的方式？哪一種型態適合你發揮長處？哪一種型態你運作起來較順手？ (p. 311)
你能否舉出三位同事，能給予你技術能力方面的指導？如果你想不出來，你為什麼還在這家公司上班？如果你有三位老師，你如何善用這項資源？ (p. 321)
這一年來，你參加過哪些課程、讀過哪些書？這些對於你的技術能力和領導能力有何助益？你從中是否能學得更多？未來一年，你計畫參加哪些課程、讀哪些書？你應該做哪些事前準備，以獲益更多？ (p. 322)
你能否忍受無所事事的時間？你是否有時間審視你的周遭，審視你自己，以找出沒有更多時間的原因？為什麼沒有充裕的時間？如果確實沒有時間，請停止閱讀，開始檢討。 (p. 331)
檢視你的個人支援網絡的成員名單。哪些人你願意維持良好關係，以繼續獲得支援？這份名單在哪個部分顯得不足，必須加以補強？ (p. 343)

上課前

瀏覽學習單。
速讀：每一份指定讀物，請在不超過 2 小時之內速讀完畢第一次。
填寫學習單。
如有時間，可再回頭重讀細讀內容。

上課時

攜帶學習單。
以 liberating structures 及互動討論方式，進行個案研討。

有些個案討論有隱私性考量，為促成坦誠討論，參與者需宣誓對現場討論內容保密 (咦)。

全部課程結束後

從頭再看一次過去寫的學習單。這陣子，你有什麼改變了嗎？
從《領導者，該想什麼？》書中不時可看出，溫伯格受到薩提爾的影響很深。請再讀讀《激發員工潛力的薩提爾教練模式》及《薩提爾的對話練習》兩本書，以進一步了解如何在職場上運用薩提爾模式。或者，直接去上薩提爾課程吧！

年假可讀的軟體領域輕讀物

Thu, 17 Jan 2019 15:00:00 +0800

中午時，非 RD 的同事請我推薦適合泛軟體產業從業人員的五份輕讀物，可在春節連續假期時好好補血。

年假，自然不方便啃太過於生硬艱澀、理論宏偉的讀物。我挑選這五份輕讀物：四本書，一組網路系列文章。敘事風格親切，高潮迭起，應該可以帶來不少啟發。

IT 實境小說

《鳳凰專案》，體會一下研發、維運、行銷、安控、財務等部門相互掣肘的慘劇，以及如何以 DevOps「三步工作法」來解決的戲劇性發展。

你還沒有達到解決專案可交付成果、故障處理、審計合規等問題所需要的那種對工作的理解程度。在你對工作的內涵有更好的理解之前，任何關於控制工作的討論都會讓你茫然無措。正所謂：夏蟲不可語冰。

敏捷神話

《Scrum：用一半的時間做兩倍的事》，不要被聳動的書名騙了，這是本不吹牛不浮誇的好書。這本由 Scrum 發明人之一 Jeff Sutherland 所寫的書，揭露 Scrum 發展過程中的軼事。讀了之後，你會領會更多 Scrum 規則背後的精神。

我在書中提及，Scrum 源自於豐田生產系統，以及空戰的 OODA 循環。你會在接下來的內容中看到，從開發價格實惠、每加侖汽油能跑一百哩的車子，到協助美國聯邦調查局 (FBI) 建立 21 世紀的資料庫系統，任何東西都可以用 Scrum 來打造。

跨出框架，需要練習

《Pepper 開發者從 0 到 1 的創新工作法》，讓不是創業家、自由工作者、研究者的平凡上班族，也能習得具體的創新做法。你可以看到開發出 Pepper 人型機器人的 Kaname Hayashi，是如何有紀律地自我要求刻意練習。

從 0 到 1 需要的不是「才能」，而是「練習」。

外國月亮

《給力》，軟體／媒體科技業巨頭 Netflix 獨一無二的企業文化，但不要驟下「國情不合」的結論。多讀幾次，試著感受適度的低情境 (low context)、直接否定 (direct negative feedback)、平權式領導 (egalitarian) 風格有什麼殊勝之處。

留住員工、使員工高度投入的方法，應該是招募對此計劃興趣濃厚、且傾向在同一工作待上很長時間的人才，而不是靠著提供他們四種加味水及設置員工睡眠艙來留住他們。

是技術，也是藝術

這原本是【主管的修練】讀書會的輔助讀物，但單獨抽出來閱讀，也行。

系列文 / 專案管理的藝術

過完年，再來一場討論會吧。

補充

好友 91 (Joey) 隨後也發表了另一份春節期間的推薦讀物。分成三大類：① 輕讀物，② 重一點，需要系列性連串看完的書，③ 想趁著連假，消化一下大部頭的書。

意者，請去看看那份清單。

Scrum 與《從 A 到 A+》

Fri, 11 Jan 2019 08:00:00 +0800

最近重新溫習近二十年的老書《從 A 到 A+》，啟發頗多。

《從 A 到 A+》作者們的實證研究方法很嚴謹 ¹。他們從 1965～1995 年名列 Fortune 500 的企業名單中，挑選「十五年累計股票報酬率」超越股市整體表現三倍以上，且不受產業循環影響的企業，研究這些績優公司從「優秀」到「卓越」的關鍵因素。最後，作者們提出「飛輪效應」來統一解釋他們的發現：

飛輪效應

某方面來說，軟體研發圈講究的 Scrum，還滿符合《從 A 到 A+》所講的飛輪效應。

飛輪的比喻

《從 A 到 A+》第八章如此說明飛輪的比喻：

無論最後的結果是多麽戲劇化，「從優秀到卓越」的轉型過程都絕非一蹴可幾。優秀公司躍升為卓越企業，靠的是累積的努力——腳踏實地一步一步，一個行動接著一個行動，一個決定接著一個決定，一圈接著一圈的轉動飛輪，點點滴滴累積起來，終於達到了持久不墜的非凡績效。

「從優秀到卓越」的公司，和對照公司一樣，都會面臨華爾街要求短期績效的壓力。然而和對照公司不同的是，在壓力下，「從優秀到卓越」的公司仍然有足夠的耐性和紀律遵循先厚植實力、再突飛猛進的飛輪模式。最後，他們終能展現驚人的績效，即使照著華爾街的標準來看，都非常成功。

這，是不是跟 Scrum 嚴守五事件 (sprint, sprint planning, daily scrum, sprint review, sprint retrospective)、三產物 (product backlog, sprint backlog, increment) 的紀律，有異曲同工之妙呢？

第五級領導

《從 A 到 A+》第二章如此說明「第五級領導」的特色：

第五級領導人具備了雙重特質：宅心仁厚，但意志堅定；謙沖為懷，但勇敢無畏。

所有「從優秀到卓越」的公司，在蛻變期都出現了第五級領導人，而對照公司卻普遍缺乏。由於第五級領導人的概念違背了傳統智慧——公司變革必須仰賴備受矚目的救星來推動，務必請切記，第五級領導人是實證研究的發現，而不是空談得到的觀念。

最大的諷刺是，通常一個人能夠位高權重，是因為他積極進取，野心勃勃，這卻和第五級領導所要求的謙虛性格背道而馳。

這，是不是跟 Scrum master 所講究的「僕人式領導」、product owner 講究的「為 product backlog 當責」，有異曲同工之妙呢？

找對人

《從 A 到 A+》第三章如此說明「先找對人，再決定要做什麼」的觀念：

推動優秀公司邁向卓越的企業領導人，並非先找出巴士該往哪裡開，然後要員工把車子開過去。他們反而先找對人上車（要求不適合的人下車），接下來才弄清楚車子該往哪個方向開。

第一，如果你先思考「該找什麼人」，而不是「該做什麼」，將比較容易因應瞬息萬變的世界。其次，如果你找對了人上車，根本就不太需要操心激勵員工和管理員工的問題。第三，如果找錯了人，就算你找到了正確的方向都沒用。

卓越公司的領導人通常都了解，成長的最大瓶頸不在於市場、技術、競爭或產品，「能不能延攬到適合的人才，並且留住人才」的重要性凌駕於這一切。

《從 A 到 A+》的後記，甚至如此主張：

放寬「用對人」的定義，多關注這個人性格上的優點，不要太強調專業知識。他們可以學習技能，獲得知識，但是卻無法透過學習，培養出適合組織的基本人格特質。

應該善用景氣不好的時候，多方延攬卓越的人才，即使當時你腦中還沒有想到適當的職位。

這，讓我聯想到 The Scrum Guide 主張的五大價值觀：

當 Scrum Team 體現和活化承擔 (commitment)、勇氣 (courage)、專注 (focus)、開放 (openness) 和尊重 (respect) 這五種價值觀時，Scrum 的三根支柱：透明性 (transparency)、檢視性 (inspection)、調適性 (adaptation) 就會出現並幫助大家建立信任。隨著 Scrum Team 成員從事 Scrum 角色、活動和產出物的過程中，他們就會學習和探索這些價值。

若不幸找到錯的人，這五大價值觀是否能夠很快灌輸在他們身上呢？

真實與透明

《從 A 到 A+》第四章如此說明「面對殘酷現實，但決不喪失信心」的觀念：

領導力和願景有關，但是領導力也和創造能聽到真話和面對現實的環境有關。

如果你是很有領袖魅力的強人，應該花時間好好想一想，領袖魅力是資產，也是負債。你性格上的優點也可能埋下了問題的種子，員工會自動過濾資訊，不讓你接觸到殘酷的真相。你仍然可以克服領袖魅力帶來的問題，但是必須有充分的自覺，長期投注心力注意這個問題。

這，是不是跟 Scrum 的 sprint review 及 sprint retrospective 所講究的重點，有異曲同工之妙呢？

刺蝟原則

《從 A 到 A+》第五章主張：「從優秀躍升到卓越，必須對於三個互相交集的圓圈有深入的理解，並且把這種理解轉化為單純而清楚的概念」：

刺蝟原則

「從優秀到卓越」的公司比較像刺蝟——單純、憨厚，只懂得「一件大事」，但卻能一以貫之。對照公司則比較像狐狸——詭計多端、行動敏捷，懂得許多事情，但卻前後矛盾，缺乏一致性。

「從優秀到卓越」的公司，平均要花四年的時間，才能釐清他們的刺蝟原則。

在較微觀的尺度來說，這，是不是跟 Scrum 的 product goal 與 sprint goal，有異曲同工之妙呢？

紀律

《從 A 到 A+》第六章主張「企業應該建立起一種文化，讓員工能在三個圓圈中採取有紀律的行動，堅守刺蝟原則」：

紀律

自由、責任、紀律，凡此種種，是不是跟 Scrum 的「自組織文化」與紀律，有異曲同工之妙呢？

科技

《從 A 到 A+》第七章主張要以合宜態度面對科技：

「從優秀到卓越」公司的領導人，都有一股發自內心的創造性驅動力，因為渴望追求卓越而追求卓越；至於表現平平的公司，領導人背後的驅動力通常只是害怕落後。

「從優秀到卓越」的背後驅動力，絕不是恐懼。

這，是不是跟 Scrum 的 DoD (definition of done) 品質紀律，甚至敏捷原則第九條 “Continuous attention to technical excellence and good design enhances agility.” 所揭櫫的重點，有異曲同工之妙呢？

按部就班

《從 A 到 A+》的後記，在回答「我應該從什麼地方開始做起？」問題時，如此提醒：

首先，熟讀所有的發現。切記，不能單靠其中任何一項發現來造就卓越的企業，你必須把它當成一體，照著我們的架構，按部就班一一實施整套做法。

本書循序漸進的陳述架構，正好符合我們所觀察到的企業做法和步驟，因此，本書的結構就是你們的最佳指南。

這，是不是跟 Scrum 兩位發明人在《告別瀑布，擁抱敏捷》所提的警告，有異曲同工之妙呢？

Scrum 不是可以被隨意修改，來迎合既有企業文化的流程，反而是應該調整企業文化來適應 Scrum。

如果沒有用 Scrum 來建立敏捷、透明的開發環境，那隱藏的問題將會一直留在企業內損害企業的利益。那就失去了使用 Scrum 最主要的好處。

持續的改進

《從 A 到 A+》第八章在談到飛輪效應時，有這麼一段語重心長的觀察：

「從優秀到卓越」的公司，比較不喜歡在八字還沒有一撇的時候，就對外大肆宣揚偉大的目標。他們只是開始轉動飛輪——先深入了解，然後採取具體行動，一步接著一步，一圈接著一圈。等到飛輪慢慢累積了龐大的動能之後，他們才抬起頭來說：「嘿，如果我們一直這樣推動下去，沒有理由達不到目標。」

我們發現，當有了適當的條件時，員工的投入、團結、激勵和變革等問題，都自然會迎刃而解，完全不是問題。

這麼美好的飛輪，要啟動，關鍵在於「有了適當的條件」。

如果從 Scrum 角度來看，你認為，什麼是所謂的「適當的條件」呢？這是值得你我深思的大哉問。

《從 A 到 A+》附錄一說明作者們採取的研究方法及篩選過程：①根據 1965～1995 年 Fortune 500 名單，從所有美國公司中選出 1,435 家公司，②根據平均複合投資人報酬率，從 1,435 家公司到 126 家公司，③根據累積股票報酬率，訂出 11 則淘汰標準，從 126 家公司到 19 家公司。 ↩︎

你要一直打野戰嗎？

Thu, 03 Jan 2019 13:00:00 +0800

去年十二月，接連把超讚的兩本書讀完。

《什麼才是經營最難的事》較偏草創期的戰鬥智慧，《給力》較偏成長期的經營智慧。兩種規模，兩種思維，激盪我許多想法。

兩種極端的好書

不同的生存階段，不同的公司地位，需要的手法會不同。

但這並非截然二分。像《什麼才是經營最難的事》第七章，儘管強調戰時執行長與平時執行長的對比 ¹，卻也說：「平時執行長重視員工培訓，以員工成就感與職涯發展為己任。戰時執行長也重視員工訓練，以免大家在戰場淪為砲灰。」

有些事，不分平時戰時，都需要顧及到的。

所以，當我看到朋友 Vince 最近引述《什麼才是經營最難的事》第七章的一段話，很有感觸：

戰時執行長

這段話，讓我聯想到金庸。

岳飛不讀兵書？

金庸小說《射鵰英雄傳》第三十六回，提到岳飛對於兵法的獨特見解：

岳飛少年時只喜野戰，上司宗澤說道：「爾勇智才藝，古良將不能過。然好野戰，非萬全計。」因授以布陣之法。岳飛說道：「陣而後戰，兵法之常。運用之妙，存乎一心。」宗澤對他的話也頗為首肯。但岳飛後來征伐既多，也知執泥舊法固然不可，但以陣法教將練卒，再施之於戰場，亦大有制勝克敵之功。這番經過也都記在《武穆遺書》之中。

當然啦，《武穆遺書》云云，只是金庸在小說中杜撰的。那麼，真實的歷史呢？

看看《宋史》吧！

戰開德、曹州皆有功，澤大奇之，曰：「爾勇智才藝，古良將不能過，然好野戰，非萬全計。」因授以陣圖。飛曰：「陣而後戰，兵法之常，運用之妙，存乎一心。」澤是其言。

— 《宋史》卷365

乍看之下，成年之後的岳飛，似乎只擅長野戰，輕視兵書佈陣之法；但《宋史》也記載年少時岳飛的另一面：

人少負氣節，沈厚寡言，家貧力學，尤好《左氏春秋》、孫吳兵法。生有神力，未冠，挽弓三百斤，弩八石。學射於周同，盡其術，能左右射。

— 《宋史》卷365

可見，相關經典，他早就讀過了，甚至可說是讀通了——在實踐中融會貫通。

融會「常」與「變」，才有資格講「運用之妙，存乎一心」。

一代大將如此，你我呢？

短線與長線

Bryan 新文章〈會賺錢就是好公司？賺錢公司其實有兩種，你現在待的是哪一種？〉也提到一則妙喻：

小米雷軍有句名言：「站在風口上，豬都會飛。」而更多時候，馬雲這段話讓人更有感：「豬碰上風也會飛，但風過去摔死的還是豬！」（最近大陸的豬還真可憐～）

儘管《什麼才是經營最難的事》較偏草創期的戰鬥智慧，但也非常強調長線的重要性：

公司要激勵優秀人才，莫過於有個重大使命，凌駕在員工個人野心之上。
有偉大的產品願景，固然需要輔以各項指標確實執行，但如果誤把指標當願景，再努力也達不到目標。
看路不看牆。賽車新手剛開始必學的一課是：以每小時兩百哩的車速行經彎道時，不能想著不要撞牆，而要專心在路面。心中只有牆，就會撞牆；心中只有路，就會沿著路面走。

所以，你想當只會打野戰、只會搭順風火箭的人嗎？

《什麼才是經營最難的事》第七章，將執行長分成平時執行長 (peacetime CEO) 與戰時執行長 (wartime CEO) 兩種類型。 ↩︎

【主管的修練】讀書會

Mon, 24 Dec 2018 08:00:00 +0800

稍早草擬的〈接班人計畫〉偏向一對一的培訓。

若是一對多呢？

於是乎，就有了這份企劃：【主管的修練】讀書會。

這一部分是模仿《利潤的故事》的做法 ¹，尤其是楊傑美的「前端載入」方法。但我還融入剛學到的 liberating structures 等技巧 ²。改成速讀 + 互動討論的形式，應該既緊湊又有趣吧。

「前端載入」

以下是企劃內容。

簡介

探討初階中階主管的六大課題：① 領導與管理思維、② 參與式決策、③ 人才管理教育和支持、④ 溝通與衝突化解、⑤ 團隊績效的考核標準、⑥ 團隊文化和核心信念 ³。

課程以個案研討形式為主，有大量課堂討論，學員需要依照進度先行閱讀指定讀物。能配合的，再考慮參加。

適合對象

已經是，或有志於在職涯中成為主管者。

進度

請依照指定進度，先自行想辦法閱讀以下指定讀物。

第一週／領導

主要讀物：《領導，不需要頭銜》

輔助讀物：〈太多領導，太少管理〉，算是對《領導，不需要頭銜》pp. 78-81 的平衡報導。

第二週／管理

主要讀物：《三年後，你的工作還在嗎？》

輔助讀物：系列文 / 專案管理的藝術

第三週／管理

主要讀物：《可複製的領導力》

輔助讀物：系列文 / 專案管理的藝術

第四週／參與式決策

主要讀物：《誰說我們不能一起做決定》＆《原來你才是絆腳石》

輔助讀物：系列文 / Titansoft 的經驗談

第五週／人才管理教育和支持

主要讀物：《別讓績效管理毀了你的團隊》

輔助讀物：

第六週／團隊文化和核心信念

主要讀物：《給力》

輔助讀物：系列文 / 專案管理的藝術

⑧ 沒有英雄、人員培育與接班計畫

輔助讀物：

《下一步，成功》第四章。
如何管理比你聰明的人

第七週／總結

主要讀物：《原則》第一部分＆ Principles For Success 影片

輔助讀物：系列文 / 專案管理的藝術

⑩ 歷史借鏡、能重複應用的才有價值

上課前

瀏覽學習單。
速讀：每一份指定讀物，請在不超過 2 小時之內速讀完畢第一次。
填寫學習單，頁數不夠請自行增印。
如有時間，可再回頭重讀、細讀內容。

上課時

攜帶學習單。
以 liberating structures 及互動討論方式，進行個案研討。

有些個案討論有隱私性考量，為促成坦誠討論，參與者需宣誓對現場討論內容保密 (咦)。

全部課程結束後

讀一讀 Andrew Grove 的《葛洛夫給經理人的第一課》。

關於《利潤的故事》這本書，我在〈2018 個人回顧〉一文有更詳細的介紹。 ↩︎
我是在 Scrum.org 在台北舉辦的 ScrumOn 活動中，第一次體驗有趣的 liberating structures 技巧。 ↩︎
這六大主題的界定，其中有五項是參考【帶人的技術】線上課程的廣告文案。他們的文案列了五點：①建立成長型管理思維和觀念，②學會高素質人才管理、教育和支持，③檢視團隊內溝通與衝突化解方法，④評估團隊績效的適用考核標準，⑤樹立超強團隊文化和核心信念。 ↩︎

2018 個人回顧

Thu, 20 Dec 2018 08:00:00 +0800

到了年終，又開始要做個總回顧，再對來年許願。

如果說 2016 和 2017 都是華麗冒險年，那麼，2018 對我來說，是收攝靜觀的一年。

去除一些不便揭露的事情，以下是簡單的回顧。

補血課程

這一年，由於財務及時間問題，參加的補血課程大幅減少。只能精選再精選。

這兩門課，都是後座力十足，不管是觀念上還是實務上。後面都會提到。

至於專題演講及研討會，參加的場次就多了，不及備載。

其中悸動最深的，就屬 Maria Gomori 的【大師對談：在關係中重生－從糾纏到滋養】講座了。能親炙高齡 98 的國寶級大師，多麼難得的機緣呀！

Maria Gomori, 2018-05-06, Taipei

這麼難得的機緣，說什麼，都得買第一排搖滾區的座位。

第一排搖滾區

坐在第一排，近距離觀察許多互動細節，驚喜發現，去年我在三梯次薩提爾培訓課程學到的 ¹，果然與 Maria Gomori 大師是一脈相承的。一整天的活動，彷彿一場總複習。

而且是大師親自帶領的總複習。超值！

演講及授課

今年，演講次數也大幅減少：

從限制理論角度談敏捷導入階段 (@ Agile Summit 2018)

取而代之的，是授課及工作坊：

系統思考的四堂課 (@ 公司內訓 & DevOpsDays Taipei 2018)
SBE 的四堂課 (@ 公司內訓)
敏捷原理與團隊塑造・二日精修版 (給學員的話)
為了精準估算，你必須付出什麼代價？ (@ Agile Tour Kaohsiung 2018)

自從受過【體驗式課程的遊戲設計與操作實務】的洗禮，又讀過《刻意練習》及《豐田形學》，我越來越喜歡工作坊這種「微培訓」形式。明年應該也會繼續這樣子吧。

量化之旅

「精進量化技能」被我在 2017 年底列入來年許願項目。

到了今年七月，因緣際會之下，參加了君婷老師這場開腦洞的首發課程。

510 / 專案監管的系統思考及 KPI 設計攻防

這是專案管理課程。像「milestone 重於 WBS」的觀念，之前只是隱隱約約感覺到；但在課堂上被專家一語道破，我就更放心了。還有許許多多內容，都讓我可以融入到慣用的敏捷模型中。畢竟，人性是普遍的，箇中蘊含的系統動力也是普遍的。

後來，我持續探索〈Agile PMO〉、〈敏捷的價值與指標〉、〈DevOps 的價值與指標〉、〈改變／改革：流程與衡量指標〉等議題，都是發軔自此課程的啟發。

但這不僅僅是專案管理課程，更是開眼的「數字」教育。之後，再看其他涉及量化管理／公司治理的書，都格外有感：

對數字開始懷疑

的確是打通任督二脈的補血課程！

等比級數的推坑力

要「精進量化技能」，免不了要更認識獲利模式。

對工程背景的我來說，這是大工程。因此，我選擇用「系統閱讀」的方式去建構這方面的基本知識。

起點是《10 年後會留在書架上的 100 本書》² 。按圖索驥，挑選勝間和代的《創造利潤的方程式》來讀。這真是扎實建構思維模型的好書。讀完一次花了一整個禮拜，需要沉澱。改天還真想把這本書的精髓畫成 CLD 呢。

事情還沒結束。

勝間和代還推坑了另一本奇書《利潤的故事》 (The Art of Profitability)。

創造利潤的方程式

拙作《創造利潤的方程式》的反面可說就是《利潤的故事》這種書。我是在「如果弄成只有一種利潤模型，會如何呢？」的想法之下，寫了那本書的。

這就引起我的好奇心了：能夠讓勝間和代專門寫一本書來 ~~打對台~~ 對比的，想必是不簡單的對手。

果真如此。

《利潤的故事》體裁雖然是商業小說，有趣，但不是本容易徹底消化的書。作者還特別提醒：不能讀得太快。得有耐心，照著書中的步調，乖乖寫作業（是的！有作業！）。更可怕的是，這本書居然也是個書坑，幾乎每一份作業，都順道規定一兩本指定讀物——簡直是等比級數的推坑力。

既然《利潤的故事》也暗中運用系統閱讀的方法來安排章節及作業順序，既然我也下定決心要系統閱讀這議題，那麼，就乖乖的照著最右邊這本大書坑，按圖索驥吧。

自己手邊只有老版本的《十倍速時代》與《愛因斯坦的夢》，靠著 TAAZE 才補上一些拼圖——但還是不齊。等簡體書及原文書到齊，再合拍一張吧。

《利潤的故事》及推坑的叢書

《利潤的故事》推坑書單如下：

洞悉大師亞當斯 / Obvious Adams
燃燒的權力 / Power to Burn
數盲 / Innumeracy
十倍速時代 / Only the Paranoid Survive
創意的生成 / A Technique for Producing Ideas
愛因斯坦的夢 / Einstein’s Dreams
艾西莫夫論太空 / Asimov On Astronomy
富甲天下 (新版) / 天下第一店 (舊版) / Sam Walton: Made in America: My Story
獲利寶典 / The Profit Zone
一個廣告人的自白 / Confessions of an Advertising Man
奧格威談廣告 / Ogilvy on Advertising
閱讀初步 / ABC of Reading
孫子兵法
Starbucks 咖啡王國傳奇 / Pour Your Heart Into It
永恆的價值 / Of Permanent Value
典範 / Paradigms
利潤模式 / Profit Patterns
創造新財富 / Value Migration
羅素的制勝法則 / Russell Rules
力量之泉 / Sources of Power
數位革命 / Being Digital
他們的數位化經營策略 / How Digital Is Your Business?

洋洋灑灑，這就是我這兩個月以來沈重的閱讀清單呀。

雖然沈重，但，浸潤在這種「藝術的學習」境界，也挺過癮的。

學習，有五種層次 -- 《利潤的故事》

收攝靜觀

十二月，特地安排兩件事，讓自己有收攝靜觀的機會。

距離上次親自玩 LSP 也已經一年半了。正巧好友 Sam 要舉辦一場【策略會議引導・樂高認真玩】，趕緊報名參加。

年終，給自己一個沉澱的時間與空間。

我的 LSP 作品之一 (2018-12-12)

本週二，應好友之邀，去現場看看真正的 “scrum”。

身為 Scrum Master，沒親眼去現場看橄欖球，像話嗎？呵。年末，總是要熱血一下。

2018 亞洲 U19 青年橄欖球錦標賽

從這兩場高強度的賽事中，領悟到不少 Scrum，甚至團隊經營的點點滴滴：

衝刺，再衝刺
傳球
佈陣
局部最佳化
後勤
目標
Ａ咖
“Try”
“Swarm”
Baseline
Pivot
餘裕
下一步

太多太多聯想與感想。也不禁令我思考起自己的下一步。

2019 許願

2019 年，希望自己能做到：

繼續更深度的 BOSA 探索與實踐。
繼續精進量化技能。
正式正視與深化教練技能。
重讀一次福爾摩斯（這是這兩年遺憾沒能做到的）。
增進商務英語聽說能力。
開放冒險選項。

就醬。

我在 2017 年上了三梯次為期九天的薩提爾培訓課程。相關心得請見〈六日薩提爾體驗〉及〈引導者，要懂心理〉這兩篇文章。 ↩︎
我在〈精讀 vs 泛讀〉一文中，有提到《10 年後會留在書架上的 100 本書》這本書。 ↩︎

為了精準估算，你必須付出什麼代價？

Wed, 19 Dec 2018 08:00:00 +0800

開場對話

研發團隊，常會被問到一個問題：

「請問一下，這個Ａ功能，大概要多久才能完成？」

這個問題，不會因為你跑的是敏捷，就自動免疫。那麼，身為經過敏捷思維洗禮的人，該如何做出合宜的應對？

我在 Agile Tour Kaohsiung 2018 開辦一場 2.5 小時的工作坊，帶領大家親自體驗這個議題。

不過，這個題材的背後，其實還有三段故事。

故事，要從一年半前講起。

第一段故事：結構化流程

一年半前，我曾提過一個心願：

我想用結構化的 Sprint Planning 流程，讓錨定效應、以關係為中心、目的型談判自然發生，讓參與其中的人，逐漸在刻意不遮掩的建設性衝突中，潛移默化。¹

這個心願，即使我今年已經將自己的招牌課程【敏捷原理與團隊塑造】進化到二日版 ²，也都還未能夠實現。要完整實現，恐怕得擴充至二天半，甚至三日版。

這是一個小缺憾。

年底正好有個在 Agile Tour Kaohsiung 2018 舉辦工作坊的機會，我就來小試一下心中設想的「結構化的 Sprint Planning 流程」，以後再看看有沒有機會將這次經驗併入招牌課程。

第二段故事：衡量

設計工作坊，要先定義好最核心的體驗內容。

Sprint planning，或者 release planning，都有一個共同議題：衡量。正好這陣子我一直在研究這類衡量、指標等相關議題 ³，便將工作坊的題目訂為【為了精準估算，你必須付出什麼代價？】。

核心的體驗內容決定好了，體驗的動線，則以《如何衡量萬事萬物》這本書做為參考標的。

如何衡量萬事萬物

第一次看到這本書名，是在《精實企業》及《精實執行》。能同時被這兩本經典引述，想必非泛泛之書。

當時只覺得可以從中借用到一些衡量妙法，像是費米推論之類的。萬萬沒想到，這簡直是改變三觀的奇書。恰好又跟我這陣子在系統閱讀的主軸相吻合，讀來可說是點頭如搗蒜。

看懂這本書，內化並實踐，有助於從根本解決一些盤根錯節的敏捷持久落地的企業面難題。

初步啃完這本奇書，就花了我好幾天，累積起來共十七個小時。十七小時的心得，在短短的 2.5 小時的工作坊是無法盡數展現出來的，我只能先揀選一個雖粗淺但稱得上是全貌的流程，作為工作坊的體驗主動線。

AIE 通用衡量方法

第三段故事：PDCA

核心的體驗內容決定好了，體驗的動線也決定好了，就剩下體驗的劇本了。

既然要辦的是工作坊，重點自然不是說教，而是體驗，而且是能成為肌肉記憶的體驗。

這一點比較簡單。自從經過【體驗式課程的遊戲設計與操作實務】的洗禮 ⁴，我將招牌課程【敏捷原理與團隊塑造】調整成「高速高頻率 PDCA 循環」的風格，廣受好評，已成為自己的拿手招術。

因此，我決定這次的工作坊，也比照辦理。

高速高頻率 PDCA 循環

在敏捷世界裡，不管是 sprint planning 還是 release planning，都很強調全員參與。因此，我的工作坊劇本也設計成要全員參與，以反應真實情況：

在這兩個半小時的體驗活動中，我會用真實案例的改編版本，帶大家體驗 Sprint Planning 及 Backlog Refinement 的核心要素。不管你是 PO、PM、UX、RD、QA，都能從活動中親自體認到，我們到底有沒有必要追求精準的估算？以及，萬一真的有必要，我們又該做什麼樣的準備？

分組方法有很多，有安全穩當的，也有刺激難以掌控的。當天在 Agile Tour Kaohsiung 2018 活動現場，看到大家非常專業，便臨時起意，將現場人士分成三大組：Scrum Master 組、PO 組、developer 組。

非常冒險的決定。但，敏捷，本來就是要冒必要的險嘛！

分組

整場 2.5 小時的活動，有笑聲，有~~吵架聲~~激辯聲（過程中一度擦出火花），也有嚴肅的制憲大會——像極了真實的職場情境：

流程會議

感謝超強的參與者，尤其是始料未及的 Scrum Master 組，讓我這場首發的工作坊，得到超出我預期的效果／笑果。

「高速高頻率 PDCA 循環」風格，在這 2.5 小時中，應該算是嚴格貫徹了。

未央歌

一年半前許下的心願「結構化的 Sprint Planning 流程」，這次 2.5 小時的工作坊，大約實現了六成。

要完全實現，全程可能要 3 小時。

在改版成功之前，先貼出這場 2.5 小時 Workshop 可公開的部分。

下一步呢？請靜待吧。

我在〈以談判角度看 Sprint Planning〉文章中，談到我對高品質的 Sprint Planning 有著不一樣的願景。 ↩︎
今年我將自己的招牌課程【敏捷原理與團隊塑造】升級成【二日精修版】，承載更多我想傳達的核心理念。最近剛結束的公開班是 2018-09-13～09-14 這一梯次，課後感想文在此。 ↩︎
這陣子研究衡量、指標等相關議題，相關心得請見〈敏捷的價值與指標〉、〈DevOps 的價值與指標〉、〈改變／改革：流程與衡量指標〉等文。 ↩︎
詳見〈三週生出一款新桌遊，一段奇幻旅程〉一文。 ↩︎

改變／改革：流程與衡量指標

Fri, 07 Dec 2018 13:00:00 +0800

改革，很不容易；摧毀改革，卻很簡單。知名的改革框架，莫不注重改革的整合與固化。

敏捷亦然。像這篇文章〈慢慢的，公司内敏捷的热度就退了…..〉就訴說一則可悲的故事：

我並沒有告訴他們具體要怎樣做，只給了他們一些理論上的指導，然後他們就開始集思廣益，動手佈置。這其中展現出來的主動思考能力、自組織能力和執行力，讓我不由得暗地裡豎起大拇指。基於這樣良好的基礎，他們的敏捷過程推進的也非常順利，我輔導了他們 3 個月左右，他們已經熟練的掌握了一些實踐方法，加上本身已經具備的自組織能力和執行力，似乎繼續做下去，就可以達到不錯的成熟度。

然而時隔一年後，我偶然路過他們的辦公區，才發現一切並沒有照著「理所當然」發展，而是都恢復了原樣。

團隊成員坐在各自的工位上埋頭工作，他們不再聚集在白板前。專案經理每週一將工作分配好，並定期檢查狀態。工作區氣氛嚴肅而沉悶，一個似乎是 Leader 的人大聲訓斥著員工，指責他反覆犯同樣的錯誤。

似乎，敏捷從未來過。

如何確保改革的整合與固化，而不只是曇花一現？

高德拉特的《目標》裡頭藏有這問題的答案，藏在兩處很少被人提到的橋段。

偏執、執著的伏筆

在書中，主角羅哥 (Alex Rogo) ¹ 是優尼公司白靈頓鎮的工廠廠長。他與工廠財務長劉梧 (Lou)、生產經理唐納凡 (Bob Donovan) 等人，努力拯救工廠的經營危機。

羅哥、劉梧、唐納凡 (From: The Goal)

經過一番奮鬥，終於立下了顯赫戰功，主角羅哥在升官執掌三個工廠的事業部之前，認真反思過去三個月跌跌撞撞的過程，試圖歸納出可複製的成功因素。他們在《目標》第 32～40 章進行多場機鋒對話，聚焦五步驟就是在這思辨交鋒過程中總結出來的。

不過，鮮為人知的是，這幾章還隱藏一個重要的改革訣竅，埋在一段獨白與一段對話中：

❶ 在第 40 章，羅哥有一段內心獨白：「唐納凡說得對，劉梧對衡量指標簡直有一種偏執。」這是第一個哏。

❷ 在第 36 章，羅哥對唐納凡說了一句話：「假如劉梧對衡量指標很執著，那麼你（唐納凡）一定是對流程很執著了。」這是第二個哏。

你能體會為什麼高德拉特會刻意埋這兩個所謂偏執、執著的伏筆嗎？我也是不斷反思改革的成與敗，才漸漸體會到這伏筆的精妙。

敏捷固化的軌跡

改變／改革要固化，需要辨識出流程與衡量指標。

如果單以《目標》來說，流程是指聚焦五步驟，衡量指標是指 T, I, OE。

敏捷轉型，既然是一種改變／改革，也會遵循類似的軌跡。就以前面那篇文章最後提出三點「想讓改變不再是一陣風」建議來說：

改變考核機制，在改變的初期調低原有 KPI 指標，增加對輔助工具（敏捷、精益或其他方法）的使用情況的考核。

在改變過程中，發現對組織有益的流程，要加入到 KPI 中，變為日常考核的一部分。

給所有好的「動因」以正向的反饋，即使結果看起來沒那麼炫目。

這三點建議，正好與《目標》第 32～40 章的流程與衡量指標兩大伏筆相互呼應。

看到這裡，不禁對埋哏的高德拉特肅然起敬。《目標》第 32～40 章，真的值得用思辨的大腦多讀幾遍。

好的商業小說，需要對等的識讀力。

結語

改變／改革要固化，需要內外兼修。其中，流程與衡量指標，是關鍵的硬性要素。因此，除了擘劃改變的框架，別忘了也要設置適當的衡量指標。

衡量指標是兩面刃，要謹慎，尤其是均衡感。² 掌握到均衡感，將能促進改變／改革的固化。

系列文章

❶ 改變的框架

❷ 改變／改革：流程與衡量指標

❸ 推動改變的評估流程

《目標》主角 Alex Rogo 的中譯名，原本是「羅哥」，但 2021 的譯本卻改譯為「羅戈」。我個人較偏好舊譯。 ↩︎
針對衡量指標的均衡感，請參考我的兩篇文章：〈敏捷的價值與指標〉與〈DevOps 的價值與指標〉。 ↩︎

Scrum 沒有明說的事：休耕期

Tue, 04 Dec 2018 08:00:00 +0800

Scrum 的官方白皮書 The Scrum Guide 非常輕薄短小（像 Nov 2017 版只有 19 頁），它的理念是：只制定最核心的原則、價值、角色、活動、產出物，其餘的則交給團隊根據經驗主義 ¹ 去調適出最適合自己的細節。

想當然爾，有很多事，Scrum 並沒有明說。

那麼，沒有明說的事，就不需要做、就不能做了嗎？做了，就違反 Scrum 嗎？

這是許多奉 The Scrum Guide 為圭臬的人，常有的盲點。

Scrum 沒有所謂的「暫停」？

譬如說，有人對 sprint 這種百米賽跑的壓力提出疑問：

Run scrum 一陣子了，有感覺到一些跟傳統軟體開發專案不一樣的壓力。以前這種方式對 team member 來說，會有淡季跟旺季的差別，所以大家比較好安排自己的休假，或者在淡季的時候安排一些 researching、training 的工作。

現在 run scrum 覺得每個 sprint 壓力都好大，每個 sprint 都好趕，都剛剛好在最後一刻達到 sprint goal。大家也會因為齊步走的關係，所以都不太好意思請長一點的假。以前一年可能最多面臨四次 milestone review 的壓力，現在是至少每四週都會面臨一次這種壓力，Scrum guide 又說 sprint 開始以後就是一個 sprint 接一個下去，中間不會有間斷，但我們真的好想暫停 0.5 個 sprint 讓大家喘口氣。

前輩們都怎麼處理休假問題跟這種持續性壓力的問題呢？

Scrum 真的沒有「暫停」這件事嗎？

首先，回到 The Scrum Guide 原始文本，看看它是怎麼說的：

The Sprint

Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

Sprint 長度在整個開發過程中都是固定的，前一個 Sprint 結束後，下一個新的 Sprint 立刻接著開始。

如果只以形式主義來說，這些 sprints 的確好像是一棒接著一棒，棒棒相傳，不漏接，無止息——沒有假期。

再進一步思考 sprint 這個載具的原始目的——即所謂 sprint goal，就可發現，goal 的意義，是由我們 Scrum team 來賦予的。就連 The Scrum Guide 都叫你要保持彈性，不要形式主義：

Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.

每個 Sprint 可視為一個不超過一個月的專案，如同其他專案一般，Sprint 是用來完成某些事情的。每個 Sprint 有著要打造些什麼的目標，而由一份設計和有彈性的計畫來引導其打造的過程、工作與最後的產品 Increment。

Sprint goal 的意義，是由我們 Scrum team 來賦予的。

問題是，你想賦予什麼意義呢？

譬如說，市場探索，可不可以是一種 sprint goal 呢？用戶研究，可不可以是一種 sprint goal 呢？五日 design sprint，可不可以是一種 sprint goal 呢？

甚至有點離經叛道的講：恢復元氣，能不能算是一種 sprint goal 呢？

地力需要恢復，人力也是。

休耕期

恢復軟體本身的元氣，有一個更正式的名詞——休耕期 (fallow)。

在《編程的頂尖對話》中，大神 Douglas Crockford 如此解釋軟體研發領域的休耕期觀點： ²

軟體研發的休耕期

「一般來說，團隊應該知道什麼時候合適（進行這種清理程式碼、重寫的事）」，大神 Douglas Crockford 毫不客氣挑明地講：「管理層很難看到這一點⋯⋯管理層很久之後才會發現。」

如果沒有這種特地保留起來的休耕期，那麼，重構、技術債的議題，幾乎註定會一直被推遲到比馬里亞納海溝還更低的順位。這將嚴重破壞 Scrum 的基石：PSPI ³。

敏捷陣營也有人呼應這種想法。像 Toronto Agile Conference 2017 有一場演講 “Technical Debt Is a Systemic Problem, Not A Personal Failing”，用的是 “technical-debt sprints” 一詞，還畫出 CLD 呢：

Technical-Debt Stories and Sprints

「休耕期」觀念，不是出於傳統的 Scrum 論述，The Scrum Guide 也沒講，你認為它有違反 Scrum 嗎？

如何做？

那麼，該如何踏出第一步呢？或者更敏感地講：誰該去在貓脖子上掛鈴鐺？

大神 Douglas Crockford 說：「團隊應該知道什麼時候合適，管理層很久之後才會發現。」

所以，請先自問：你們有規律地跑 retrospective 嗎？在團隊層次，甚至在更大的組織層次？

2018-12-21 補充

我參加 Scrum.org 在台北舉辦的 #ScrumOn 活動。經過六十分鐘 PSM I 洗禮，以及敏捷專家學會 Percy 的推坑，特地去查閱 Nexus Guide。

發現，裡面正好有特地提到技術債議題。特地摘錄於此：

軟體開發必須在技術債變得讓 Nexus 不可接受前，找出並解析依賴關係。若缺乏透明度，不可能有效指引 Nexus 有效地將風險最小化並將價值最大化。

Software must be developed so that dependencies are detected and resolved before technical debt becomes unacceptable to the Nexus. A lack of complete transparency will make it impossible to guide a Nexus effectively to minimize risk and maximize value.

The Scrum Guide 說：「Scrum 是立基於經驗導向的流程控制理論 (empirical process control theory)，或是經驗主義。經驗主義立論於知識來自於經驗和依照已知的資訊來下判斷。Scrum 使用疊代和逐步 increment 的方式，來最大化可預測性和控制風險。」 ↩︎
Douglas Crockford 在 CUSEC 2010 Keynote - The Software Crisis 這場演講主張：‘Perhaps we should take advice from Exodus: “Plant and harvest crops for six years, but let the land rest and lie fallow during the seventh year.” Maybe do six sprints where you add new features, but on the seventh sprint, don’t add new features at all.’ ↩︎
我個人認為，Scrum 的判準，就在於 increment，以及能否在各個疊代過程中，捍衛並精進這個 increment 的整全狀態。詳見〈敏捷的判準〉一文。 ↩︎

為什麼 LeSS 這麼迷人，可是總是輸給 SAFe？

Fri, 30 Nov 2018 15:00:00 +0800

在一篇 Terry & Ruddy 對話紀錄中，看到一系列有趣的 LeSS vs. SAFe 討論：

「為什麼 LeSS 這麼迷人，可是總是輸給 SAFe？」

「SAFe 是敏捷跟辦公室政治作出了完美的妥協（應該吧？），所以大家比較 Buy-in 吧。」

「可是 LeSS 乾淨啊，所有會 Scrum 的人讀到 LeSS 都會喜歡啊。」

正好這陣子也在思考這議題，便忍不住狗尾續貂一下。我只從「控制權」角度補充一則觀察。

LeSS

LeSS 直接就在名字表明它的「乾淨」立場，它就是崇尚 “less is more”、“more with less” 哲學的：

LeSS can be viewed as a scaling framework for product development, but can also be viewed as a descaling framework for organizations.

— LeSS / Principles / More with LeSS

崇尚 less 結構，也崇尚 less 控制與監管。LeSS 主張「支持，而非控制」：

The managers’ frame of mind must be support, not control.

Management support from the person(s) who has the organizational authority to make structural changes in your group—usually the head of your product group. This support must be… supporting.

True volunteering is a powerful way of engaging peoples’ minds and hearts. It’s underused, probably due to the feeling of loss of control by managers. But for people in teams it feels empowering.

— LeSS / Adoption / Three Principles

這些「支持，而非控制」的傾向，可直接上溯至敏捷思維的源頭——2001 年揭櫫的敏捷根本原則「自組織團隊」：

The best architectures, requirements, and designs emerge from self-organizing teams. 最佳的架構、需求與設計皆來自於能自我組織的團隊。

— Principles behind the Agile Manifesto

所以前面那則對話紀錄評論道「可是 LeSS 乾淨啊」。

SAFe

從這角度來看，SAFe 的「自組織團隊」程度就比較偏低了。

在 SAFe 的 value stream coordination 體系之下，有結構化的敏捷發布火車 (agile release train; ART)，有與之搭配的一系列結構化機制；以及⋯⋯專屬角色。

儘管 SAFe 第九原則是 “decentralize decision-making”，但是，從這些專屬機制與角色的配置來看，監管與控制的程度，SAFe 顯然較對傳統組織的胃口：

Product and Solution Management (from SAFe)

沒有明言的事

沒有明講的，不代表就不會存在。

Scrum 規模一但擴大，就必定會需要某種程度的協調與對齊。SAFe 和 LeSS 都不否認這些事情的存在，差別在因應的態度、處理的方式。

SAFe 認為，要主動定義這些控制機制：新角色、新決策小組、新節奏。

LeSS 認為，more with less，不須大動干戈引進新角色、新決策小組、新節奏。既有的 Scrum 三角色直接沿用，只要原班人馬再組成 product owner team 即可（頂多再有個 head of product group 做為組織結構上的管理者）。

對於「控制權」不同的態度，決定了不同的導入方式。

SAFe 和 LeSS 孰優孰劣，我沒有資格論斷。至少你可以從「控制權」角度，重新思考本文開頭的提問：

「為什麼 LeSS 這麼迷人，可是總是輸給 SAFe？」

以及，換作是你，會做什麼選擇。

以及，你的選擇，還需要哪些配套措施（文章開頭引述的對話紀錄中，已經有提示了）。

「從 Ops 角度看 DevOps」的感想

Wed, 28 Nov 2018 23:00:00 +0800

在台灣（或許在其他地方也是），DevOps 的話語權，很大幅度都被 Dev 一方把持。我們很少聽到 Ops 一方的說法。

成功的改革，需要兼顧各方利益者的需求及痛點。隨著 DevOps 守備範圍日益擴大，這種失衡狀態必須改變。

今晚參加 DevOps Taiwan 社群舉辦的講座：【從 Ops 角度看 DevOps】，聽聽胡士亮 (Robert Hu) 從正統 Ops 角度來詮釋 DevOps，甚至 OpsDev，收穫頗大。

聽知識，聽心得，也聽熱情與願景。

也更確定自己設想的方向，是符合正統 Ops 下一步思維的：predictive analysis & AIOps。

OpsDev recap (from Robert Hu)

這場講座印象最深的觀念是：同一件事情，在某些時候，由 Dev 下手較好；在某些時候，卻是由 Ops 下手較好。所以，手握 Dev 及 Ops 雙邊武器，就有較大的選擇彈性。

DevOps vs. OpsDev (from Robert Hu)

這就讓我想到，以前搞 microservices 時，如果不透過 NetflixOSS 之類的 Dev 黑魔法，就很難做出那些瞠目結舌的機制。而現在，透過 Kubernetes + Istio 之類的 nonintrusive Ops 黑魔法（或者更精準地說：service mesh），就不必改變 Dev 的 coding 習慣。

譬如說：

Circuit breaker：過去要靠 Java Hystrix、C# Polly、Python PyBreaker 這些程式語言程式庫的層次才能做到，現在，直接交給 Istio 即可。
Distributed tracing：過去要靠 Java Zipkin、Java/C#/Python/etc OpenTracing 這些程式語言程式庫的層次才能做到，現在，直接交給 Istio 即可。

這也意味著，好好掌握新一代的 Ops 技術，會促進內部協作，也會大幅拉大與競爭對手的差距——那些仍活在舊時代的 infra 對手們。

時代在進步，現在 Ops 已經不是只能拿冷兵器作戰的小步兵了，而是手持核武的將士——自我升級的鑰匙，在你手裡。

小小的感想。

再次感謝 Robert Hu 這麼精彩的分享！

從 Ops 角度看 DevOps

2018-11-29 補充

剛剛看完一場 live online training “Istio on Kubernetes: Enter the Service Mesh”，其中有一段話說得好，可作為文章的註腳：

“The first generation of microservices was primarily shaped by Netflix OSS and leveraged by numerous Spring Cloud annotations sprinkled all throughout your business logic. The next generation of cloud native apps and microservices will leverage sidecars and a service mesh.”

「判準與指標」系列

Wed, 28 Nov 2018 00:00:00 +0000

DevOps 的價值與指標

Wed, 28 Nov 2018 08:00:00 +0800

看完〈敏捷的價值與指標〉之後，很自然的會進一步追問：「那麼，什麼才是 DevOps 圈子所認定的價值，以及對應的指標，尤其是領先指標？」

這問題其實比較容易回答。畢竟，相較於兄弟領域 agile，控制與監管，原本就是 DevOps 不可分割的一部分。

再者，DevOps 的價值主張也非常明確具體。根據 SEI 提出的 DevOps 操作型定義：¹

DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality.

因此，時間與品質，就是 DevOps 所認定的價值。

剩下來的疑問就是：指標？

來看看兩份經典的說法吧。

技術價值流

DevOps 巨著 The DevOps Handbook 第一章，定義技術價值流 (technology value stream) 為：「把業務構想轉化為向客戶交付價值的、由技術驅動的服務所需要的流程。」

價值流始於工程師（包括開發、QA、IT 維運和資訊安全人員）向版本控制系統提交了一個變更，止於變更成功地在生產環境中運行，為客戶提供價值，並產生有效的反饋和監控資訊。

由此觀之，DevOps 的指標，必定會緊扣在技術價值流的環節身上。

DevOps value stream (from: Lean Enterprise, p.139)

此書第一章，根據精實原則，提出三項 DevOps 衡量指標：

前置時間 (lead time)。
處理時間 (process time)，以及所佔的比例。
返工指標 (percent complete and accurate)。²

此書第六章，進一步建議要合理設置流程改進的優先級：

為了積極管理技術債務，要確保至少把 20% 的開發和維運時間投入到重構、自動化工作、架構優化以及非功能需求上。

如果組織不願意支付這「20% 的税」，那麼技術債務將會最終惡化到靠近所有可用資源的程度。

將 20% 時間用於創造用戶不可見的正面價值

請思考一下，這些算是領先指標，還是落後指標？與「賺錢」之間有強烈的因果關係嗎？

高績效組織

DevOps 年度報告一直是 DevOps 領域的重頭戲。在 2018 年的報告 Accelerate: State of DevOps 2018 中 ³，從全球近兩千位專業人士的調查中，歸納出五個關鍵的軟體交付與維運效能 (software delivery and operational performance; SDO performance) 層面，以及對應的指標：

部署頻率 (deployment frequency)
變更的前置時間 (change lead time)
服務恢復時間 (MTTR)
變更失敗率 (change fail rate)
可用性 (availability)

高績效組織的 SDO 效能指標

請思考一下，這些算是領先指標，還是落後指標？與「賺錢」之間有強烈的因果關係嗎？

均衡感

和敏捷一樣，DevOps 也在追求一種巧妙的均衡感。不僅著眼於百米衝刺的短期成效，更著眼於馬拉松的長期績效。

一言以蔽之：在團隊中，如果看不到這種均衡感，那麼，鐵定不是 DevOps。

所以，在談要不要 DevOps 之前，務必誠實自問：這種均衡感，是你想追求的嗎？

若回答「是」，再試著找出這種均衡感的領先指標吧。

「判準與指標」系列文章

❺ DevOps 的價值與指標

SEI 提出的 DevOps 操作型定義，可視為一種狹義的 DevOps 定義。詳見〈一句話囊括 DevOps 的目標〉一文。 ↩︎
返工指標 (percent complete and accuracy)，在 The DevOps Handbook 書中寫成 %C/A 符號，但在更廣大的 lean 社群中更常用 %C&A 符號（像 TKMG 維護的 Lean 術語表）。個人認為，後者比較妥當。 ↩︎
這份年度報告，也有簡體中文譯版：〈2018 全球 DevOps 现状报告〉。 ↩︎

敏捷的價值與指標

Tue, 27 Nov 2018 08:00:00 +0800

同溫層朋友提出一則有趣的提問：

如何衡量敏捷的成效？ by Howie Yu (2018-11-23)

從該討論串，以及後續追加的其他討論看來，「賺錢」算是簡潔扼要又難以反駁的「成效」衡量標準。畢竟，這是商業世界。

只不過，「賺錢」畢竟已經是落後指標了，有流程改善意識的人，應該要更關注領先指標。

「錢」是很重要的價值，但「窮得只剩下錢」不該是軟體研發所追求的價值。

因此，當時我給的簡短回答是：

TL;DR　對於「價值」是否有增益。

回頭看看當初導入敏捷的痛點及原因，找出起初認定（或誤認）的價值是什麼。尤其是：這所謂的「價值」，是否可追溯至敏捷宣言或 Modern Agile 四層面。若追溯不了，或許一開始就投錯藥方了。

導入敏捷後，是否在敏捷宣言或 Modern Agile 四層面有所進展。進而檢討：這些進展，是否有對應到當初導入敏捷的痛點及原因。

在導入敏捷之初，或者說，在評估是否要導入敏捷之初，其實應該早就握有一票沈痾清單了。這份沈痾清單，就是大家最在意、最想要增益的「價值」。

沈痾清單，初期常會以「落後指標」形式來界定；但這還不夠。對於大家最在意的一些落後指標，還需要更進一步，研究出具有強烈因果關係的「領先指標」，才能夠發揮高槓桿的改善。

什麼才是敏捷圈子所認定的價值，以及對應的指標，尤其是領先指標？

來看看三本經典的說法吧。

敏捷專案儀表板

Scrum 發明人 Jeff Sutherland 及 Ken Schwaber 合著一本小書《告別瀑布，擁抱 Scrum》，第七章介紹敏捷工作室可採用的評估指標，用來「追蹤和改進專案績效，建置專案和管理報告，追蹤專案歷史，反映目前趨勢，評估工作室的成本和獲利，以此來確定是否需要擴張或縮小工作室」：

Scrum studio dashboard

生產效率 (Productivity)：利用特定數量的資金，所完成的業務功能的單位個數。
品質 (Quality)：軟體缺陷個數。
價值 (Value)：軟體開發中，投資的每一塊錢，為組織創造價值的效率（用百分比表示）。

請思考一下，這些算是領先指標，還是落後指標？與「賺錢」之間有強烈的因果關係嗎？

衡量敏捷的成功

《洞悉敏捷》第八章，介紹四個度量維度，作為衡量敏捷效能的框架：

快速性 (do it fast)：生產力、回應性 (responsiveness)。
正確性 (do it right)：品質、客戶滿意度。
及時性 (do it on time)：可預測的交付節奏。
持續性 (keep doing it)：員工滿意度。

請思考一下，這些算是領先指標，還是落後指標？與「賺錢」之間有強烈的因果關係嗎？

敏捷輪盤

《The Great ScrumMaster 中文版》第六章很懇切地提醒：

在開始改變你們的工作方式之前，先搞清楚變革原因會是個好主意，不要只是因為它是個新潮的東西就開始著手去做。

你們目前的強項有哪些？瓶頸是什麼？你期望的結果是什麼？如果這些期望不夠高、不夠好，那麼或許你還沒準備好面對變革。

本章接著介紹 12 個度量維度，幫助我們判斷現在是否為變革的好時機：

敏捷輪盤 (Agile Wheel)

書中將這個「敏捷輪盤」視為團隊共識的探詢工具，我則進一步將它視為敏捷效能的指標：

上市時間。
客戶滿意度。
從客戶取得的回饋。
交付的可預期性。
團隊健康。
團隊合作。
與他人的溝通。
效率。
生產力。
品質。
持續改善。
對改革的反應。

請思考一下，這些算是領先指標，還是落後指標？與「賺錢」之間有強烈的因果關係嗎？

價值

看了三本經典條列的 N 項敏捷的度量指標，可以回頭審視文章開頭的大哉問了。

敏捷，對於「價值」是否有增益？

但在試著回答這問題之前，請先試著釐清一個核心議題：什麼才是敏捷圈子所認定的「價值」？

如果你嘗試將《告別瀑布，擁抱 Scrum》、《洞悉敏捷》、《The Great ScrumMaster 中文版》列的 3 + 4 + 12 項價值指標分類，不難看出，敏捷，不僅著眼於百米衝刺的短期成效，更著眼於馬拉松的長期績效。

敏捷，是一種巧妙的均衡感。

這種均衡感，約略可對應到 Modern Agile 四層面：

Make People Awesome
Make Safety a Prerequisite
Experiment & Learn Rapidly
Deliver Value Continuously

這種均衡感，也像極了《投資前的精準判讀》提出的永續事業模型 (model of a sustainable business)。¹

一言以蔽之：在團隊中，如果看不到這種均衡感，那麼，鐵定不是敏捷。

所以，在談要不要敏捷之前，務必誠實自問：這種均衡感，是你想追求的嗎？

若回答「是」，再試著找出這種均衡感的領先指標吧。

「判準與指標」系列文章

❹ 敏捷的價值與指標

從小提問看企業價值 ↩︎

Agile PMO

Thu, 15 Nov 2018 08:00:00 +0800

“Project” 一詞，儼然成為 agile 及 DevOps 圈子的禁語。

譬如說，敏捷祖師爺 Martin Fowler 的網站有一篇 “Products Over Projects” 文章，DevOps 巨著 The DevOps Handbook 第 7.7 節的篇名叫做〈投資於服務和產品，而非專案〉。最近甚至還有一本新書，直接取名叫做 Project to Product 叫人棄暗投明呢。

見微知著。這個圈子，褒 product，貶 project，是政治正確的常模。 ¹

這個圈子，對於 “project” 反感，對於素來予人控制與監管印象的 “PMO” (Project Management Office，專案管理辦公室) ² 就更反感了。

但 PMO 真的與敏捷水火不容嗎？

敏捷陣營的聲音

聽聽看 Scrum 領域三位大神的說法吧。

頭兩位大神 Jeff Sutherland 及 Ken Schwaber 是 Scrum 發明人。他們合著一本小書《告別瀑布，擁抱 Scrum》，言簡意賅，完全是務實的經驗談。附錄Ｃ〈企業級敏捷攻略〉專門探討敏捷擴展的議題，難得看到兩位老爹發表與其他基本教義派不同的接地氣觀點。其中對於 “project” 的看法是：

Scrum 避免使用傳統的「類」瀑布式的專案計畫，但是策略性的日常專案管理的本質是堅定不移的。高級成員需要觀察每個團隊各自的 iteration 和發佈計畫，才能全面的評估整個專案所處的狀態。

他們也進一步闡述遠光燈的觀點：

Scrum 是追求「近期可能性的藝術」，而不是詳細預測未來 6 到 12 個 sprints 內應該交付什麼的黑色藝術。但隨著團隊的擴大和增加，為了未來較遙遠的 sprint 做額外嚴謹的分析，將有助於避免日後需要對架構做過多的重構。為了能將系統架構未來可能的演變方向看得更清楚，進行額外的發布計畫也是合適的。因此，sprint 計畫會議中，可以「看看過去的幾個 sprint」，也可以進行一些「萬一」(what-if) 的計畫，如此將能夠協助團隊權衡產品待辦清單，並向發起者傳達一個更合理的願景和產品路線圖。

Ken Schwaber 創立的 Scrum.org 培訓機構，也刊登過一篇 “The Agile PMO” 文章，說明他們對於 PMO 並未排斥。

第三位大神 Mike Cohn，是 CSM/CSPO/CST 等認證的主辦機構 Scrum Alliance 的共同創辦人，著作等身，都是敏捷領域的經典 ³。最近也在他的機構 Mountain Goat Software 開辦很精彩的 Better User Stories 線上課程，是非常活躍的 Scrum 培訓師。

在敏捷領域，Mike Cohn 雖然是祖師爺等級的人物，但不是基本教義派。譬如說，雖然 “project” 一詞儼然成為這圈子的禁語，但他可不這麼認為：

Projects provide a planning horizon that is longer than a sprint—typically in the range of two to six months. This “definite beginning and end” that is focused on a “unique product, service or result” encourages product owners to select truly important things to work on rather than whatever some customer or salesperson screamed about yesterday.

I always encourage product owners and their teams to identify a milestone they are working toward that is longer than a single sprint.

Projects remain a useful construct. They provide a motivation to accomplish something grander than could be done in a single iteration.

— “Is It Time to Stop Thinking about Projects?”

畢竟 milestone 這種策略控制點的設置與控制，原本就是專案管理知識體系的擅長之處。

他甚至鼓勵將傳統上 PMBOK 重視的某些活動，引進敏捷開發的節奏中：

Becoming agile does not mean we need to throw out everything we’ve learned over the past 100 or so years of doing project management. Some things—project kickoff meetings included—remain valuable.

Risk management is not formally defined as part of agile frameworks like Scrum. And that’s understandable as a lot of risks do go away (or get exposed) with the short iterations common to agile. But there are still projects that benefit from lightweight but explicit risk management. I suggested starting that during the kickoff meeting.

— “Advice on Conducting Agile Project Kickoff Meetings”

三位大師的論述，像極了《神鵰俠侶》中「不滯於物，草木竹石均可為劍」的境界，大師風範，令人佩服。

PMO 陣營的聲音

也來聽聽看 PMO 領域的說法吧。

PMO 並不是像敏捷基本教義派陣營口中那麼僵化守舊的。像 2013 年《業務驅動的 PMO 最佳實踐》一書主張，有成熟敏銳度 (maturity acumen) 的 PMO，需要根據專案類型與管理方法兩個維度，將組織層級的專案管理分成四個象限，並以宏觀視野統籌處理：

組織範圍的專案管理

至於最正宗的專案管理國際組織 PMI 是怎麼想的呢？

在 “An agile PMO transformation” 一文中，列舉 “agile PMO” 的「八要八不要」，並且主張：

For many organizations, using the words “PMO” and “agile” in the same sentence could be considered an oxymoron. It may come as a surprise to expect the PMO to lead the agile transformation, but we think that for organizations to reach the full potential of the approaches outlined in this update, such as managing the enterprise-level portfolio and creating stable teams, the PMO will need to be engaged and lead the way.

If PMOs are ready and willing to transform, they can greatly influence the success of their organization’s agile transformation.

可見，狀似傳統僵化的 PMO，其實也已經正視敏捷變革。因此，我們不時可看到新名詞 “agile PMO” 出現，連管顧公司也湊熱鬧湊出一個 “Lean-Agile PMO” 呢。⁴

正名？

敏捷陣營常會對 “agile PMO” 一詞嗤之以鼻，認為只是換湯不換藥。

因此，Mike Cohn 挑明地說，為了避免困擾，不妨考慮換個名字：

A project management office (PMO) that is engaged in and supportive of transitioning to Scrum can be a tremendous boon.

Many PMOs choose to rename themselves to better match their revised role. Though there is no one standard name, I have heard these most frequently: Scrum center of excellence, Scrum competence center, Scrum office, and development support.

Many people have become cynical and suspicious of name changes and of well-crafted names. That cynicism will be directed at the PMO if it is renamed but remains otherwise unchanged. So, whatever it’s called, the PMO that supported the organization’s sequential development process will need to change more than just its name to succeed with Scrum.

— “The Roles of the Project Management Office in Scrum”

PMI 在 Agile Practice Guide 第六章也提及 “center of excellence” 一詞：

Some organizations have been transforming their PMOs into agile centers of excellence

至於崇尚極簡作風的 LeSS 陣營，則主張廢棄 “project” 或 “office” 字眼，改用 “Head of Product Group” 概念，以及 “Go See” 管理：

No project/program organization or project/program management office (PMO). No support groups such as configuration management, continuous integration support, or “quality and process”.

Head of the Product Group — Most LeSS organizations still have managers including a “head of product group.” They support the teams by Go See and help them remove obstacles and improve. LeSS organizations don’t have matrix structures and there are no “dotted-line” managers.

“Head of Product Group” is called differently in different organization, here we mean the hierarchical manager of all the teams.

— LeSS Organizational Structure

看了這麼多論點，你認為 “agile PMO” 是噱頭嗎？

儘管敏捷圈子普遍褒 product 而貶 project，但有趣的是，The Scrum Guide 對於 sprint 卻有這種類比：“Each Sprint may be considered a project with no more than a one-month horizon 每個 Sprint 可視為一個不超過一個月的專案。” ↩︎
想在五分鐘之內快速了解 PMO 是什麼東西，可讀讀 Joe 寫的這篇文章：What is PMO。 ↩︎
Mike Cohn 在敏捷領域的名作：User Stories Applied: For Agile Software Development (2004)、Agile Estimating and Planning (2005)、Succeeding with Agile: Software Development Using Scrum (2009)。 ↩︎
The Many Benefits Of An Agile PMO: What You Should Know ↩︎

接班人計畫

Thu, 08 Nov 2018 08:00:00 +0800

彼得・杜拉克説：經理人的基本任務，除了平衡長短期的需要外，最重要的就是培養下一代的經理人。¹

諾爾・提區説：成功組織會贏，贏在它的領導人不斷栽培組織上下每個層級的其他領導人。²

其實我很早就在默默做這件事了。畢竟以長遠來看，堅實的中階主管層，決定一個組織能走得多久多遠。

就像此文所說：

只要组织内部没有足够数量的领导，一个庞大的组织是无法在短时间内发生改变的。国家也好，大企业也罢，要想进行改革，需要的不是一个具备卓越能力的明星领袖，而是具备领导能力的人超过一定的数量。

想要「具備領導能力的人，超過一定的數量」，是需要佈局的。

佈局

我 2017 年初就開始佈局了，先從共同語言開始³：

（2017 年）三月，自掏腰包，拿《三年後，你的工作還在嗎》及〈沒了名片你還剩下什麼？新書發表演講筆記〉當部門內的讀書會材料，激發大家的工匠魂及總管魂。

非正式調查，大家對其中的〈職場自由之道：第一天就為離開做好準備〉觀點最有感——很合乎我的預期。

共同語言有了，之後再推動一些事情，就名正言順多了。

最近規模比較大的，是在部門內舉辦第一場 Open Space Technology (OST；開放空間會議) ，提煉大家對於 2019 年的部門願景：

部門 OST 活動，一隅 (2018-10-19)

從活動過程及結論中，可看出某些人在心態上已經做好承接更大責任的準備。因此，我可以更積極進行這件事了。

俗氣一點講，是副手計畫；吊書袋的講法，是接班人計畫 (succession planning)。

「一對一關懷式指導」

我所崇敬的作家 Marcus Buckingham 在 2017 領導力研習會 (Global Leadership Summit) 給的【重塑績效管理】演講中⁴，提出很簡單卻很有效的 “frequent strengths-based check-ins” 建議：

frequent strengths-based check-ins

There is one silver bullet that forms the foundation of a great team: frequent strengths-based check-ins about near-term future work. Every week. One-on-One.

In the one-on-one, managers should ask just two questions:

What are your priorities for the week?

How can I help?

One year is made up of 52 little sprints. Your job is to make sure sprint #37 is as energized and focused as sprint #1.

This is not feedback. There is all sorts of research that shows we go into “fight-or-flight mode” in the face of feedback. People don’t want feedback; they want attention and coaching.

Leaders should not manage more people than they can honestly have a one-on-one check-in every week. This is leadership.

我想，這種近身的教練模式，正是接班人計畫所需要的落地作法。

材料

華倫・班尼斯在《領導，不需要頭銜》說道：「領導課程只能教你技巧，無法傳授個性或眼光。」

這也是接班人培訓困難之處。

領導者：個性和眼光

原本是想直接套用現成的《帶人的技術 │ 新手主管的必殺訣竅》線上課程內容。但稍微研究了一下，這線上課程比較適合自學，不太適合近身的教練模式——除非搭配適當的補充材料。

因此，我還是回到自己慣用的方式：指定讀物，個案研討，行動，回饋。

培育對象是中階主管，所以我只選擇簡單易讀的，不那麼高大上的材料。

至於具體的培訓議題順序，則還在研究。或許也不是獨自研究就能成形的，應該要與接班人共同議定吧。

嗯，就這麼辦。

Photo credit: https://unsplash.com/photos/Y4kw_G_xhsQ

2018-12-24 後續發展

我又另外企劃了一對多形式的〈【主管的修練】讀書會〉。

〈人才培育與傳承的策略思維〉，哈佛商業評論・中文版，2008 年 10 月號。 ↩︎
「接班人」培育計畫，該有的正確觀念 ↩︎
以提問角度看 TOC 聚焦五步驟 ↩︎
Session notes of GLS 2017: Session 5 – Reinventing Performance Management by Marcus Buckingham. ↩︎

從小提問看企業價值

Fri, 02 Nov 2018 08:00:00 +0800

如何選人？

我有一篇舊文〈專業態度的養成〉是針對中低階領域的提問重點；善用這些切入點，可挖掘出人才潛力股。這也是年度績效面談時，我會提問的重點之一。

那麼，中高階領域呢？如何選領導者，選團隊，或者更廣泛一點講：如何選公司？

我有兩個私房切入點，剛好是兩本書教我的。

改變的角度

第一本書是《關鍵領導九十天》。這是我每隔幾個月就會重溫的書。

關鍵領導 90 天

改變，是中高階人士常會面對，甚至需要主導的議題。此書提出一套「STARS 模式」來分析所處的改善／改變／改革局勢，其中「界定你的學習程序」工具很實用：

為了使你在學習上的投資獲得最高的報酬，就必須從眼前大量的資訊中，有效地汲取可行的洞見，才能集中力量，營造收集資訊、分析、假設、測試的良性循環。

你該如何收集初期的引導問題清單？首先，要針對過去、現在、未來提出問題。事情為何會那麼做？那樣做的理由，今天是否仍站得住腳？狀況是否改變，是否未來該有不同的做法？以下針對這三方面，提供了問題範例。

以這套引導問題清單為基礎，再混搭下一本書的模型，可營造出絕佳的說故事時間。圍繞這類事例，正是了解這位領導者，這團隊，或者更廣泛一點講：這間公司的絕佳切入點。

永續的角度

第二本書是《投資前的精準判讀》。畢竟，針對領導者、團隊，甚至公司的價值判定洞見，誰能像價值投資教父華倫・巴菲特那樣經得起考驗呢？

《投資前的精準判讀》歸納巴菲特的洞見，提出一個很重要的羅盤：

永續事業模型 (model of a sustainable business)

這個永續事業模型 (model of a sustainable business)，連指數型基金之父 Jack Bogle 都稱許道：「這張圖像哥白尼一樣，顯示了太陽真正的位置。」

有時候，連企業掌舵者也未必很清楚知道這一點，遑論各層級的負責人。

搞懂這個，搞懂這間企業對這事業模型的立場，再談推動改善／改變／改革吧。你所推動的事情，若不和這間企業自己的永續事業模型對齊，你只是努力地在當另一個唐吉訶德。

更極端的是，如果這間企業根本沒有自己的「永續」想法，那麼，你連唐吉訶德都不必去當了，直接跳船吧。畢竟，孫子兵法說：

故校之以計，而索其情。曰：主孰有道，將孰有能，天地孰得，法令孰行，兵眾孰強，士卒孰練，賞罰孰明，吾以此知勝負矣。將聽吾計，用之必勝，留之；將不聽吾計，用之必敗，去之。

夫未戰而廟算勝者，得算多也；未戰而廟算不勝者，得算少也。多算勝，少算不勝，而況無算乎！吾以此觀之，勝負見矣。

尋找線索

《投資前的精準判讀》的模型及分析角度很有用。

這本書教我們如何從對話或各種一手資訊中尋找線索：

尋找文化線索

也教我們如何從對話或各種一手資訊所體現的溝通風格中，洞悉難以言說的深層事物：

溝通風格

好書像寶藏，看你怎麼轉化運用。

譬如說，面談時，不要盡是在瑣碎的事情上面打轉。試著用具體的實例，探出深層的永續事業層面，這才是重點。

譬如說，專案計畫書、產品路線圖、impact map、product backlog，亦可用這些角度去測出背後的永續事業理念；或者⋯⋯沒有永續可言的理念。

兩本有趣的私房書，給大家參考。

Lean Startup 的判準

Thu, 01 Nov 2018 08:00:00 +0800

《商業周刊》第 1615 期，有一篇總編輯的話〈拖鞋戰法，先做了再修！〉：

網路時代的敏捷開發法，強調「先做了再修改」，中心思想不是「預測」(predict)，而是「順應」(adapt)，讓市場告訴你如何改變。因此「先做出可用、但不完美的產品」後，直接拿到市場測試，根據顧客意見，再回頭修改，反覆這個循環，直到產品上市。

在快時代下，過去強調「凡事先想透徹」的戰法出現破綻，步伐顯得沉重，而「先做了再改」的敏捷戰法則相對靈活。講到這裡，快低頭看看，你穿的是皮鞋還是拖鞋？

這下子 PO/PdM 可高興了，拿此文所謂「拖鞋戰法」當立論基礎，向團隊臃腫的 Scrum/Kanban DoD 磨刀霍霍。這也在台灣 Scrum 社群引發熱烈討論。

我留的評論是：

其實，這仍然是方法論判準的老問題。

敏捷有許多流派，不是只有 Scrum 才叫正宗，不是只有 Kanban 才叫適用。

某些 PO 心中所想的，其實既不是 Scrum 也不是 Kanban，而是 lean startup（精實創業）——儘管他們自己也不知道。

選錯方法論，選錯判準，自然扞格不入。

先搞清楚 PO 內心真正要的方法論，搞清楚這方法論背後的世界觀，搞清楚判準，才能進行攻防對話。

Lean Startup 的源流

Lean startup 路線，比較正式的起源，據 Steve Blank 在哈佛商業評論〈精實創業改變全世界〉所述：

2004 年，我投資一家由艾瑞克．萊斯 (Eric Ries) 和威爾．哈維 (Will Harvey) 成立的新創公司，並提出一個但書，我堅持他們必須上我的課，我才會投資。

艾瑞克很快就發現，科技產業傳統採行的「瀑布式開發法」那種線性開發方式，應該改為反覆修正、敏捷回應的開發方式。艾瑞克也看出這套新創業準則，與大家耳熟能詳的、豐田「精實生產」系統之間的共同點，因此，將這套結合顧客開發與敏捷反應的方法稱為「精實創業」。

這些工具因為一連串的暢銷書，而逐漸廣為人知。

2011 年，Eric Ries 總結自身及他人經驗，出版《精實創業》一書，替這種路線正式定調。身為教父，他也策展了一系列經典之作：

Lean startup 理念貌似常識，但若真的要有正確不偏頗的理解，這些輕薄短小的書都是必備讀物，勿等閒視之。

Lean Startup 的判準

Lean startup 在執行時，的確常會與 Scrum 或 Kanban 混搭。像《精實執行》第二版第 13 章如此建議：

控制你的功能管線，限制同時間被處理的功能數量，並且僅於你已驗證過所部署之功能具有正面或負面的影響之後（亦即，產生經驗學習），才著手處理新功能。進行這項工作的好方法，就是運用 Kanban。

但在方法論層面，仍然該有所區辨，尤其會涉及到接下來要談的嚴肅話題：判準。

Lean startup 理念貌似常識，但真正核心的判準，未必都被清楚地認知。

我個人認為，lean startup 的判準，就是 Ash Maurya 在《精實執行》書中所勾勒的三大風險、四大階段。如果以 Ash Maurya 發明的精實畫布 (lean canvas) 攤開來看：

《精實執行》有系統地消除三大風險

三大風險、四大階段，彼此的判讀基準如下：

階段	產品風險	顧客風險	市場風險
⓵瞭解問題	你在解決什麼問題？	競爭對手是誰？	誰感到痛苦？
⓶定義解決方案	誰感到痛苦？	你將如何解決這些問題？	定價模型為何？
⓷定性驗證	這項產品有什麼令人無法抗拒的地方嗎？	你有足夠的顧客嗎？	價格合適嗎？
⓸定量驗證

至於 lean canvas 的各個空格，該如何制訂質性與量化的指標，就得量身定做了。

看到這裡，你認為本文開頭所提到的「拖鞋戰法」，是落在 lean startup 哪一個格子呢？

合乎現實嗎？

要走 lean startup 路線，就要弄清楚 lean startup 的判準，並致力於判準的實踐品質，這是將方法論落地實施的重要關鍵。

問題是：這個判準，合乎現實嗎？更進一步的問題是：是怎樣的世界觀，才會催生如此的判準？

Lean startup 的世界觀就是，我們對萬事萬物的認知，充斥仍待驗證的粗糙假設。能用最少的投入成本，降低最多的不確定性，就是最好的學習。

認清這個判準，以及這個判準背後代表的方法論及世界觀，有助於你成為高性價比的策略執行家。

或許更重要的是，你支持這種方法論，卻又得與一知半解者合作，你就應該在這些判準的層次上，盡一切努力守護這些判準的認知與實踐品質，並最大化這些判準的價值能見度。

在判準的層次動工，比各自表述的爭辯更有力。

「判準與指標」系列文章

❶ 軟體開發，除了方法論，還有⋯⋯

❸ Lean Startup 的判準

❹ 敏捷的價值與指標

❺ DevOps 的價值與指標

❻ 如何衡量敏捷對於軟體研發效能的利益？

敏捷的判準

Wed, 31 Oct 2018 08:00:00 +0800

今年暑假，我第一次去台中的國美館，參觀 2018 年全國美術展。

這年度盛會，分成油畫、水彩、版畫、水墨等十大類。大開眼界之餘，也不禁有個奇想：為什麼要分這麼多類別來競賽？為什麼不選出一個跨十大類別的首獎，就像武林盟主一樣？

很外行吧！畢竟，油畫的美感判準，與版畫的美感判準、攝影的美感判準，本來就有很大不同，不能草率化約在同一把尺來衡量高下境界。

把照片拍得像油畫，就能夠贏過油畫嗎？

我們有選擇美術媒材的自由。一旦擇定媒材，就要正視及尊重該媒材的運用手法、該媒材營造的世界觀，以及該媒材表現境界的判準。

軟體開發，亦然。

前一篇文章初步提到方法論與判準之間的關係，這一篇文章，就來繼續探討幾種常見軟體研發方法的判準。

「多元典範的軟體開發取向」認為：我們可以視問題的性質，採取瀑布或敏捷軟體開發典範。

然而，採取某種典範，不但要說明自己的方法論立場，而且要採用該一典範的方法論判準。

瀑布方法的判準

敏捷三叔公 David Ko 在〈原來瀑布老祖是想做敏捷啊〉考古文章中指出，瀑布式開發始祖 Winston W. Royce 在 1970 年發表的會議論文中，總共提出兩種想法，一種是後來被世人普遍稱為~~萬惡的~~ waterfall 的版本，另一種則是帶些更務實風格的修正版。

兩種想法，背後的核心觀念，其實都是 phase gate 或 stage gate 的 “gate” 機制：

Royce 1970 - Managing the development of large software systems: concepts and techniques

以上圖來說，圓圈圈的部分，就是在各個階段 (phase/stage) 負責把關的守門員：

PSR: Preliminary Software Review
CSR: Critical Software Review
FSAR: Final Software Acceptance Review

這就是瀑布方法論的判準。

合乎現實嗎？

要走 waterfall 路線，就要弄清楚 waterfall 的判準，並致力於判準的實踐品質，這是將方法論落地實施的重要關鍵。

問題是：這個判準，合乎現實嗎？更進一步的問題是：是怎樣的世界觀，才會催生如此的判準？

Waterfall 的世界觀就是，萬事萬物，都有一個自然的、可預測的線性執行順序。在這些自然的線性順序當中，會有一些關鍵的控制點，或者像《利潤的故事》所用的「地景的控制點」妙喻：「有些地方，就是比其他地方重要」。

地景的控制點

這些「地景的控制點」，就是瀑布方法 phase gate 判準之所在。

不可否認，的確有人在這種方法論、世界觀、判準底下活得很好。認清這個判準，以及這個判準背後代表的方法論及世界觀，有助於你和這類人種互動。

或許更重要的是，你不同意這種方法論，卻又得與這類人種合作，你就應該在這些判準的層次上，挑戰關心對方對這些判準的認知與實踐品質。

在判準的層次動工，比各自表述的爭辯更有力。

Scrum 的判準

儘管 Scrum 是很精簡的框架，但真正核心的判準，未必都被清楚地認知。

我個人認為，Scrum 的判準，就在於 increment，或者更具體一點講：PSPI (potentially shippable product increment)。

The Scrum Guide (2017 版) 說：

Scrum 使用疊代和逐步 increment 的方式，來最大化可預測性和控制風險。

在 Sprint 結束時，increment 是一種可檢視，完成的工作實體，並可支持經驗主義。

簡言之，Scrum 是以 increment 作為載具、「地景的控制點」，藉以反映出透明性、檢視性、調適性這三大主張，藉以最大化可預測性及控制風險。

並不是隨隨便便任何一個軟體中間狀態都夠資格稱為 “increment”，而是有標準的。Scrum 是很精簡的框架，將這標準交由團隊來定義 (DoD; definition of done)，但能否嚴守這個承諾共識，決定了 Scrum 實踐的成敗：

Scrum Teams 用疊代和逐步 increment 的方式交付產品，將回饋的機會最大化。用逐步 increment 的方式交付「完成」的產品，可以確保一直提供一個潛在可用的產品版本。

真正執行的人員和檢視 increment 成果的人員，需要對「完成」之定義，有一個共同的認知。

在 Sprint 的最後，新的 increment 必須是「完成」的，這意味著它必須是可用的狀態，並符合 Scrum Team 對於「完成」之定義。

在 Sprint 過程中，對於品質的目標不可以降低。

簡言之，Scrum 的判準，就在於 increment 的定義，以及能否在各個疊代過程中，捍衛並精進這個 increment 的整全狀態。

合乎現實嗎？

要走 Scrum 路線，就要弄清楚 Scrum 的判準，並致力於判準的實踐品質，這是將方法論落地實施的重要關鍵。

問題是：這個判準，合乎現實嗎？更進一步的問題是：是怎樣的世界觀，才會催生如此的判準？

Scrum 的世界觀就是，萬事萬物，都有一個自然的生物成長順序。或嬰兒，或幼童，或成年，在每一個當下，必然都是整全的生命個體。

認清這個判準，以及這個判準背後代表的方法論及世界觀，有助於你與其他物種分別為聖。

或許更重要的是，你支持這種方法論，卻又得與反對者合作，你就應該在這些判準的層次上，盡一切努力守護這些判準的認知與實踐品質，並最大化這些判準的價值能見度。

在判準的層次動工，比各自表述的爭辯更有力。

2019-02-11 補充

Mike Cohn 在新文章 Why Agile Teams Put So Much Emphasis on Being Done Each Iteration 中，對這論點做了更詳細的說明。

Kanban 的判準

Kanban 是極度精簡的框架，甚至連「框架」都不太能夠稱得上。因此，他的判準很容易辨識，也很容易衡量，那就是 Kanban 的核心規則：拉動系統 (pull)、WIP 限制。

問題是：這個判準，合乎現實嗎？更進一步的問題是：是怎樣的世界觀，才會催生如此的判準？

Kanban 的世界觀就是，萬事萬物，都有一個自然的流動順序。我們所該做的，就是讓這流動，以小批量的方式，毫無阻礙地順流而下。

認清這個判準，以及這個判準背後代表的方法論及世界觀，有助於你掌握這個「入門毒藥」(gateway drug) ¹ 的殊勝之處，以及⋯⋯潛在的問題。 ²

或許更重要的是，你支持這種方法論，卻又得與反對者或不可知論者合作，你就應該在這些判準的層次上，盡一切努力守護這些判準的認知與實踐品質，並最大化這些判準的價值能見度。

在判準的層次動工，比各自表述的爭辯更有力。

善用判準作為施力點

判準，是將方法論落地實施的重要關鍵，也是方法論歧見的槓桿解。

畢竟，方法論，甚至背後的世界觀，不是那麼容易就撼動得了。

試問：你對自己採用的軟體開發方法論，了解它的判準嗎？

試問：你對其他人採用的不一樣的軟體開發方法論，也了解它的判準嗎？

理解別人的判準，善用判準作為施力點，在判準的層次動工，比起辯論不同方法論之間的優劣，更有建設性，也更能推動事情的前進。

「判準與指標」系列文章

❷ 敏捷的判準

軟體開發，除了方法論，還有⋯⋯

Thu, 25 Oct 2018 12:22:16 +0800

在某些人眼中，「敏捷」是狂熱份子聚集的邪教。

或許是被困在守舊勢力太久了，敏捷信徒不只有改變世界的熱情，更有捨我其誰的急迫感。不過，在傳播理念或推動改變時，若操之過急，忽略對方所處的情境、歷史及歷程，就很難有建設性對話。在這守舊勢力龐大的世界，自然很容易陣亡。

但這還只是表象。歧見，單靠對話仍不足以化解，更需要在方法論層次達到理解，方可進退有據。

尤其在看過《社會科學的理路》之後，我領悟到一些根源問題及槓桿解。

圖一　《社會科學的理路》第一版 (2001) 及第四版 (2018)

方法論形塑世界觀

我們都在採用方法論，不管我們自覺或不自覺。

瀑布模型是一種方法論，敏捷是一種方法論，Scrum 及 Kanban 則是敏捷方法論底下更具體的實踐作法。

為什麼會決定採取某一種方法論？原因可能很多，本文不予探討。本文想談的是，採取某一種方法論，就會逐漸被該方法論所形塑的世界觀所包圍，以及接下來的連鎖效應——不管我們自覺或不自覺。

論到方法論及世界觀，我想要引述《社會科學的理路》的見解。

本書作者黃光國教授，是台灣社會心理學界的大老。他花了將近十年的工夫寫成本書第一版 (2001 年)，析論二十世紀發展出來的五種科學哲學主要典範之間的關聯。退休後推出的第四版 (2018 年)，將原本具有歷史意義的第一章整個抽換掉，很可惜，所以我仍然留著第一版。

《社會科學的理路》，從科學哲學角度指出：

圖二　方法論與世界觀

看起來有點抽象，讓我們從「軟體開發流程」的角度來照樣造句，就會茅塞頓開：

任何一種軟體開發流程所主張的「本體論／認識論／方法論」，構成了該一開發流程的「世界觀」，它在性質上是一種形而上學的預設，是由軟體開發團隊的基本信念所決定的。
一個軟體開發者，對於方法論的回答，必然會受到其「本體論／認識論」立場的限制，而不能隨意選擇。當他決定採用某種方法論的時候，他也必須同時接受其「本體論／認識論」預設。

所以，採取瀑布模式的人，採取敏捷模式的人，兩群人的世界觀，以及信念、預設，是非常不一樣的。

想合作，或是想進一步改變對方，就得先認清這一點：你們的對話，是不同世界觀的對話。

方法論之外，還有判準

瀑布模型是一種方法論，敏捷是一種方法論。

不同方法論，有優劣之別嗎？

或許有吧。但更常見的事實是：不同方法論，各有擅長的場域。

《社會科學的理路》第一版的第一章，從科學哲學角度指出：

圖三　典範的判準

文中點出很重要的觀念：「判準」。

看起來有點抽象，讓我們再從「軟體開發流程」的角度來照樣造句吧！

我是贊同「敏捷運動」的。然而，我卻認為：「敏捷／不敏捷」不能夠作為軟體開發流程好壞的判準。
我主張的「多元典範的軟體開發取向」認為：我們可以視問題的性質，採取瀑布或敏捷軟體開發典範。然而，採取某種典範，不但要說明自己的方法論立場，而且要採用該一典範的方法論判準。
在我看來，軟體開發而沒有判準，是非常不可思議之事。

判準，是將方法論落地實施的重要關鍵，也是方法論歧見的槓桿解。

試問：你對自己採用的軟體開發方法論，了解它的判準嗎？

試問：你對其他人採用的不一樣的軟體開發方法論，也了解它的判準嗎？

先賣個關子。下一篇文章，再分別針對瀑布與敏捷取向，談談我所認為的方法論判準。

「判準與指標」系列文章

❶ 軟體開發，除了方法論，還有⋯⋯

從系統思考看 DevOps：以 microservices 為例

敏捷之途無他，刻意練習而已矣！

Wed, 19 Sep 2018 23:25:01 +0800

親愛的學員們：

感謝你們 9/13 ＆ 9/14，一起共度充滿歡笑的兩日。

課堂上，我多次提醒：請大家回去之後，要持續刻意練習；自練，對練，都好。

你可能會有疑問：

要刻意練習什麼？
要如何刻意練習？

怕細節沒講清楚，我用這篇文章來補充吧。而且，就用我們在課堂上玩過好幾次的 impact mapping 來展開這議題吧（你看，我這不也是一種刻意練習嗎？）。

Goal

這番刻意練習的總目標是：成為更好的 Scrum master，引領團隊達成他們被賦予的商業目標。

Actors

Scrum master 有多種樣貌。

在 The Great ScrumMaster 書中提到 Scrum master 的核心能力有：

心態模式則有：

在 “Evolution of the Scrum Master” 文章中提到 Scrum master 的升級路線：

在 “The 8 Stances of a Scrum Master” 及 “Myth: The Scrum Master is a Junior Agile Coach” 文章中列出 Scrum master 的八種姿態：

Servant leader
Coach
Facilitator
Teacher
Mentor
Manager
Impediment remover
Change agent

這是窮舉不盡的。短短兩天的課堂，我只講解其中極為重要的三項，並在 Q&A 時淺淺帶到第四項：

Teacher：教學輔導與分享經驗。
Facilitator：掌控討論流程，確保會議如質進行。
Coach：成員個人的成長，團隊的自組織、責任感與所有權。
Change agent：在組織的各個層面，引領影響變革。

單以這幾項來說，就已經很難樣樣到位了。

所以，需要刻意練習。

Impact

◉ Teacher

身為敏捷原理與實踐的專家，越能夠傳道授業解惑，就越能有效達成前述的總目標。

整整兩天課程，你們已經親自體會到敏捷圈的 “teacher” 是何等樣貌了。

正如學員 LinChi 所說：

兩天的課程學到不少東西，透過遊戲反映現實工作的情況。有時用說的不一定有說服力，做中學的震撼比較大。

如果你覺得這種 “teacher” 樣貌的效果極好，那麼，回去面對自家團隊時，也會想試試看嗎？

這就需要刻意練習。

刻意練習的素材，可先從 Kanban in Action 第 13 章下手。先模仿，照表操課，謹守「高頻 PDCA 循環」心法，日後你自然會湧現改編及創造的點子。或者，去上課，直接向第一流明師取經吧。

◉ Facilitator

許多人被不良職場習氣禁錮了，渾然忘記自己才是職涯的主人。身為敏捷精神的守護者，若是越懂得提供機會讓團隊成員自發湧現觀點，就越能夠孵育高效的自組織團隊，就越能有效達成前述的總目標。

記得嗎？在 1、2、3、7 這幾個單元中，我一直提醒：「這些寫在白板及便利貼上面的種種絕妙點子，完全都是你們大家自己想出來講出來的喔！我完全沒有主動教導你們喔！」這就是引導的魔力。

請試著回憶，整整兩天，我用了多少次 ORID 這個極度基礎的回顧手法？你也可以試著拆解我是如何用 impact mapping 這個貌似簡單的框架，橫跨兩日，貫串 4、8、9 這幾個單元。

如果你覺得這種 “facilitator” 樣貌的效果極好，那麼，回去面對自家團隊時，也會想試試看嗎？

這也需要刻意練習。

刻意練習的指引，可先從繁體版《誰說我們不能一起做決定》(2/e) 或簡體版《結構化研討：參與式決策操作手冊》(3/e) 下手，打好引導的基本功。接著，請翻閱 4、5、8、9、10 單元的講義，常常揣摩哪一個框架可以適用於當下的引導情境。也請多多觀摩體驗好的流程設計（譬如 Design Sprint），模仿，拆解，日後你自然會湧現改編及創造的點子。

◉ Coach

敏捷原理，說穿了，很單純，也很合理；但落地實施起來為何總是卡卡的？

正如學員 SamLi 所說：

關於敏捷與團隊相關的書目很多，但是能夠在自身的職場運用自如，可謂是知易行難。

很多時候，單純的「知」還不夠，還需要「行」的反覆淬鍊，甚至成為肌肉記憶。這就需要動用教練法。

身為團隊專屬的指導者，若是越懂得利用近距離即時指導的機會，持續提供客製化培訓，就越能夠鍛鍊出高效的自組織團隊，也就越能有效達成前述的總目標。

教練法，是個高明的技藝。

記得嗎？在 5、8、9、10 這幾個單元，我額外加重比例在主動示範及積極矯正上。原本構想是要以金魚缸手法，讓大家現場充分對練，也充分觀察。可惜課堂時間有限，無法完全照原本的構想進行，這就需要你們回去後刻意練習了。

教練法，我自己也還在探索，僅提供三本書給你們參考：

What to Do Next?

如果你所在的場域，有專家等級的 mentor，那麼，恭喜你。

如果沒有呢？

《刻意練習》給了很棒的建議：

若想進步，就得為自己創造機會。若沒有老師，就得自己設計一套練習活動。 (pp. 206–207)
先找出頂尖專家，弄清楚他們做了些什麼才能如此成功，接著發展出讓自己可以做到那些事的訓練技巧。 (p.148)
想在沒有老師的情況下有效練習一項技能，建議記住三個重點：專注投入、意見回饋、解決問題。將技能分成可以有效重複練習和分析的幾個部分，確定弱點何在，並找出解決方法。 (p.209)

私下揣摩。敏銳觀察。

私下練習。

同好對練。

參與社群。

找時機實際發揮。

有心的你，一定找得出適合你的刻意練習方法。並且在過程中，逐步發展出你的風格。

在這個世界上，你就愛一種東西，你就在你愛的這個東西裡把自己練到完美，練到無懈可擊，你因此尋得滿足，此外的一切其實無足輕重。你變得堅強，足以抵抗不時傾巢而來的寂寞，你變得勇敢，你學會拒絕周遭的喧譁與熱鬧，你學會簡單而嚴肅，你形成一種風格，唯你獨有。

— Quote: 劉大任，《強悍而美麗》

加油吧！

Scrum master 培訓系列

❶ 如何訓練一個新的 Scrum master？

❷ 敏捷之途無他，刻意練習而已矣！

❸ Scrum 認證模擬測驗的兩項啟發

❹ 敏捷啟航的專業基礎：共同語彙

思維的重量訓練

Tue, 04 Sep 2018 11:30:00 +0800

上週五【系統思考的四堂課・DevOps 特別版】，表定 7 小時，延長賽到 7.5 小時，感謝首梯公開班同學的熱情參與，共度刺激的一天。

課後仍持續收到提問，我挑選幾則統一回覆。

【系統思考的四堂課・DevOps 特別版】2018-08-31 課堂實況

有學員問道：「為什麼課前作業會挑選這麼難的題目？」

我承認，這兩份課前作業，有難度；但這難度是必要的。要有這樣的挑戰強度，才能反襯系統思考的威力。否則，簡簡單單就能破解的作業，為什麼還要花金錢花時間前來上課呢？

好吧，說正經的。要有這樣的挑戰強度，才能先將各位的思維肌肉稍微鍛鍊一下，負重訓練到能夠跟得上課程現場的思辨強度。

這門課，原本在我公司裡面是分成四個禮拜，每次 1.5 小時；個案研討素材，得以在四個禮拜的自發性小組討論活動去分散腦力負荷。現在，變成公開班，一整天 7 小時，腦力挑戰嚴峻。所以，把個案研討素材提前到正式上課前就讓大家咀嚼思考，課堂進行才會有效率。

（儘管如此，份量仍然沈重到哀鴻遍野。所以，第二梯公開班，我可能會拆成兩個半天舉行，一週 4 小時，隔週上。）

這種鍛鍊思維肌肉的方法，不是我發明的。大師在《司徒賢達談個案教學》p.191 如此解釋「長個案」與「短個案」的選擇標準：

缺乏工作經驗的人，應該用心研讀長個案，然後在複雜的情況下練習整合與重組資料、發掘問題，並依據資料分析的結果採取行動。此一程序對「練功」效果極好。

短個案的使用者，必須從有限的文字中進行許多邏輯推演，因此對個案中管理議題或產業相關的「互補知識」必須相當豐富，比較適合有經驗的中高階經理人。使用短個案的前提是：學員本來功力就有一定水準，而且由於必要的推論多，可以利用討論把他們的寶貴經驗萃取出來，尤其對忙碌的在職學員更是如此。

感謝大師背書。

有學員問道：「為什麼你的系統思考方法，要分因果關係圖與 CLD 兩部曲？」

其實這是限制理論暨豐田方法的專家稲垣公夫在《深思快想》這本奇書當中首先提出的，突破了我過去的盲點（詳見這篇文章），便將這實施觀點納入我的系統思考 SLR·CPI 方法論中。

如同我在講義上提到的，如果你骨骼精奇，天生就是練武奇才，或許可以一開始就直接從 CLD 切入。可惜，我發現，很多人基本功不太扎實，容易犯下過度簡化、倒果為因等邏輯謬誤。

CLD 是很犀利的工具，但也容易誤用，淪為替既有結論背書的橡皮圖章。

「有不得機得勢處，其病必於腰腿求之。」要提高系統思考的品質，還是得講究理則的起手式才是。否則，畫出的 CLD 再犀利，一堆就倒，有什麼用？

有學員問道：「該怎樣從因果關係圖當中抽取 CLD 的變數／變項？」

對初學者，我建議：大量觀摩精選範例。

鋪陳一次因果陳述，自己畫一次 CLD，對照範例，看圖說故事，檢討。休息一兩天，再覆盤。如此刻意練習一陣子，你會抓到 CLD 變數／變項的感覺。

當然啦，《第五項修練 Ⅱ・實踐篇》及《深思快想》也各有建議的手法，不妨一試。

有學員問道：「這方法似乎只能用來分析問題現況與原因，但似乎不能用來尋找解法？」

某方面來說，的確如此。但進一步來說，精準找到客觀局勢與根本原因，是否有助於激發你尋找槓桿解的專注力及創意呢？

再度借用大師的論點吧。《司徒賢達談個案教學》p.23 將狹義知識分成三大類：

結構性知識：各種變項間的「因果關係」，以及這些因果關係背後的理由、影響因果的因素等。
行動的程序性知能：採取行動、制定決策原則、研判下一步的知識與能力。
診斷的程序性知能：針對現象找出原因的知能。

套用這種分類，系統思考主要隸屬於「結構性知識」與「診斷的程序性知能」這兩大類。

《司徒賢達談個案教學》p.293 進一步說：

決策過程中的重要作法「找出前提、驗證前提」。

知識庫中「資訊」和「解決方案」的存量，通常遠多於「結構性知識」。然而當面對特定問題時，有時雖然想得到的可能解決方案很多，但未必知道應該如何選取；所掌握的資訊也很豐富，但未必知道哪些資訊才對解決此一問題最具有關鍵性。這時，在決策過程中常用到的「找出各方案的前提，再來驗證前提」的思考過程，就可以幫助方案的選擇。

在此一決策分析過程中，方案的提出相當仰賴知識庫中所擁有的「解決方案」；而「找出前提」則要靠知識庫中「因果關係」或結構性知識去了解分別在哪些情況下，哪個方案更能達到預期的目標。因此，想得出來的方案要夠多、夠合理，才有得比較；而強大的「結構性知識」則可以推斷這些方案的可行性分別建立在哪些前提上。

套用這種觀點，系統思考可協助你建構扎實的「結構性知識」，並在「驗證前提」方面替你提出的解決方案把關。

以上是針對【系統思考的四堂課・DevOps 特別版】首梯公開班同學的提問，予以統一回覆。更多學員的心得分享，請見 1, 2, 3, 4, 5, 6。

系統思考工作坊 - 系列文章

❶ 【系統思考的四堂課】緣起

❷ 第一場公開班課後回覆：思維的重量訓練

❸ 從系統思考角度讀《獨角獸專案》

➍ 從系統思考角度談 DevOps 三步工作法

系統思考的四堂課

Thu, 21 Jun 2018 23:26:00 +0800

過去四週，我在公司內帶了一系列【系統思考的四堂課】。本文回顧整件事的來龍去脈，為自己做個紀錄及紀念。

緣起

其一

過去兩年，我分別以限制理論的 thinking processes（思維程序；思考方式）及系統動力學 (system dynamics) 兩大思維角度，給了幾場 DevOps 及 Docker 的演講（見文章 1、文章 2、文章 3）。過程中，觀察到一些有趣的事：

DDD 要說故事，CLD 要說故事，CRT 要說故事，user journey 要說故事，簡報要說故事。

凡事都要有說故事的能力。

— Quote: 2017-04-27 Tweet

突然發現，系統思考的系統基模中，大半都是雙裂結構；這恰巧與 TOC 的 Evaporating Cloud 有許多相互呼應之處。

— Quote: 2017-07-18 Tweet

我隱約察覺到，來自系統思考陣營的 CLD 與來自限制理論陣營的 CRT，兩者有種深層的相似性。

其二

後來，在某個場合，Ruddy 老師向我拋出一則有趣的提問：「為什麼高德拉特發展出 CRT 這種方法，而不直接採用現成的 CLD？」

我答不出來。頂多只是憑直覺喃喃自語：「或許是比較容易溝通吧！」

其三

某一天，在《抉擇》第 209 頁巧遇一張 CLD。果然高德拉特也懂 CLD，只是選擇不常用它。

「或許是 CRT 比 CLD 容易溝通吧！」

這類思緒，不時湧出，甚至開始浮現一些狂想：

認真思考將 CLD 與 CRT & FRT 混用，或在某種程度上融合的可能性。

— Quote: 2017-04-26 Tweet

有難度的狂想。當時的我，還想不出具體的方法融合。

突破

直到今年四月，在稲垣公夫《深思快想》這本奇書看到一線曙光：

《深思快想》

不愧是限制理論暨豐田方法的專家，早我一步（好吧，早我好幾步）整合好 CRT + CLD 了。

站在巨人的肩膀上，我可以省點力氣了？

沒這麼簡單。

稲垣公夫語重心長提醒：

「思考的深度」與「專業性程度」互不相干。也就是說，有人使用極艱深的專業知識，卻用淺薄的方式思考；有人則深入思考身邊人盡皆知的常識。

想鍛鍊深入思考的能力，與其只偶爾仔細思考困難的問題，不如養成經常對日常事務深思熟慮的習慣。

勝間和代在《培養商業腦的七種組織力》也提醒過一樣的事：

不斷進行切入重點來養成思考方式，雖看似繞遠路，其實就是最快的捷徑。沒有辦法養成邏輯思考的人，單純的原因就在於質量的不足而已。可以的話，希望各位持續進行幾年的時間來培養這個習慣。

不照著鍛鍊，不會化成自己的血肉。

既然兩位都這麼說，我就乖乖照著做吧！

刻意練習

我挑選兩個案例來刻意練習。一是不太熟悉的，以當期的科技島讀夾娃娃機文章為案例；一是非常熟悉的，以現在服務的公司當案例，總結這四年工作上看遍的成敗點滴，了卻一樁長年心願。

兩個案例，仗著過往的 CRT 及 CLD 功底，個別繪出草圖並不難；但若進一步要求兩者的內在一致性，也費了好幾天功夫。

很有成就感。

既然都做到這地步，孤芳自賞太可惜了，索性拿這份商業模式分析圖找上我們家 CEO，用 CRT + CLD 連續技講了一遍，檢驗我的分析是否正確。

之後，持續刻意練習 CRT + CLD，漸漸生出效果，更快就能勾勒出具有內在一致性的初版。

以這種角度來閱讀文本，對文本的鑑賞標準在不知不覺中提高，也更能體會《一流的人讀書，都在哪裡畫線？》點出的訣竅：

《一流的人讀書，都在哪裡畫線？》

用這種態度，何止是在書上畫線，連優質的網路分析文章也盡在狩獵範圍之內。

譬如說，面對詹宏志的演講，不會讀的人，只會酸他太晚才知道所謂「資本的力量」；會讀的人，就會看到其中的系統基模，以及可引為己用之處。

這才是深刻的閱讀層次。

開講

今年二月，我在公司內部群組推薦好友 Taco 開的系統思考工作坊，幾位好學的同事前來打探，令我竊喜：公司內總算有人對這主題感興趣了。

這一天，我等了好久。

也正是時候。正值自己在「系統思考」及「教學培訓」兩方面都有突破，便尋思：何不結合兩者，設計符合自己想法的教案，主動分享這方面的新體悟？

就用系統思考的方法來教系統思考吧。

算是一種 self-contained feedback loop？ (笑)

於是，在公司內自動請纓開辦【系統思考的四堂課】。一周一堂 90 分鐘，正好一個月結束。

課程公告：

正如我帶讀書會及工作坊的風格，會以個案研討形式為主，有大量課堂討論及回家作業。回家作業大概需要花一個小時。能配合的，再考慮參加。

人數上限：12。

Agenda:

課前作業 - 中等收入陷阱

Week 1 (5/31 四) - 系統思考簡介、因果分析

Week 2 (6/07 四) - 系統動力學

Week 3 (6/14 四) - 系統基模

Week 4 (6/21 四) - 應用：Large-scale Scrum 或商業模式分析

場地所限，設下人數上限。結果，還是有人拜託超收。 (笑)

【系統思考的四堂課】第一梯次

為了這四堂課，努力策劃主題內容，梳理系統思考的具體步驟。最花功夫的是案例。要切題，又要多元，更要有相當程度的表面複雜性，才能對比映襯出系統思考的簡潔與犀利。

沒有單一書籍符合上述所有需求。所以，兩個月以來，重讀許多書籍，萃取精華。

系統思考：

深思快想
第五項修練
系統思考 (Systems One 中譯本)
系統思考 (Thinking in Systems: A Primer 中譯本)
問題可以一次解決（舊版：問題不能拆開來看）

思維模式：

成長心態：

走過一輪，提煉出可適用於 CRT 及 CLD 兩種系統思考層次的大一統方法，並將六大步驟湊出頭字詞，命名為「SLR·CPI 法」：SLR 是單眼相機，CPI 是消費者物價指數，夠好記吧！

教第一堂課的感想是，活動設計上，要再補強 CLR (categories of legitimate reservations) 的部分，或者，從社會科學的研究方法中取材相關內容。畢竟，「理則思考」是台灣高等教育上嚴重缺失的一環。

教第二堂課的感想是：真的需要現場手繪，並搭配 LOOPY 推導。

教到第三堂課時，把之前課堂上分析過的種種大案例全部再拿出來對照，也順便類比到公司現況，讓大家現場立即體驗到彼得・聖吉說的「熟習系統基模，是組織開始將系統觀點應用於實務的第一步」箇中深意。

誰說《第五項修練》是沒有用的老書呢？

教第四堂課時，火力全開，為【系統思考的四堂課】給了場算是高潮的完結，也鬆了一口氣。

為人，也為己

在公司內開這門課，長遠目標是推動並深化學習型組織，中期目標是為日後的 LeSS 鋪路，短期目標則是強化質性思考的能力。

畢竟，從「中等收入陷阱」案例的系統思考分析中，兩種競爭力取向的動力昭然若揭。為了推動高端循環，質性思考是關鍵能力。質性路線比量化路線更抽象，更虛無飄渺，更難有適切的判準，常常都是淪為事後諸葛。所以，更需要在這方面刻意練習，及早提升這方面的素養。

為別人，也為了自己。

某方面來說，我現在對別人做的許多事，部分是為了 N 年前沒能從（缺席的）mentor 那邊得到的我而做的。

某種角度來說，也算是一種與內在小孩的對話。

譬如說，我真想給當年的自己，看這段窮查理的話：

並且帶著他逐步分析出這樣的 CLD：

有這樣的 mentor，今天的我，又會是怎麼樣的一個人呢？

沒有這樣的 mentor，就只能靠自己了。

文末，一點小雜感。人生如夢，一尊還酹江月。

系統思考工作坊 - 系列文章

❶ 【系統思考的四堂課】緣起

❷ 第一場公開班課後回覆：思維的重量訓練

❸ 從系統思考角度讀《獨角獸專案》

➍ 從系統思考角度談 DevOps 三步工作法

三週生出一款新桌遊，一段奇幻旅程

Thu, 26 Apr 2018 11:36:45 +0800

這款新桌遊，從四週前動念，歷經一次小實驗，一次高裝檢，到前天第一次對外正式啟用，現在總算可以慢慢寫它的誕生歷程了。

對模擬遊戲的四大疑惑

學生時代從《第五項修練》讀到啤酒遊戲 (Beer Game)，就對規則簡單但意義深遠的模擬遊戲，心嚮往之。

但直到近幾年，才真正有機會親炙它們。

我在【TOC企業變革之路・體驗工作坊】玩了啤酒遊戲、在 Agile Tour Hsinchu 2016 玩了 getKanban、在 CSPO 課堂玩了 Business Value Game，儘管各有收穫，但心中卻也一直有個疑惑：

啤酒遊戲、getKanban、Business Value Game，為了教育意義，好像牌卡順序都是事先設計好的？

— Quote: 2017-11-10 Tweet

刻意安排事件卡的出現順序或參數，比較容易控制某些障礙一定會在某些時刻被觸發，遊戲設計者想推銷的某些破關密技也一定會管用——畢竟，全部都是事先計算好的。動機良善。只不過，這也會削弱教育意義的效度：這遊戲想傳達的理念或破關密技，會不會只適用在像這種刻意安排好的事件排列組合及參數設定上？

真實的人生，不會只有這麼一套巧合的劇本。

第二個疑惑是，這類模擬遊戲，雖然已針對現實做簡化，但仍然非常緊貼該課題所處的領域。動機良善。只不過，這也會削弱跨領域應用的彈性。譬如說，非軟體研發領域的人，若無視 getKanban 或 Business Value Game 卡牌上一堆軟體研發流程、角色、狀況、參數，甚至短空長多的瓶頸升級招數，也能在遊戲中領悟箇中深意嗎？

尤其是我的【敏捷原理與團隊塑造】招牌課程，最初是設定給 IT 領域，但後來漸漸有非 IT 領域的企業內訓需求，甚至非營利組織也來邀約，我必須認真處理這問題，尋找或設計更合適的模擬活動。

第三個疑惑是，這類模擬遊戲，雖然已針對現實做簡化，但規則仍然複雜，不管是遊戲規則還是計分板規則。

像啤酒遊戲，主體規則非常簡單，但遊戲過程須紀錄編製的統計圖表可就令人咋舌：遊戲記錄表、庫存／缺貨圖表、需求預測圖表、出貨記錄表、訂貨記錄表、長鞭效應分析圖。鑑於計分板規則也是遊戲體驗過程的一部分，甚至是最容易出錯的一環，綜合來說，我不認為啤酒遊戲是簡單的。就算搬到電腦上玩，我也不認為啤酒遊戲是簡單的。

至於其他遊戲，有的是牌面資訊複雜，有的是流程複雜，有的是角色分工複雜，都需要詳讀使用說明書。

規則複雜，連帶產生第四個疑惑是，這類遊戲，有可能 plug and play 融入一個小時的教學單元之中嗎？這算是個人主觀的偏好，希望盡量將活動模組化，比較容易單獨施行，或視情況需要，與其他不同的活動模組混搭編排。

因此，後來陸續問世的 UX in the Jungle 或鳳凰項目沙盤推演，顯然是定位在更大規模的商業模擬，顯然沒有同時處理這四大疑點，我就沒有親自去體驗了。

我一直在尋找，甚至想設計出符合以下特性的模擬活動：

簡單的規則。
抽象化場景。
隨機事件。
多重策略，多重結局。
可在一個小時內，搞定規則解說、試玩、正式玩、檢討的基本款循環。
只要調整設定，即可擴充至更長的體驗時間。

這想法，一直埋藏在心中。直到有一天⋯⋯

— Quote: 2018-03-24 Tweet

解套的契機，就是參加了【體驗式課程的遊戲設計與操作實務】三天課程，而且是在第一天就出現了靈感。

三大明師現身說法

這門匯集三大明師運課精華的合體課程，早在 2017 年首發課程消息一出，我就躍躍欲試。畢竟，我上過一堆 Bryan & Joe 的課，深知這種課程設計的魅力及成效；我也從功夫老師（劉恭甫）的書，尤其是《左思右想》這本神作，學到許多實用的思考框架。三大明師黃金組合，再加上一堆神級人物搶著當首發課的學員（請見【一談就贏・鄭志豪】的這篇文章），著實令人心動。

只可惜首發的 TTT 課程，與另一個我也很想上的薩提爾課程衝堂，只好暫緩。

就這樣過了一年。終於排除萬難，上這堂今年對我來說最重要的三天課程了。

果然滿是第一線明師替課程注入靈魂的乾貨。

頭兩天課程，老師現身說法，演示並拆解數種體驗式課程的訣竅：

團康
一頁紙
架構地圖
模擬活動
卡牌活動
桌遊
角色扮演

這些形式，我都曾在課程或會議引導場合嘗試帶領過，但全都是自學：從書本學方法、從明師運課過程逆向工程些許訣竅、從自己的土炮經驗中反思調整而來，自認不到位之處仍多。這次，有系統的重新學習體驗式課程的理論及訣竅，見識第一流明師的頂級風格——原來，體驗式課程可以執行得如此細緻！

我也常在課堂上立即刺激出更多想法。

譬如說，某個我極具把握，也在公司內及公司外真槍實彈執行過四次的一小時活動【積木拼圖】，原本以為已經夠好了。沒想到經過這兩天洗禮，還能刺激我想出更有趣的調味料。翌日，在公司現學現賣印證所學，果真有加分效果！更讓緊接著要處理非常敏感且尖銳的 retrospective meeting，超出預期的成功。

取法乎上，果然有必要。

課堂上，老師大方演示並無私拆解各自拿手的招牌課程單元，對於上過許多課的我來說，不時有意外的驚喜。

譬如說，睽違兩年，再玩一次小火車，依然有感。再聽 Joe 拆解幕後的機制，更是徹底體會「障礙」與「斷點」的奧秘。

譬如說，在某個角色扮演案例中飾演觀察員，很慶幸發現自己半年前的談判課沒有白學，很快就察覺雙方卡關之處。也算是意外的成果檢驗吧。

三週生出一款新桌遊

這門課，頭兩天是老師們的現身說法。兩三週之後，同學們會再回來齊聚一堂，活用兩日所學，逐一端出自己設計的課程，讓老師及其他同學體驗與點評。

就如同【一談就贏・鄭志豪】的這篇文章所說，如果拿自己既有的教案交差，那就太犯規了。我們真的在這期間，絞盡腦汁研發出全新的單元。樸拙在所難免，但交由專家點評，才是讓自己更快速進步的捷徑。若只端出已經錘鍊過的東西，就喪失從明師身上挖寶的尚好機會。

對我來說，儘管課程第一天就開始有一些零零星星的靈感浮現，但仍歷經一整個禮拜的發散探索，才慢慢收斂出幾個較可行的方案。譬如說，從以下這份用 TTSS 角度發想的一部分概念草圖，可約略看出設計探索的軌跡：

桌遊草圖

繼續細部設計約一個禮拜，邀請七位熱心同事幫忙試玩。當時來不及做投影片，只能先手繪分鏡圖來解釋故事及規則（這也算是一種 minimum viable product 吧）：

桌遊規則

公司同事太強大了。桌遊試車一小時，馬上對困擾我很久的機率設計，給出很實質的改善建議。也激發我新的靈感，可將此桌遊規則微調，彈性擴充成 1 小時，甚至 1.5 小時的版本。

經此實驗，主軸確定了，便放心在成果總驗收日端出來請各位老師同學點評。非常感謝大家現場給予的回饋，從主題設定、規則、學習成效，甚至控場細節，都讓我收穫滿滿。

同時，還親身體驗到其他同學端出的寶貝：人際溝通、簡體字教學、物流機制、正向思考、物理治療、牙齒修磨、乳房腫瘤治療、馬蓋先、急診室體驗，這一天，簡直是夢幻的滿漢全席！眼界大開，學到許多日後可參酌運用的手法。

Comment from Jacky Liu

很幸運的，我的這款【先遣小姑嘗】桌遊，得到了【體驗式課程的遊戲設計與操作實務】第四梯次的「最佳教育設計獎」：

最佳教育設計獎

這些經驗及修正意見，讓我稍後在某營造業龍頭進行【敏捷原理與團隊塑造】企業內訓時，效果超出預期。

這段旅程，很刺激，很燒腦，也讓我對於「一線老師有各自不同注入靈魂的做法」這件事，不再感到虛無飄渺。

感謝 Bryan、Joe、功夫老師及同梯學伴，共度這奇幻旅程。

以 impact mapping 進行參與式決策

Fri, 23 Feb 2018 10:54:14 +0800

我在半年前〈以談判角度看 Sprint Planning〉一文曾提過：

只要是我有權主導的 Sprint Planning，都會先花些時間請 PO 重新展開 Impact Mapping 及 Scaling Lean 的內容，尤其是還沒有穩定扎實 Product Backlog Refinement 的團隊。

欲達我心目中的理想境界，需要先讓團隊成員練習一兩次 impact mapping，才能在正式上戰場時，更有效產出高品質的 impact map。

就連 PO 本身也需要練習。尤其是沒有「參與式決策」習慣的 PO，對於這類方法，常以自身專業角度提出質疑：

— Quote: 2018-01-15 Tweet

畢竟，就如《精實創業》提醒的，傳統 PO 或 PdM 養成過程中，並不會特別被鼓勵用這種方法做事：

這項改革與人們一直以來在企業中被灌輸的認知，或企業領導人一直以來所學的知識是相違背的。

真正的問題在於企業領導人及中層管理幹部。有許多企業領導人當年成功，是因為他們擅於分析，他們自認是分析家，應當為公司做企劃分析、為公司的未來訂定計畫。

因此，對於這類型的 PO，需要在平日就善於伺機提問，甚至需要以更高的標準去要求，才能讓他們看到 impact map 的價值，甚至「參與式決策」過程的必要性。畢竟，少了「參與式決策」的助力，敏捷之旅會更崎嶇。

— Quote: 2018-02-06 Tweet

培訓

2018 年初，終於等到時機成熟，有機會對某團隊大膽試行，朝向我心目中理想境界前進一步。

首先，是培訓。

我先利用三次機會（包括【敏捷原理與團隊塑造】第二梯次），小規模試行各 1.5 小時的「Impact Mapping + MVP 迷你工作坊」。

我也趁這三次的施教機會，實驗一些個案研討手法及引導句型。

以前在非正式引介 impact mapping 的過程中，我發現許多人對 “impact” 這一層最不容易掌握訣竅。雖然 impact mapping 有原版的建議句型 ¹ ，但我覺得操作起來還不太足夠。因此，我嘗試納入周碩倫老師在【創新的用途理論導讀會】介紹的用途及需求觀點，讓 “impact” 這一層更容易引導出來。

創新的用途理論導讀會 by 周碩倫

Lean Canvas

在帶整個團隊玩真槍實彈的 impact mapping 會議之前，我通常會請 PO 先私下繳交一份 impact mapping 作業給我看——這應該算是 PO 的基本功。

原本是要這樣的。不過，對 PO，應該要有更高標準的要求吧！甫經一天 Lean Startup 課堂洗禮的我，突然萌生一個瘋狂的念頭：

— Quote: 2018-02-14 Tweet

畢竟，先認真做好 lean canvas，就有一個堅實的基礎再往下展開成 impact map：

Lean canvas 的 revenue streams 及 key metrics，約略對應到 impact map 的 goal (WHY)。
Lean canvas 的 customer segments，可對應到 impact map 的 actor (WHO)。
Lean canvas 的 unique value proposition，約略對應到 impact map 的 impact (HOW)。
Lean canvas 的 solution，約略對應到 impact map 的 deliverable (WHAT)。

我請 PO 暫時先不必管 lean canvas 的 channels 及 cost structure 欄位，至於其他七個欄位，都建議 PO 先獨自整理到某個程度，比較有助於當場對團隊產出的 impact mapping 進行有建設性的補充。

於是，這位可憐的 PO，春節假期一直在做我給的 lean canvas 作業⋯⋯ 🤣

Impact Mapping 議程設計

團隊培訓完了，PO 也獨自做完 lean canvas 了，接下來就是真槍實彈的 impact mapping 會議。

我沒有完全照著 Impact Mapping 書中建議的程序，而是根據 Facilitator’s Guide to Participatory Decision-Making 書中提到的鑽石模型 (diamond model) 及串組式流程設計 (string)，再穿插 Gamestorming 書中介紹的一些小技巧（像 brainwriting 的小變形），讓整個活動有層次，有節奏，且讓每個人的想法都有機會呈現與碰撞。

注重「參與式決策」的過程，也注重產出的結果。

理想上，這樣的活動，我認為要三個小時，甚至四個小時，才會達到高品質的 WHAT 層次。如果只有兩小時，可能只能做到中等品質的 HOW 層次。不過，一連進行四小時（即使是分成上午及下午各半場），對引導者本人來說是小事，但其他人的專注力可能通不過這樣的考驗。

下次再帶這樣的活動，我應該會設計成 Part 1 (Goal → WHO → HOW) 及 Part 2 (HOW → WHAT → iterative 總結) ，分兩天進行。也會多穿插些提示引導問句及迷你思考框架，以更有效率校準水平。

我在〈咬文嚼字的必要性（一）：用句型輔助思考〉文中曾提過 impact mapping 有一個原版的建議句型。 ↩︎

咬文嚼字的必要性（一）：用句型輔助思考

Thu, 04 Jan 2018 14:00:00 +0800

前同事 Peter Su 提出他在荷蘭工作的觀察：

貼文短短，卻已提到幾則重點：

準則
思考框架
句型
參考範例

儘管自己還沒有在國外工作過，但成天浸潤在外文書籍，也感同身受。

關於「思考框架」這一點，我在〈思考框架的刻意練習〉一文提過自己的看法。現在這篇文章，我想繼續談談「句型」這一點。

用句型輔助思考

歐美系的思考框架或準則，很喜歡用「句型」式的步驟來引導思考。

譬如說，在軟體研發領域常用的 user story，本身就有一個經典句型：

As a <type of user>, I want <some goal> so that <some reason>.

另一個似乎開始引人注目的 JTBD (jobs to be done) 也有一個經典的 job story 句型：

When <situation>, I want <motivation> so I can <expected outcome>.

在 Impact Mapping 書中，Gojko Adzic 建議使用以下句型來開展 actor 及 behavior impact 的關係：

<The actor> can help us to achieve <some goal> by <behave> faster/better.

<The actor> can obstruct us from achieving <some goal> by <behave> slower/worse.

在 Specification by Example 書中，Gojko Adzic 建議使用以下 Gherkin 句型來制定實例化需求：

Given <a precondition> when <an action happens> then <the following post-conditions should be satisfied>.

在限制理論的衝突圖（疑雲圖）中，針對 B→A、C→A、D→B、D′→C 四個邏輯關聯及假設，Jelena Fedurko 提出一些邏輯檢驗句型，甚至還主張要「大聲唸出來」呢：

In order to <left clause> we must <right clause> because <assumption>.

前面示範的都是短句，但句型也可能很長。像大師 Geoffrey Moore 就提過很長的 value proposition 句型：

For <bulls-eye customer> who <key purchase motivation insight> our product is a <in customer language> that <key benefit>. Unlike <key competitors> ours <key differentiators> at a price <than competitors>.

句型，讓初學者容易依循上手，但蜜月期總有結束之日。若只追求表面句型的合式，而不進一步認真雕琢句子內容，輕則無法發揮此思考框架的威力，重則誤用。

因此，有志之士，對於這些句型背後的填空之處，尤其是命名，會吹毛求疵到咬文嚼字的地步。

不明就裡的人會納悶：「真的有必要這樣嗎？」

來看幾個例子吧。

團隊共創法

團隊共創法 (consensus workshop method) 當中，第四步驟是命名。

命名，也是有箇中眉角的。

Yves 在〈找出組織無法變敏捷的阻礙 – 團隊共創法實做〉一文提到「移除『缺乏』，讓命名更貼近核心」的訣竅：

在 ICA 的課程中學到，如果阻礙是含有『缺乏』的字眼，如不夠、太少等，代表這只是表象或症狀，需要花些時間去挖掘更深層的造成原因。所以我嘗試以我的觀點再往深入去發掘，讓字面上沒有『缺乏』的字眼。

你覺得，這是吹毛求疵咬文嚼字嗎？

專案管理

在專案管理領域，WBS 及 activity（或稱 task）兩者，很常被人混為一談。

以 PMI 的 PMBOK 體系而言，WBS 是屬於 scope management 知識領域，activity 則是屬於 schedule management 知識領域。一靜，一動。

本質不同，表述形式自然不應相同。

關於 WBS，在 PMBOK Guide 4th 如是說：

Work Breakdown Structure (WBS) [Output/Input]. A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project.

雖然到了 PMBOK Guide 5th 及 6th，此定義都略作調整，刪掉 “deliverable-oriented” 字眼：

Work Breakdown Structure (WBS). A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.

但大體上，WBS 的表述形式，仍是以「名詞」或「名詞片語」為主。

至於 activity，在 PMBOK Guide 6th 如是說：

Define Activities is the process of identifying and documenting the specific actions to be performed to produce the project deliverables. […] Activities represent the effort needed to complete a work package. The Define Activities process defines the final outputs as activities rather than deliverables, as done in the Create WBS process.

很明顯的，activity 的表述形式，是以「動詞字句」為主。

實例化需求

實例化需求 (specification by example; SBE) 也是個易學難精的技藝。所幸新書 Writing Great Specifications: Using Specification by Example and Gherkin 適時出現，站在巨人的肩膀上，擔起 “Gherkin Manual of Style” 的責任。

先摘錄整體風格的建議：

Don’t write scenarios about the UI. Write about business outcomes. Nobody cares about the UI; they care if they can get their job done.
Keep your scenarios at an abstraction level that allows you to aim for as few Givens, Whens, and Thens as possible without sacrificing readability.

再摘錄針對「Given/When/Then」的個別建議。某些建議，甚至咬文嚼字到「語態」及「時態」等文法層次：

Don’t phrase Givens as actions. Use passive voice in past tense, or phrase each Given as a list of things that need to happen before the actors can move the action forward.
Aim for one When keyword per scenario.
User tasks take place in the present and should be phrased in active voice to differentiate them from contexts and outcomes.
User tasks should allow actors to proceed to Thens. If a When needs additional clarification, it’s merely a user action.
To facilitate outside-in development, use the following template to phrase most of your Thens: should be able to .

這些風格建議，對於實際帶過 SBE workshop 的人，可說心有戚戚焉。

限制理論

限制理論對於清晰思考的要求非常高，thinking processes (TP) 更是如此。

就拿只有五個框框、五個箭頭的 evaporating cloud（衝突圖、疑雲圖）來說吧。如果單論表面形式，可能已經是最簡單最簡潔的了——但也沒那麼單純。

Jelena Fedurko 在《撥雲見日》一書如是說：

絕大多數的疑雲圖之所以無效，原因是寫圖的人不理解正確、精確地遣詞用字的重要性。

摘錄幾則「正確精準的遣詞用字」建議：

每個框內的陳述，應該是一個簡單的句子，沒有任何因果字眼，如「因為、因此、由於、為了」等。
目標 A、需求 B、需求 C 是正面陳述。不要使用「不、非、否」之類的文字。
每個框內的陳述，都應該包含一個動詞。
B 和 C 的內容，是需求而不是行動（描述因為重複發生的動作，如：確保、維持、提供、支持、預防或避免等，而形成的持續狀態）。

書中還有更多嚴謹的建構及檢驗步驟，值得認真練習。

系統思考

系統思考／系統動力學領域常用工具有二：CLD (causal loop diagram) 及 SFD (stock and flow diagram)。其中，SFD 涉及兩種量化元素的類型：存量 (stock) 及流量 (flow)，門檻較高 ¹ ，因此多數人會改由較簡單的 CLD 入門。但這也意味著，這些人不一定具備該有的「變量」敏銳度。

對「變量」不敏銳，會反映在錯誤命名上。難怪 Seeing the Forest for the Trees 一書特別提醒，在 CLD 中請堅持以「名詞」形式來表述：

RULE 5: USE NOUNS, NOT VERBS

If you look at all the causal loop diagrams in this book, you will find that every item is a noun or a noun phrase, rather than a verb or a verb phrase.

There is often a tendency to express the appropriate action as a verb (hire or fire) rather than as a noun equivalent (hiring or firing). If you can keep to nouns, even here, so emphasizing the action itself, you will find that your causal loop diagrams are clearer.

書中也提醒，不要將「增加」或「減少」之類的字眼偷渡進來，那等於是越俎代庖：

RULE 6: DON’T USE TERMS SUCH AS “INCREASE IN” OR “DECREASE IN”

When drawing causal loop diagrams you will inevitably be tempted to include these two phrases in your descriptions.

However strong the temptation, resist it. That’s what the arrows are for, especially the Ss and the Os.

此書的「CLD 十二條黃金法則」，值得仔細體會：

結語

予豈咬文嚼字哉？予不得已也。

為了充分發揮思考框架的威力，請暫時不要當差不多先生吧。

畢竟，嘗試深度掌握某些知識體系，先蹲後跳，後發先至，是划算的投資。

【咬文嚼字的必要性】系列

❶ 咬文嚼字的必要性（一）：用句型輔助思考

❷ 咬文嚼字的必要性（二）：階段性的預期成果設定

❸ 請珍惜你們學到的通關密語

就連系統思考經典入門小書 Systems One 作者 Draper L. Kauffman Jr. 也自承：『常有人要求我將本書「升級」為一本正式介紹系統動態的書籍，尤其是將關鍵的「存量－流量」概念放進書中。當我一開始規劃本書前身的授課教材時，也曾嘗試向我十年級學生解釋「存量－流量」圖示及模型，但我失敗了。不到一半的學生在學習後仍記得其中有用的部分，因此我忍痛將此刪除。我不想搞砸既有的成功基礎。本書在此領域已經被成功定位為「介紹系統思維最簡單的一本書」。增加長度或複雜度可能對某些應用有幫助，但也會降低對其他人的協助。我不確定改寫後，是否還能像現在這樣廣為大眾所接受。』大師都如此說了，可見 SFD 門檻之高。 ↩︎

從系統思考看 DevOps

Sun, 29 Oct 2017 11:40:00 +0800

自從去年在〈有了 Agile，為什麼還要有 DevOps？〉及〈從限制理論看 DevOps〉兩場演講中，分別以 lean thinking 及 theory of constraints (TOC) 兩個角度探討 DevOps 之後，心中一直有個願望：想再從「系統思考」角度探討 DevOps。

畢竟，「系統思考」算是名門正派，「學習型組織」更是我從研究所時代就心嚮往之的目標。當時買的《第五項修練》第一版，還一直在我的書架上最尊榮的位置呢。

不過，想將它應用到 DevOps 場域上，我還不太有把握。畢竟系統思考的重要思維工具 CLD (causal loop diagram)，比一般因果推理的思維工具，多了變量 (variable) 及時間滯延 (delay) 觀念，燒腦程度更甚於 TOC 的 CRT (current reality tree)。

想法，就這麼擱置了。

直到今年初，接連聽了呂毅老師一場演講（在組織教練中看見系統性模式）及兩天 LeSS 課程，被老師用 CLD 貫串全場的氣勢，以及推廣系統思考的熱情所感動，決定回到初衷，勇於接受挑戰。

於是，重拾《第五項修練》，重新咀嚼系統基模，研究如何以淺顯的方式解釋 CLD。我也嘗試搭配 LOOPY 這個有趣的軟體，降低 CLD 學習門檻。最後，從 DevOps 中挑選熱門的話題 microservices 作為箭靶，以增進實用性。萬事俱備，結果就是以下的演講。

DevOps Taiwan Meetup #8 (2017-10-26)

DevOps Taiwan Meetup #8 (2017-10-26).
從系統思考看 DevOps：以 microservices 為例

活動簡介：

台灣第一次舉辦的 DevOpsDays Taipei，涵蓋許多精彩的文化與技術議題。

大會中，許多講者不約而同提到「系統思考」的概念，這是什麼？許多講者也提到 microservices 的重要性，但為什麼許多人想導入，卻鍛羽而歸？

此演講以系統思考的 causal loop diagram 角度，探討 microservices 常見的導入誤區：意外的敵人 (accidental adversaries) 及捨本逐末 (shifting the burden) ，並根據系統基模角度提出對應的槓桿解。

希望你聽了之後，能夠初步掌握系統思考的切入點，也對於 microservices 導入，多了一分把握。

提醒：建議先複習一下 Andrew Wu 在【DevOps Taiwan Meetup #4 (2017/02/22) ／這一夜讓我們來聊聊 Microservices】的內容：

投影片 @ Slideshare

部落格文章

投影片：

實況錄影：

這場演講，開宗明義就說了：只探討「動態性複雜」，不探討「細節性複雜」。因此，刻意不著重在 microservices 技術細節。正好現場有兩位深富 microservices 實務經驗的高手，就順便 cue 他們幫忙回答技術提問。

感謝 andrew 幫忙回答資料儲存問題：

交易處理是 RDBMS 強項，不過 RDBMS 先天就跟 microservices 不大搭，分散式的環境下要有別的處理方式。

非交易的資料可透過 Message Queue 等等非同步的方式來達成最終的一致性。如果範圍切割得夠小，也許你仍然可以在單一服務內繼續用 RDBMS 的交易控制。如果交易被迫得被分散在兩個服務之間，那麼分散式交易的機制就必須確實實作（例如 2 phase commit 之類的技巧）。

感謝 jini 幫忙回答 transaction 問題：

但在金融交易時，若該 domain object 一定要在同一個 transaction context 時，那麼該服務就不該被切割。此外，有某些狀況也許可以切割，類似客戶與訂單的關係，這部份就可以用 async 加上 status 來處理，甚至有一個 batch 來 review 最終一致性。

最後，希望這種「系統思考」角度，對大家在導入 DevOps 的過程中，有些許幫助。更進一步，朝向學習型組織邁進。

演講最後推薦的幾本書，別忘了要去看喔！

你曾經變成你自己最糟糕的一面嗎？

Tue, 03 Oct 2017 21:28:27 +0800

湯姆・漢克與梅格・萊恩主演的《電子情書》中，有一段台詞：

Do you ever feel you’ve become the worst version of yourself? That a Pandora’s box of all the secret, hateful parts - your arrogance, your spite, your condescension - has sprung open? Someone upsets you and instead of smiling and moving on, you zing them. “Hello, it’s Mr Nasty.” I’m sure you have no idea what I’m talking about.

妳曾經變成妳自己最糟糕的一面嗎？那就是一個裝有所有的恨意、輕蔑跟降尊紆貴的潘朵拉盒子被打開。有人讓你感到不悅，但是你沒有選擇離開，反而用毒舌回敬。「哈囉，惡毒的人來了。」我相信妳一定不知道我在說什麼⋯⋯

高壓情境下，的確會做出異於平日的舉動。

在 Joe 的【302 專案的談判與協商】課堂上，我就這麼扎扎實實體驗到了。

案例

我在最近〈以談判角度看 Sprint Planning〉及〈引導者，要懂心理〉兩篇文章都提到自己的感觸：談判思維，對於專案及團隊引導是有幫助的。因此，我刻意不選擇一般類型的談判課，而是先挑針對專案情境而設計的談判課。

專案情境？首選自然是 Joe & Bryan 金字招牌，沒有第二。

【302 專案的談判與協商】是一門體驗課程，三個案例，六種角色，從刀刀見血的分組攻防戰中，親自品嚐箇中酸甜苦辣。

三個案例，一個很和平的談成了，一個很激烈的破局了，一個稍帶激昂的談成了。

讓我反思最多的，是破局。

習慣

這個案例，儘管應該是我最熟悉的，但在高壓情境中，竟然渾然忘記平日的我，一定會為了促成事情發生而儘早揭露某些關鍵資訊；反而陷入一種被遊戲規則設計好的陷阱（尤其是績效指標），糾結，直到最後關頭才驚覺，但局面已經難以挽回，對方亦無台階可下，可算破局。

我忘了在這種情境中，自己的角色不重要，最重要的目標應該是＿＿＿＿。

在高壓情境下，在誤判 ZOPA 時，連自以為無比自然的「做事習慣」都會被無情解體了，那麼，這真的已經變成自己的「做事習慣」嗎？更遑論其他從書裡、文章裡、課程講義裡、老師口頭提示的，但尚未充分整合融會進來的觀念及技巧。

果然還需要常保反思警醒之心。

另一個有趣的案例，讓我在一個安全的實驗室放膽演一回，演一個我幾乎不曾公開展現過的特質。我很享受這個過程，也發現：適度使用，的確有效果。這也令我換位思考：下一回，當我在真實人生遇到這樣的對手，是否也能冷靜地看透 position 背後的 needs？

「要求」(position) 是假的，「需求」(needs) 才是真的。所謂談判，就是一場「發覺對方需求」的遊戲。

— 《價值談判》

選項

在隊友的交叉掩護下，仍有餘裕的小空檔，我便刻意實驗一些從其他書上看過的技法。有些如預期般有效，有些則否。頓時體會到，那些技巧，既非沒用，亦非絕對有用，而是要審時度勢，拿捏出手輕重及順序。最需要的，不是死啃理論、案例、框架、SOP，而是要在拳拳到肉的體驗中，在安全的挫折中，打破慣性，得到體悟：永遠有其他意想不到的選項。

畢竟，正如 Joe 所說：「今天，我能坐在談判桌上，代表我仍然有優勢之處。」

視角

上完課隔天，立刻發現，面對高壓情境，居然比以前更能泰然處之。甚至還能夠切換廣角鏡、標準鏡、望遠鏡，從較多面向去盤算該如何出牌，或是打 pass。

簡單的說，自己的出牌選項變多了。

很感謝 Joe 在喉嚨不適的情況下，仍然用心帶領這麼一場難忘的談判體驗。收穫的，不只是談判，不只是職場關係的優勢策略，更是對自我冰山的高強度體檢。

很值得的冒險！

思考框架的刻意練習

Fri, 22 Sep 2017 11:00:00 +0800

思考框架

我自認是個思考框架控。

學生時代只是不自覺就這麼做了。但後來被勝間和代《新・知識生產術》洗腦，我就開始下意識蒐集並應用。

過度依賴既定框架是不好的 ¹，但是，看到連鼓吹思考框架甚力的勝間和代也曾有此疑問，且給出一份建議，我就放心了。她在《培養商業腦的７種組織力》書中是這麼說的：

另一位我很崇拜的憲哥（謝文憲），在書籍中也一再重申：

養成持續且大量的閱讀習慣，是每個人成長，成為一個咖的必經過程。找到案例、找到一個比你更好的架構，來印證你觀點的重要時刻。

— Quote: 《人生準備 40% 就衝了》

某次演講，更是一針見血當頭棒喝：

謝文憲演講

刻意練習

既然這兩位私淑對象都如此說，我就決定，做事不要只訴諸本能，要刻意練習，提升到理論層面。畢竟：

— Quote: 2017-07-26 Tweet

同時，不只是對自己，連演講及引導場合，我也刻意朝這方向鋪陳。（所以，你會發現，近年來，我的演講內容，常會夾帶些理論框架⋯⋯）

漸漸的，開始能夠體會勝間和代所說「從現有的組織架構創造出新的組織架構」的箇中深意。譬如說，我在帶領【引導者讀書會】時，不知不覺就將鑽石模型 (diamond model) 與薩提爾冰山模型結合起來。也在本周兩個場合突發奇想，將《關鍵對立》提出的「影響因素源頭模型」與《鉤癮效應》提到的「法格行為模型 (Fogg Behavior Model)」結合起來，從新的角度分析《克服團隊領導的五大障礙》的模型。

謎之音：簡直是模型大亂鬥。

這麼做，不僅是智性的體操，不僅是一種擴充求解空間的方法，也是一種沈澱反思的過程。

《刻意練習》說：

刻意練習，只在跨出舒適圈後才能奏效，需要學生不斷嘗試去突破現階段的技能水準。這意味著幾乎得傾盡全力，所以往往不會太有樂趣。

「傾盡全力」這一點，我是承認的；但「不會太有樂趣」這一點，我倒不這麼認為——這可是非常有趣呀！

《刻意練習》又說：

刻意練習，幾乎等於加強或調整先前習得的技能，必須著重該技能的特定面向，努力改善。隨著時間過去，這一步一步的改善，最終會打造出專家級表現。

「專家級表現」這一點我還不敢苛求；但至少會朝著劉大任在《強悍而美麗》描述的境界邁進：

在這個世界上，你就愛一種東西，你就在你愛的這個東西裡把自己練到完美，練到無懈可擊。

你因此尋得滿足，此外的一切其實無足輕重。就這樣，你變得堅強，足以抵抗不時傾巢而來的寂寞；你變得勇敢，你學會拒絕周遭的喧嘩與熱鬧；你學會簡單而嚴肅，你形成一種風格，唯你獨有。

是的，形成一種風格，唯你獨有。

像《精準明確思考術》或《超神速全腦學習法》都一再警告依賴既定框架的陷阱：思考怠惰。 ↩︎

引導者，要懂心理：薩提爾之旅後記

Wed, 02 Aug 2017 15:11:04 +0800

前情提要

我在〈六日薩提爾體驗〉一文曾提到：「私心認為，現階段的自己最需要的，並非那些直接就派得上用場的各式各樣的引導技巧，而是可能沒辦法直接就派得上用場的薩提爾心法。」因此，繼三月、四月參加陳桂芳老師帶領的 3+3 天薩提爾之旅之後，六月底，我又再接再厲，再上三天。

基礎篇＋應用篇＋助人篇，整整湊滿了九天。

這次【助人篇：薩提爾自助助人進階工作坊】三天的課程，心得很難寫。因為，體會都在身體裡，在呼吸裡，在內在冰山中。

能寫下來的重點，大概只有兩句話：「和諧而專注的跟隨歷程對話」及「跟隨內在歷程，而不是事件或故事線」吧。

感謝老師、助教小老師、學習夥伴。這九天的冒險旅程，將是我很大的滋養與資源。接下來能做的，大概就是借用從 Joe 那邊學到的方法，刻意練習，自我改變。

引導者讀書會

刻意練習的機會【引導者讀書會】自動找上門。¹ 帶著帶著，不知不覺竟也累積了五場。

既然名為「讀書會」，就有主要讀物及補充讀物。不過，照本宣科不是我的風格。我刻意實驗一些創意混搭手法，尤其是剛學完九天的薩提爾模式。

譬如說，用在破冰上。

讓破冰不只是嘻嘻哈哈的團康，而是藉著「直接切入正題」來破冰，一直是我努力揣摩、刻意練習的手法。我曾在六月中旬【Agile Workshop / 敏捷原理與團隊塑造】課程中小試過一次，反應不錯，因此，我在這讀書會的第一場活動，就是以略帶懸疑的風格，用薩提爾的冰山模型來破冰 + 腦力激盪：

這還是第一回破冰，暖場成分居多。下一回的中心議題，就更深入破這個「冰」了：

後來，更將 Facilitator’s Guide to Participatory Decision-Making 書中提到的鑽石模型 (diamond model) 與薩提爾冰山模型相結合，協助大家從理性及感性兩層面，充分體認團體決策的動態。

這種手法，「歷程提問」的界線控制是一大挑戰。若能謹守「歷程，而非內容」的心法，的確能帶出不一樣的品質。

冰山提問，是需要刻意練習的。²

跨界取經

重要的觀念，不會只有一本書提到，也不會只有一個領域提到。

雖然我不太想把【引導者讀書會】引導到談判領域 ³ ，但是，某些祕訣，在《誰說我們不能一起做決定》及《激發員工潛力的薩提爾教練模式》中反覆提到，在《FBI 協商談判術》及《再也沒有難談的事》也反覆提到。既然理無專在，我就來混搭吧！

譬如說，我就出了這麼一份作業：用右邊兩本書的內容，評註圈點左邊書籍提到的談判案例。刺激吧！

這就是跨界的鉤子。

引導者，要懂心理

整個過程，我充分體會到薩提爾模式的威力。可以說，沒有之前那九天薩提爾之旅的扎實訓練，我不可能看到這一層景緻。

不知不覺中，好像走出一條連自己都料想不到的蹊徑。

幸好我一開始選擇的課，就是溯源的 Satir 課，而不是限縮在職場領域的應用。猶記當時的出發點是：

既然要上課，就要上源頭的。儘管我是從陳茂雄的《激發員工潛力的薩提爾教練模式》一書開始接觸到薩提爾模式，但是，我不想把經驗限縮於職場場域——那是很可惜的事。

任性且大膽，誤打誤撞的幸運。

溯源的好處是，掌握系統全貌，掌握核心關鍵。就以三月底我剛踏進【薩提爾課程．基礎篇】教室的第一天來說吧，原始動機的確是針對別人；但一兩天後就發現，到頭來還是得反諸自己。不反諸自己，成效有限，很快就會卡住。

《論語．憲問》說：「古之學者為己，今之學者為人。」

不可否認的，這九天都在不斷挑戰自己的舒適區，衝擊頗大。不過，引導者本來就要像治療師那樣，隨時認真檢視及測試自己的風格。像《米紐慶的家族治療百寶袋》所說：

溯源的另一個好處是，只要再加把勁，我可以轉化運用在許多領域。像這五場【引導者讀書會】，核心法寶其實就是 Satir 冰山歷程。

也熊熊想到：這讀書會一直辦下去，好像順便就可以拿來開另一場【新手小主管讀書會】，或是作為 Scrum Master 引導技能養成班了⋯⋯

薩提爾課程 - 系列文章

❶ 六日薩提爾體驗

❷ 引導者，要懂心理

我在〈以談判角度看 Sprint Planning〉一文曾提到，「最近在公司內部，受同事之邀，一連主持了幾場【引導者讀書會】，每次一小時。一邊帶，一邊也趁機系統化沈澱反思自己一路以來的土法煉鋼心得。」 ↩︎
活動前，自己先惡補《沙維雅模式冰山歷程提問範例》的相關內容，自評，當場在「歷程提問」的界線控制上，約有 70分吧。 ↩︎
畢竟，在談判領域，我還很嫩，書也沒讀通，不能誤人子弟自曝其短。所以，我十月份要去拜師學藝。 ↩︎

以談判角度看 Sprint Planning

Thu, 27 Jul 2017 12:18:03 +0800

自從去年 Q3 個人的 Scrum 首航開始，讓我壓力最大的，並不是主持 Retrospective，而是 Sprint Planning。上完 CSPO 課程後，更是對高品質的 Sprint Planning 有著不一樣的願景。

研發團隊需要再教育，PO 又何嘗不是呢？

只是，不同的 PO 有不同的團隊領導風格，大多數個性鮮明的 PO 也不是那麼容易被改變。這就有待 Scrum Master 善用軟技巧去適時引導。

其中，最立竿見影直接見效的，就是會議引導技術。

最近在公司內部，受同事之邀，一連主持了幾場【引導者讀書會】，每次一小時。一邊帶，一邊也趁機系統化沈澱反思自己一路以來的土法煉鋼心得。

談判？

在反思、設計、取材的過程中，偶然發現，《價值談判》這本有趣的小書，還滿適合想要改善 Sprint Planning 的人讀讀。

尤其是 PO 及 Scrum Master。

《價值談判》

雖然我不太想把 Sprint Planning 直接定位成一種「談判」，尤其是涉及「權力」的談判；但不可否認的，Sprint Planning 過程中，本來就有很多談判的元素在裡面。

工具是中性的，看你怎麼運用。

既然連「一談就贏」談判名師／明師都認可這本書，我相信單以「談判」角度來說，這本書是可信的。那麼，下一個問題就是，這本書真的適合給 Sprint Planning 參考嗎？

且讓我摘錄幾段吧！

錨定效應

我常引用《執行力的修練》的四大紀律框架來指導敏捷開發活動。其中，紀律一「鎖定極重要目標」也正是 Sprint Planning 的起手式。

《價值談判》也有許多與此類似的論述：

「要求」(position) 是假的，「需求」(needs) 才是真的。

所謂談判，就是一場「發覺對方需求」的遊戲。如果你是以「我能得到什麼」為思考的出發點，這場談判絕對很難成功；記得要先從「我和對方認為的重要價值是什麼」、「如何滿足這些價值」開始思考，談判品質會在彼此專注於「價值」時得到提升。

所謂談判，最終只是一場「認知鬥爭」，先將對方的認知拉到對我自己有利的標準點上，再來開始談判。善用錨定效應。

所以，只要是我有權主導的 Sprint Planning，都會先花些時間請 PO 重新展開 Impact Mapping 及 Scaling Lean 的內容，尤其是還沒有穩定扎實 Product Backlog Refinement 的團隊。

什麼才是「贏」？

如果沒有妥善經營共識，Sprint Planning 往往淪為 PO vs 團隊之間的拉鋸戰。一方認為「加功能」才是贏，另一方認為「清技術債」才是贏，彼此據理力爭；但殘酷的現實是，最後主導權往往都落在有職位權的那一方。

這是真的「贏」嗎？

《價值談判》是這麼說的：

世上所有談判，大致可分為兩類，一種是以關係為中心，另一種則是以利益為中心。真正卓越的談判家，是能夠將原本以利益為中心的談判對象，轉換成以關係為中心。

回想你目前的談判對象，未來是否還需要碰面往來？如果需要，你們之間就會以關係為中心進行談判，在這樣的談判中，比起短期經濟利益，信任和評價等這種會有長久影響的價值更為重要。

如果要以「關係」為中心，就不能草率了事，要花心思：

各位認為社內協商容易或社外協商容易呢？

大部分人會認為社內協商比較困難，為什麼？我想應該是因為錯誤的信任所導致，像是「你應該知道我在想什麼」的氛圍。因此社內員工只會越來越用「無理要求」來強迫對方接受，而不再用邏輯與根據來說服對方。

為了能有效談判，記得要拋下「你應該知道我在想什麼」這種毫無根據的錯誤信任，並以邏輯與根據填補空缺才行。

卓越的談判家，會在讓步時提出充分的邏輯與根據，好讓對方覺得這份讓步是有價值的。

這些，都是慣常 command-and-control 的老派 PO 必須調整的，也是 Scrum Master 必須適時引導的。

雙人舞

其實，好的 Sprint Planning，不只是 PO 的責任，團隊成員也是。團隊成員不只是接案，也在提案，所以，也需要學習（或被引導）正確的協商方法。

畢竟，正如《價值談判》所說，「談判就像在跳雙人舞」：

談判，其實就是一種表達方式、一套邏輯，不論要談什麼內容，營造能使對方開口的氛圍很重要。

在談判桌上，不要因為對方沒有採納我的提案而感到失望或憤怒，卓越的談判家只會投注更多心力在如何讓自己的提案更出色。

如果雙方都是談判專家，彼此能夠交換的條件就會越多，等於是更容易創造出創意對策。

結構先行

回到本文開頭的起心動念。

最近在公司內部，受同事之邀，一連主持了幾場【引導者讀書會】，每次一小時。一邊帶，一邊也趁機系統化沈澱反思自己一路以來的土法煉鋼心得。

突然有個感觸：好像應該開始總結這十個月以來，穿梭數個團隊帶領 Sprint Planning 的所見所聞，以 Facilitator’s Guide to Participatory Decision-Making 書中提到的鑽石模型 (diamond model) 及串組式流程設計 (string) 加以精鍊。

我想用結構化的 Sprint Planning 流程，讓錨定效應、以關係為中心、目的型談判自然發生，讓參與其中的人，逐漸在刻意不遮掩的建設性衝突中，潛移默化。

不過，我這種流程設計，對於資淺 PO 來說，應該是備感壓力吧。呵呵。畢竟，這高度考驗著說故事能力 (story telling) 及參與式決策的開放心態 (participatory decision-making)。可是，少了這些，怎能算是合格的廿一世紀 PO 呢？

我們家的 CEO 接受這樣的挑戰了，那麼，你呢？

Sprint Planning

自我改變，起點不是先挑戰意志力

Tue, 16 May 2017 22:44:42 +0800

一看到 Joe 多年後重開【大人學講座04 : 有效自我改變的系統化做法】，二話不說，立刻報名。

為什麼這麼有信心呢？

原因之一，已經上過好幾次 Joe 的課程，尤其是與這主題風格類似的【別總是直球對決】。我很清楚這類課程的系統性及實用性。

原因之二，看了 Joe 的幾篇文章，意猶未盡，想看看多年後重開的加長版講座，又有什麼新的體悟？

原因之三，儘管課程文案特別提醒「不適合的對象：嘗試想改變別人者。改變的關鍵首重於自身的覺醒。所以若你是想聽完後去影響身邊人 (小孩、朋友) 的，我覺得幫助會有限喔，所以就請別浪費錢了。」但反骨的我，還是想嚐嚐看有沒有一些幫助。

答案是：有！

基於不破梗不爆雷原則，不便直接透露五糾結、五方向、五表單的內容，我只徵引一些最有感的類似觀點，作為呼應。

很多人並沒打算玩真的

Joe 說：「『不做為』本身也是一種作為；不要到了被迫改變時才改變。」

這跟《大人學選擇》 pp. 265–266 說的「及時的責任」一樣：「大部分的人更該擔心的，是不選擇，眼睜睜地看著狀況越來越惡化，如同溫水煮青蛙般的『慢性選擇消失問題』。」

所有選擇都有代價

Joe 說：「請先盤點思考：我願意犧牲什麼？」

這跟《大人學選擇》 pp. 19–20 說的「原則四：預想最壞的情況會怎麼樣，並預作準備」道理一樣：「當你連最壞的狀況都想過一輪時，代表你對這項選擇也做好了全方位的規劃。後續執行時的順暢度，其實也會跟著大幅提升。」

意志會耗盡

市面上一堆《先別急著吃棉花糖》、《輕鬆駕馭意志力》、《恆毅力》書籍，不斷鼓吹並販賣「提升意志力」的秘方。不過，Joe 的這句話，有如當頭棒喝：「意志力就像電池，是有限資源。」

的確，日常生活的種種重要／不重要、急迫／不急迫的事，在在都在消耗我們的意志力。我們該選擇對抗天性，還是選擇順從天性？

Joe 說：「最好的忍耐，是不忍耐；最好的判斷，是不判斷。」

聽到這裡，突然領悟到許多專案管理方法，之所以講究以簡馭繁，就是這個道理。像 Scrum 限縮 Sprint Backlog，就是為了避免面臨無盡的選擇、插單的誘惑、父子騎驢的判斷，白白消耗團隊的意志力。

意志力，是有限資源，請好好保護它，請善用它滿格的黃金時刻。

不叫我們遇見試探

論語泰伯篇：「危邦不入，亂邦不居。」

新約主禱文：「不叫我們遇見（陷入）試探。」

《你要如何衡量你的人生？》 pp. 242–244 說：

百分之百的堅持，要比百分之九十八來得容易。

我發覺要抗拒「就這麼一次，下不為例」的誘惑，其實是我這一生最大的決定。為什麼？因為人生總有許許多多的情況要你妥協，讓你有「身不由己」之感，然而只要出現一次「下不為例」，總會再出現另一個「下不為例」。萬一我這次跨越界線，往後就會不斷出界。如果你不越界，個人道德界線的力量將非常強大。

這道理，對個人適用，對團隊適用，對組織一樣適用。

由此也可看出為什麼 Scrum 發明人在《告別瀑布，擁抱敏捷》書中苦口婆心說出一段貌似專制頑固的論調：

Scrum 不是可以被隨意修改來迎合既有企業文化的流程，反而是應該調整企業文化來適應 Scrum。

在 Scrum 中，阻礙軟體開發方式的文化障礙將無所遁形。如果沒有用 Scrum 來建立敏捷、透明的開發環境，那隱藏的問題將會一直留在企業內損害企業的利益，那就失去了使用 Scrum 最主要的好處。

Kanban 的 WIP 設計，是一種隔絕誘惑的方法。Scrum 的 sprint timebox 設計，也是一種隔絕誘惑的方法。

請設計聰明的隔絕誘惑、逃離誘惑的方法。

內心的自動導航機制

Joe 引述《為什麼我們這樣生活，那樣工作？》書中提出的「習慣迴路」理論，提供一些破除舊習慣、養成新習慣的自動導航機制，讓「心中善良而任性的小孩」可以整合對齊。

Joe 說：「習慣不能改，只能覆蓋。」

不過，整個誘因建構三部曲「提示」→「行為」→「期待獎勵」當中，起手式「提示」的關鍵，仍在於自我察覺力。看起來，就像任何觸及心靈的手法，「自我察覺力」仍是非常重要的鍛鍊。

兩個月的作業

這是一門值得好好沈澱，對自己許下承諾的課。

希望兩個月後回頭來看，能在某些地方邁入良性的自動導航系統。在自己身上，在家人身上，在團隊身上。

「做自我的改變，跟買 3C 產品一樣，早買早享受！」

六日薩提爾體驗

Wed, 19 Apr 2017 16:14:28 +0800

在團隊帶領時，總是會遇到許多需要訴諸軟技巧的時刻，尤其是引導 (facilitation)。

雖然上了一些課，閱讀一些書籍，也親自實驗帶了一些引導活動（過程請見〈2016 個人回顧〉及〈欣賞式探詢〉文章），但總覺得少了一塊很重要的成分。

一塊說不上來的成分。

同溫層族人常會推薦 ICA Taiwan 的課（像 David Ko 的這篇推坑文及 Yves Lin 的這篇推坑文），但私心認為，現階段的自己最需要的，並非那些直接就派得上用場的各式各樣的引導技巧，而是可能沒辦法直接就派得上用場的薩提爾心法。

Why Satir?

組織，其實和個人一樣，都有行為、應對姿態，都有感受、感受的感受、觀點，也都有期待、渴望，甚至自我——都有各層次的冰山。

冰山如此，改變歷程亦如此。還沒如實看到冰山：自己的冰山、別人的冰山，就奢談馬斯洛層級、變革管理、引導或領導，似乎有點太跳躍了。

我想認真學習如何探索冰山。我在〈2016 個人回顧〉一文也預告過，我想上體驗課程，親自體會箇中幽微之處。

既然要上課，就要上源頭的。儘管我是從陳茂雄的《激發員工潛力的薩提爾教練模式》一書開始接觸到薩提爾模式，但是，我不想把經驗限縮於職場場域——那是很可惜的事。

因此，我參加陳桂芳老師在旭立文教帶領的 3+3 天薩提爾之旅。

異常充實超值的六天。

引導

此行主要目的並非觀課，但是職業病使然，不自覺就會側面觀察：第一天，一群陌生人，該如何破冰，讓大家逐漸充分敞開，而且是敞開幽微敏感的內心？

超神奇的，能一下子就把四十人充分混搭到充分對談的地步！

中間肯定是有技巧的，可是，一切的觸媒仍在於「與人接觸」。

這正是薩提爾模式美妙之處，充滿安全及信賴的接觸情境。

不怕千招會，就怕一招精

教室走廊有一幅掛圖，清楚展示薩提爾手法的豐富性：

說實在的，來上課前，心中的確抱著一絲期待，期待能夠盡量體驗到越多手法越好，滿足好奇心。

可是，老師其實並沒有急於把每一招都展示出來，而是保持彈性，依循現場的情境與動力，仔細帶出特定手法的幽微細節：

基礎篇的三天，我們體驗了生存姿態、冰山、家庭雕塑、一致性溝通。
應用篇的三天，再加入家庭圖、影響輪、內在資源。

如果純粹以帳面上的數量來說，六天課程，體驗了七大手法。但事實上，貫串所有活動的最核心手法，就是冰山。

冰山，可說是知己、知人，與己和、與人和的重要關鍵。

六天課程，一次次的個案分析演練，某種意義上，算是專注把「冰山」這一招練到銘印心坎的程度。回頭反思，這也算是繞開我當初表層的「期待」，直接訴諸更底層的「渴望」。

也算是一種「未滿足的期待」的轉化吧。

雕塑

以前在看相關書籍時，就對薩提爾招牌的「雕塑」手法十分好奇。但也不禁懷疑：真有那麼神奇嗎？

真的要親臨現場，才能體會到雕塑的震撼。

現場學員，活生生的第一手家庭雕塑，令人戰慄。

沒想到，原生家庭的影響，居然如此深遠。四種生存姿態，真的就像系統思考領域所講的系統基模，在許多個案中反覆出現。

案頭一堆薩提爾個案書，果然是真的，雕塑過程的現場動力，果然也是真的。

望著雕塑，望著冰山，著力點要放在哪裡，會自然浮現出來。也深深體會到，每個人都有多種應對的選擇，不要被環境命定論自我設限了。

老師的結語：「一致性溝通，本身就是一項冒險。選擇在你自己。」

自己的冰山

第五天，有一項課後作業：畫自己的家庭圖及影響輪。

當下還無異狀。但下課返家途中，莫名有一股說不出來的悶悶抑鬱感。這才驚覺：18歲之前 vs 18歲之後的冰山，挖呀挖，好像觸碰到某個一直不敢直接承認的脆弱之處。也算是⋯⋯嗯，隱藏得連自己都看不太到。

或許正如 Maria Gomori 在《心靈的淬鍊》所說：「雕塑可能在主角身上引發不同於平常的意識狀態 (altered state)。」

悶悶狀態長達六個小時。睡前趕緊寫冰山筆記，隔天課堂小組分享，才得到些許紓解。

也對自己做了個重要的選擇。

一連串家庭圖、影響輪、內在資源轉化下來，有種能量充滿的感覺——不靠催眠也做得到。

過程中也才發現，自己的冰山居然有這麼多隱而未現的東西。自己如此，遑論別人了。難怪薩提爾手法中，不斷強調帶著偵探帽，要邀請，要核對求證。

六日薩提爾體驗，看別人雕塑及冰山的同時，其實也在看自己。幸虧走了這一遭，打通了閱讀之「腦」到體驗之「心」的路徑。

身體學會的，誰也拿不走

經過整整六天的薩提爾洗禮，回頭看這些書，尤其是裡面的個案及雕塑過程，點頭如搗蒜。

像《薩提爾成長模式的應用》前言有一句話：「重點不是口述出來的 “問題” 或 “故事線”，而是案主做了些什麼，來回應他們眼中的 “問題”。」以前會理所當然的一眼瞄過去，現在，則是浮現出栩栩如生的雕塑角色的立體圖像，演將出來，共舞，共鳴。

回頭看陳茂雄的《激發員工潛力的薩提爾教練模式》，突然發現，許多以前標注的想要記憶的重點，似乎不太需要主動去記憶了。果然，身體學會的，誰也拿不走。這就是體驗式課程的威力。

就連與薩提爾模式無關的《克服團隊領導的五大障礙》，再回頭看，就完全理解作者的施力點是在哪裡了。

果然，上課，就要上溯源的。

不僅書本看得更懂了，言談舉止也受到影響。

回到工作崗位 facilitate 團隊時，回到家庭面對柴米油鹽醬醋茶時，居然也有一點點桂芳老師的習慣用語、引導提示語上身（只是⋯⋯稍微再陽剛一點點，哈）。

對於團隊的耐心也提升了。像在 Sprint Planning 時，面對某個可預見的失敗，我居然會刻意不介入。有時候，要讓當事人用肉身感受到痛，激發底層的期待，甚至渴望，才有撼動觀點或規條的機會。畢竟，在可控制的風險下，不介入混亂的發生，也是薩提爾改變歷程中，鬆動觀點，賦予當事人自覺、擔起選擇責任的重要觸媒。

我也察覺到自己慣用的 ORID 引導手法中，似乎只觸及到行為、感受、觀點層次。有機會的話，想嘗試再下探一兩層。嗯，是挑戰，但值得一試。

實體課程要的是什麼？

親炙這些一流的體驗式課程，後遺症是，想腰斬一些自認難以做到這種境界的演講及課程了。從文字圖像及影片就吸收得了的內容，似乎也不值得輪到我來講了。

在這個書籍、文章、教學視頻、線上課程，甚至 webinar 直播充斥的年代，實體課程還能夠吸引得了人，就是要提供獨特的互動經驗：講者與學員之間的互動，甚至學員彼此之間的協作互動。

這一年來深深的體會。

給自己立的期許是：演講及課程，要做到不只撼動到行為及觀點層次，更要下探期待及渴望。

自我期許，要精熟三項道具：便利貼，卡片，樂高積木。

自認目前較接近預期境界的，只有近日即將公告的【敏捷原理與團隊塑造】吧。

交融

一年前的自我期許：「左腦高德拉特，右腦薩提爾」，如今兩者總算開始加速融合。

相隔三週，接連上了六天薩提爾體驗課，突然想從網路問答中撤退。面對面時，連別人的冰山都不見得探索得到，遑論網路上？別再與世界爭辯了，把能量放在活生生的與人接觸吧。

三天基礎篇、三天應用篇的薩提爾之旅，很深沉的觸動與悸動。如果你也想體會一下知己、知人，與己和、與人和，就給自己一個冒險的機會吧！

薩提爾課程 - 系列文章

❶ 六日薩提爾體驗

❷ 引導者，要懂心理

CSPO，超越收據的收穫

Wed, 08 Mar 2017 14:52:29 +0800

為什麼要去上 Scrum 認證課程？

去年 Q4 起，在有限的職權範圍內，小規模試行敏捷轉型。一路走來，自認在 Scrum 這一塊還有很多不足之處，想親炙這領域的先行者，以印證自己摸索的心得，並解決思考及實踐上的盲點。

上課，是一條捷徑。

因此，看到 Terry Wang 的〈Scrum Alliance 的 certificate〉一文，我開始對 Scrum 認證課程感興趣。

證照（「收據」）不是目的：

其實認證只是一份收據，他不會幫你加薪，不要為了拿而拿。

收據真的只是其次，這些課程都是世界級的，滿滿的都是知識，只是看每個人能拿多少回家。

再次強調，認證只是收據，不要為了拿而拿，是為了去跟大師學習。

至於那些所謂的「收據」，我倒是不需要了。反正又不是自己要開課教人考證照。

為什麼要去上 CSPO 課程？

那麼，接下來的問題是：要去上哪一門課呢？CSM？CSPO？CSD？

Terry 的文章，讓我嚇了一跳：我完完全全誤會了，原來 CSD 比 CSM 及 CSPO 還難拿到呀。

原本以為，像 Scrum Master 這種帶點 coach 性質的人，養成教育應該更難才是。

撇開其他因素，純以自己的需求來評估。

身為一個技術人，CSM 或 CSD 似乎是首選？

但是，突然覺得，現階段的自己，好像比較需要去上 CSPO 的課，才能用 PO 的語言去 facilitate PO。

至於 to facilitate/coach developer 一事，本來就是自己的守備區，也一直在做了。

其實，在軟體研發這一行，developer 畢竟是第一線執行者，很容易就吸收 PMP 的 planning/executing/monitoring/controlling 觀念（但對於繁文縟節則敬而遠之），或 Scrum 及 Kanban 這種輕量級的風格。

反倒是 PO，擅長的是發想願景，不見得擅長執行面。

— Quote: 2017-01-05 Tweet

難怪有兩種 PM：PdM (product manager) & PjM (project manager)。

畢竟，個別來看，單單在「行腳商人」及「總管」這兩個圈圈裡努力奮鬥，都不見得做得到位了，遑論 PdM 及 PjM 跨界合體，身兼兩者之長。

職場生涯中，我就親眼看到一大堆沒有 PjM 觀念的 PdM 把優秀工程師逼走的血淋淋實例。尤其是根本就沒有 CSPO 心態的 PdM。

教育 PO，比教育 developer 難。

你覺得賈伯斯是容易被教育的嗎？

所以，我才要去上 CSPO 課⋯⋯

如果只從 Scrum Master 角度出發，想去 facilitate PO，小缺點就是，會只被當成 project manager。優先序一出現衝突狀況，會被質疑沒有 product manager 或 portfolio manager 的高度。

因此，對於那些沒有 PMP 也沒有 Scrum 也沒有 Kanban 觀念的 PO，先換位思考，用他們的語言說話，（或許）才比較容易 facilitate 他們。

換位思考

上呂毅老師的 CSPO 課程，最大的體悟是「強制換位思考」。尤其是 Johari Window，是很有必要的。

「Sprint review 的重點，不是 demo working software。」這一金句，也真的是顛覆我的成見。

“Learning” 的確是整個 sprint 從頭到尾都一直在持續發生的，尤其是想當然爾全程都積極參與的 Scrum Master 及 developers。只是，該 “learning” 的，可不止這些人，而是所有 stakeholders。而且，某些 stakeholders 只會在某些 event 才有較高機率有義務出席——sprint review 就是這樣的表定 event。

所以，對這些有義務出席 sprint review 的 stakeholders 來說，出席這個 event 的重點是什麼？

大概就是朝這個方向思考吧。甚至，整個 sprint 過程中，PO 也應該以此作為首要關注點，不要微管理。

果然還是需要換位思考。

Worksheet in CSPO course

PO 真的有自覺嗎？

現場觀察，及老師回憶，來上 CSPO 課的，的確以工程師居多。

所以，可以想見，兩天醍醐灌頂後，回到工作場域，許多沒有職位權的人，將面對極大的不匹配及無力感。

所以，權位以外的影響力，真的很重要。

所以，憲哥的書，華倫班尼斯的書，大人學的課，請多多自我預備吧。這是當場我給同學們的小小建議。

否則，找機會讓遠來牧師去貴公司講道吧。畢竟，耶穌說：「我實在告訴你們：沒有先知在自己家鄉被人悅納的。」

跨界拼圖

人生首張證照，當生日禮物。

而且，某種意義上，也算小小的跨界。

CSPO Certificate

上完課之後的感想是：果然應該要來上 CSPO 課，拼圖才完整。

也成功推坑幾位同事，擴大盟友。

更令我開心的是，超強的同事，已經開始運用這兩天上課學到的東西了。

被 CSPO 課程洗腦後，再看一些沒有用 Impact Mapping 結構表述的產品藍圖，就覺得層次不足，漏洞百出。

重點是層次，不是形式。

上了兩天 CSPO 課，與一些已經浸潤於 Scrum 協作環境的大江南北英雄英雌共同演練，心中真是無限感觸。

我是努力用理性推導，小步試行（還從許多其他領域偷渡觀點及作法），別人卻是早已像呼吸一樣，相忘於江湖。

感覺很像當年，我是去學習 PMP 觀念，別人則是去複習他們早就每天都在做的事。

這就是差距。

這差距，就要靠軟功夫及硬功夫去彌補了。

不能逃避的責任

現在完全能夠體會 Terry 說的「假如你真的有興趣，去上課，拿到了收據，我認為你對台灣的軟體產業有一份責任，你需要把台灣的軟體產業變得更好，因為你是先知先覺者。」

這是我們的責任。

說好了要一起變強。加油吧！

打怪升級路線圖

Tue, 27 Dec 2016 08:00:00 +0800

遊戲化

我第一次看到將「遊戲化」概念運用到職場上的點子，是在《加入遊戲因子，解決各種問題》這本有趣的書：

遊戲的十個組成要素

第二次看到將「遊戲化」概念運用到職場上的點子，是在《三年後，你的工作還在嗎？》書中看到的「職能路線圖」，猶如 RPG 遊戲的打怪升級路線，從等級 1 一路打到等級 11：

職能路線圖

第三次看到將「遊戲化」概念運用到職場上的點子，是在 Bryan 的【A101 職場大人學：職場人際關係與優勢策略】課堂上，學到如何巧妙運用新世代的特質來設計遊戲規則：

還有那張所謂的「集點卡」：

與「遊戲化」三度接觸後，儘管我還沒參加 Bryan 的【大人學講座09：用遊戲思維規劃你的職涯策略】，但也已經激發出許多可以派得上用場的想法了。

其中一個想法，簡單來說，就是準備一份「打怪升級路線圖」。

個人與團隊

打怪升級路線圖，好處多多。

第一個好處，當然是針對自己，檢視自己在工匠、總管、行腳商人這三大屬性中，還要打什麼怪、練什麼功、衝什麼裝備。

第二個好處，是在團隊領導上。

正如《三年後，你的工作還在嗎？》書中提到的：

團隊現況雷達圖

雖然我的職責範圍是帶領工程團隊，理應只需顧好「工匠」路線，但正如我在〈工作分解講座・閱讀材料〉一文闡述的：

專業工作者，除了精進本職學能之外，我認為，還需要致力掌握適當的工作分解／拆解技能。

工作分解／拆解，並不只是專案經理的責任，而是實際執行者也必須參與的。這也是專業工作者的責任區。

老實說，敏捷開發追求的「自組織團隊」境界，對工程師的要求是很高的。身為工程團隊的主管，很有必要擬定一份「打怪升級路線圖」，界定各職等該有的專業技能及專業態度，團隊才有方向感，也才有人資層面的操作依據。

萬事起頭難。該如何草擬這麼一份「打怪升級路線圖」呢？

以軟體研發領域來說，其實有一個滿簡單的切入點。

先把整個 Scrum cycle 跑完時，每個環節各需要哪些能力及態度，統統列出來，再慢慢去分組歸類。其實，這就已經將一位「工匠」的專業技能及專業態度，都大致涵蓋進來了。

就以專業技能為例，Scrum 的 “definition of done” 就是一個不錯的出發點。請想一想，在整個 Scrum cycle 當中，你對每一個職等的人，各有什麼 definition of done 的期許？

如果你是認真看待每一個職務、職能、職等，你一定找得出一些評估角度。而且，不必強求第一次就訂得完美。

我這幾天就是用 Scrum + DevOps life cycle 的角度，再搭配參考《三年後，你的工作還在嗎？》的「職能路線圖」及「知覺價值」，彙整出一份研發部門的「打怪升級路線圖」。

招聘

「打怪升級路線圖」第三個好處，是在招聘上。

既然我們對內，都期許團隊有如此水準了，理應有資格以此標準來挑選未來可能共事的人才。

當然啦，面試現場，我不會真的把這張表格攤開來，請君入甕對號入座。

我用情境題。

我會出一些面試前就請對方作答的申論題，問他們對於敝公司產品或服務的看法：好的、可以再改善的、不好的。並針對某幾點提出企劃，說明如果錄取後，可以怎麼協助改善。當然啦，這只是企劃，不是要對方事必躬親；我們招聘的是工程師，他大可選擇只從工程角度提出企劃。

這種問題，可看出他們做了多少功課，有沒有獨立見解，有沒有 WBS 工作拆解能力。

反正，就算面試前不問，我也會在面試時問。但，臨場才要對方思考，那就更困難了。

有人質疑：只是要招聘工程師，出這種題目，會不會太誇張了？

其實這類問題，其他部門在甄選大三大四實習生時就廣為運用了。我拿來用在招聘正職員工身上，應不為過。

畢竟，我們不是大公司，沒有本錢只請小螺絲釘；要選既有能力又有熱情，有潛力可以獨當一面的多能技術人。我們也不是需要研發高檔演算法的公司，所以，技術能力，到一個合理地步就夠了。反而是更根本的態度，會決定我們能不能放心把任務交給他。

尤其是敏捷開發，更是有這種要求。

所以，先想想自己團隊需要什麼樣的人吧。不同的出發點，會導致不同的面試策略。

何況，也不是每一題都要作答到滿分。都滿分的話，那就是白袍巫師等級了。

進階情境題

最近我也從 appreciative inquiry 學到一些有趣的探詢角度，搭配心中的「打怪升級路線圖」，面試真的簡單多了。當然啦，那又是另一段故事了⋯⋯

欣賞式探詢例子

種種情境題，目的都是設法蒐集足夠的線索，以在「打怪升級路線圖」給予適當定位。

以上簡單介紹最近體會出來的三個「打怪升級路線圖」用途，供大家參考。

工作分解講座・閱讀材料

Wed, 30 Nov 2016 08:00:00 +0800

緣起

我在〈One-Week Sprint 的節奏〉一文提到個人的「迷你版 Scrum」首航經驗：

第一個 sprint 順利達標，儘管變數層出不窮。

萬萬沒想到第一次嘗試帶 Scrum，而且是「1 舊人 + 2 新人」的高風險組合，就很有機會實現。除了天時地利人和的配合，事先認真的 WBS 分析，應是重要因素。

後來幾個 sprints，大體上也都順利達到 due-date performance。回顧經驗，我仍然認為「事先認真的 WBS 分析」是重要因素。

所以，當我想將成功經驗推廣到其他專案上面，有一個重要的前置作業，就是灌輸全員 decomposition 意識。

要以「WBS + activity」為單位，還是以「user story + task」為單位，我並沒有強制規定（也不是現階段的重點）。但其中的 decomposition 意識，則必須確實掌握。

因此，第一步，我先召集大家玩一次〈TOC 瓶頸處理九大原則〉，從樂高遊戲中學習；接下來的第二步，嗯，又是我「讀書會」招數派上用場的時機了。

讀書會的進行方式：

活動前：各自閱讀指定材料。
活動中：搭配 workshop 演練案例，而且是以公司真實的專案為實例，不僅具體，又能直接連結每個人的工作。

這種訓練是很重要的。畢竟，連自己經手過的專案都分解／拆解不出來了，還談什麼後續的 planning poker 呢？

真實專案 workshop 我打算分兩回合進行。以下僅列出可以公開釋出的閱讀材料，給大家參考。

Part I / 基本觀念

專業工作者，除了精進本職學能之外，我認為，還需要致力掌握適當的工作分解／拆解技能。

工作分解／拆解，並不只是專案經理的責任，而是實際執行者也必須參與的。這也是專業工作者的責任區。

這不是我個人的偏見，而是連 PMBOK 5/e 都如是說：

The project manager, in collaboration with the project team, then determines the final decomposition of the project scope into the discrete work packages that will be used to effectively manage the work of the project. (§5.4.2.2)

Each work package within the WBS is decomposed into the activities required to produce the work package deliverables. Involving team members in the decomposition can lead to better and more accurate results. (§6.2.2.1)

首先，請先讀讀以下這篇文章，初步了解 WBS (work breakdown structure; 工作分解結構) 的基本觀念：

PM 的牛肉在哪裡？再談 WBS (by Bryan)

有餘力的話，可再選讀：

小提醒：「工作分解結構」觀念，不管是古典的 PMP，還是近代流行的 agile、Scrum、Kanban，其實大原則是相通的。讀這幾篇文章時，請留意幾個重點：

Deliverable (用名詞表述) 與 activity (用動詞片語表述) 的劃分。
逆向拆解。
100% Rule。
麥肯錫的 MECE 原則（Mutually Exclusive, Collectively Exhaustive），也就是說，WBS 拆解要做到「彼此獨立、毫無遺漏」。此處，「毫無遺漏」是首要重點。

Part II / 軟體界的工作分解

軟體研發領域，也需要工作分解：

The Scrum Field Guide, Chapter 12: “Decomposing Stories and Tasks”

請留意文章中這句話：“Our sprint length wasn’t the problem. Our ability to decompose work was.” 請思考背後的論述。

Part III / 好的 User Story 原則

INVEST 原則簡介

《Scrum：用一半的時間做兩倍的事》第六章

INVEST 原則細說 (by Bill Wake)

Part IV / User Story 拆解術

一般建議：

針對 workflow 的拆解建議：

Five Story-Splitting Mistakes and How to Stop Making Them

Part V / 切到多細？

User story 及 task 要切到多細，並沒有標準答案。不過，我還是蒐集一下專家們給的建議。

Scrum 共同發明人 Ken Schwaber 在 Agile Software Development with Scrum 書中建議：

“Tasks should have enough detail so that each task takes roughly four to sixteen hours to finish.”

Essential Scrum 第 19 章建議：

“Teams that take this approach typically follow a helpful rule of breaking down tasks so that no one task is more than eight hours of effort, although some might be a bit larger. At this level of granularity the team has a good idea of what really needs to be done and whether it can accomplish those tasks in the time it has available.”

The Scrum Field Guide 第 12 章則建議：

“Follow the rule that tasks should be completed in no more than two days.”

個人經驗是，努力將 task 切到不超過 2 個工作天的程度，能有效降低專案的不確定性及風險。

【敏捷的工作分解方法】系列

❷ 工作分解講座・閱讀材料

TOC 瓶頸處理九大原則

Mon, 14 Nov 2016 08:00:00 +0800

高德拉特初試啼聲之作《目標》，最為人津津樂道的，不外乎是「聚焦五步驟」（又稱 POOGI）及「鼓-緩衝-繩」(Drum-Buffer-Rope; DBR)。

此兩者都是流程，都是可立即實施的方法。

不過，在進入流程之前，有沒有更基本的現象觀察及原則歸納，可讓我們在運用這些流程時，更具方向感，不易走偏？畢竟，不懂原理，貿然盲目依循流程，並不會增加成功機率，反而可能因為不明就裡，不知變通，導致無法排除障礙，進而放棄整套方法。

尋找原則

高德拉特在《目標》書中，曾藉由鐘納 (Jonah) 之口，對主角羅哥 (Rogo) 說出：

事實上，為了說明瓶頸和非瓶頸之間的關係以及應該如何管理工廠，我擬定了九個原則。 — Quote: 《目標》 p.222

可惜的是，翻遍全書，我始終找不到像 1、2、3 這樣清楚條列出來的九原則。連用「原則」關鍵字去搜尋，都湊不滿九個數字。

因為找不到具體的條列清單，我只能獨自揣測，列出我所以為的「瓶頸處理九大原則」。列出來後，再拿來複習 TOC 體系的聚焦五步驟、DBR、關鍵鏈，甚至非屬 TOC 體系的 Kanban、Scrum、DevOps，都有耳目一新之感。

本週六我將會在 Agile Tour Hsinchu 2016 給一場演講〈瓶頸處理九大原則〉。內容有點硬，為了調和，我將源自《目標》書中針對 MTO/MTA 而設計的瓶頸遊戲，改編成專案導向環境。一小時的演講，時間有限，這次只能先玩個十分鐘的初級版。

因為以後還有機會帶人玩這遊戲的進階版，為了避免破梗，影響日後其他人從遊戲中學習的效果，這場演講的投影片就不公開了。如果反應不錯，以後還有的是機會；如果效果不好，那⋯⋯也不值得公開了。

投影片可以不公開，但「瓶頸處理九大原則」倒是很值得公開。以下僅就《目標》中譯版的頁碼順序，列出我所揣測的「瓶頸處理九大原則」，供大家參考。

仔細揣摩這源自「依存關係」與「統計波動」兩大現象的九大原則，可深化對許多事物的看法。

瓶頸處理九大原則

➊ 每個人時時刻刻都在工作的工廠，是非常沒有效率的工廠。 (p.132)

➋ 我們根本不應該試圖平衡產能，我們反而需要多餘的產能。要平衡流量，而不是產能。 (p.222, p.405)

➌ 瓶頸不一定很壞，或很好，瓶頸只是你們所要面對的現實罷了。找到瓶頸在哪裡之後，你們必須利用瓶頸來控制通過系統和進入市場的流量。 (p.223)

➍ 怎麼樣會浪費掉瓶頸的時間呢？其中一個方法就是讓瓶頸在休息時間停工；另外一個方法就是讓瓶頸處理不良的零件，或是讓零件在後來的作業中，因為工人的疏忽或是流程控制馬虎而產生瑕疵；第三個浪費瓶頸時間的方法，就是讓瓶頸處理你們不需要的零件。⋯⋯應該事先就淘汰不良的零件，確定瓶頸只處理沒有問題的零件。 (p.250, pp.253–254)

➎ 工廠的產能，就等於瓶頸的產能。假如瓶頸損失一小時的生產時間，就等於整個系統損失了一小時。 (p.252, p.363)

➏ 要如何充分運用瓶頸呢？有兩個主要的原則：首先，絕對不可以浪費瓶頸的時間，應該讓瓶頸只處理對「今天」的有效產出有所貢獻的零件。另外一個方法是，減輕瓶頸的負擔，把部分工作移交給非瓶頸的生產資源。 (pp.253–254)

➐ 非瓶頸資源的利用程度，並不是完全由其生產潛力來決定，而是由系統中的其他制約因素來決定。 (p.329, p.405)

➑ 對於通過瓶頸的零件而言，排隊占了大半的時間，因為零件會在瓶頸前面大排長龍，等待瓶頸處理。對於只通過非瓶頸的零件而言，等候則占據了大半的時間，因為它們為了等待從瓶頸來的零件，只好在裝配部前面守候。也就是說，不管在哪一種狀況下，瓶頸都掌控了零件在工廠耗費的時間；換句話說，瓶頸控制了存貨和有效產出。 (p.362, p.406)

➒ 在非瓶頸設備省下的每個小時都是虛幻的。⋯⋯我們絕對不可以試圖把系統中的每一種資源都發揮到極致。追求局部效益的系統，絕對不是好的系統，而是非常沒有效率的系統。 (p.364, p.406)

(2016-11-19 補充) 應觀眾要求，我將遊戲內容去掉，釋出精簡版投影片，供大家參考。

瓶頸處理九原則 (精簡版)

後續延伸活動

(2017-02-08 補充) 於 Agile Meetup Taipei 發表兩小時加長版：【從限制理論看敏捷開發】。

(2017-03-06 補充) 已擴充為四小時的企業內訓版：【敏捷開發與團隊塑造】。意者內洽。

One-Week Sprint 的節奏

Wed, 26 Oct 2016 00:00:00 +0800

我曾在 iThome 的 2012 年度必看好書中，推薦 The Scrum Field Guide（當年還是第一版，現在則有第二版了）。當年看這本書時，還沒置身 Scrum 團隊的經驗，純粹是為了未來做準備，所以，對書中講的種種招數，只能默記在心，等待實務印證。

整本書非常精彩，但最讓我印象深刻的，就是駭人聽聞的 “one-week sprint" 論調：

From: The Scrum Field Guide

儘管當時不甚理解箇中用意，但我是好學生，一直把 “one-week sprint” 當成心嚮往之的標竿，日後也不時把所見所聞拿來對照思考。

日後在職涯接觸了更多流程思維：由 Toyota 引領風潮的 Lean Production 及 JIT、高德拉特的 TOC，都強調從 “flow” 來分析系統。浸潤日久，就比較能理解 “one-week sprint” 的緣由。這也滿符合大多數地球人的時間感：

你應該建立工作節奏，好讓每個人都容易掌握自己在一段時間內能夠完成多少事，而最後的成果通常會讓他們自己感到訝異。

— Quote: 《Scrum：用一半的時間做兩倍的事》

良善的立意，仍然要有充分的前提佈局及配套措施；不是嘴巴喊喊「我們要搞 one-week sprint」就真的能夠 one-week（天下哪有這麼簡單的事～～～）。

那麼，“one-week sprint” 能實現的前提是什麼？

從最近我第一次實踐 Scrum 的過程中，我發現，答案其實就在 The Scrum Field Guide 的那一頁。

Decomposition。

時機

先講講背景故事。

敝公司的大節奏是以季 (quarter) 為單位。十月份是 Q4 的開始，所以各產品、專案都於此刻開始提出本季的計畫。此為其一。

我所隸屬的某產品專案，十月中旬，有兩位新人報到並分配到此專案下，此為其二。

不巧的是，這產品專案，十一月一日，有一位工程師要請增產報國假，所以，要趁著十月份，將工作交接給那兩位新人，此為其三。

因此，單以十月份來說，在這種「1 位準備交接的舊人 + 2 新人」的高風險組合，要是我不儘早作出較周密的調度規劃，屆時一定慘兮兮。

以我本身較熟悉的 PMP 訓練、101 專案管理一日特訓班、102 流程設計與跨部門溝通、106 動態排程基礎等課程，都強調 WBS、work package、activity 的層次拆解，critical path 的辨識，以及 milestone 的設置。所以，我打算以自己較有把握的專案管理手法切入，先規劃為期 3 weeks 的 WBS + activities，並每隔一週設一個 milestone。

思之於此，突然靈機一動：這不正與 The Scrum Field Guide 的那一頁講的兩大要點「decomposition 與 one-week sprint」若合符節嗎？差別只在於，我原本是以專案管理圈慣用的 “deliverable” 字眼作為表述單位，而不是以敏捷圈慣用的 “user story” 字眼；但兩者在 task/activity 層次則是類似的，而且，我也的確將 task/activity 切得夠細了，細到符合 The Scrum Field Guide 的建議：

Follow the rule that tasks should be completed in no more than two days.

那麼，現在，我到底要用傳統的專案管理手法來執行這高風險任務，還是⋯⋯

進而一想：反正我本來就想找機會試行 Scrum 或 Kanban，那麼，擇日不如撞日，何不趁此機會，來一次個人的 Scrum (subset) 首航？

⋯⋯而且，就一口氣挑戰看看 one-week sprint 吧？

盤算

挑戰之前，還是要先秤秤自己以及團隊有幾兩重。

兩位新人是我面試的，一位是我研究所學弟，一位出自台灣某敏捷開發聖地的實驗室，對他們的背景及能力，有某種程度的信心。

至於我自己，要感謝稍早敏捷三叔公 David Ko 發起的這個活動，讓我蒐集到一些阻力清單：

有了這份清單，配上 Project Management in the First Lane: Applying the Theory of Constraints 第五章的 CRT 圖，有助於我設想些應對措施，才比較敢挑選戰場來試驗。

接下來，就隨時抱著開放心態，見招拆招嘍～～～

工具

我用兩份專案管理工具。

第一份是只給自己看的 Microsoft Project 文件，用來掌握全貌。或許是受到 PMP 訓練的影響，即使現在是跑 (a subset of) Scrum，又是首航，還是覺得要有這種東西，看到 3 個 sprints 的 WBS、work package、activities、critical path 才安心。

另一份是給團隊成員看的 Google Spreadsheet，主要是在 daily Scrum 時，用 Kanban 之類易懂的視覺化媒介，讓團隊全體一起溝通工作進展及阻礙。

調整實驗了幾天，還是覺得秀出我在 101 專案管理一日特訓班學到的 “JB Big Table” 給團隊成員看，不僅比正統的 Kanban 更容易有全局觀，尤其是層次及時間感，就連 Kanban 素來講究的 WIP 也都內建其中。

“JB Big Table” 真的很管用，儘管這次我也只有用上一小部分。

反思

一週後，第一個 sprint 順利達標，儘管變數層出不窮。

萬萬沒想到第一次嘗試帶 Scrum，而且是「1 舊人 + 2 新人」的高風險組合，就很有機會實現。除了天時地利人和的配合，事先認真的 WBS 分析，應是重要因素。

The Scrum Field Guide 說的是真的！

Your problem isn’t your sprint length. You need to improve your task decomposition.

也順便速記幾則初步的檢討反思：

理解精神真的很重要。理解了，才知道該如何遵守規則，或許更重要的是，知道為何及如何違反規則。
One-week sprint 對於「聚焦」的要求更高，真的更該集中鎖定在要徑上。
儘管只有 one-week sprint，但已經出現《關鍵鏈》點出的「資源爭奪」問題了。在第一個 sprint 中我沒有處理得很好，但在第二個 sprint 中，我採用 TOC 聚焦五步驟中的第二步 “exploit” 及第三步 “subordinate” 來處理。
身處專案導向的矩陣型組織，初步的觀察體會：
- 資源主管，如果有敏捷的正知見，滿適合當照顧小羊的 Scrum master。
- PO 的確不適合身兼 Scrum master，會有難以排解的利害衝突。
某個層次來說，選擇了 Scrum、選擇了 DevOps，甚至廣義一點來說，選擇了 lean、選擇了 TOC，就要有心理準備：這些流程或方法論，都有「持續改善」的機制在裡面，都要求你的 commitment。沒有這種心理準備，往往就是無法移除障礙的原因。
One-week sprint 固然痛快，但我在《為什麼上班這麼累？其實是你心累》看到一則警語：「因急迫性所產生的高效率，其實也是一種心理上的成癮。」所以，要注意何時該踩剎車。

許多議題，我也還沒有答案。但是，抱持開放心態，與團隊一同探索，應是一大樂事吧！

2022-10-31 補充

原理上，Scrum 並沒規定 sprint 週期是幾天。坊間多半認為，在還不知道團隊能量、產品複雜度、外部依賴性等情況下，以 2 weeks sprint 做為試行的起點，是滿中庸的選擇。

我自己則是：在自己有把握緊密參與的情況下，我會直接以 one week sprint 做為起點，但預期第一個 sprint review 會無法 100% done，以此曝露團隊該改進之處：規劃面、技術面、協作面⋯⋯。

當然啦，若某團隊真的要走 one-week sprint 路線，利害關係人也必須理解如此行的理由及限制：每個 sprint 交付物的 “increment” (增量)，真的就只是 one-week 能夠產出的合理規模——這需要教育。

【敏捷的工作分解方法】系列

❶ One-Week Sprint 的節奏