<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Backlog on Tarragon</title><link>https://tarrragon.github.io/blog/tags/backlog/</link><description>Recent content in Backlog on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Tue, 28 Jul 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/backlog/index.xml" rel="self" type="application/rss+xml"/><item><title>教學模組的 Backlog 段格式規範</title><link>https://tarrragon.github.io/blog/posts/backlog-format-spec/</link><pubDate>Tue, 28 Jul 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/posts/backlog-format-spec/</guid><description>&lt;h2 id="這篇要解決什麼">這篇要解決什麼&lt;/h2>
&lt;p>Backlog 段的責任是讓「這個模組還有什麼沒寫」在不讀完整份大綱的情況下就能被回答。教學模組寫到一定規模後，未完成的工作會散在大綱各處：vendor 覆蓋表的空欄、知識卡候選清單、推演階段表、跨模組的交接缺口。這些內容各自都有存在的理由，但它們共用一個讀者需求——有人（可能是幾個月後的自己）想知道「現在該接著做什麼」。&lt;/p>
&lt;p>實際發生過的情況是：backend 十二個模組各自發展出不同的 backlog 段名，&lt;code>大綱待辦&lt;/code>、&lt;code>觀念網路補完方向&lt;/code>、&lt;code>後續深化方向&lt;/code>、&lt;code>下一輪推演大綱&lt;/code>、&lt;code>後續推演大綱&lt;/code>、&lt;code>規劃方向&lt;/code>、&lt;code>後續擴充方向&lt;/code>、&lt;code>目前缺口與後續批次&lt;/code> 都出現過。每個名字在它自己的模組裡都說得通，合起來的後果是跨模組盤點必須逐檔閱讀、且無法確定有沒有漏掉某個段名。&lt;/p>
&lt;p>規範要解的是這個彙總問題，不是要把各模組的規劃思路壓成同一種。因此格式分兩層：可彙總的標準表在上，模組自己的敘事在下。&lt;/p>
&lt;h2 id="段落結構">段落結構&lt;/h2>
&lt;p>每個教學模組的 &lt;code>_index.md&lt;/code> 用 &lt;code>## Backlog&lt;/code> 作為段名，段內先放標準表，表下方保留該模組原有的規劃敘事作為 H3 子段。&lt;/p>





&lt;div class="highlight">&lt;pre tabindex="0" class="chroma">&lt;code class="language-markdown" data-lang="markdown">&lt;span class="line">&lt;span class="ln"> 1&lt;/span>&lt;span class="cl">&lt;span class="gu">## Backlog
&lt;/span>&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln"> 2&lt;/span>&lt;span class="cl">&lt;span class="gu">&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln"> 3&lt;/span>&lt;span class="cl">| 項目 | 類型 | 前置條件 | 規模 |
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln"> 4&lt;/span>&lt;span class="cl">| ---- | ---- | -------- | ---- |
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln"> 5&lt;/span>&lt;span class="cl">| 八個 T1 vendor 的 deep article（CircleCI / Gatling / JMeter / Locust / LitmusChaos / Gremlin / Toxiproxy / Nobl9） | vendor | 需與效能模組界定角度分工 | 8 篇（大） |
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln"> 6&lt;/span>&lt;span class="cl">| 判讀訊號表格補行動建議欄 | 主章 | 無 | 小 |
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln"> 7&lt;/span>&lt;span class="cl">
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln"> 8&lt;/span>&lt;span class="cl">&lt;span class="gu">### 下一輪推演大綱
&lt;/span>&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln"> 9&lt;/span>&lt;span class="cl">&lt;span class="gu">&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">10&lt;/span>&lt;span class="cl">（模組原有的階段表與敘事，不動）&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>段名固定的理由是它要能被 grep。&lt;code>rg -l &amp;quot;^## Backlog&amp;quot; content/*/*/_index.md&lt;/code> 要能列出全部有待辦的模組，少一個就代表該模組漏了這段，而不是「它可能叫別的名字」。&lt;/p>
&lt;p>段的位置放在模組完成狀態之後、跨分類引用之前。讀者的閱讀順序是先知道現況、再知道待辦、最後才需要往外跳。Tripwire、知識卡補強方向這類本來就不進 backlog 表的內容，可以留在 Backlog 段外作為 sibling H2。模組若還沒有完成狀態段與跨分類引用段，Backlog 放在文末即可。&lt;/p>
&lt;h2 id="標準表的四個欄位">標準表的四個欄位&lt;/h2>
&lt;p>四個欄位的共同判準是「彙總時需不需要」。四個欄位各自對應一個彙總視角：總量（還剩幾件事）、分布（缺口集中在哪一類產出物）、可啟動性（哪些現在就能開始）、成本量級（哪些要花大力氣）。&lt;/p>
&lt;h3 id="項目">項目&lt;/h3>
&lt;p>寫具體要產出什麼，不寫方向。「8 個 vendor 的 deep article（CircleCI / Gatling / JMeter / Locust / LitmusChaos / Gremlin / Toxiproxy / Nobl9）」是項目；「vendor 層需要深化」是方向。&lt;/p>
&lt;p>判準是讀完這一格能不能直接開檔開始寫。答案是否的時候，那句話屬於下方的敘事段而非標準表。方向本身有價值——它記錄了為什麼這些項目值得做——但它回答不了「現在該接著做什麼」。&lt;/p>
&lt;h3 id="類型">類型&lt;/h3>
&lt;p>從固定的五個值裡選，讓跨模組彙總能按類型分組：&lt;/p>
&lt;ul>
&lt;li>&lt;code>vendor&lt;/code>：vendor deep article、migration playbook、服務頁&lt;/li>
&lt;li>&lt;code>主章&lt;/code>：模組主章的新章節或既有章節的修訂&lt;/li>
&lt;li>&lt;code>知識卡&lt;/code>：新建卡片或既有卡片的補強&lt;/li>
&lt;li>&lt;code>案例&lt;/code>：案例庫的採集、深挖、反例補齊&lt;/li>
&lt;li>&lt;code>跨模組&lt;/code>：需要動到別的模組才能完成的項目&lt;/li>
&lt;/ul>
&lt;p>固定枚舉的代價是偶爾會有項目落在邊界上。判斷方式是看產出物落在哪個目錄：產出物進 &lt;code>vendors/&lt;/code> 就是 vendor，進 &lt;code>knowledge-cards/&lt;/code> 就是知識卡，進 &lt;code>cases/&lt;/code> 就是案例，落在模組根目錄的章節檔就是主章。同時牽涉兩個模組的，看主要工作量在哪一邊，另一邊在前置條件欄註明。&lt;/p>
&lt;h3 id="前置條件">前置條件&lt;/h3>
&lt;p>寫「還缺什麼才能開始」，沒有就寫 &lt;code>無&lt;/code>。&lt;/p>
&lt;p>這一欄決定了項目能不能被現在的自己接手。&lt;code>無&lt;/code> 代表素材與依賴都就位，隨時可以開工；有內容的則指出卡在哪裡——「需要先建 case 庫」「等 11.9 的路由落點確定」「需要實機環境驗證」。&lt;/p>
&lt;p>&lt;code>無&lt;/code> 是一個斷言，寫之前要實際確認過落點與素材——它讓該列成為盤點時最先被挑走的一列，而斷言錯了的挫敗發生在開工之後。有內容的則要寫成可觀察的事件（「等 11.9 的路由落點確定」「該形態的案例庫有第一則紀錄」），寫不成可觀察事件的含糊阻塞（「需要素材」「等時機」）永遠不會觸發。這也是候選與待辦的那把尺：寫不出可觀察的解除條件，多半代表它還是候選、該回到後續候選段。&lt;/p>
&lt;p>盤點時這一欄是排序的主依據。前置條件為 &lt;code>無&lt;/code> 且規模小的項目，是進度停滯時最容易重新啟動的入口。&lt;/p>
&lt;p>項目源自別處的路由落空時，這一欄要寫明是哪一篇指過來的。跨模組路由的目的地端沒有任何機制知道有哪些 inbound 路由押在自己身上，而那條路由的讀者正在等這一項——少了這個註記，這一項讀起來會像是模組自己想做的事，優先序因此被低估。這是既有欄位的用法界定，不新增第五欄。&lt;/p>
&lt;h3 id="規模">規模&lt;/h3>
&lt;p>可數的項目寫「數量（級距）」，例如 &lt;code>8 篇（大）&lt;/code>、&lt;code>4 張卡（中）&lt;/code>；不可數的只寫級距 &lt;code>小&lt;/code> / &lt;code>中&lt;/code> / &lt;code>大&lt;/code>。兩種寫法都帶級距，這一欄才能跨模組排序——只寫數量時 &lt;code>8 篇&lt;/code> 與 &lt;code>大&lt;/code> 無法比較。&lt;/p>
&lt;p>三級的分界用單次工作能否完成來判定：&lt;code>小&lt;/code> 是一次專注時段內能做完（補一段、加幾個連結、建一張卡）、&lt;code>中&lt;/code> 是需要跨幾次（一篇完整文章、一組卡片）、&lt;code>大&lt;/code> 是需要獨立規劃批次（一整批 vendor deep article、一個新的案例庫）。&lt;/p>
&lt;p>這一欄的用途是讓盤點結果能回答「這個模組的缺口是零碎的還是結構性的」。十個 &lt;code>小&lt;/code> 項目與一個 &lt;code>大&lt;/code> 項目的處置方式不同：前者適合順手清掉，後者要排期。&lt;/p>
&lt;p>寫 &lt;code>中&lt;/code> 的項目要能說出它為什麼跨不過一次專注時段、又為什麼不需要獨立排期。三級裡只有 &lt;code>中&lt;/code> 兩邊都不必舉證，它因此是最省力的值；整個模組的 backlog 全是 &lt;code>中&lt;/code> 時，排序與「零碎還是結構性」兩個用途同時失效，該重判一次。&lt;/p></description><content:encoded><![CDATA[<h2 id="這篇要解決什麼">這篇要解決什麼</h2>
<p>Backlog 段的責任是讓「這個模組還有什麼沒寫」在不讀完整份大綱的情況下就能被回答。教學模組寫到一定規模後，未完成的工作會散在大綱各處：vendor 覆蓋表的空欄、知識卡候選清單、推演階段表、跨模組的交接缺口。這些內容各自都有存在的理由，但它們共用一個讀者需求——有人（可能是幾個月後的自己）想知道「現在該接著做什麼」。</p>
<p>實際發生過的情況是：backend 十二個模組各自發展出不同的 backlog 段名，<code>大綱待辦</code>、<code>觀念網路補完方向</code>、<code>後續深化方向</code>、<code>下一輪推演大綱</code>、<code>後續推演大綱</code>、<code>規劃方向</code>、<code>後續擴充方向</code>、<code>目前缺口與後續批次</code> 都出現過。每個名字在它自己的模組裡都說得通，合起來的後果是跨模組盤點必須逐檔閱讀、且無法確定有沒有漏掉某個段名。</p>
<p>規範要解的是這個彙總問題，不是要把各模組的規劃思路壓成同一種。因此格式分兩層：可彙總的標準表在上，模組自己的敘事在下。</p>
<h2 id="段落結構">段落結構</h2>
<p>每個教學模組的 <code>_index.md</code> 用 <code>## Backlog</code> 作為段名，段內先放標準表，表下方保留該模組原有的規劃敘事作為 H3 子段。</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-markdown" data-lang="markdown"><span class="line"><span class="ln"> 1</span><span class="cl"><span class="gu">## Backlog
</span></span></span><span class="line"><span class="ln"> 2</span><span class="cl"><span class="gu"></span>
</span></span><span class="line"><span class="ln"> 3</span><span class="cl">| 項目 | 類型 | 前置條件 | 規模 |
</span></span><span class="line"><span class="ln"> 4</span><span class="cl">| ---- | ---- | -------- | ---- |
</span></span><span class="line"><span class="ln"> 5</span><span class="cl">| 八個 T1 vendor 的 deep article（CircleCI / Gatling / JMeter / Locust / LitmusChaos / Gremlin / Toxiproxy / Nobl9） | vendor | 需與效能模組界定角度分工 | 8 篇（大） |
</span></span><span class="line"><span class="ln"> 6</span><span class="cl">| 判讀訊號表格補行動建議欄 | 主章 | 無 | 小 |
</span></span><span class="line"><span class="ln"> 7</span><span class="cl">
</span></span><span class="line"><span class="ln"> 8</span><span class="cl"><span class="gu">### 下一輪推演大綱
</span></span></span><span class="line"><span class="ln"> 9</span><span class="cl"><span class="gu"></span>
</span></span><span class="line"><span class="ln">10</span><span class="cl">（模組原有的階段表與敘事，不動）</span></span></code></pre></div><p>段名固定的理由是它要能被 grep。<code>rg -l &quot;^## Backlog&quot; content/*/*/_index.md</code> 要能列出全部有待辦的模組，少一個就代表該模組漏了這段，而不是「它可能叫別的名字」。</p>
<p>段的位置放在模組完成狀態之後、跨分類引用之前。讀者的閱讀順序是先知道現況、再知道待辦、最後才需要往外跳。Tripwire、知識卡補強方向這類本來就不進 backlog 表的內容，可以留在 Backlog 段外作為 sibling H2。模組若還沒有完成狀態段與跨分類引用段，Backlog 放在文末即可。</p>
<h2 id="標準表的四個欄位">標準表的四個欄位</h2>
<p>四個欄位的共同判準是「彙總時需不需要」。四個欄位各自對應一個彙總視角：總量（還剩幾件事）、分布（缺口集中在哪一類產出物）、可啟動性（哪些現在就能開始）、成本量級（哪些要花大力氣）。</p>
<h3 id="項目">項目</h3>
<p>寫具體要產出什麼，不寫方向。「8 個 vendor 的 deep article（CircleCI / Gatling / JMeter / Locust / LitmusChaos / Gremlin / Toxiproxy / Nobl9）」是項目；「vendor 層需要深化」是方向。</p>
<p>判準是讀完這一格能不能直接開檔開始寫。答案是否的時候，那句話屬於下方的敘事段而非標準表。方向本身有價值——它記錄了為什麼這些項目值得做——但它回答不了「現在該接著做什麼」。</p>
<h3 id="類型">類型</h3>
<p>從固定的五個值裡選，讓跨模組彙總能按類型分組：</p>
<ul>
<li><code>vendor</code>：vendor deep article、migration playbook、服務頁</li>
<li><code>主章</code>：模組主章的新章節或既有章節的修訂</li>
<li><code>知識卡</code>：新建卡片或既有卡片的補強</li>
<li><code>案例</code>：案例庫的採集、深挖、反例補齊</li>
<li><code>跨模組</code>：需要動到別的模組才能完成的項目</li>
</ul>
<p>固定枚舉的代價是偶爾會有項目落在邊界上。判斷方式是看產出物落在哪個目錄：產出物進 <code>vendors/</code> 就是 vendor，進 <code>knowledge-cards/</code> 就是知識卡，進 <code>cases/</code> 就是案例，落在模組根目錄的章節檔就是主章。同時牽涉兩個模組的，看主要工作量在哪一邊，另一邊在前置條件欄註明。</p>
<h3 id="前置條件">前置條件</h3>
<p>寫「還缺什麼才能開始」，沒有就寫 <code>無</code>。</p>
<p>這一欄決定了項目能不能被現在的自己接手。<code>無</code> 代表素材與依賴都就位，隨時可以開工；有內容的則指出卡在哪裡——「需要先建 case 庫」「等 11.9 的路由落點確定」「需要實機環境驗證」。</p>
<p><code>無</code> 是一個斷言，寫之前要實際確認過落點與素材——它讓該列成為盤點時最先被挑走的一列，而斷言錯了的挫敗發生在開工之後。有內容的則要寫成可觀察的事件（「等 11.9 的路由落點確定」「該形態的案例庫有第一則紀錄」），寫不成可觀察事件的含糊阻塞（「需要素材」「等時機」）永遠不會觸發。這也是候選與待辦的那把尺：寫不出可觀察的解除條件，多半代表它還是候選、該回到後續候選段。</p>
<p>盤點時這一欄是排序的主依據。前置條件為 <code>無</code> 且規模小的項目，是進度停滯時最容易重新啟動的入口。</p>
<p>項目源自別處的路由落空時，這一欄要寫明是哪一篇指過來的。跨模組路由的目的地端沒有任何機制知道有哪些 inbound 路由押在自己身上，而那條路由的讀者正在等這一項——少了這個註記，這一項讀起來會像是模組自己想做的事，優先序因此被低估。這是既有欄位的用法界定，不新增第五欄。</p>
<h3 id="規模">規模</h3>
<p>可數的項目寫「數量（級距）」，例如 <code>8 篇（大）</code>、<code>4 張卡（中）</code>；不可數的只寫級距 <code>小</code> / <code>中</code> / <code>大</code>。兩種寫法都帶級距，這一欄才能跨模組排序——只寫數量時 <code>8 篇</code> 與 <code>大</code> 無法比較。</p>
<p>三級的分界用單次工作能否完成來判定：<code>小</code> 是一次專注時段內能做完（補一段、加幾個連結、建一張卡）、<code>中</code> 是需要跨幾次（一篇完整文章、一組卡片）、<code>大</code> 是需要獨立規劃批次（一整批 vendor deep article、一個新的案例庫）。</p>
<p>這一欄的用途是讓盤點結果能回答「這個模組的缺口是零碎的還是結構性的」。十個 <code>小</code> 項目與一個 <code>大</code> 項目的處置方式不同：前者適合順手清掉，後者要排期。</p>
<p>寫 <code>中</code> 的項目要能說出它為什麼跨不過一次專注時段、又為什麼不需要獨立排期。三級裡只有 <code>中</code> 兩邊都不必舉證，它因此是最省力的值；整個模組的 backlog 全是 <code>中</code> 時，排序與「零碎還是結構性」兩個用途同時失效，該重判一次。</p>
<p>改動任何一欄的格式時，同一批要把既有實例掃過一遍。規範文章改完就結案的話，範例列與它抄來的那個模組會從此不一致——立規範與掃存量是兩件事，前者不會自動完成後者。</p>
<h2 id="哪些內容不進-backlog">哪些內容不進 Backlog</h2>
<p>Backlog 記錄的是<strong>已經決定要做、只是還沒做</strong>的工作。以下三類內容經常被誤放進來：</p>
<p><strong>候選與評估中的想法</strong>留在原本的「後續候選」段。候選的語意是「將來可能做」，它與 backlog 的差別在有沒有做過取捨。把候選寫進 backlog 會讓項數失去意義——盤點時看到二十項，其中十二項其實還沒決定要不要做。</p>
<p><strong>Tripwire 與判讀條件</strong>留在各自的段落。它們是「什麼情況下要重新評估」，觸發前不構成待辦。</p>
<p><strong>已完成項目</strong>直接刪除，不留刪除線或「已完成」標記。完成紀錄的住址是 git history 與模組完成狀態段。Backlog 表要維持「表裡的每一列都是待辦」這個不變條件，否則讀者每次都要先過濾一遍。</p>
<p>這條約束及於整個 <code>## Backlog</code> 段，不只表格。完成清單放在表下方的 H3 子段時，讀者仍然要先過濾才知道哪些是待辦，而過濾正是段落結構要替他省掉的動作。同樣地，內容為空的待辦子段（只有一句「這一節記錄……」而下面沒有項目）該刪除——空段讀起來像「這裡還沒盤點」，跟「這裡沒有待辦」是兩個不同的訊息。</p>
<h2 id="總覽的維護規則">總覽的維護規則</h2>
<p><code>content/backend/_index.md</code> 的總覽段只放索引，不複製各模組的 backlog 內容。</p>
<p>索引的每一列是「模組名（含連結）／項數／主要缺口一句」三欄，細節一律點回各模組。這條規則的理由是 SSoT：各模組的 <code>_index.md</code> 是自己 backlog 的唯一真實來源，總覽複製內容就會產生兩份、而更新時只改一份的機率遠高於兩份都改。</p>
<p>索引仍然會過時——項數會變、主要缺口會換。但過時的代價不同：索引過時的後果是數字不準，讀者點進去就會看到正確的；複製內容過時的後果是讀者拿到錯誤的清單，且沒有訊號提示他該去對照。</p>
<p><strong>禁止複製的範圍不限於總覽這個方向。</strong> 同一份清單在模組自己的 <code>_index.md</code> 裡出現兩次（標準表一次、下方的推進紀錄敘事再列一次）產生的是同一個機制，而且更容易發生——兩份內容在同一個檔案裡，寫的時候看起來像是在補充說明，不像在複製。判準是：任何一處把 backlog 的項目重新列出來，就要問「這些項目改了之後，誰會記得回來改這裡」。答案是「沒有人」時，改成指回標準表。</p>
<p>新增教學模組時要同步在總覽補一列。這與新增頂層 <code>content/&lt;module&gt;/</code> 要更新 <code>content/_index.md</code> 是同一類的登記責任。</p>
<h2 id="與寫作原則的關係">與寫作原則的關係</h2>
<p>這份格式規範看起來牴觸「情境優先於模板」（AGENTS.md 原則八），實際上它劃在原則的邊界外側。分界畫在<strong>讀者拿它做什麼</strong>這條軸上，內容的類別（教學／維運）只是它的粗略代理：要理解單一情境為什麼成立時，把不同情境套進同一組欄位會讓判讀條件消失；要在多個項目之間比較與排序時，欄位一致正是比較能成立的前提。</p>
<p>用內容類別當標籤會失準，因為同一份文件的不同段落可以落在軸的兩端——模組 <code>_index.md</code> 的章節說明是教學、Backlog 段是跨項比較，兩者共存於同一個檔案。判斷某一段該不該欄位化，問它服務的是哪一種閱讀動作，而不是問它屬於哪一類文件。</p>
<p>這也是為什麼標準表停在四欄：欄位的准入條件是「彙總會用到」而非數量上限——想加第五欄時先問它對應哪個彙總問題，對應不出來就該留在下方的敘事段。</p>
<p>模組自己的敘事段保留在標準表下方，正是為了守住這條界線。推演階段的順序依賴、觀念網路的補完理由、vendor 覆蓋的設計決策，這些內容繼續用各模組自己的語言寫，不受四欄約束。</p>
]]></content:encoded></item></channel></rss>