故事點數使用什麼

① 用戶故事與敏捷方法之三-----什麼時候使用用戶故事

上兩篇闡釋了Why：為什麼使用戶故事，而不是詳盡的文檔？

What、How、Who：什麼是用戶故事，怎麼寫，誰來寫，誰使用？

這一篇闡釋When，在Scrum流程的各個環節如何使用用戶故事：

終於來到敏捷的流程上。

用戶故事幾乎是貫穿於整個敏捷開發流程。在每個環節都有其重要做用。任何一個環節如果沒有很好的執行和使用，就難以發揮用戶故事的作用，造成團隊轉而對詳盡的文檔的再度依賴。

用Scrum為例子，Scrum的5大活動：

-- Sprint計劃會議（Sprint Planning Meeting）

-- 每日站會（Daily Scrum Meeting）

-- Sprint評審會議（Sprint Review Meeting）

-- Sprint回顧會議（Sprint Retrospective Meeting）

-- 產品Backlog梳理會議（ Proct Backlog Refinement）

要用好用戶故事，需要進行如下活動：

1、用戶故事估算

2、優先順序排序

3、用戶故事拆分

4、任務拆分和估算（與用戶故事估算區分）

5、發布計劃

6、迭代計劃

7、測量和監控速率

Why為什麼要進行用戶故事估算？

作用一：客戶團隊參考用於排優先順序。比如：一個業務價值高的故事估算出來要4周完成，1個或者多個業務價值中等的用戶故事只需要1天就可以完成。客戶團隊可能會將業務價值中等的這個故事排出更高的優先順序，先做。

作用二：為後續的發布計劃提供必要的數據參考，以便得出發布周期和范圍，允許±2個迭代的誤差。

作用三：（附加作用）此過程讓團隊充分溝通，客戶團隊和開發團隊達成共識，需求的討論存在於大家共同的腦海里。

What什麼是用戶故事估算？

粗粒度的用戶故事，還沒有排入迭代的產品特性或者已拆分的獨立故事。團隊共同預估和猜測這個用戶故事的大小，以粗略估計其工作量。

How如何進行用戶故事估算？

撲克牌

經驗（猜測）、理想周、小於一個理想周的工作量用斐波那契數列計算（1、2、3、5、8、13、21、34、55、89）以團隊7人為例。

Who誰來進行用戶故事估算？

理論上是團隊共同決定，開發人員參加的越多越好。現實中，團隊重要人員參與，根據實際情況。

1、客戶團隊：不能主動對估點發表意見，不參與估點。只能盡其所能的回答開發團隊的問題（不知道答案，先猜猜看）。

2、開發團隊：盡可能多的問問題。通過撲克牌進行估點，經過幾輪（一般不超過3論）討論，最終達成一致。

When什麼時候進行用戶故事估算，多久一次？

產品Backlog梳理會議。根據發布頻率決定，比如三個月一次發布，每三個月進行一次用戶故事估算。舉例，如果三個月一次發布，每次發布之間留一個星期進行產品Backlog梳理，這個期間是最好的進行下一次發布用戶故事估算的時間。

失敗因素：

1、客戶團隊和開發團隊關系不融洽。

2、客戶團隊和開發團隊任何一方都太過於強勢，無法平等溝通。

3、存在不平等的關系，造成並非每個人都參與其中，存在一部分人只是看重要人物的決定而跟風。

Why為什麼要進行拆分和估算？

1、拆分便於多人共同協作於一個用戶故事。

2、估算便於合理安排一個迭代可完成的任務量。

What什麼是任務拆分和估算？

按照優先順序排列，准備放入當前迭代的用戶故事，進行任務拆分，便於團隊共同協作於一個用戶故事。並由任務完成者對這個任務進行工作量的預估。

How如何進行任務拆分和估算？

拆分可以根據開發團隊的特定技術專長來進行。比如：一個用戶故事需要後端開發，前端開發，測試，就可以拆分為三個任務卡。

拆分可以根據任務的邏輯流程的先後順序來進行。比如：一個用戶故事需要先新增一條數據，然後對數據進行讀取、計算並修改數據，最後刪除數據，可以拆分為三個任務卡。

用理想天的方式進行估算。

Who誰來進行任務拆分和估算？

團隊一起決定用何種方式拆分，由任務完成者主力進行該任務的估算。

When什麼時候進行任務拆分和估算？

迭代計劃會議的時候

失敗因素：

過於糾纏於細節

Why為什麼要進行優先順序排序？

為了計劃一個發布，PO和客戶團隊必須排列一個故事的優先順序。

What什麼是優先順序排序？

每個用戶故事都是獨立的可測試的完整可發布使用的功能。PO按照優先順序排列，確認哪些先做和後做。團隊按照優先順序從高到低在承諾時間內優先完成優先順序高的任務。

基本優先順序排序：

-- 高優先順序 High

-- 中優先順序 Mediem

-- 低優先順序 Low

為了避免無休止的對優先順序的爭論，可以使用DSDM方法

-- 必須有（High）

-- 應該有（High）

-- 可以有（Mediem）

-- 這次不會有（Low）

為了避免並列存在並列高優先順序無法取捨，可以使用序列法

-- 1、2、3、4、5

How如何進行優先順序排序？

優先順序排序分風險驅動和價值驅動。

敏捷模式下，是價值驅動高於風險驅動。先做高價值的用戶故事，風險也許會隨著時間推移而消失。但是如果隨著時間推移，風險並未消失，甚至有增無減，仍然要考慮先處理風險高的任務。

優先順序排序要考慮的因素，包括但不限於以下幾種：

-- 用戶故事的價值

-- 用戶故事的規模

-- 用戶故事的風險

Who誰來進行優先順序排序？

PO和客戶團隊，也可以參考開發團隊的意見

When什麼時候進行優先順序排序？

任何時候，已經進入迭代並開始沖刺的用戶故事除外。

取決於團隊的靈活機動性，靈活性高的話，計劃會議時候是最好的優先順序排序和調整的時機。

How如何計算團隊速率？

初始速率：第一個迭代的速率估計，歷史經驗、猜測

例子：6人團隊，2周一個迭代10天，團隊的理想天是6*10=60天，這僅僅是理想天，因此要根據情況減半，或者1/3。由此算出的第一個迭代的初始速率為20或者30。

團隊速率：通過6個月的持續反饋和改進，團隊的速率接近一個穩定的值，這個值就是團隊的速率。

Who誰來計算團隊速率？

SM

When什麼時候計算團隊速率？

一個迭代完成，或者開始。

Why為什麼要制定發布計劃？

即便敏捷開發是不斷順應市場變化而變化的，仍然是需要一個預期和發布時間預估，只是無法精準到天，允許±2個迭代的誤差。（傳統瀑布流的開發模式也無法精確到天，事實上傳統模式下的開發總會比計劃的發布日期拖延幾個月到半年交付）

What什麼是發布計劃？

根據產品路線圖，規劃發布。以做出一個合理的預測，完成符合用戶期望的發布需要多少輪迭代。

發布計劃需要包含以下要素：

1、粗粒度故事，不包含很多細節。

2、對這些故事的用戶故事估點，和優先順序排序。

3、選擇一個固定的迭代長度。（1周、2周、4周，長度越長風險越大，因為反饋周期變長，反思和修正的機會變少）

4、團隊的速率

How如何將用戶故事估算轉換為開發速率和發布時間預估？

用理想周進行估算的例子：

通過SM、PO、客戶團隊達成一致，本次發布計劃預計包括用戶故事： A、B、C、D、E

A用戶故事的估算是一個理想周（5天），團隊總共7人。總共任務點數=5天*7人=35點。

B用戶故事的估算是兩個理想周（10天），團隊總共7人。總共任務點數=10*7=70點。

C用戶故事估算是斐波那契數列8點

D用戶故事估算是4個理想周（20天），團隊總共7人。總共任務點數=20*7=140點。

E用戶故事估算是斐波那契數列21點

總計 故事點數為 35+70+8+140+21=274

若團隊速率為62，則開發時間為274/62=4.4個迭代±2個迭代。

因此可以估計發布時間點為6~7個迭代後。團隊經過6~7個迭代可以發布A、B、C、D、E五個用戶故事所構成的交付產品。

Who誰來制定發布計劃

團隊

When什麼時候制定發布計劃

按照發布周期，2~6個月，發布完成後，休整一個星期。這個星期進行backlog梳理，需求澄清會，發布計劃會，等等。

Why為什麼要做迭代計劃？

對粗粒度的用戶故事進行更加細致的討論，但仍然避免過於糾纏於細節。目的是確定團隊這個迭代做什麼，排列優先順序，並從高優先順序的用戶故事開始選取。

What什麼是迭代計劃？

每個迭代開始的第一天，團隊共同討論做什麼，如何做，誰來做。

How如何進行迭代計劃？

-- 優先順序排序

-- 任務拆分

-- 任務估點

Who誰來做迭代計劃?

團隊

When什麼時候做迭代計劃？

每個迭代開始的第一天

讀書筆記用戶故事與敏捷方法----流程篇就更新到這里，後續繼續更新用戶故事與敏捷方法-----產品篇。

謝謝！

歡迎添加QQ討論：26988505

② 極簡敏捷：故事點，理想人天，故事個數

針對這些問題，很多實踐了多年的敏捷教練也不一定能夠回答的清楚。敏捷落地的過程中經常會有人對點數估算覺得困惑和難以理解，所以就更不容易執行到位了。

有人說故事點是規模，也有人說是工作量，還有人說是復雜度，還有人說其實就是理想人天（不是某一個人的人天，段野穗而是大家達成相對一致的抽象的人天）。

哪個才是最准確的？

甚至有些教練開始拋棄「晦澀難懂」的故事點，而直接採用理想人天（有些團隊實際落地會採用），或者不進行估算而直接採用數故事個數的方式（DevOps中經常採用此方式）。

來看看敏捷大師們是如何定義的？

Mike Cohn：故事點是一個度量單位，用於表示完成一個產品待辦項或者其他任何某項工作所需的所有工作量的估算結果。

Robert C.Martin：故事點是工作量的單位，被估算的不是時間，而是工作量。

讓我們來給故事點做個通俗的解釋：

故事點就是  工作量或規模 +復雜度因素+風險因素+不確定性因素，採用相對估演算法估算出來的一個抽象的綜合估值（數字）。

是不是依然感覺晦澀難懂，頭有點暈？

讓我們換一種表達形式：

這就是說我們在做點數估算的時候，首先要對比基準點的故事，進行相對故事工作量/規模大小的估算，然後要額外考慮故事的復雜度因素，風險因素，不確定性因素，並且為這些因素額外加上對應的點數，這樣估算出來的點數就更加具有參考價值，也具備了相對准確性（注意：不是絕對准確，也不應該追求絕對准確）。

注意：

1.一個點不代表任何時間長短，所以敏捷團隊只有通過迭代實際交付衡量驗證，才能知道團隊實際產能，才能將速率（一個迭代Sprint交付的點數總和）和排期計握卜劃結合起來做規劃。

2.團隊每個迭代產出的故事點大小，只能團隊和自己比較，速率的變化。

3.故事點數衡量的是團隊，而非個人。並且不能用於績效考核，以免產生負面效果，數據失真。

通常採用 斐波那契數列，有時根據具體情況也可以採用自然數來替代（具體要看故事之間的差別，思考怎樣的數字間隔差異更加適合團隊具體的情況）。

使用斐波那契數列有著源自自然的優勢，斐波那契數列又稱為黃金分割數列，大自然的奧秘蘊含其中，隨著數字間距的擴大，對於顆粒度較大的需求更加便於我們判斷選擇哪個數字，隱晦和模糊的數字有其美妙之處 -- 「大數定律」，當數量變大時，模糊性就消失了！

通常採用: 敏捷撲克估演算法

基本過程：

1）選擇一個基準故事，點數設為1（團隊達成共識，並且之後所有迭代以此故事為基準故事）

2）PO依次介紹故事背景，內容，驗收標准 等信息

3）團隊成員對故事做各自的點數估算，同時出牌（常用 斐波那契數列：1，2，3，5，8，提供8倍的估算范圍）

4）團隊成員對牌面數字偏差較大的進行解釋估算理由（較大，較小 都要簡單闡述理由）

5）然後重新進行第二脊攜輪估算（一般情況下，考慮到估算成本和效率，每個故事2輪估算即可，必要時可以進行多輪）

6）直到團隊成員達成基本一致（不是絕對一致，最終結果簡單協商確定即可）

這樣做的好處是估算過程，團隊可以充分討論和溝通，信息得到充分快速的交流，並且避免一言堂或信息披露不足。

這樣的方式可以加快風險，障礙，依賴的提前發現，並促進了團隊信息交流和達成一致，團隊內部信息披露也更加充分。

這里要注意的核心點是：敏捷估算是 相對估算，所有故事的點數大小，均參考基準故事來進行相對比較。

下面我們來聊聊這些方法到底有哪些區別，以及分別在什麼場景下進行選擇，才是最適合我們的方式。

場景：

經典的敏捷團隊，團隊氛圍友好，跨職能自組織團隊。促進團隊交流，發揮團隊的力量。

優點：

1.通過估算游戲，團隊成員對每一個故事進行了充分溝通和討論，分享了彼此掌握的知識和信息點，提前發現了部分風險和障礙，加強了對故事的認知和理解，達成全方位的需求共識。

2.通過估算游戲，獲得了一個團隊共同認可的相對准確的數據衡量。

3.所有迭代的基準點對齊後，可以對迭代計劃和團隊迭代交付速率有了數字量化的依據和衡量。（一個點不代表任何時間長短，所以敏捷團隊只有通過迭代實際交付衡量驗證，才能知道團隊實際產能，才能將速率和排期計劃結合起來）

缺點：

1.估算過程需要花費一點時間，但實際執行過程可以有簡化提效的空間，抓住核心點是溝通達成理解一致。

2.點數估算比較抽象，新的團隊不容易掌握和理解概念。

場景：

涉及人力成本統計或者人員安排和排期預算等情況下。

優點：

比較好理解和安排計劃，理想人天是對人天估算進行了人員抽象，也可以採用敏捷撲克估演算法。

缺點：

執行起來，估算者容易和自己的實際工作情況聯系，干擾到估算結果。

估算結果很容易被拿來做績效考核，或者和個人產出掛鉤，導致對團隊產生負面影響（敏捷團隊考核團隊而非個人）

場景：

在DevOps的需求流交付模式下，通常會採用此方法，大量需求，需求顆粒度相對均勻，團隊較為成熟，並且企業更加關注宏觀需求數量（通常作為一段時期的吞吐量數據被採集使用）。

優點：

快速簡單易用，直接數個數，便於統計，省去了估算的成本。

缺點：

1.需求顆粒度不均勻的情況下，導致偏差較大，數據的可信度較低。

2.需要配合嚴格的需求拆分標准執行，例如規定較為嚴格的需求顆粒度上限，並且需要立即執行到位，對於大顆粒度的需求缺少過度過程（敏捷需求是漸進明細，允許大顆粒度需求的存在，點數可以有更大的用處），對於較為成熟的團隊比較合適，新團隊需要適應。

3.增加了較大的前期需求拆分成本，團隊缺少執行的過度時間。

如果你的團隊想了解經典的敏捷實踐，並且前期需求顆粒度大小不夠均勻，需求經常需要討論，請選擇故事點數。

如果你們的需求拆分的很到位，顆粒度比較均勻，可以選擇不進行估算，直接數個數。

如果你需要盡快做出計劃和預算，或者外包項目需要提前上報人日成本，可以選擇理想人日。

當理解了以上概念的深層次含義，你也可以根據實際需要將三種方式進行部分結合，靈活運用。

作為一名敏捷教練和工程效率專家，在經過了多年以上三種實際實踐後，我個人最喜歡的方式還是 敏捷點數估算。

需要思考的是，在保持敏捷故事點數原滋原味的優點基礎上，將點數估算的落地成本降低，並且基準點做必要的對齊和選擇，這樣你就可以靈活運用點數獲得你想要的效果。

那麼你會如何選擇呢？

③ 敏捷估算中的故事點和工期

經常聽到有人對於敏捷故事點估算有些糾接，不太清楚故事點估算的意義何在，通過實踐和學習後略有心得，所以隨筆記下順便梳理思路。

在談估算之前，我們先看看工期估算是怎麼會事。
在軟體開發過程中，工期可以理解為完成所需功能需要的時間，是個絕對值，通常以人天度量。但有兩個問題工期無法避免：

再來說說故事點，故事點是什麼？

要做的功能有多大，是個相對值，以點數度量。英文表示故事大小是並陵世用到了 Size/Scale/effort 之汪腔類的詞，我不確定中文到底用什麼詞合適，所以借用學到的詞「體量」。或者我們通俗點說這是個啥任務，是包餛飩，包餃子，包包子還是烙大餅？另外，不管誰來做這個功能，它就是這么大，不增不減。它的復雜度是一樣的，它的風險是一樣的，它的不確定性是一樣，要完成這個功能開發不論是誰都要完成這么多工作任務。

故事點不等於工作量，也不等於復雜度，更不等於風險和不確定性，它是一個綜合估值，即，故事點估值等於工作量，復雜度因素，風險因素和不確定因素的綜合估值。故事點估算是相對概念，所以它能夠讓不同能力的人，就同一任務的估算達成一致。比如說，做一個登錄功能，程序員 A 的用 2 兩天完成；程序 B 的用 3 天完成，但這並不影響程序 A 和 B 將登錄頁面的具體任務拆分並統一評估為 2 點作為基準。那麼如果注銷功能程序員 A 用時 1 天完成，程序員 B 用時 2 天完成，這也同樣不影響兩位程序員都認為 注銷功能的規模只有登錄功能的一半大小，對應的故事點可以是 1 點。所以說故事點的估算可以做到相對穩定和一致。這樣一種相對估算一致性在團隊中形成，才可以有效的進行團隊估算，並過而演化為團隊產能。就像是下面兩瓶水，我們可能不太確定定兩瓶水各有多少，但是我們可以通過相對估算得出，大瓶的容量可能是小瓶容量的 2 倍，那麼如果以小瓶為參照，我們就可以說大瓶的容量等於兩個小瓶容量，這個 2 倍的小瓶容量就是大瓶容量的一個相對估值。

需要注意的是估算的准確性僅限於當前團隊。換句話說，一個用戶故事的點數僅是基於當前產品其它功能的一個相對大小估算，是當前團隊的一個統一估算，僅對當前團隊具有參考價值。如果非要在不同團隊之間以用戶故事點為單位進行統一話，就需要所有團隊對估算有一個統一的參考值和統一的估算方法，以確保不同團隊的估算不會有太大偏差，但比較難。我們需要單獨成篇來分析研究。

為什麼要引入故事點來做評估呢

第一，明確團隊速率（產能）
工期估算是無法提供產能信息的，我們常到說，某些單位的產能是月產出多少多少，但軟體開發的產能卻不能說月產能多少多少人天，也沒有辦法說月開發多少多少功能。因為第一人天是投入不是產出；第二功能有大有小，有簡單有復雜不能做位統一的度量單位。所以說度量產能是人天無法做到的，也是功能數無法實現的，除非所有功能大小一致絕肢。

當然以故事點來度量產能也只是相對准確。至於如何是稍後說明。

第二，實現團隊估算
團隊估算有助於團隊成員參與需求分析，培養參與感。再則團隊估算會刺激團隊基於不同角色來剖析產品需求，提前暴露不確定性，避免需求盲點。最重要的是大家在產能方面形成了一個參考基準，一旦團隊通過迭代捕捉到了產能，也就可以以產能為切入點，與產品干係人就團隊交付效率達成共識，從而避免拍腦袋給日期，又給不準的尷尬局面。
用戶對於交付日期的苛刻要求通常源自於對開發團隊產能不了解，對於最終交付結果的不確定。

第三，通過穩定的產能，及迭代交付 PSP（潛在可發布產品）增量，可以消除用戶顧慮，讓用戶在不斷地交付體驗中獲得安全感，並能通過提前反饋，優化改進降低產品失敗的可能性。舉個例子，一個功能，如果我們直接用人天來衡量交付的話，用戶第一印象會，這個功能要用 10 天來完成，好久啊；但是如果有故事點來衡量交付的話，用戶則會馬上意識到，哦，這個功能不小啊，有 10 個故事點。10 天更多體現的是投入，而 10個點則更多體現的是大小，價值。

那麼工期估算和故事點估算有什麼關系呢？

工期估算和故事點估算其實應該完全分開，其估算的根本目的不同。故事點估算主要為了明確要交付些什麼，即不管是團隊中什麼人來做，什麼時間來做，要交付的故事是什麼樣，體量有多大，所以故事點的估算要相對穩定。

故事點估算通要在迭代計劃前完成，即迭代開工前，就要明白告訴團隊和用戶，每個用戶故事規模大概是什麼樣。工期通常在迭代計劃時確定，旨在告訴團隊，基於現在的團隊現狀，我們可以承諾在迭代內完成多少交付。團隊現狀包括人員配比，成員知識能力，時間要求，工作依賴等。

工期是團隊基於本身能力所做出的一種估算，建立在承諾及勇氣的基礎上。是由團主動做出的估算，所以會更樂於且勇於兌現。這是相較於傳統人天估算的一大進步。人天估算由於非團隊集體估算，也不是基於團隊現狀做出的估算，通常會造成團隊由於害怕無法按期交付，拚命加緩沖時間，而用戶卻又堅決不妥協的局面。

分析到這里，我們應該清楚了，故事點估算和工期估算的目的是不同的，方法也是不同的。

④ 故事概念與故事點

故事點這個概念大家都聽說，也都在用，但是對於怎麼估點，大家都是一頭霧水。我試著來辨析一下。
故事點用來評估故事的工作量規模，工作規模希望用一個量化指標來定義，便於統計。
而要做到真正的量化是很難得，主要的困難在於個體能力的差異造成對於工作量的感知是不一樣的。通常我們說工作量第一反應是需要投入的工作時間，如果採用工作時間來代表工作量，就會直接進入上述的坑，因為工作時長是一個主觀量。
我們只有承認任何一項工作都有一個客觀的難度和工作量，那麼評估才是有意義的。既然工作時長不夠客觀，那麼還有什麼其他的標准？
我認為，可以引用政經中馬克思提出的概念：價值是凝結在商品中的一般人類勞動。
對應到故事工作量評估，我們可以說：
1）每個故事都有特定的價值，也對應著一定的勞動量；
2）同時，避免杠，我們把參與人和執行人都限定在一般人類，所謂一般人類，也就是我們現有項目的團隊人員水平（大家都是憑力氣吃飯，你懂的）。
翻譯一下，也就是說每個故事對應的工作都有其固有的難度（這個難度限定在當前系統、當前架構和當前業務復雜度下），一種難度對應一定的工作量，也就是說我們評估的是完成這個故事的工作難度。

另外，我們必須面對現實，我們認為完成一個工作，一個五年的老手和一個剛入職的新員工所花費漏茄的力氣（時間）是不一樣的，因為我們承認這兩類人的時間價值是不一樣的，但是當他們把整個工作完成後，我們認為投入勞動的價值是一樣的。

實踐中通常建議以故事點來代表工作量，而點數的含義團隊可以自己定義。這個闡述又把皮球踢回給團隊了，很多團隊對點數的定義表示悲觀，又在工作時間這個上面進行徘徊。
這里我建議採用《敏捷革命》第六章關於故事點數的實踐：
1、採用斐波那契數列進行點數評估
「在斐波那契數列中，不通的數字之間的差異足夠大，因此，我們能輕易地分辨出一個數字與另一個個數字的差異。如果一個人評估某個事項的難度相當於5，另一個事項的難度相當於8，那麼我們就會本能地覺察出其中的差異。但5和6之間的差異呢？就相察搜旁當微妙了，我們的大腦其實並不能區別出來」
2、允許定性存在，不必追求絕對准確
3、故事點數是團隊共同評估的結果
能力差異是造成對工作規模直觀感受差異的主要原因，所以我們在實踐中要規避這個因素。我敗橡們假設在一個團隊內部除了新員工以外每個人都是某一或者某幾個領域的專家，對於某個領域有若干個專家，各領域之間也會有一定程度的交流，其餘的人可以被認為是潛在的專家，那麼我們可以主要參考專家的意見，團隊其餘人員的意見為輔。假如評估故事點在計劃會上進行，那麼可以採用每個人打分的方式，進行計算。那麼計算發放就很多了，比如取平均值，比如剔除最大值最小值，比如取中位數。
我推薦：權重法計算，領域專家的權重占總共一半，其他人平均獲取權重

⑤ 什麼是「故事點 」「故事線」

1、故事點：代表了開發用戶所用故事所需的全部工作量，是團隊的估算必須考慮到影響工作量的所有因素。包括要開展的工作的數量、工作的復雜度、要開展的工作中存在的任何風險或不確定性。

2、故事線：指文藝作品或文章的主要脈絡，作品的情節發展，人物設置均以主線為基礎，為主線服務。一般文藝作品有除主線內容，也有輔線（也可稱支線）內容，輔線是在整本小說主要線索的發展中，發生的分支線索思路。

(5)故事點數使用什麼擴展閱讀

故事線作為主題展開的一種方式具有很多優點，它使展覽更具有吸引力，更能調動觀眾參與的積極性，調動觀眾的思維活動能力。同時各種展示方式也具有各自的優劣勢，需要我們更進一步的研究，取長補短。

目前狹義「故事線」的展覽，在世界范圍內還不是很多，大家都在探索之中。希望有更多的人參與到這種設計中來，使這種主題展開方式進一步完善，得到更好的應用。

狹義故事線的展示方式還在應用和發展之中，雖然還有很多問題需要解決，但是由於它的趣味性和相對的唯一性，相信人們不會停止對它的思考和嘗試。隨著實踐經驗的積累，智慧的發揮，現在認為難於解決的問題，將來或許就會找到適當的解決辦法。

⑥ 繪本故事的點讀法是指什麼

點讀是指親子指讀

1、請調整好圓茄寶貝的坐姿，小背挺挺直哦！

2、請家長們引導幼兒左手放於書的左下方，右手握拳，伸出食指放於標記好的點上，從兒歌標題開始，指一個，讀一個。

數的點數

點數的方法和指讀的方法一樣，左手放於書的左下方，跡攜右手握拳，食指放於點下面 點一個數一個。點數完後記得要引導寶貝說「數到幾就姿腔伏是幾」哦！

塗色教程

左手放於書的左下方，右手的大拇指、食指、中指握好油畫棒。油畫棒不宜過長或過短，引導寶貝塗色時從左往右或從上往下塗。盡量不要塗到線條外面去喲！寶貝，加油呀！