故事点数使用什么

① 用户故事与敏捷方法之三-----什么时候使用用户故事

上两篇阐释了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、请家长们引导幼儿左手放于书的左下方，右手握拳，伸出食指放于标记好的点上，从儿歌标题开始，指一个，读一个。

数的点数

点数的方法和指读的方法一样，左手放于书的左下方，迹携右手握拳，食指放于点下面 点一个数一个。点数完后记得要引导宝贝说“数到几就姿腔伏是几”哦！

涂色教程

左手放于书的左下方，右手的大拇指、食指、中指握好油画棒。油画棒不宜过长或过短，引导宝贝涂色时从左往右或从上往下涂。尽量不要涂到线条外面去哟！宝贝，加油呀！